docs: RMGR-WP-0008 receiving surface for work records and registers

STATE-WP-0079's cutover slice plan assumed repo-manager could receive all 167
of its owned inventory items because RMGR-WP-0001/0002/0003 are finished.
Verified false: parse/ holds only workplan.py, the source tree has no
reference to sbom, repo_goal, contribution, technical_debt or
extension_point, and the State Hub adapter calls exactly three operations
(rm_update_task_status, rm_reconcile, rm_scaffold).

Of 425 inventory items roughly 6 can move today. This workplan builds the
surfaces the rest need: workplan write path, intake, decision, dependencies
and human-flag, the register spine, and the topic/classification contract.

A4 (owner-side UI) is deliberately left at wait -- rmgr is a CLI and those
views may belong to hub-core's projection layer; ownership should be decided
before anything is built.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-20 08:54:01 +02:00
parent c1a965284b
commit ebb1891b2d

View file

@ -0,0 +1,195 @@
---
id: RMGR-WP-0008
type: workplan
title: "Receiving surface for work records and repository registers"
domain: infotech
repo: repo-manager
status: proposed
owner: codex
topic_slug: infotech
created: "2026-08-20"
updated: "2026-08-20"
parent_project: prj-state-hub-retirement
parent_workplan: SHR-WP-0001
related:
- 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
```task
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
```task
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
```task
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
```task
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
```task
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
```task
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
```task
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