feat: advance repository records and provenance

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d

docs/repository-classification-contract_v1.0.md

@@ -0,0 +1,34 @@
+---
+id: RMGR-CONTRACT-CLASSIFICATION-0001
+type: contract
+title: "Repository classification receiving contract"
+version: "1.0"
+status: active
+created: "2026-08-21"
+updated: "2026-08-21"
+workplan_task: RMGR-WP-0008-T06
+canon_source: the-custodian/canon/standards/repo-classification-standard_v1.0.md
+---
+
+# Repository classification receiving contract v1.0
+
+Repo Manager reads `.repo-classification.yaml` as repository authority and
+validates it against version 1.0 of the Custodian's Repo Classification
+Standard. It publishes the validated value in repository snapshots; downstream
+topic or domain services consume that projection and do not replace the file.
+
+The required scalar fields are `category` and `domain`. Optional list fields
+are `secondary_domains`, `capability_tags`, `business_stake`, and
+`business_mechanics`. Controlled values and the tag syntax are in the companion
+machine-readable contract.
+
+Invalid classifications fail observation with field-specific errors. Repo
+Manager does not coerce unknown values, infer the primary domain from technical
+tags, or write classification during observation. A canon vocabulary change
+requires a new contract version and implementation update; the canon remains
+the source of meaning.
+
+Boundary with hub-core: Repo Manager owns file validation and the repository
+projection. Hub-core may aggregate those projections into topics and fleet
+navigation, but does not become classification authority.
+

docs/repository-classification-contract_v1.0.yaml

@@ -0,0 +1,53 @@
+id: RMGR-CONTRACT-CLASSIFICATION-0001
+version: "1.0"
+status: active
+authority_path: .repo-classification.yaml
+canon_source: the-custodian/canon/standards/repo-classification-standard_v1.0.md
+required:
+  category:
+    - experimental
+    - research
+    - project
+    - tooling
+    - product
+    - business
+  domain:
+    - infotech
+    - financials
+    - communication
+    - consumer
+    - health
+    - industrials
+    - energy
+    - utilities
+    - materials
+    - realestate
+    - crypto
+    - agents
+    - space
+    - government
+optional_lists:
+  secondary_domains: domain
+  capability_tags: lowercase-kebab-case
+  business_stake:
+    - execution
+    - intelligence
+    - finance
+    - legal
+    - sales
+    - experience
+    - technology
+    - operations
+    - product
+    - people
+    - procurement
+    - sustainability
+    - automation
+  business_mechanics:
+    - intention
+    - control
+    - coordination
+    - operation
+    - adaptation
+projection_owner: repo-manager
+aggregation_owner: hub-core

docs/repository-standards_v0.1.md

@@ -70,3 +70,43 @@ one deduplicated request to `repo-manager`; repeated `fix-consistency` runs cann
 resolve the gate and waste execution time.
 
 Work: `RMGR-WP-0005-T01`.
+
+## Coding-assistant commit provenance
+
+Interactive coding assistants keep the supervising human as Git author and add
+standard trailers to the commit message:
+
+```text
+Assistant: codex
+Assistant-Model: gpt-5
+Assistant-Process: 12345@workstation
+Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d
+```
+
+`Assistant` is required when the hook identifies an assistant. Model, process,
+and session are emitted when known. Process identifiers include the host because
+PIDs are host-local; session identifiers are opaque and must not contain
+credentials. `Assistant-Model` is the canonical model attribution;
+assistant-specific `Co-Authored-By` prompt conventions are deprecated because
+the human remains the author and the model is not a co-owner.
+
+The hook accepts stable, tool-neutral overrides `ASSISTANT_NAME`,
+`ASSISTANT_MODEL`, `ASSISTANT_PROCESS`, and `ASSISTANT_SESSION`. It also performs
+best-effort detection for Claude Code, Codex, and Grok variables. Tool-specific
+variables are compatibility inputs, not this contract: launch wrappers should
+set the neutral values when an exact model or stable session is required.
+
+Install the governed hook and derive a report from repository history:
+
+```bash
+rmgr assistant-provenance install
+rmgr assistant-provenance report --path .
+```
+
+The `prepare-commit-msg` hook never rejects a commit, does nothing for a human
+environment, and does not duplicate existing trailer tokens. Known automation
+with its own Git identity, currently `custodian-sync`, does not need assistant
+trailers. History before the configured cutover commit stays unattributed; it
+must not be inferred from timestamps or writing style.
+
+Work: `RMGR-WP-0009`.

docs/work-record-uuid-derivation_v1.md

@@ -0,0 +1,46 @@
+---
+id: RMGR-CONTRACT-UUID-0001
+type: contract
+title: "Deterministic work-record UUID derivation"
+version: "1"
+status: active
+created: "2026-08-21"
+updated: "2026-08-21"
+workplan_task: RMGR-WP-0005-T03
+---
+
+# Work-record UUID derivation v1
+
+For a live workplan or task, implementations derive the existing
+`state_hub_workstream_id` or `state_hub_task_id` field with UUIDv5:
+
+```text
+namespace UUID: a4058507-5c4a-5a00-ab06-fffa4fb46009
+name bytes:      UTF-8(<fleet-namespace> + "\n" + <canonical-identifier>)
+```
+
+The fixed UUID is itself UUIDv5(URL,
+`https://helixforge.org/repo-manager/work-record/v1`), but consumers use the
+fixed value above rather than recomputing it. Fleet namespace names are
+lowercase DNS-label style. Canonical identifiers are
+`PREFIX-WP-NNNN` or `PREFIX-WP-NNNN-TNN`.
+
+The repository is not a namespace. Under the current N1 posture, the fleet must
+declare one shared namespace name before activation. A future fork uses its own
+namespace name and therefore derives different UUIDs for the same unqualified
+identifier, as required by ADR-011.
+
+Only proposed, ready, active, blocked, or backlog workplans and their unfinished
+tasks enter the live derivation set. Finished and archived history retains its
+minted identifiers. Before creating, re-deriving, or unarchiving a record, run
+the live-collision preflight. Any duplicate is a hard refusal; it is never
+silently disambiguated with a repository slug.
+
+```bash
+rmgr identifier derive --namespace <fleet-namespace> --record-id RMGR-WP-0005
+rmgr identifier preflight --root /path/to/fleet
+```
+
+Activation and bulk migration remain separate governed steps. Publishing this
+function does not retroactively rewrite existing identifiers.
+