state-hub/workplans/STATE-WP-0080-register-project-flavor-awareness.md

---
id: STATE-WP-0080
type: workplan
title: "statehub register: stop repo scaffolding, hand off to repo-manager"
domain: infotech
repo: state-hub
status: finished
owner: codex
topic_slug: infotech
created: "2026-08-16"
updated: "2026-08-19"
parent_project: prj-state-hub-retirement
parent_workplan: SHR-WP-0001
related:
  - RMGR-WP-0004
  - STATE-WP-0079
  - CFED-WP-0001
  - SHR-WP-0001
state_hub_workstream_id: "bbfce36a-0b19-462f-af78-167f9eb89b86"
---

# statehub register: stop repo scaffolding, hand off to repo-manager

## Goal

Stop `statehub register` from producing non-conformant repository files, and
hand repository scaffolding and standards conformance to `repo-manager` — where
decision `747011c6` places them.

**This workplan does not implement flavor awareness.** That is `RMGR-WP-0004`.
The state-hub side is a guard, a delegation, and a clean exit.

## Why this changed shape

Drafted 2026-08-16 as a full flavor-awareness implementation inside
`statehub_register.py`; retargeted the same day after decision `747011c6`:

> Hubs are registers: they index and project repository-owned records. They do
> not scaffold, template, or rewrite repository files. Repo Manager owns
> repository representation and governed mutation, and therefore owns the
> standards repositories must comply with.

Implementing here would have built the capability twice, inside the component
being retired under `STATE-WP-0079`, and deepened exactly the boundary violation
the hub refactor exists to remove. The originating residual (`SHR-WP-0001-T01`)
is unchanged; only its owner is.

Tasks T05–T08 below are `cancel`led with pointers to their `RMGR-WP-0004`
successors. They are retained rather than deleted so the handoff is legible.

## The defect being contained

`statehub_register.py` has no reference to `.repo-classification.yaml`,
`category`, or `repo_flavor` in 872 lines, so it cannot distinguish a project
repository from a durable product repository. It therefore:

- writes `INTENT.md` unconditionally (`:248`) and treats missing intent as a hard
  error (`:786`–`:790`), though `project-repository-flavor_v0.1` calls shipping
  both `INTENT.md` and `GOAL.md` an anti-pattern and forbids requiring
  `INTENT.md` on `prj-` repos;
- derives the workplan prefix from the slug (`:78`, `_default_wp_prefix`),
  yielding `PRJ-WP-` for every project repo, so all `prj-` repos collide;
- writes a generic `{PREFIX}-0001-statehub-bootstrap.md` (`:269`) that competes
  with the project's real foundation workplan.

Hit twice: `prj-state-hub-retirement` and `prj-canon-federation`, both requiring
manual deletion after registration.

## Guard against non-conformant scaffolding

```task
id: STATE-WP-0080-T01
status: done
priority: high
state_hub_task_id: "65c52600-15fe-45bd-82b1-dfeff54698af"
```

Add a minimal flavor guard to the register path — detect project flavor from
`.repo-classification.yaml` `category`, `GOAL.md` `repo_flavor`, or the `prj-`
slug prefix, and on a match **refuse to scaffold**, with a message pointing at
`repo-manager`, rather than writing files the standard forbids.

Deliberately a refusal, not an implementation: a partial flavor-aware templating
path here would become a second source of truth competing with `RMGR-WP-0004`.

Durable-repo behaviour is untouched.

**Result (2026-08-18):** `statehub register` exits before writing files when any
of those three signals match. Message points at
`rmgr scaffold --path <repo> --flavor project --wp-prefix <PREFIX>-WP`.
Durable path (`write_registration_files`) is unchanged.

## Delegate registration scaffolding

```task
id: STATE-WP-0080-T02
status: done
priority: high
state_hub_task_id: "ab1e079c-b36f-4bfc-a9fd-fb43f7f93924"
```

Once `RMGR-WP-0004-T03` lands, route scaffolding through Repo Manager instead of
refusing, using the dual-run strangler pattern already proven in `RMGR-WP-0002`
and `RMGR-WP-0003`. Hub-side registration keeps only what a register legitimately
does: record the repo, its identity, and its host path.

Coordinate the cutover point with `RMGR-WP-0004-T05`.

**Opened (2026-08-18):** T01 guard is live and `RMGR-WP-0004-T03` (`rmgr scaffold`)
has landed. Ready to replace the refusal with a delegated scaffold call.

**Result (2026-08-18):** `statehub register` on a project-flavor checkout:
refuses without `--wp-prefix` if `GOAL.md` is missing (T01); with
`--wp-prefix` calls `rmgr scaffold` via the dual-run adapter and skips
`write_registration_files`; if `GOAL.md` already exists, registers the
repo + host path only. Durable repos still use hub templating.

## Correct the inventory disposition

```task
id: STATE-WP-0080-T03
status: done
priority: medium
state_hub_task_id: "91cb1a33-7748-4d65-bfbc-bad21234e364"
```

Confirm the register/scaffolding capability is dispositioned `move` →
`repo-manager` in `prj-state-hub-retirement/inventory/`, not `keep`. If it is
recorded as `keep`, correct it and cite decision `747011c6` — `SHR-INV-0001` is
the retirement lane's source of truth, and a stale disposition would resurrect
the boundary violation during cutover.

**Result (2026-08-18):** Already `move`. `jobs-callers-ops.yaml`
`caller:custodian-cli` (`custodian_cli / statehub register`) is
`disposition: move`, `owner: repo-manager`, capability `repo-onboarding`.
No inventory edit required.

