repo-manager/SCOPE.md

Scope

One-liner

Long-lived tooling component: repository representation, file-backed record indexing, consistency reconciliation, and governed repository control for HelixForge.

In scope

• Repository registration, identity, classification, and lifecycle.
• Local checkout, host-path, remote, revision, and synchronization awareness.
• Discovery, parsing, validation, and indexing of repository-owned records.
• Workplan, task, decision, capability, service, policy, and relationship declarations when their authoritative form is stored in a repository.
• Consistency reconciliation between files and replaceable projections.
• Controlled repository mutation through explicit commands and policy checks.
• Repository event emission, idempotency, audit evidence, and recovery.
• Repository-specific coach, lead, and director agent assignments.
• APIs and adapters through which hub-core addresses repositories (port.repo, port.work in the extension architecture).

Out of scope

• Cross-domain inboxes, conversations, and message routing: hub-core.
• General work or issues without a repository authority: issue-core.
• Recurring scheduling and workflow execution: activity-core.
• Authentication, user directories, and identity proofing: identity authorities.
• Authorization policy decisions: flex-auth or its successor.
• Credential custody: OpenBao/platform credential services.
• Git hosting: Forgejo or another source-code forge.
• Domain-specific operational, financial, security, or governance truth.
• A universal knowledge store or search engine.
• Hosting production domain-hub business data or operator consoles.

Coordination

Item	Location
Parent project	prj-state-hub-retirement
Stream	S1 in architecture/child-workplan-map_v0.1.md
Foundation workplan	RMGR-WP-0001
Disposition inventory	prj-state-hub-retirement/inventory/ (repo-* capabilities)

Initial extraction source

The first implementation may reuse proven State Hub behavior for repository registration, host paths, workplan parsing, consistency reconciliation, and file-backed status changes. Extraction must preserve behavior with compatibility tests while removing assumptions that Repo Manager owns cross-domain state.

API boundary

External consumers use versioned contracts. They must not depend on Repo Manager's persistence schema. Commands distinguish requested action from confirmed repository state; a successful command is not complete until the resulting repository revision and normalized event are recorded.

Implemented local reuse surfaces

• rmgr sync --path <checkout> --push is the normal file-record closeout: assign missing deterministic identifiers, verify the pushed Forgejo revision and primary checkout, then request central reconciliation. A queued receipt remains pending; repository files remain authoritative.
• rmgr provenance install configures the shared hook directory. The current .githooks/pre-commit composes the Custodian generated-only commit guard with staged-secret detection for its explicit checkout allowlist. It preserves the provenance hooks; local hooks remain bypassable.
• The generated-only guard implementation belongs to the-custodian/scripts/check_generated_only_commit.py. Sharing this hook does not generate indexes, prove fleet generator adoption, or prove a week without standalone generated commits (CUST-WP-0079-T05).
• registry/capabilities/capability.security.repository-secret-prevention.md declares the bounded source/CLI capability for reuse-surface. Its local checkout coverage and discovery maturity are distinct from fleet enforcement.

Per-repository Make targets and build pipelines own their generated artifacts. Repository reconciliation and hook installation do not transfer that ownership or establish a general generated-file pipeline.

Staged work-record generator adoption

The tracked .generated-work-records.json opts this repository into the shared pre-commit generation lane. make generated-work-records uses the isolated .generated-work-records.mk recipe and the Custodian adapter to render from staged Markdown with the existing State Hub renderer. make generated-work-records-check verifies the staged result without writes. Unstaged source edits are preserved; unstaged generated-file edits and unresolved conflicts stop the commit. The existing generated-only guard and secret scan remain in place. This adoption covers WORK-RECORDS.md only; other owner indexes retain their own generators. It makes no schedule or public-release change.