<divclass="wrap"><header><divclass="eyebrow"><span>canon-project-repository-flavor</span><spanclass="stat">accepted · accepted-1</span><span>the-custodian</span><span>reviewed 2026-08-31</span><span>generated from canonical source — do not edit</span></div><h1>Project Repository Flavor (prj-) v0.1</h1><pclass="sub">Source: <code>the-custodian · canon/standards/project-repository-flavor_v0.1.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</code></p><pclass="sub">Review due: 2027-02-28</p></header><divclass="layout"><navclass="rail"aria-label="Sections"><ol><li><ahref="#purpose"><spanclass="n">·</span>Purpose</a></li><li><ahref="#when-to-use-a-project-repository"><spanclass="n">·</span>When to use a project repository</a></li><li><ahref="#naming"><spanclass="n">·</span>Naming</a></li><li><ahref="#authority-boundary"><spanclass="n">·</span>Authority boundary</a></li><li><ahref="#required-files"><spanclass="n">·</span>Required files</a></li><li><ahref="#lifecycle"><spanclass="n">·</span>Lifecycle</a></li><li><ahref="#residuals-before-completion"><spanclass="n">·</span>Residuals before completion</a></li><li><ahref="#completion-record"><spanclass="n">·</span>Completion record</a></li><li><ahref="#archive-procedure"><spanclass="n">·</span>Archive procedure</a></li><li><ahref="#workplan-and-agent-conventions"><spanclass="n">·</span>Workplan and agent conventions</a></li><li><ahref="#minimal-layout-example"><spanclass="n">·</span>Minimal layout example</a></li><li><ahref="#reference-instance"><spanclass="n">·</span>Reference instance</a></li><li><ahref="#conformance-checklist"><spanclass="n">·</span>Conformance checklist</a></li><li><ahref="#related"><spanclass="n">·</span>Related</a></li></ol></nav><main><sectionid="purpose"><h2>Purpose</h2>
<p>Define the durable <strong>project repository</strong> flavor used for complex cross-repository efforts: naming, required files, authority boundary, lifecycle, residual handoff, and archive procedure.</p>
<p>This standard implements and completes <strong>ADR-005</strong> (<em>Cross-Repo Workplans Live in Dedicated Project Repos</em>). It does <strong>not</strong> replace the Repo Classification Standard: project repositories still use <code>category: project</code> in <code>.repo-classification.yaml</code>.</p>
</section>
<sectionid="when-to-use-a-project-repository"><h2>When to use a project repository</h2>
<p>Create a project repository when <strong>all</strong> of the following hold:</p>
<ol><li>The work coordinates change across <strong>two or more</strong> functional repositories.</li><li>Binding the coordination workplan to any single product/tooling repo would misrepresent ownership or pollute that repo's history.</li><li>The effort has a <strong>bounded outcome</strong> with explicit success and retirement conditions (not an open-ended product roadmap).</li></ol>
<p>Do <strong>not</strong> create a project repository for:</p>
<ul><li>single-repo workplans;</li><li>small cross-cutting fixes that fit one lead repo's workplan plus dependency links;</li><li>durable products, libraries, or services (those use <code>INTENT.md</code> and ordinary product/tooling/research categories);</li><li>long-lived domain charters (those remain under <code>the-custodian/canon/projects/</code>).</li></ul>
</section>
<sectionid="naming"><h2>Naming</h2>
<divclass="scroll"><table><thead><tr><th>Element</th><th>Convention</th></tr></thead><tbody><tr><td>Git / local directory</td><td><code>prj-<kebab-slug></code></td></tr><tr><td>Hub <code>repo</code> slug</td><td>same as directory name</td></tr><tr><td>Workplan prefix</td><td>short uppercase prefix derived from the project, ending in <code>-WP-</code> (example: <code>SHR-WP-</code> for State Hub Retirement)</td></tr><tr><td>Classification</td><td><code>category: project</code></td></tr></tbody></table></div>
<p><strong>Canonical prefix is <code>prj-</code>.</strong> ADR-005's illustrative <code>proj-</code> form is superseded for new repositories. Do not invent parallel prefixes (<code>project-</code>, <code>xrepo-</code>, …).</p>
<p>Slug rules:</p>
<ul><li>lowercase kebab-case;</li><li>outcome-oriented (<code>prj-state-hub-retirement</code>), not a random ticket id;</li><li>stable for the life of the project (rename only with an explicit migration note in <code>history/</code>).</li></ul>
<divclass="scroll"><table><thead><tr><th>Concern</th><th>Owner</th></tr></thead><tbody><tr><td>Project goal, success gates, retirement conditions</td><td>project repo (<code>GOAL.md</code>)</td></tr><tr><td>Architecture decisions, sequencing, dependency map, migration ledger, risks, consolidated evidence</td><td>project repo</td></tr><tr><td>Cross-repo workplans that coordinate the effort</td><td>project repo (<code>workplans/</code>)</td></tr><tr><td>Production implementation, tests, deployables</td><td><strong>participating functional repositories</strong></td></tr><tr><td>Per-repo implementation workplans and local evidence</td><td>each functional repository</td></tr><tr><td>Durable post-project standards and ADRs</td><td>permanent homes (<code>the-custodian</code> canon, or the owning product/tooling repo)</td></tr></tbody></table></div>
<p><strong>Hard rules:</strong></p>
<ol><li>Project repositories <strong>MUST NOT</strong> host production implementation code for the systems being changed.</li><li>Project workplans <strong>link</strong> child workplans by stable ID; they <strong>MUST NOT</strong> copy or replace child task lists.</li><li>The hub remains a read/index layer; work records originate as files (ADR-001).</li><li>Results of the project live primarily in the modified functional repositories and promoted canon. The project repo is coordination + provenance.</li></ol>
<divclass="scroll"><table><thead><tr><th>Path</th><th>Required</th><th>Role</th></tr></thead><tbody><tr><td><code>GOAL.md</code></td><td><strong>yes</strong></td><td>Outcome, invariants, success gates, project retirement conditions. <strong>Replaces <code>INTENT.md</code> for this flavor.</strong></td></tr><tr><td><code>SCOPE.md</code></td><td><strong>yes</strong></td><td>Project authority, participating repos, in/out of scope, work-record rule.</td></tr><tr><td><code>README.md</code></td><td><strong>yes</strong></td><td>Short entry point linking <code>GOAL.md</code>, <code>SCOPE.md</code>, genesis/history, active workplans.</td></tr><tr><td><code>AGENTS.md</code></td><td><strong>yes</strong></td><td>Agent session protocol for this project (orient → work → close; hub integration).</td></tr><tr><td><code>.repo-classification.yaml</code></td><td><strong>yes</strong></td><td><code>category: project</code> plus domain / capability tags for the <em>effort</em>.</td></tr><tr><td><code>workplans/</code></td><td><strong>yes</strong></td><td>At least one foundation workplan; prefix unique to the project.</td></tr><tr><td><code>history/</code></td><td>recommended</td><td>Genesis and significant milestones (why the project exists).</td></tr><tr><td><code>WORK-RECORDS.md</code></td><td>generated</td><td>Hub index; do not hand-edit.</td></tr><tr><td><code>.custodian-brief.md</code></td><td>generated</td><td>Offline orientation brief.</td></tr></tbody></table></div>
<p>Durable product and tooling repositories explain <strong>why they exist</strong> with <code>INTENT.md</code>. Project repositories are temporary and outcome-bounded; they use <strong><code>GOAL.md</code></strong> instead.</p>
<p><code>GOAL.md</code> MUST include:</p>
<ol><li><strong>Outcome</strong> — what success looks like in one short section.</li><li><strong>Invariants</strong> — rules that must hold during the project.</li><li><strong>Success gates</strong> — checkable conditions for “goal achieved”.</li><li><strong>Project retirement</strong> — conditions under which <em>this repository</em> may be archived (usually: gates met + residuals handed off + durable decisions promoted).</li></ol>
<p>Recommended frontmatter:</p>
<pre>---
repo: prj-<slug>
repo_flavor: project
project_status: draft | active | completed | archived
started: "YYYY-MM-DD"
reviewed: "YYYY-MM-DD"
---</pre>
<p><strong>Anti-pattern:</strong> shipping both <code>INTENT.md</code> and <code>GOAL.md</code> in a <code>prj-</code> repo. If a durable intent emerges, promote it into a permanent repository's <code>INTENT.md</code> (or canon) and keep the project goal as the temporary outcome document.</p>
<h3>Relation to durable <code>INTENT.md</code></h3>
<divclass="scroll"><table><thead><tr><th>Repository kind</th><th>Purpose document</th></tr></thead><tbody><tr><td>product / tooling / research / business / experimental</td><td><code>INTENT.md</code></td></tr><tr><td><strong>project (<code>prj-</code>)</strong></td><td><strong><code>GOAL.md</code> only</strong></td></tr></tbody></table></div>
<p>Tooling that scaffolds repositories (e.g. <code>statehub register</code>) MUST treat <code>GOAL.md</code> + <code>repo_flavor: project</code> as sufficient purpose documentation for <code>prj-</code> repos and MUST NOT require inventing an <code>INTENT.md</code> that pretends the project is a permanent product.</p>
</section>
<sectionid="lifecycle"><h2>Lifecycle</h2>
<pre>draft → active → completed → archived</pre>
<divclass="scroll"><table><thead><tr><th>Status</th><th>Meaning</th><th>Repo / hub signals</th></tr></thead><tbody><tr><td><code>draft</code></td><td>Convention and foundation still forming; may not yet be registered</td><td><code>project_status: draft</code>; workplans often <code>proposed</code> / <code>ready</code></td></tr><tr><td><code>active</code></td><td>Coordination and child implementation in progress</td><td><code>project_status: active</code>; at least one workplan <code>active</code> or <code>ready</code></td></tr><tr><td><code>completed</code></td><td>All success gates have accepted evidence; residuals have live owners outside this repo</td><td><code>project_status: completed</code>; project workplans <code>finished</code> or cancelled with rationale</td></tr><tr><td><code>archived</code></td><td>Repository is read-only provenance</td><td>forge archive flag; hub repo/workplan <code>archived</code>; no normal writes</td></tr></tbody></table></div>
<p>Promotion rules:</p>
<ul><li><code>draft → active</code> when <code>GOAL.md</code> / <code>SCOPE.md</code> are reviewable and the foundation workplan is <code>ready</code> or <code>active</code>.</li><li><code>active → completed</code> only when <strong>every</strong><code>GOAL.md</code> success gate has accepted evidence <strong>and</strong> residuals are live work records elsewhere (see below).</li><li><code>completed → archived</code> after the completion record is written, durable decisions are promoted, and a final consistency/link check passes.</li></ul>
</section>
<sectionid="residuals-before-completion"><h2>Residuals before completion</h2>
<p>Actionable leftovers MUST NOT live only in finished workplan prose or <code>SCOPE.md</code>. Before any project workplan is set to <code>finished</code>, and again before <code>project_status: completed</code>, each residual becomes a <strong>live work record</strong> outside the closing narrative:</p>
<ul><li>intake with <code>origin: residual</code> + <code>origin_ref: <WP-id></code>, or</li><li>a next workplan / decision / engagement / register-entry in a permanent repo.</li></ul>
<p>Canon: <code>work-record-types_v0.1.md</code> § Residuals. Fleet residual listing is a State Hub concern, not a project-local queue file.</p>
<p>Before archival, the project repository MUST contain a completion record (recommended path: <code>history/YYYY-MM-DD-completion.md</code>) that lists:</p>
<ol><li>deployed or merged revisions that realize the outcome;</li><li>every participating repository touched, with links to merged PRs/commits or child workplan IDs;</li><li>promoted durable artefacts (canon paths, ADRs, standards);</li><li>migration and retirement evidence pointers (counts, cutover windows, backups);</li><li>residual work-record IDs and their owning repos;</li><li>rollback expiry or remaining operational obligations, if any.</li></ol>
<ol><li>Verify all success gates and retirement conditions in <code>GOAL.md</code>.</li><li>Confirm residuals are live and owned outside this repository.</li><li>Promote remaining durable decisions/standards to permanent homes; leave pointers from the project repo.</li><li>Finish or cancel project workplans; move finished files to <code>workplans/archived/YYMMDD-<id>-<slug>.md</code> per workplan convention.</li><li>Write the completion record.</li><li>Set <code>project_status: archived</code> in <code>GOAL.md</code> frontmatter.</li><li>Run <code>statehub fix-consistency</code> (or equivalent) so the hub reflects finished workplans and the archived status.</li><li>Archive the repository in the forge (read-only); do <strong>not</strong> delete it.</li><li>Optionally mark the hub registration archived / read-only.</li></ol>
<p><strong>Archive means read-only provenance, never deletion.</strong> Historical evidence and coordination narrative remain queryable.</p>
</section>
<sectionid="workplan-and-agent-conventions"><h2>Workplan and agent conventions</h2>
<ul><li>Workplan files: <code>workplans/<PREFIX>-WP-NNNN-<slug>.md</code> with fleet status vocabulary (<code>proposed</code> … <code>archived</code>).</li><li>Session start order for agents: <code>GOAL.md</code> → <code>SCOPE.md</code> → genesis/history → active workplans (see project <code>AGENTS.md</code>).</li><li>Progress and task status follow ordinary State Hub / fix-consistency rules.</li><li>Ad-hoc low-risk fixes may use <code>workplans/ADHOC-YYYY-MM-DD.md</code> with canonical id <code>{PREFIX}-WP-ADHOC-YYYY-MM-DD</code>; anything multi-step belongs in a normal workplan.</li></ul>
<p>The first repository under this standard is <code>prj-state-hub-retirement</code> (State Hub retirement / hub-core consolidation). Use it as the structural reference when scaffolding later <code>prj-</code> repos; do not copy its domain-specific content.</p>
<p>A repository conforms to the <code>prj-</code> flavor when:</p>
<ul><li>[ ] Named <code>prj-<slug></code> and classified <code>category: project</code>.</li><li>[ ] Has <code>GOAL.md</code> with outcome, invariants, success gates, and retirement.</li><li>[ ] Has no durable-product <code>INTENT.md</code> (or documents an explicit temporary exception during migration of a mis-scaffolded repo).</li><li>[ ] Has <code>SCOPE.md</code>, <code>README.md</code>, <code>AGENTS.md</code>, and <code>.repo-classification.yaml</code>.</li><li>[ ] Hosts coordination workplans only; implementation lives in child repos.</li><li>[ ] Links child workplans by ID rather than duplicating their tasks.</li><li>[ ] Defines archive/completion discipline consistent with this standard.</li><li>[ ] On completion, writes a completion record and archives read-only.</li></ul>
</section>
<sectionid="related"><h2>Related</h2>
<ul><li>ADR-001 — Workplans and Work Items Are Repository Artefacts</li><li>ADR-005 — Cross-Repo Workplans Live in Dedicated Project Repos</li><li><code>repo-classification-standard_v1.0.md</code> — <code>category: project</code></li><li><code>work-record-types_v0.1.md</code> — residuals and work-record kinds</li><li><code>workplan-terminology-fleet_v0.1.md</code> — workplan vocabulary</li></ul>
