correct-naming-families-count 5.1: the doctrine restates the naming families count-free

[brettheap]

Lane: codeXfactory-5

Realizes task 5.1, the doctrine, of the ratified change correct-naming-families-count (ratified on PR #1266 by the ratifying commit d296570b on its branch, squash-merged as a38585e9 on 2026-10-07). It edits docs/project-repo-schema.md only, with design.md D3's wording verbatim. Two commits: 615c79c4c is the doctrine edit, and c07a6fdb7 ticks 5.1 in the change's tasks.md citing this PR number (#1270, the tick on the prefer-triad 5.1 model of PR #1254).

Authority

Brett Heap, 2026-10-08, in session, verbatim:

"do the 5.1 doctrine edit for naming families"

That word authorizes AUTHORING and OPENING this realization PR. It is not a merge word. Merging waits on Brett Heap's separate merge word.

The task, verbatim from openspec/changes/correct-naming-families-count/tasks.md

5.1 openxFactory, the doctrine. After ratification, in its own pull request: docs/project-repo-schema.md restated as design.md D3 proposes. The heading at :236 becomes ## Naming, and the naming families. The sentence at :240-242 says the suffixes sit apart from "every family the pinned standard's naming policy spells as a CamelCase word". The sentence at :248-251 becomes count-free, keeping the four forms it names as members. One INFORMATIVE note dated to the pin lists the families the pin in force declares and says it governs nothing. The header gains an Amended by: correct-naming-families-count (ratified <date>, openxFactory PR #<n>) line beside the existing one. No other sentence moves: the realization's git diff names exactly those hunks, and any other hunk is a finding against the edit. docs/project-repo-schema.md is not a registered release member, so no digest, inventory member or changelog entry moves. The pull request touches openspec/changes/ only to tick this box, under its own Rule 6 window.

The five changed places, before and after

Line numbers were checked against current main (c9dfd4f8): the heading is still at :236, the CamelCase sentence at :240-242 and the governed-as-DATA sentence at :248-251.

1. Header, a second Amended by: line beside the existing one (lines 16-25 after). The existing Amended by: prefer-triad-project-shape … block is untouched; this follows it in the same continuation form (docs/lifecycle-notebook-projection.md already carries three Amended by: lines in the same header).

+Amended by: correct-naming-families-count (ratified 2026-10-07,
+  openxFactory PR #1266) — the naming section made count-free: the families are
+  the ones the pinned standard's naming policy declares, governed there as DATA,
+  and this document states neither how many there are nor which. The section's
+  heading, the sentence placing the leg suffixes in a different visual class,
+  and the sentence naming where the families are governed are restated to say
+  so, and one INFORMATIVE note, dated to the pin, lists what that pin declares
+  and governs nothing. Realized per
+  `openspec/changes/correct-naming-families-count/tasks.md` task 5.1. This
+  document's own status line and ratifying citation are unchanged by it.

2. Heading (:236).

-## Naming, and the four families
+## Naming, and the naming families

3. The CamelCase sentence (:240-242). The next sentence, "The assembly root is bare because the thing you clone has no suffix — the precedent the aggregation root already sets.", is re-wrapped across the same lines and its words are unchanged (word-level proof below).

-different visual class from every other live family, all of which are CamelCase
-words. The assembly root is bare because the thing you clone has no suffix — the
-precedent the aggregation root already sets.
+different visual class from every family the pinned standard's naming policy spells
+as a CamelCase word. The assembly root is bare because the thing you clone has no
+suffix — the precedent the aggregation root already sets.

4. The count-free sentence (:248-251).

-The four families are governed as DATA in the pinned standard's
-`contracts/repository-naming.yaml`, not by this prose: `open<Product>` neutral
-products, `<X>-Install` installs, `<Domainx><Product>` domain descendants, and the
-project legs above.
+The naming families are the ones the pinned standard's
+`contracts/repository-naming.yaml` declares, and they are governed there as DATA,
+not by this prose, which therefore states neither how many there are nor which.
+Among them are `open<Product>` neutral products, `<X>-Install` installs,
+`<Domainx><Product>` domain descendants, and the project legs above, which are
+the families the rules in this section reach.

5. The one INFORMATIVE note, dated to the pin (new, directly after place 4, in the file's > Amended … blockquote form).

+> Informative, dated 2026-10-07 to the pin. At the commit
+> [`contracts/openreposhape-pin.yaml`](../contracts/openreposhape-pin.yaml)
+> names, `1a9fc537bcce…`, the naming policy declares six families:
+> `neutral-product` (`open<Product>`), `install` (`<X>-Install`),
+> `domain-descendant` (`<Domainx><Product>`, a claim answered by a declared
+> pin), `project-leg` (`<Project>`, `<Project>-spec`, `<Project>-code`),
+> `family` (a holder, reported only where its `family.yaml` declares it), and
+> `workspace` (`<user>-wip`, one person's private index of unfinished work).
+> This list is a reading of the data at that pin and governs nothing. The policy
+> at the pin in force is where the families are read, and a later pin may
+> declare more or fewer without this doctrine moving.

The pin was read, not assumed: contracts/openreposhape-pin.yaml:226 is commit: "1a9fc537bcce37301c85fc108fabd8a599b02000" on main, and git -C openRepoShape show 1a9fc537…:contracts/repository-naming.yaml declares exactly six families: ids at precedence 1 to 6 — neutral-product, install, domain-descendant, project-leg, family (declared_only: true, declared by family.yaml) and workspace (^[a-z0-9]+(?:-[a-z0-9]+)*-wip$) — under a header reading "the six live naming families". Its sha256 is a4eebad2…f096a4, the digest the pin file records. The note, the heading, and both sentences are checked to equal design.md D3's proposed text by a whitespace-normalized containment test (all three print True).

The hunk rule: no other sentence moves

git diff -U0 origin/main -- docs/project-repo-schema.md has these hunk headers, and nothing else:

@@ -15,0 +16,10 @@   header: the second Amended by line (place 1)
@@ -236 +246 @@       heading (place 2)
@@ -241,3 +251,3 @@   CamelCase sentence (place 3)
@@ -248,4 +258,18 @@  count-free sentence + the informative note (places 4 and 5, adjacent)

That is five changed places in four git hunks; places 4 and 5 touch adjacent lines, so git joins them. git diff --stat origin/main for the doctrine commit: docs/project-repo-schema.md | 40 +++++++---, 32 insertions(+), 8 deletions(-), one file.

Word-level proof for place 3, git diff --word-diff=plain --word-diff-regex='[^[:space:]]+':

different visual class from every [-other live family, all of which are-]{+family the pinned standard's naming policy spells+}
{+as a+} CamelCase [-words.-]{+word.+} The assembly root is bare because the thing you clone has no
suffix — the precedent the aggregation root already sets.

Only the clause changed; the assembly-root sentence is word-for-word the same. The phrase "every other live family" and the count "four famil…" no longer appear anywhere in the document. docs/project-repo-schema.md is not a registered release member: no digest, inventory member or changelog entry moves.

The tick (c07a6fdb7, openspec/changes/correct-naming-families-count/tasks.md, +20 -1)

- [ ] 5.1 becomes - [x] 5.1 and a dated note is appended to that box, worded on #1254's: DONE 2026-10-08 in openxFactory PR #1270 → 615c79c4c6c592e7a12bb8e68b639e9198ac545c, lane codeXfactory-5, naming Brett Heap's word, the five places, "the wording is design.md D3's, verbatim", that no digest, inventory member or changelog entry moves, and ending "The tick holds on main only through that pull request's merge, which waits on Brett Heap's merge word and its required checks." No other box and no other line of the change moves (git diff --stat origin/main..HEAD: two files, docs/project-repo-schema.md +32 -8 and tasks.md +20 -1).

Validators (re-run at the FINAL head c07a6fdb7; the doctrine commit alone gave the same results)

Run in a scratch checkout directory NAMED openxFactory, with CI's pytest-suite submodules initialized (git submodule update --init openXwallet and git submodule update --init --recursive openXdox openDox), so repository identity and the skipped-family set match CI.

• Pinned OpenSpec CLI (@fission-ai/openspec@1.12.0, content address verified):
  • python3 scripts/validate-openspec-cli-pin.py --change correct-naming-families-count --strict: 1 passed, 0 failed, exit 0.
  • --all --strict: 113 passed, 1 failed (114 items), exit 0 — the same as main. The one failure is the accepted add-chain-attestation exception that contracts/openspec-cli-pin.yaml already carries.
• House validators, each exit 0: validate-code-surface.py . (passed), validate-target-release.py . (47 active proposals, 47 declaring; passed), validate-sequenced-after.py . (47 active changes; passed), validate-sequenced-after.py . --ledger-diff ("per-change sweep ledger consistent with the corpus (234 rows)"), proposal-support.py . verify correct-naming-families-count ("proposal support verification ok").
• doc-health, scripts/doc-health.py --single-repo . --as-of 2026-10-08, the final head against main c9dfd4f8: both report 31 critical, 26 error, 69 warning, 19 info, "New regressions vs previous report: 0". The two reports differ by exactly two lines, the canon-word count (382741 → 382979) and the ratified row (85892 → 86130), which is this edit's added words. No finding names docs/project-repo-schema.md or this change, in any family (ratified-provenance and status-validity among them).
• Secret scan of the diff (no gitleaks on this host, so token, key and credential patterns plus a 32-hex-character sweep over the added lines): no match.

Merge state

Held for Brett Heap's merge word; it touches openspec/changes/ (the 5.1 tick), so it lands under a Rule 6 landing window.

Copilot review not requested (Brett Heap, 2026-10-06)

🤖 Generated with Claude Code

Summary by Sourcery

Make the project repository naming doctrine count-free and governed by the pinned naming standard.

Enhancements:

• Restate the repository naming doctrine so naming families are defined by the pinned standard without asserting a fixed count, while documenting the families declared by the current pin.
• Record the ratified naming-doctrine realization in the change task checklist.

Documentation:

• Update the project repository schema's naming section and amendment history to use count-free, pin-governed terminology and add an informative snapshot of the current naming families.

[sourcery-ai]

Sorry @brettheap, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 1 day and 3 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[sourcery-ai]

Reviewer's Guide

This doctrine-only PR updates docs/project-repo-schema.md so naming-family authority and cardinality come from the pinned repository-naming.yaml data rather than the prose, while documenting the current pin’s six-family snapshot as non-authoritative and recording the amendment provenance.

File-Level Changes

Change	Details	Files
Restates the naming doctrine as count-free and delegates authoritative family membership to the pinned naming standard.	Renames the section to avoid asserting a fixed family count. Rephrases the CamelCase comparison against families declared by the pinned policy. States that this document neither determines the number nor identity of families, while retaining the four forms relevant to the section. Adds a pin-dated informative snapshot of the six families declared at the referenced commit and explicitly gives it no governing authority.	docs/project-repo-schema.md
Records the ratified change and realization in the document header.	Adds a second Amended by entry citing the ratification date, PR number, task, and scope of the doctrine edit. Leaves the existing amendment entry and document status and ratifying citation unchanged.	docs/project-repo-schema.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Sourcery assessment

Approved.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[brettheap]

LANDING — lane codeXfactory-5, session ed23f049-7e99-4601-8a6d-760b6aeb5f26@Eagle, 2026-10-08T18:26:47Z, PR #1270 into opensoft/openxFactory main

Landing on Brett Heap's word "merge the 5.1 PR when green" (2026-10-08). The final head is c07a6fd, and all 14 checks are green, including merge-master-approval. Main has moved one commit past this PR's base: #1263 → 3a2ab30, which touched only specs/038-opendox-document-tool-self-maintenance/. It doesn't overlap this PR's two files. Register: brett-wip 28f9a387a.

Lane: codeXfactory-5

[brettheap]

LANDED — lane codeXfactory-5, session ed23f049-7e99-4601-8a6d-760b6aeb5f26@Eagle, 2026-10-08T18:27:52Z, PR #1270 into opensoft/openxFactory main → e83259b

Squash-merged at 2026-10-08T18:27:26Z on Brett Heap's word "merge the 5.1 PR when green". Every required check was green at c07a6fd. This closes the window opened at 18:26:47Z. Task 5.1 of correct-naming-families-count is done. The change's archive (§ 6) waits on its own word.

Lane: codeXfactory-5