State what the fleet model achieves, before the per-type rules

[ptr727]

Adds a ## What It Achieves section between "What This Repo Is" and "How This Repo Operates", so a reader learns what the model buys before meeting the mechanics and the per-type rules.

The gap

The README went from what the repo holds straight into how it operates, then into the per-type rules. The objectives were real and consistently applied across every file here, and nowhere written down. A reader had to infer them from the machinery.

What lands

Eight objectives, each naming the machinery that delivers it so the claim is checkable rather than a slogan:

• Workflow consistency by contract, not by copying a YAML file: the fixed part is the orchestration seam, and what a repo builds inside it is its own, so a Hugo site and a NuGet package satisfy one contract without pretending to be one pipeline.
• Technical consistency the three surfaces share. The editor, the CLI, and CI read the same config, so a rule that holds in review holds everywhere.
• Best practices promoted once, in GOVERNANCE.md or CODESTYLE.md, rather than rediscovered and re-argued in the next repo.
• Feedback loops that close on the procedure, not the instance. A repo that cannot be stood up from the docs alone is a documentation defect.
• A new language or target is a spec change, with detection, checks, and carried files declared, then proven by a cold standup.
• Re-deployment measured and traceable, with staleness detected by content hash against the hub's own past revisions rather than a version stamp a repo can keep while editing underneath it.
• A fidelity table, below.
• The human/agent split, below.

The two that carry the weight

Every carried unit declares how much freedom it grants. This is the "must be exactly this / must do something but how is yours / yours entirely" distinction, and it already exists in spec/files.json as a declared field. The table just surfaces it:

Level	The obligation	Who owns the content
verbatim	Byte-identical to canonical, after governed normalization	The hub
interface	Honor a named contract, checked by name and wiring	The repo owns the body entirely
intent	Reach the same outcome, judged by meaning	The repo owns the wording and shape
presence	The unit exists	The repo owns all of it

The human contributes where domain expertise is decisive, and only there. The maintainer keeps what an agent cannot know or must not decide: creating a repository, granting a write outside the owner boundary, changing a ruleset, approving every merge, and every judgment about the domain a repo serves. The agent takes the mechanical scale-out, the part that does not benefit from human attention and degrades under it. Each repo's own knowledge has a declared destination so domain expertise is never diluted into a carried file that the next re-vendor overwrites.

Every number is checked, not recalled

Claim	Verified against
thirteen project types	spec/project-types.json, 13 keys
guarantees D1 to D9	WORKFLOW.md, 9 ### D<n> headings
four fidelity levels	spec/files.json, the set actually in use is exactly intent, interface, presence, verbatim

Also in this diff

The reference-definition block is alphabetized while three entries are added to it. The governance* keys sat out of order against the rule that each group is alphabetized by reference name.

Verification

• prose_lint blocking set clean tree-wide, and clean on changed lines.
• markdownlint clean, including the new table, the hand-added ToC entry, and the three new reference definitions.
• cspell clean over README.md and HISTORY.md.
• CRLF-only by byte scan.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds an explanatory section to the README so readers learn the fleet model’s concrete objectives (“what it achieves”) before the operational mechanics and per-type rules.

Changes:

• Adds a new “What It Achieves” section (plus ToC entry) describing the model’s objectives and the machinery that makes each objective checkable.
• Introduces a fidelity-levels table and adds new reference links used by the section.
• Alphabetizes/extends the README reference-definition block to include new entries.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

README.md:79

• This sentence says fidelity is "declared per unit" in spec/files.json, but several baseline entries omit the fidelity field (e.g., README.md, HISTORY.md, OPERATIONS.md) and rely on the default of presence instead. Consider calling out that presence is the default when fidelity is omitted so readers don’t infer every entry must specify it explicitly.

- **Every carried unit declares how much freedom it grants.** This is the distinction that makes the whole thing tolerable to work in, and it is declared per unit in [spec/files.json][files] rather than left to be inferred:

README.md:86

• The table isn’t indented as part of the preceding list item. In GitHub-flavored Markdown, an unindented table typically breaks out of the list, which can split the “objectives” bullets into two separate lists with the table in between. Indent the table so it clearly nests under this bullet and the list remains continuous.

| Level | The obligation | Who owns the content |
| --- | --- | --- |
| `verbatim` | Byte-identical to canonical, after governed normalization | The hub. A paraphrase is a defect, not an adaptation. |
| `interface` | Honor a named contract, checked by name and wiring | The repo owns the body entirely. |
| `intent` | Reach the same outcome, judged by meaning | The repo owns the wording and shape. |

[ptr727]

Answering the two suppressed findings from round 2, both fixed in 7d2357ba3af2924e99bcca3c1c67519352dd8580.

1. The table broke the list. Correct, and it is a rendering defect rather than a style preference. Unindented, the table terminated the list in GitHub-flavored Markdown, so the eight objectives rendered as two lists with a table wedged between them. It is now indented to the bullet's content column and the list is continuous, verified as 8 top-level bullets with 0 unindented table rows between them.

2. presence is the default, and the prose implied otherwise. Also correct, and checking it made the point sharper. Nine baseline entries carry no fidelity field at all (README.md, HISTORY.md, OPERATIONS.md, .gitignore, .github/dependabot.yml among them), and spec/fidelity-model.md states the default in two places.

Rather than only noting the default, the sentence now says what it means: an entry naming no level takes presence, the most permissive of the four, so silence grants freedom rather than withholding it. A reader's safe assumption about an unmarked entry is the opposite of the true one, which is worth saying outright in a section whose whole point is how much freedom each unit grants.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.