Policy authority consolidation inventory¶

This document freezes the first cross-branch inventory used by ADR-0005. It is an audit input, not a second policy authority. The semantic rules remain in their canonical policy or repository-local sources until later migration pull requests move them deliberately.

Frozen source revisions¶

The initial inventory is based on these exact branch revisions:

Later audits must record a new snapshot instead of silently treating changed branch tips as part of this inventory. Paths listed below are therefore paths at those frozen revisions, not statements about the current repository tree. In particular, the historical skills/bootstrap-agent-policy/** trust seed was later superseded by the single skills/agent-policy/** skill under ADR-0007.

Classification test¶

For every normative statement, classify ownership in this order:

1. Artifact-independence test. Would the requirement retain substantially the same meaning for a Web application, Agent Skill, CLI, library, service, or other repository type? If no, classify it as artifact-contract or repository-policy.
2. Engine-independence test. Would the requirement retain substantially the same meaning when followed by a different coding agent, general-purpose agent, automated reviewer, or a human following the same procedure? If no, classify it as adapter.
3. Context test. Is it artifact- and engine-independent but applicable only in a named operational situation such as pull-request review or external-artifact intake? If yes, classify it as context-policy; otherwise it is a shared-policy candidate.
4. Repository-identity test. Does the rule depend on local paths, branch identities, schemas, profiles, publication boundaries, release descriptors, or maintenance invariants? If yes, keep that part as repository-policy even if a more general rule is shared.
5. Normativity test. Does the statement actually impose an obligation or prohibition? Rationale, examples, historical records, and future proposals are explanatory and do not become competing authorities.

A mixed document is split conceptually at statement level. The document itself is not assigned one ownership class when different sections have different authorities.

policy branch¶

Existing shared corpus¶

The current policy/core/*.md, policy/security/*.md, and policy/artifacts/*.md files are the primary existing shared-policy or context-policy candidates. The current core profile already selects twelve atomic core modules. These files require a later atomicity and scope audit, but they are already close to the target one-rule-per-file model.

Policy-repository maintenance material¶

The following sources contain normative material about maintaining the policy toolchain itself and therefore must not be mistaken for shared policy merely because they live on the policy branch:

skill branch¶

The skill branch contains the highest-priority duplicate-authority candidates.

The skill source repository is migrated before skill/template/. The copyable distribution is a separate artifact contract and must not change incidentally during source-policy consolidation.

webapp branch¶

The current webapp branch deliberately excludes coding-agent operating policy from the Webapp artifact contract. That boundary is preserved.

The root source repository may later adopt the policy toolchain for its maintainers, but template/ remains policy-neutral unless a separate reviewed distribution decision changes that contract.

First duplicate families to normalize¶

The first statement-level audit should prioritize these semantic families because they already appear in more than one branch:

Artifact-specific contracts may instantiate or enforce a general principle without becoming duplicate policy authority. For example, a Webapp release-evidence schema can enforce exact revision binding while the shared policy separately states how agents must report evidence. The audit must distinguish those layers rather than deleting domain contracts merely because they resemble a shared rule.

Estimated pull-request sequence¶

The current estimate is eight to ten reviewed pull requests:

1. Authority baseline (policy): ADR-0005, this frozen inventory, classification rules, and migration roadmap.
2. Atomic review policy (policy): decompose generic review semantics from the frozen Skill review document; reuse existing core/security rules rather than cloning them.
3. Context and adapter model (policy): add review-context selection and separate semantic rules from GitHub/Antigravity output rendering. This may require a configuration-schema version transition.
4. Conflict and provenance enforcement (policy): validate explicit overrides, canonical origins, duplicate authorities, and generated-output freshness.
5. Stable policy promotion (policy): promote one reviewed candidate full SHA using the existing two-step stable-release model.
6. Skill source adoption (skill): add the pinned policy configuration and Skill-source local policy, generate source-maintainer instructions/review output, and remove handwritten shared-policy duplicates.
7. Webapp source adoption (webapp): add pinned source-maintainer policy while preserving the policy-neutral Webapp artifact contract.
8. Policy self-hosting (policy): separate policy-repository maintenance rules from the shared corpus and consume the promoted shared policy for policy maintenance.
9. Skill distribution decision (skill, conditional): decide whether template/ should itself ship a pinned policy configuration; if yes, change and validate the distribution contract separately.
10. Follow-up cleanup/publication (conditional): remove obsolete explanatory duplicates or update cross-branch publication only when the preceding migrations prove the new authority graph is closed.

Items 9 and 10 are conditional. The core consolidation can complete in eight pull requests if no consumer-distribution change or separate cleanup PR is needed.

Completion evidence for this inventory phase¶

This phase does not claim that every normative sentence has already been extracted. It establishes the accepted classification model, fixed source revisions, high-risk source set, duplicate-family priorities, and bounded PR sequence. The next pull request performs the statement-level decomposition of generic review policy against these frozen inputs.