Inventory canonical documents and their owners #2675

Problem

The accepted Base governance design and implementation plan identify package 10 as a required deliverable. This issue translates that package into a reviewed, bounded issue/PR train; it does not authorize implementation before the issue reaches Ready.

Expected behavior

Build the evidence-backed inventory required before semantic drift checks. Crosswalk the PRD, area designs, detailed contracts, code/reference, user guides, README/FAQ, operations/security docs, decisions, release notes, examples, templates and derived artifacts to canonical owners. Identify migrations and revise the README last after canonical detail is in place. Record all organization repositories and distinguish the special .github profile and repos with no Project.

Scope and non-goals

Scope: Build the evidence-backed inventory required before semantic drift checks. Crosswalk the PRD, area designs, detailed contracts, code/reference, user guides, README/FAQ, operations/security docs, decisions, release notes, examples, templates and derived artifacts to canonical owners. Identify migrations and revise the README last after canonical detail is in place. Record all organization repositories and distinguish the special .github profile and repos with no Project.

Non-goals: Do not silently expand scope, activate unreviewed policy, mirror issue fields onto PRs, grant agents merge/release authority, or make changes outside the named affected areas. Any new product decision or materially new work gets a separate issue and decision record.

Affected areas

• docs/documentation inventory or governance docs, README, FAQ, PRD, docs index and repository profile matrix.
• Accepted source: governance design and implementation plan, PR #2664
• Parent tracker: #2665

Impact and evidence

1. Product intent: Implements only the accepted governance design and plan; any product-requirement change must be filed separately.
2. Architecture and contracts: Destination is the package-specific section of the merged governance design/implementation plan plus the affected canonical contract named above.
3. User guidance: The issue identifies likely guidance paths; the implementation PR must name updated user/FAQ/README paths or give a change-specific reason why none is affected.
4. CLI/API and reference: The affected-area list determines whether CLI/API/reference docs change; the implementation PR must cite the exact reference path or justify no impact.
5. Operations and safety: No privileged automation or merge authority is implied; the PR must list operational/security effects and any rollback.
6. Validation and testing: The issue lists the planned tests; the PR must report executed validation and explain any unavailable test.
7. Examples and downstream use: The implementation PR must identify affected examples/consumers or give evidence that this change has no downstream surface.
8. Governance and contributor process: This package changes or preserves the contributor/governance contract as described in Scope; links must point to the canonical rules.
9. Decision records: No new decision is accepted by this issue; any durable deviation requires a proposed decision record and explicit maintainer acceptance.
10. Release notes: The PR must include a user-facing release-note line or a reasoned none; this issue does not pre-decide that disposition.

These are issue-stage dispositions to refine during Triage. Before Ready, every category must have its exact destination or evidence-based no-impact reason; the PR repeats the ten-category evidence for actual changes.

Open questions

• None known. If implementation exposes an unresolved contract, return this issue to Triage and record the decision before implementation continues.

Plan

• S1: One focused PR for this issue. Use Fixes #N only if no additional slice is needed; if the maintainer approves multiple PRs, name each S1…Sn here before the first is opened and use Part of #N.
• Dependencies: the P1 issue
• Acceptance criteria:
• Each relevant document kind has a canonical location, accountable owner, consumers and update triggers.
• The inventory identifies duplicate/derived documents and states whether they must be migrated, generated or retired.
• The PRD is reviewed against product intent; any correction is a separate issue/PR.
• README revision is planned last and links to canonical detailed material.
• The repository inventory includes all 11 active org repos, with .github called out as issues-disabled and homebrew-base as having no Project/manifest.
• Validation:
• Cross-check inventory paths against tracked files and local links.
• Verify each listed repository and Project/profile claim against live GitHub and checkout metadata.
• Review owner and update-trigger coverage with maintainers.
• Risks and rollback: A static inventory can become stale; include ownership/update triggers and feed package 11. No canonical details are deleted until consumers are migrated.
• Decision impact: No decision is accepted merely by implementing the issue. Record the relevant accepted decision/ADR and file a superseding record if the maintainer approves a change.