## Moved: remove the templating path

```task
id: STATE-WP-0080-T04
status: cancel
priority: low
state_hub_task_id: "342aa5e8-96d0-4832-be60-f48815a86f71"
```

After delegation is live and `RMGR-WP-0004-T06` compatibility tests pass, delete
the templating code from `statehub_register.py` — `INTENT.md` generation, the
`AGENTS.md` / `CLAUDE.md` / `.custodian-brief.md` templates, `project_rules/`,
and bootstrap-workplan generation.

Sequence behind `STATE-WP-0079`'s strangler so removal lands with the rest of the
retirement rather than as an isolated breaking change.

**Readiness audit (2026-08-19):** Delegation remains live and the State Hub
registration regression suite passes (`20 passed`). Repo Manager's focused
scaffold/standards suite also passes (`11 passed`), but `RMGR-WP-0004-T06`
correctly remains `wait`: it does not yet test byte-identical durable output
against the State Hub path or idempotent re-scaffolding. `STATE-WP-0079-T03` is
now recorded done because T01/T02 above supply its project/`GOAL.md` adapter;
the broader `STATE-WP-0079-T04` move/replace slice is still `todo`. Do not
delete this path until both gates close.

**Cancelled (2026-08-19) — moved to `STATE-WP-0079-T04`.** Both gates above are
still open, and this task always specified that removal should land inside
`STATE-WP-0079`'s strangler rather than as an isolated breaking change. Holding
`STATE-WP-0080` open to wait on another workplan's slice adds no information:
the removal is now recorded where it will actually be executed, alongside the
other move/replace slices and their compatibility tests.

The guard and the delegation — this workplan's own contribution — are live and
unchanged. The templating code in `statehub_register.py` is dead-but-present
until `RMGR-WP-0004-T06` proves byte-identical durable output.

## Moved: generated templates and briefs

```task
id: STATE-WP-0080-T05
status: cancel
priority: medium
state_hub_task_id: "03224fa5-56f1-4e32-bc2e-40457dceb9cc"
```

Cancelled — moved to **`RMGR-WP-0004-T04`** by decision `747011c6`.

Worth carrying forward explicitly: `make update-agent-instructions` runs
fleet-wide and shares the flavor-blind templates, so it silently re-breaks
conformant `prj-` repos on every run. That is a larger blast radius than first
registration, and it must not be lost in the handoff.

## Moved: conformance check

```task
id: STATE-WP-0080-T06
status: cancel
priority: low
state_hub_task_id: "47adb8e3-2a03-45b9-9647-fc4e42c58cd1"
```

Cancelled — moved to **`RMGR-WP-0004-T02`** by decision `747011c6`.

Conformance checking is the clearest case for the new boundary: judging whether a
repository satisfies its standard is repository representation, not hub
projection. Repo Manager exposes it as a command and a contract; the hub consumes
the result rather than computing it.

## Moved: tests

```task
id: STATE-WP-0080-T07
status: cancel
priority: medium
state_hub_task_id: "c056b8fd-d91b-4cf0-973c-d74d8e718dd1"
```

Cancelled — moved to **`RMGR-WP-0004-T06`** by decision `747011c6`.

The byte-identical-output regression guard for durable repos stays essential:
the handoff must not change what ordinary repositories receive.

## Superseded: carry the fix forward

```task
id: STATE-WP-0080-T08
status: cancel
priority: medium
state_hub_task_id: "15eca52e-7c3b-40a7-b2a8-38b0313f57a8"
```

Cancelled — superseded by decision `747011c6`, which answered this task's open
question outright. It asked whether `repo-manager` was close enough to take the
work; the decision settled that repository standards belong there regardless of
timing, and `RMGR-WP-0004` now carries the whole implementation.

Retained as the record of where the retarget originated.

## Outcome

Closed 2026-08-19. The defect is contained: `statehub register` no longer writes
non-conformant files into project-flavor repositories, and fresh project repos
are scaffolded by `rmgr scaffold` through the dual-run adapter. Repository
standards and representation now sit with `repo-manager`, per decision
`747011c6`.

| Task | Disposition |
| --- | --- |
| T01 guard | done |
| T02 delegation | done |
| T03 inventory disposition | done (already correct) |
| T04 templating removal | moved to `STATE-WP-0079-T04` |
| T05–T08 | moved to `RMGR-WP-0004-T02/T04/T06`, or superseded |

Nothing in this workplan remains executable here.

## Projection note (2026-08-25)

Closing this on the hub exposed a duplicate registration. The file carried
`03f38314`, minted by the retired local hub; central held a **different** record
for the same file, `bbfce36a` — `ADR-010`'s "same filename, different UUID"
class. The file now carries central's identifier, because central is
authoritative (`ADR-010` decision 1) and decision 6 says to mitigate by changing
the repository file rather than editing central. The cache-side identifier dies
with the cache.

Central's workplan status is now `finished`, matching this file.

**Its task projection is still the superseded draft.** Central holds the eight
pre-retarget tasks — "Detect repository flavor", "Fix workplan prefix
inference", "Scaffold GOAL.md instead of INTENT.md", "Decide the bootstrap
workplan" — four of them still open, because central never saw the 2026-08-16
retarget. None of this file's own task identifiers exist on central.

That is left deliberately rather than repaired here: re-registering these tasks
would add eight new records alongside the eight stale ones. Resolving duplicate
task identities belongs to `CUST-WP-0068` (T05/T06), which exists for exactly
this class.

**Until then, treat central's open tasks on this workplan as superseded.** The
work they name moved to `RMGR-WP-0004`; nothing here is owed.