Repository integration layer to the helic-forge agentic software factory and operations facility.
tegwick
bdb981be2b
backing_filename is what lets the read model tell a file-backed workplan from a hub-only orphan. It is written by PUT /workplans/index/bindings, which fix-consistency calls for workplans that already carry a UUID — but the registrar mints the UUID afterwards, so a freshly registered workplan stayed unbound until someone happened to run fix-consistency a second time. Nobody did: 278 of 800 workplans on central recorded no backing file, including four active and four ready. ADR-010 predicted this as the "broken links" class. The registrar now syncs bindings after minting, and on the noop path too — otherwise a record whose earlier bind failed stays unbound forever, because every later run returns early. Binding never fails the registration: the identifiers are already minted and committed, and a bind can be retried. Status is sent only when already canonical. The binding schema validates against the enum without normalising, so one legacy value 422s the whole batch; omitting beats guessing a mapping that could drift from canon. Refs CUST-WP-0068-T07 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2583210@bnt-lap001 Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006 |
||
|---|---|---|
| .githooks | ||
| config | ||
| decisions | ||
| docs | ||
| history | ||
| intakes | ||
| interfaces | ||
| schemas | ||
| specs | ||
| src/repo_manager | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| INTENT.md | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
repo-manager
Repository integration boundary for the HelixForge agentic software development and operations environment.
Repositories remain independently valid and usable. Repo Manager gives each repository a stable representation inside HelixForge, observes its declared state, performs governed repository changes, and hosts its coach/lead/director agent representation.
| Flavor | tooling (not a domain hub) |
| Domain | infotech |
| Parent project | prj-state-hub-retirement |
| Foundation WP | RMGR-WP-0001 |
Start with INTENT.md, SCOPE.md, and the genesis record.
Architecture:
- Repository representation v0.1
- Observation and command contracts v0.1
- State Hub extraction inventory v0.1
- ADR-001 Implementation foundation
- Railiance app deployment guide (
RMGR-WP-0006) - Repository standards v0.1 (
RMGR-WP-0004) - Repository registers v0.1 (
RMGR-WP-0008)
make install # or: uv pip install -e ".[dev]"
make test
rmgr --version
rmgr observe --path .
rmgr reconcile --path .
rmgr update-task-status --path . --task-id <ID> --status progress
rmgr workplan create --path . --workplan-id EX-WP-0001 --title "Example" --goal "Deliver X."
rmgr workplan update --path . --workplan-id EX-WP-0001 --status active
rmgr workplan delete --path . --workplan-id EX-WP-0001 --confirm # archives; never erases
rmgr register put --path . --kind technical-debt --entry-id TD-001 \
--title "Debt item" --data-json '{"severity":"high"}'
rmgr register list --path . --kind technical-debt
rmgr rapp wrap --path ../rapp-some-app --app some-app \
--ownership-repo some-app --from-app ../some-app
rmgr rapp validate --path ../rapp-user-engine --family-root ..
rmgr rapp place --path ../rapp-some-app --reef reef-railiance
rmgr conform --path .
rmgr prefix-uniqueness --root ..
rmgr scaffold --path ../prj-example --flavor project --wp-prefix EX-WP --no-commit
Vertical-slice proof: docs/evidence/t05-vertical-slice.md.
Direction: