repo-manager/workplans/RMGR-WP-0008-work-record-and-register-receiving-surface.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	parent_project	parent_workplan	related
RMGR-WP-0008	workplan	Receiving surface for work records and repository registers	infotech	repo-manager	proposed	codex	infotech	2026-08-20	2026-08-20	prj-state-hub-retirement	SHR-WP-0001	STATE-WP-0079 RMGR-WP-0002 RMGR-WP-0003 RMGR-WP-0004 HUB-WP-0004

Receiving surface for work records and repository registers

Goal

Build the repo-manager surfaces that STATE-WP-0079's cutover slices need in order to move. Today most of those slices have nowhere to land, and that — not anything inside State Hub — is what blocks the retirement.

Why this exists

STATE-WP-0079-T02 produced a cutover slice plan (state-hub/docs/retirement-cutover-slice-plan.md) assigning all 425 SHR-INV-0001 items to slices. Its first owner-readiness pass read readiness off workplan status: RMGR-WP-0001/0002/0003 are finished, so all 167 repo-manager-owned items were marked receivable.

That was wrong, and the correction (2026-08-20) is the reason for this workplan. Verified against src/repo_manager/:

• parse/ contains only workplan.py
• rmgr subcommands are observe, reconcile, task-status, conform, prefix, scaffold, dual-run-status
• the source tree has no reference to sbom, repo_goal, contribution, technical_debt, or extension_point
• the State Hub adapter calls exactly three operations — rm_update_task_status, rm_reconcile, rm_scaffold

What RMGR-WP-0001/0002/0003 delivered is work-record dual-run for task status, repository observation, and scaffolding. Not a general work-record write path, and not a register surface at all.

Net effect: of 425 inventory items, roughly 6 can move today (slice A2a, task status + reconcile). The rest wait on surfaces built here or in hub-core.

Scope boundary

This workplan builds receiving surfaces in repo-manager. It does not change State Hub beyond the adapter calls that route to these surfaces.

Building any of this in State Hub instead is inadmissible under state-hub/policies/retirement-freeze.md: it would establish new permanent ownership in the component being retired, and would build the capability twice.

Per SCOPE.md, file-backed records in domain repos stay authoritative; these surfaces index and govern them, they do not become a second source of truth.

Workplan write path

id: RMGR-WP-0008-T01
status: todo
priority: high

Extend the work-record write path beyond task status to workplan create, update, status change, and delete. parse/workplan.py already reads workplans; this adds the governed mutation side and an rm_update_workplan counterpart to rm_update_task_status.

Unblocks slice A2b (~9 routes plus table:workplans).

Follow the RMGR-WP-0002 dual-run shape — writeback, reconcile, mutation meter — rather than inventing a second mechanism.

Intake records

id: RMGR-WP-0008-T02
status: todo
priority: medium

Add an intake parser and index entry kind, plus the write path for create, route, note, and close. Intake is the successor to the retired suggestion backlog, so this is the discovery surface's permanent home.

Unblocks slice A2c (9 items: 7 routes, table:intakes, table:intake_notes).

Decision records

id: RMGR-WP-0008-T03
status: todo
priority: medium

Add a decision parser, index entry kind, and write path including resolve.

Note the coupling: resolve_decision is one of only two write operations sanctioned against the hub in the fleet agent instructions. Whatever replaces it must keep that guarantee — agents rely on it being available and safe.

Unblocks slice A2d (8 items, including caller:agentic-resources).

Dependencies and human-flag records

id: RMGR-WP-0008-T04
status: todo
priority: low

Workplan dependency edges and human-intervention flags. Smallest of the work-record slices and the least coupled; a reasonable first cut if T01 proves too large to land in one piece.

Unblocks slice A2e (~6 items) and the dependency routes inside A2b.

Repository registers

id: RMGR-WP-0008-T05
status: todo
priority: high

The largest gap. Six registers with no counterpart in repo-manager at all:

Register	Items	Notes
sbom-inventory	10	lockfile ingest, licence report, copyleft detection
repo-goals	9
upstream-contributions	9
register-technical-debt	9	also backs dashboard UI feedback — check before moving
register-extension-points	6
register-entries	6	MCP tools only

Unblocks slice A3 (49 items).

Treat as one register spine with per-kind schemas rather than six unrelated features — they share repo scoping, append-mostly write patterns, and the same file-backed-authority rule.

Topic and classification contract

id: RMGR-WP-0008-T06
status: todo
priority: medium

observe/load_classification read .repo-classification.yaml today. Slice A5 (topic-spine, 8 items) is dispositioned replace, so it needs a published contract rather than a lift-and-shift of the hub's tables.

Coordinate with HUB-WP-0004: the topic spine sits on the boundary between repository classification (here) and cross-domain projection (hub-core).

Owner-side UI

id: RMGR-WP-0008-T07
status: wait
priority: low

Slice A4 (22 items, replace) assumes an owner-side dashboard. rmgr is a CLI; there is none, and it is not obvious there should be one — the work-coordination and repo views may belong to hub-core's projection layer instead.

Deliberately wait: settle ownership before building. Resolve with HUB-WP-0004 and record the outcome as a decision. Do not default to building a dashboard here just because the inventory named repo-manager.

Acceptance

• Workplan write path live, A2b routable through the adapter
• Intake and decision parsers + write paths live; resolve_decision guarantee preserved
• Register spine live, A3's six registers routable
• Topic/classification contract published and agreed with hub-core
• A4 ownership decided and recorded
• Compatibility tests per slice, matching the RMGR-WP-0002 evidence pattern