Repository navigation
Propose correct-naming-families-count: the naming families are those the pinned policy declares, restated in canon by neither number nor list - #1266
Merged
Conversation
…the pinned policy declares, restated in canon by neither number nor list Brett Heap, 2026-10-07, in session, first-hand to lane codeXfactory-5, verbatim: "open an OpenSpec change for the four families heading" (logged RULED on the lane register at 2026-10-07T09:45:29Z). It authorized authoring and opening this proposal. It is not a ratification and it rules on no design point; the packet is Status: draft. THE DEFECT. Canon project-repo-schema says "The four live naming families SHALL be governed as DATA by the naming policy of the pinned openRepoShape standard" (openspec/specs/project-repo-schema/spec.md:108), and the ratified doctrine docs/project-repo-schema.md heads its section "Naming, and the four families" (:236) and says "The four families are governed as DATA" (:248). That was true at the pin in force when canon was promoted on 2026-09-03 (openRepoShape deacbdc, four families). openxFactory's pin moved to 122d729b on 2026-09-04 (#650; five: the declared-only `family` holder, openRepoShape #16) and to 1a9fc537 on 2026-10-06 (#1260; six: the `workspace` form <user>-wip, openRepoShape #86). The policy's own header says "the six live naming families". THE READING IS COUNT-FREE, NOT "SIX". The count went stale twice in a month at two correct pin advances, because canon restates a number the pinned data owns. Two MODIFIED blocks on project-repo-schema, titles unchanged, each built by script from canon: - "The naming families are governed by the pinned standard, and a descendant form is a claim that needs a declared pin": the naming families are THOSE the pinned policy declares, governed there as data and restated here by neither their number nor their full list, with the four forms its rules reach kept as named members and the descendant clause carried word for word; one paragraph added (a family the pinned policy adds or retires owes this capability no amendment for its count or listing) and one scenario added; and "the one family whose membership is not decided by the characters alone", false since the declared-only `family` form, corrected. - "A project's repositories are named <Project>, <Project>-spec and <Project>-code": the suffixes sit apart from "every family the pinned standard's naming policy spells as a CamelCase word", no longer from "every other live family, all of which are CamelCase words", false since the lowercase <user>-wip form. Three canon units replaced, each under a `Removed from canon` marker; every other sentence and all six promoted scenarios carried byte-identically (tasks.md 3.1, by line range and by modified_block_currency's own units). Restating "six", tying a count to the data with a test (openRepoShape's own fix for its prose, #88), and a dated count in canon are recorded and rejected in design.md. No open question is put. Ordering: prefer-triad-project-shape (active, ratified) writes four other project-repo-schema titles, so the keys are disjoint, no sequenced_after is owed, and either may archive first. code_surface: none, target_release: implemented. The doctrine document is NOT edited here: its heading, two sentences, one informative note dated to the pin and an Amended by: line are the tasks.md 5.1 handoff after ratification, following amend-register-act-5b-projection-proof and prefer-triad-project-shape. Historical records saying "four" (README.md:7510, contracts/CHANGELOG.md:2002, ideation/README.md:392, the archived delta) are left as written; all 146 hits of `git grep -i "four .*famil"` on main are classified in tasks.md 3.3. Also: one README Active-changes bullet and the seeded per-change sweep ledger row (active, co-modifier, declares: absent; exactly one row moved). Lane: codeXfactory-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
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 2 days and 10 hours by commenting |
Reviewer's GuideThis draft OpenSpec proposal corrects stale naming-family prose by making canon derive the family set from the pinned policy rather than restating its count or complete list, updates two related whole-set claims, and records the ratification/realization workflow without editing the ratified doctrine yet. Entity relationship diagram for pinned naming-family dataerDiagram
PINNED_STANDARD ||--|| NAMING_POLICY : reads
NAMING_POLICY ||--o{ NAMING_FAMILY : declares
NAMING_FAMILY {
string id
string form
boolean declared_only
}
PINNED_STANDARD {
string commit
}
Flow diagram for the naming-family proposal lifecycleflowchart TD
Word["Brett Heap authorizes opening proposal"] --> Draft["Draft OpenSpec change"]
Draft --> Ratify["Brett Heap ratifies proposed reading"]
Ratify --> Realize["Amend ratified doctrine in follow-up"]
Realize --> Archive["Archive change and promote modified requirements"]
Draft -.->|does not edit doctrine yet| Doctrine["Ratified doctrine"]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
…ded when the PR opens" RATIFIED 2026-10-07T10:43:48Z by Brett Heap (openxFactory operator authority), in session, first-hand to lane codeXfactory-5, verbatim: "ratify as recommended when the PR opens" (given at about 09:46Z, logged RULED on the lane register at 2026-10-07T09:47:04Z, opensoft/brett-wip lanes/log/codeXfactory-5.md; effective when PR #1266 opened at 10:43:48Z). The ratified text is the packet at PR #1266's head 3bb38c2, the head on which it opened. "As recommended" takes every recommendation the packet put, as written: D1: the naming families are THOSE the pinned openRepoShape naming policy declares, governed there as data; canon restates neither their number nor their full list D2: the correction also reaches the two sentences that restated a property of the whole set (the CamelCase clause, and "the one family" not decided by its characters) D3: the doctrine is realized in the wording design.md D3 proposes, with one informative note dated to the pin The packet put no open question. The word is a ratification only. It is not a merge word (the PR stays held for Brett Heap's merge word), and it is not a word to realize anything (the tasks.md 5.1 doctrine handoff waits on its own act). His separate merge word, "merge the naming families PR when green" (logged RULED at 2026-10-07T09:59:10Z), is noted on owner box 1.2 and is the coordinating lane's act. EVERY RULING IS THE RECOMMENDED OPTION, SO NO DELTA BYTE MOVES: specs/project-repo-schema/spec.md is byte-identical to the ratified text (0 changed lines against 3bb38c2). WHAT MOVES, following prefer-triad-project-shape's ratifying commit (020f2e4): - proposal.md: Status: ratified + one Ratified: citation; a qualifier above the filing's "NOTHING HERE IS RATIFIED" paragraph (kept verbatim); a RULED mark on each item of "What ratification decides"; a "## Ratification record" section with a rulings table; and the code_surface: gloss's file list corrected for the new record (the head none is unchanged). - design.md, tasks.md: Status: ratified + one Ratified by: citation naming this change. design.md gets a qualifier above its opening paragraph and a RULED mark with Brett's verbatim word on D1, D2 and D3, with all their reasoning kept. tasks.md gets dated notes on owner boxes 1.1 and 1.2, and 1.3, the bookkeeping this commit performs, is ticked. - .openspec.yaml: approved_by + approved_on ADDED after proposed_on, in this commit, the first to declare Status: ratified anywhere in the packet. kind, id, reason, proposed_by and proposed_on do not move. - review/ratification-2026-10-07.md: new, Status: ratified, one citation. - README.md: the Active-changes entry moves to the ratified form. NOT MOVED: the spec delta, and tests/sequenced_after/corpus-ledger.yaml (the row stays active / co-modifier; --ledger-diff consistent, 233 rows). Owner boxes 1.1 and 1.2 are not ticked: tasks.md section 1 says they are OWNER BOXES "an agent never ticks". Each carries a dated note instead. Verified on the encoded tree: pinned CLI --change 1 passed, --all 113 passed / 1 failed (114 items, the accepted add-chain-attestation exception, finding lines identical to main); code-surface, target-release, sequenced-after, --ledger-diff and proposal-support verify each exit 0; doc-health in an openxFactory-named CI-shaped checkout byte-identical to main and to 3bb38c2 (31 critical, 26 error, 69 warning, 19 info), no finding naming this packet; pytest over the corpus-reading directories 3872 passed, 2 skipped, 0 failed. Lane: codeXfactory-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
RATIFIED — Brett Heap, 2026-10-07, in session, verbatim: "ratify as recommended when the PR opens" First-hand to lane "As recommended" took every recommendation the packet put, as written:
The origin pair is The word is a ratification only. It is not a merge word and not a word to realize anything. Brett Heap's separate merge word, "merge the naming families PR when green" (logged RULED at 2026-10-07T09:59:10Z), is the coordinating lane's to act on. Owner boxes 1.1 and 1.2 stay unticked, each with a dated note. Lane: codeXfactory-5 |
|
Contributor
Author
|
LANDING — lane codeXfactory-5, session ed23f049-7e99-4601-8a6d-760b6aeb5f26@Eagle, 2026-10-07T11:20:07Z, PR #1266 into opensoft/openxFactory main. On Brett Heap's word: "merge the naming families PR when green". Lane: codeXfactory-5 |
Contributor
Author
|
LANDED — lane codeXfactory-5, session ed23f049-7e99-4601-8a6d-760b6aeb5f26@Eagle, 2026-10-07T11:20:16Z, PR #1266 into opensoft/openxFactory main → squash Merged on Brett Heap's word "merge the naming families PR when green", with every required check green at Lane: codeXfactory-5 |
brettheap
added a commit
that referenced
this pull request
Oct 7, 2026
…ding main took #1266 (correct-naming-families-count), whose README Active changes entry landed where this branch's entry sits. Both entries are kept, this packet's first; no byte of either entry changes. The ledger merged cleanly: each change keeps its own row. Refs #1262 Lane: openxfactory-1 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brettheap
added a commit
that referenced
this pull request
Oct 8, 2026
…t Heap's word 'ratify 1262 when ready' (#1264) Lane: openxfactory-1 Drafts and RATIFIES the OpenSpec change `amend-worker-input-budget-dispatch-wording`, the amendment #1262 asks for. Refs #1262. **Ratified in place, as drafted, on Brett Heap's word *"ratify 1262 when ready"*.** No requirement or scenario text moved at ratification: the spec delta is blob `eead8960` at every commit of this PR. The archive is a separate act on its own word. ## The words Brett Heap, verbatim, in session on 2026-10-07. Each is a RULED line on the lane register (`opensoft/brett-wip`, `lanes/log/openxfactory-1.md`) except the second, which the issue itself records. 1. *"(a) land as ratified, amend later"*. His ruling on Copilot's comment [`4202036546`](#1258 (comment)) at #1258. RULED at 2026-10-07T09:42:21Z (commit `98b8b3d4`). 2. *"log the issue to change this"*. The lane filed #1262. 3. *"draft the amendment change for 1262"*. This PR. 4. *"ratify 1262 when ready"*. RULED at 2026-10-07T09:58:32Z (commit `f6964352`). Its condition held at `5b3edf14`: every required check green, `pytest-suite` included, and Copilot's review `5441182701` recommending approval with one low-severity citation fix, taken in `5d236d7d`. The ratification is commit `3a7ba60c`. 5. *"yes, land it when green"*. RULED at 2026-10-07T10:04:03Z (commit `43e9a5c2`). This PR lands by SQUASH, by the lane's coordinator, inside a Rule 6 window. The squash commit is then the ratifying commit on `main`, and it carries the origin's approval pair. Closing #1262 still needs its own word, and the archive is a separate later pull request. ## What changes One `## MODIFIED` requirement in `doc-health`, *Bounded worker input budget*. Only the last sentence of its second paragraph is replaced. As promoted (canon on `main` `16779816`, lines 4083-4087): > Where the WORKER assembles the prompt from a dispatchable unit the orchestrator prepared, the orchestrator SHALL measure each unit's assembled size, record it, and SHALL NOT dispatch a unit it has measured over the budget — dispatching one and letting the worker refuse is conformant but useless, because the same unit is selected again next run. As amended (#1262's text, verbatim): > Where the WORKER assembles the prompt from a dispatchable unit the orchestrator prepared, the orchestrator SHALL measure each unit's assembled size, record it, and SHALL NOT dispatch a unit it has measured over the budget. The worker's refusal of an over-budget input (scenario "A worker receives an input over the budget") is a backstop that keeps such an input from reaching the model. It does not make an over-budget dispatch conformant, and relying on it wastes the run, because the same unit is selected again next run. `diff` of canon's block (`openspec/specs/doc-health/spec.md`:4070 to the end, 52 lines) against the delta's block gives one hunk: ```diff 17,18c17,21 < measured over the budget — dispatching one and letting the worker refuse is < conformant but useless, because the same unit is selected again next run. --- > measured over the budget. The worker's refusal of an over-budget input > (scenario "A worker receives an input over the budget") is a backstop that > keeps such an input from reaching the model. It does not make an > over-budget dispatch conformant, and relying on it wastes the run, because > the same unit is selected again next run. ``` The title, the first and third paragraphs and all six scenarios (16 bullets) are byte-identical to canon. The archived delta under `openspec/changes/archive/2026-10-06-add-worker-input-budget/` is history and is not edited. ## Task 1.1: the realization never dispatches over budget (CONFIRMED) #1262's acceptance 1, checked read-only: - `scripts/doc_health/catalog_dispatch.py` at #1137's merge `9da52e31`: - :513-515 measures each shard's assembled input in bytes; - :516-517 adds the shard to the dispatch list only when it is `<= input_budget_bytes`; - :527-528 writes `shards.json` from that list alone; - :535-543 records the rest as `shards_over_budget`. - On `main` `16779816`, the gate is at :521-522 and the write at :532-533. - The worker reads only that list. `opensoft/xFactory` `.github/workflows/doc-health-cataloger-worker.yml`:171-175 takes `ids[0]` of `shards.json` and exits 0 when the list is empty. The file is identical at `b2479b6e` (xFactory#481) and at `main`. - `tests/doc-health/test_semantic_input_budget.py`:503, `test_a_shard_measured_over_the_budget_is_never_dispatched`, asserts that the over-budget shard is not dispatched. So the amended sentence describes behaviour that already holds, and `code_surface: none` is measured, not assumed. ## The ratification (commit `3a7ba60c`) Following #1250's pattern (`3cec62fd`), in one commit, so the ratifying commit also carries the approval pair: - `proposal.md`: `Status: draft` becomes `Status: ratified`, with one `Ratified:` line citing the word, the RULED line and the record; - `tasks.md`: `Status: ratified` with a `Ratified by:` line; boxes 0.1 and 0.2 ticked with the word; - `.openspec.yaml`: `approved_by` (Brett Heap, the word verbatim) and `approved_on: 2026-10-07` ADDED after the drafting pair. Every existing field is unchanged, checked by parsing both versions; - `review/ratification-2026-10-07.md`: the record (`Status: ratified`, `Kind: report`, `Decision date:`, `Ratifier:`, one `Ratified:` citation and the ratified baseline); - `README.md`: the *Active changes* entry in its ratified form, ending **RATIFICATION ONLY**. Not moved: `specs/doc-health/spec.md`, the ledger row and the self-gate row. ## Files - `openspec/changes/amend-worker-input-budget-dispatch-wording/`: - `.openspec.yaml`: an `ad_hoc` origin written by `proposal-support.py declare-adhoc` with the drafting pair, the approval pair added at ratification, and a `related:` list; - `proposal.md`, `tasks.md`, `review/ratification-2026-10-07.md`; - `specs/doc-health/spec.md`, the one delta. - `README.md`: the *Active changes* entry. - `tests/doc-health/test_modified_block_currency_self_gate.py`: one `_LEDGER_SUBJECTS` row, with its docstring count and chronology. The carriage arm reports this block once, at INFO (1 of 25 units uncarried, which is the amended sentence). A `**Removed from canon by**` marker was not used, because the marker would be promoted into canon and carry the old sentence with it, which #1262's acceptance 3 forbids. - `tests/sequenced_after/corpus-ledger.yaml`: the seeded row (`--moved-by '#1264'`). Registered and not taken (`tasks.md` § 5): a code comment at `scripts/doc_health/catalog_dispatch.py`:527-528 and a test docstring at `tests/doc-health/test_semantic_input_budget.py`:506-508 still echo the old clause. Editing them would give a wording packet a code surface. ## Review Copilot reviewed each head this PR asked it to: - `5441182701` at `5b3edf14`: approval recommended, with one low-severity citation fix (`r4205972528`), taken in `5d236d7d`. - `5441515765` at `3a7ba60c`, the ratifying commit: three non-normative record fixes (`r4206239376`, `r4206239452`, `r4206239504`), taken in `e9c63a18`. None touched requirement or scenario text; the spec delta is still blob `eead8960` and `.openspec.yaml` is unchanged. - `5441560962` at `e9c63a18`: approval recommended, no findings. - `5441620162` at `a2761b1f`, this head (after the merge of `main` below): approval recommended, no findings. Every review thread is answered and resolved: 4 threads, 0 unresolved. `main` then moved to `a38585e9` (#1266, `correct-naming-families-count`), and this branch took it by merge commit `a2761b1f`, never a rebase. The only conflict was the head of the README *Active changes* list, where both entries are kept, this packet's first, with no byte of either entry changed. ## Gates Same-kind full clones named `openxFactory`. **At this head, `a2761b1f`, against `main` `a38585e9`:** | gate | `main` `a38585e9` | this head | | --- | --- | --- | | `validate-openspec-cli-pin.py --all --strict` | exit 0; 113 passed, 1 failed (the accepted `add-chain-attestation` exception), 0 undispositioned | exit 0; 114 passed, the same 1 accepted exception | | `validate-openspec-cli-pin.py --change amend-worker-input-budget-dispatch-wording` | n/a (exit 2, no such change) | exit 0; 1 passed | | `proposal-support.py . verify amend-worker-input-budget-dispatch-wording` | exit 0 | exit 0 | | `validate-code-surface.py`, `validate-target-release.py`, `validate-scope-globs.py` | exit 0 | exit 0 | | `validate-sequenced-after.py .` | exit 0 (47 active, 19 declaring) | exit 0 (48 active, 20 declaring) | | `validate-sequenced-after.py . --ledger-diff` | exit 0 (233 rows) | exit 0 (234 rows) | | `validate-former-id-arrival.py`, `validate-release-tag-gate.py` | exit 0 | exit 0 | | `doc-health.py --single-repo .` | 31 critical, 22 error, 69 warning, 19 info | 31 critical, 22 error, 69 warning, **20 info**. The one added finding is this block's carriage-ledger INFO, named by the self-gate row. No other line moves: no `ratified-provenance` or `proposal-origin` finding names the ratified packet | | pytest: `tests/sequenced_after`, `tests/proposal-support`, the self-gate module and `test_semantic_input_budget.py` | | 537 passed | **Earlier, against `main` `16779816`,** the same validator and doc-health rows held at `24b7862b` (draft), `5b3edf14` (ledger seeded), `3a7ba60c` (ratified) and `e9c63a18`. At `24b7862b` the pytest subset (`tests/doc-health`, `sequenced_after` and nine more gate modules) and the whole suite (`--continue-on-collection-errors`) failed exactly the same ids as `main` (7 and 237, from the clone's uninitialized `openDox` and `openXdox` legs) plus the 4 `sequenced_after` ledger tests that fail until the row is seeded; at `5b3edf14`, with the row seeded, those modules passed (337 tests). CI's `pytest-suite` runs the whole suite with the legs. It was green at `5b3edf14`, and `gh pr checks` reports it at this head. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Lane: openxfactory-1 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brettheap
added a commit
that referenced
this pull request
Oct 8, 2026
Lane: openxfactory-4 main moved through #1266 (correct-naming-families-count) and #1264 (amend-worker-input-budget-dispatch-wording), which touch README.md, the sweep ledger and two other changes, and not this change's directory. Section 4 names the new base and the commits since fc4fa0f; section 6 carries the re-measured numbers (pinned gate 114 passed of 115 items, ledger 234 rows, doc-health 20 info, corpus directories 311 subtests). The doc-health report is again byte-identical to main alone. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This was referenced Oct 8, 2026
brettheap
added a commit
that referenced
this pull request
Oct 8, 2026
…amilies count-free (#1270) Lands task 5.1 of the OpenSpec change correct-naming-families-count, ratified 2026-10-07 (PR #1266 → a38585e). - Direction, Brett Heap, 2026-10-08: "do the 5.1 doctrine edit for naming families". - Merged on Brett Heap's word "merge the 5.1 PR when green" (2026-10-08). docs/project-repo-schema.md now has an Amended-by note naming the change, the heading "Naming, and the naming families", and a count-free sentence. That sentence says the naming families are the ones the pinned standard's contracts/repository-naming.yaml declares and governs as data, so the prose states neither how many there are nor which. An informative blockquote, dated 2026-10-07 to the pin 1a9fc537, lists the six families declared there; it governs nothing. The phrases "four famil" and "every other live family" no longer appear. tasks.md ticks 5.1 with its DONE note. The archive (§ 6) waits on its own word. Every required check is green at c07a6fd, including merge-master-approval. Copilot review not requested (Brett Heap, 2026-10-06). Lane: codeXfactory-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brettheap
added a commit
that referenced
this pull request
Oct 9, 2026
…23375303) (#1261) Lane: openxfactory-4 (openXfactory-4-openDox_extraction) Refs #656 (stays OPEN). **THE RATIFICATION RECORD for `realize-doc-health-direction-arc`** (plan 038's T071), the doc_health direction arc's own change. It landed as a draft through #1247 → `51456835` and #1253 → `fc4fa0ff`. No requirement, decision or task text moves: the change has no spec delta (`skip_specs: true`). It lands through the holder's lander in a Rule 6 window; this actor merges nothing. ## The word RULED by Brett Heap, 2026-10-06 at about 18:59Z, by interactive multi-choice, verbatim *"Ratify it (Recommended)"*, recorded at #656 comment [`6023375303`](#656 (comment)) (created 2026-10-06T19:00:45Z). The option text he saw read *"I post your word on #656 and land the ratification record (Status: ratified, Ratified by) under a Rule 6 window. T072 can start right away; T074 and T075 then follow in order."* ## The form followed `cd494e4c` / #1151, "Ratify add-neutral-product-standalone-operability on Brett Heap's word (#656 5815412869)", file for file and field for field. The holder's ruling at #656 [`6023619783`](#656 (comment)) confirms the one choice that differs from the change's as-filed text (below). ## What is ratified, and what the word authorizes - **Ratified:** the change as landed on `main` at `fc4fa0ff` (#1253, merged 2026-10-06T18:56:42Z). Its change-directory tree, `02d362f6ebcaf49e18aa107f7ce2b3a409ca2275`, is identical at #1253's final head `e4f3f1db` and on current `main`, and the last commit on `main` that touches it is `fc4fa0ff`. Copilot's review at `e4f3f1db` read "Approval recommended", Findings: None. - **D1–D7 stand as recommended.** `tasks.md` 1.2 provides that the word rules `design.md` § 11's D1–D7 as recommended unless it says otherwise, and the word does not. The record says that this applies 1.2's own rule and does not claim Brett Heap was shown the seven one by one. - **Authorized:** per the ruling record, the realization in plan 038's order: T072 (opportunistic, ARC-6), then T074 and T075. None of it happens by the word itself. - **Nothing archives or promotes.** The change stays ACTIVE until its realization is merged and green, and it gates neither release 2's close nor #1144's archive (ARC-Q3 (a)). ## What this PR changes Six files. None of the changes is requirement or scenario text. **`openspec/changes/realize-doc-health-direction-arc/proposal.md`** - `Status: ratified`, with a `Ratified:` citation. - A qualifier above the filing's "DRAFT. FILING IS NOT RATIFYING" paragraph, which is kept verbatim as the filing's record. - A `## Ratification record` section. - A read-at-ratification note after the D1–D7 list. **`design.md` and `tasks.md`** - `Status: ratified`, with a `Ratified by:` citation. This is the citation split #1144's record carried. - `design.md` § 11: the same read-at-ratification note. - `tasks.md` 1.1 (the filing, citing #1247 → `51456835` and #1253 → `fc4fa0ff`) and 1.2 (this act) are ticked. Boxes go from 0 `[x]` / 23 `[ ]` to **2 `[x]` / 21 `[ ]`**. - 1.2 keeps its as-filed wording and gains a marked italic note on the one divergence (below), as #1151 did for its own 1.8. **`.openspec.yaml`** - `approved_by` / `approved_on` are ADDED after `proposed_on`. `kind`, `id`, `path`, `reason`, `proposed_by` and `proposed_on` do not move. **New record:** `review/ratification-2026-10-06.md` (`Status: ratified`, `Kind: report`, one `Ratified:` citation). **`README.md`:** the *Active changes* entry's status, now linking the record. The sequenced-after ledger row does not move. **The one divergence from the text as filed.** `tasks.md` 1.2 says the record carries `Status: record`. It carries `Status: ratified` with a `Ratified:` citation, as #1144's record did. `document-lifecycle` sanctions both spellings, the option put to Brett read "(Status: ratified, Ratified by)", and a `Status: record` file trips `record-immutability` (CRITICAL) on any later edit, such as a Copilot fix commit on this PR. Confirmed by the holder at #656 `6023619783`. ## Gate state at `f9f71063` The tree is `main` at `40d6e5c1` plus this PR's twelve commits (the change itself, five merges of `main` and six re-measurements of the record), with the submodules initialised. After the first head, `main` moved five times: the archive of `add-worker-input-budget` (#1258), then #1266 and #1264, then the archive of `amend-worker-input-budget-dispatch-wording` (#1269), then #1263, #1270, #1271 and #1267 (renew-resolved-council-protocol), then #1272, #1275 (the archive of `correct-naming-families-count`) and #1277 (a bot review-lane repin). They touch `README.md`, `docs/`, the sweep ledger, other changes, the review-lane contracts and workflows and the doc-health and project-repo-schema specs, and not the change directory (its tree is still `02d362f6ebcaf49e18aa107f7ce2b3a409ca2275` on `main`, last commit `fc4fa0ff`). So `main` was merged in, never rebased, and everything below was re-measured. `main` has since moved again, to `b4b9d903` (a new change, `refresh-install-repository-enumerations-opsxfactory-gateway`: its own directory, a README entry and a ledger row). It is not merged here, per the holder's one-merge instruction, and a trial merge with it is clean. ``` OPENSPEC_TELEMETRY=0 openspec validate realize-doc-health-direction-arc --strict → valid (the pinned 1.12.0) validate-openspec-cli-pin.py --all --strict → exit 0, 0 UNDISPOSITIONED failures 113 passed, 1 failed (114 items); the 1 = the accepted exception, as on main alone validate-code-surface.py . / validate-target-release.py . → passed validate-sequenced-after.py . / --ledger-diff → pass; ledger consistent (235 rows), this row unmoved proposal-support.py . verify realize-doc-health-direction-arc → ok doc-health.py --single-repo . → 31 critical, 26 error, 69 warning, 19 info report byte-identical to main alone (same clone kind); 0 findings name this change doc-health families (1.2's falsifier) → proposal-origin 0 findings, status-validity 0 findings (negative control: dropping proposal.md's Ratified: line takes ratified-provenance 27 → 28 critical, naming proposal.md) pytest -m "not postgres" -k "ledger or records or sequenced or openspec" → 615 passed, 3 skipped pytest sequenced_after code_surface target_release proposal-support scope_globs packet_reference → 866 passed, 311 subtests passed pytest tests/doc-health → 2157 passed ``` An earlier `tests/doc-health` run showed 8 failures in `test_neutrality_dispatch.py`. They were this actor's own environment, not the tree: an exported `REPO` variable collided with the fake scout worker's `REPO`. With it unset the file gives 25 passed, and the whole directory is green above. ## Copilot - **First head `0039a47e`:** review `5436306140`, "Approval recommended", Findings: None, 0 threads. - **Head `739da6e0`** (after the first merge of `main`): review `5440756736`, "Approval recommended", Findings: None, 0 threads. - **Head `69479c77`** (after the second merge of `main`): review `5459920482`, "Approval recommended", 0 threads. - **Head `83e3511e`** (after the third merge of `main`): review `5460937374`, "Approval recommended", 0 open findings, 0 threads. - **Head `b186eb62`** (after the fourth merge of `main`): review `5462168108`, "Needs a closer look", **0 open findings**, 0 threads. Its stated reason is that final approval depends on human validation of the governance authority and the historical provenance assertions. The holder ruled at #656 [`6069024568`](#656 (comment)), item 5, that this is NOT a block, because that authority is Brett Heap's ratify word `6023375303`. - **Checks at `b186eb62`:** the rollup was SUCCESS with 15 status checks, all SUCCESS, including `merge-master-approval`, `pytest-suite` and SonarCloud Code Analysis. 0 threads unresolved. - **Head `f89fc853`** (after the fifth merge of `main`): review `5464071466`, "Needs a closer look", **0 open findings**, 0 threads. Its stated reason is that the exact-head checks and the Codex review were then pending, and that final approval also depends on governance provenance, which the holder's ruling at #656 `6069024568`, item 5, covers. - **Final head `f9f71063`** (a record-only correction of the corpus subtest figure, 312 to 311, which the completed run measured): Copilot requested through the reviewer API after the push. Its result, the checks and the thread count are recorded here once the exact final head has been reviewed. ## Codex - At `b186eb62`, `@codex review` was posted twice (comments `6067925769` and `6069046343`), and the `chatgpt-codex-connector[bot]` answered both with the usage-limit message (comments `6067927988` and `6069048581`). No Codex review existed at that head. - At `f89fc853`, `@codex review` (comment `6071059884`) was answered with a review: **Reviewed commit `f89fc853cb`**, "Didn't find any major issues" (comment `6071083487`; summary comment `6071062721`, Code Review completed at 2026-10-08T23:29:24Z). - At the final head `f9f71063`, `@codex review` was posted once after the push (comment `6071252263`). The bot's reply is recorded here once it arrives. READY needs a Codex "Reviewed commit" at the exact head, or Brett Heap's explicit waiver (#656 `6069024568`, item 4). ## What is NOT done - No code, pin, gitlink, contract bundle or release tag moves. T072, T074 and T075 are the realization, and none of them starts by this PR. - Plan 038's `specs/038-…/tasks.md` is not edited here. T071's tick there goes in the holder's own bookkeeping batch. - Nothing archives or promotes. **Rule 6:** this PR touches `openspec/changes/` and the README OpenSpec Records block, so it lands in a declared window by the holder, and not by this actor. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Lane: openxfactory-4 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lane: codeXfactory-5
Status: ratified (2026-10-07, Brett Heap, verbatim "ratify as recommended when the PR opens", over the opening head
3bb38c20; ratifying commitd296570b; RATIFIED comment). Held for the merge word: Brett Heap's separate word "merge the naming families PR when green" (logged RULED 2026-10-07T09:59:10Z) is the coordinating lane's to act on once every required check on the final head is green. It touches openspec/changes/, so it lands under a Rule 6 landing window.The word, verbatim
Brett Heap, 2026-10-07, in session, first-hand to lane
codeXfactory-5(logged RULED on the lane register at 2026-10-07T09:45:29Z): "open an OpenSpec change for the four families heading". It authorized authoring and opening this proposal. It is not a ratification and it rules on no design point.The defect
openspec/specs/project-repo-schema/spec.md:108: "The four live naming families SHALL be governed as DATA by the naming policy of the pinned openRepoShape standard".docs/project-repo-schema.md:236, the heading "Naming, and the four families", and:248, "The four families are governed as DATA in the pinned standard'scontracts/repository-naming.yaml".The pinned policy, read at each commit openxFactory has pinned:
deacbdcneutral-product,install,domain-descendant,project-leg122d729bfamily(a declared-only holder, openRepoShape #16) addede9c4827b1a9fc537f335c077)workspace(<user>-wip, openRepoShape #86) addedCanon was promoted on 2026-09-03 at
deacbdc, when "four" was true, and it has been false since 2026-09-04. The policy's own header at the pin in force says "the six live naming families", and none is marked otherwise.familyisdeclared_only, which governs when the classifier reports it, not whether it is a family.The proposed reading: count-free, not "six"
The count went stale twice in a month at two correct pin advances, because canon restates a number the pinned data owns. Two
## MODIFIEDblocks onproject-repo-schema, titles unchanged, each built by script from canon:familyform, is corrected.<Project>,<Project>-specand<Project>-code: the suffixes now sit apart from "every family the pinned standard's naming policy spells as a CamelCase word". The old text said "every other live family, all of which are CamelCase words", which has been false since the lowercase<user>-wipform.Three canon units are replaced, each under a
Removed from canonmarker. Every other sentence and all six promoted scenarios are carried byte-identically (tasks.md § 3.1, proved by line range and bymodified_block_currency's own unit derivation).design.mdrecords and rejects three alternatives: restating "six" (A1); a count tied to the data by a test, which is openRepoShape's own fix for its prose in #88 (A2); and a dated count in canon (A3). No open question is put.Doctrine realization (tasks.md § 5.1, after ratification, not in this PR): the heading becomes
## Naming, and the naming families, the two sentences are restated asdesign.mdD3 proposes, one INFORMATIVE note dated to the pin lists today's six families and says it governs nothing, and anAmended by:line is added. No anchor links to the heading (checked here and in openRepoShape, codexFactory and the aggregation).Ordering:
prefer-triad-project-shape(active, ratified) writes four otherproject-repo-schematitles. The keys are disjoint, so nosequenced_after:is owed and either change may archive first (design.mdD5).code_surface: none,target_release: implemented.Out of scope: historical records
git grep -n -i "four .*famil"onmain16779816returns 146 hits, each classified in tasks.md § 3.3:spec.md:108; doctrine:236and:248(§ 5.1).README.md:7510,contracts/CHANGELOG.md:2002,ideation/README.md:392, and the archived2026-09-03-add-project-repo-schemadelta:97.contracts/policies/standards-bodies.yaml:1195("the four family listings") is about O*NET SOC families 11/13/15/27, not naming families.Validators
@fission-ai/openspec@1.12.0, content address verified):--change correct-naming-families-count --strict1 passed, 0 failed;--all --strict113 passed, 1 failed (114 items), exit 0, against cleanmain16779816at 112 passed, 1 failed (113 items). Every finding line is identical on the two trees. The one failure is the acceptedadd-chain-attestationexception carried incontracts/openspec-cli-pin.yamldispositions:.validate-code-surface.py .,validate-target-release.py .,validate-sequenced-after.py .,--ledger-diff("consistent with the corpus (233 rows)"; exactly one row moved, this packet's), andproposal-support.py . verify correct-naming-families-count.--single-repo . --as-of 2026-10-07, in a scratch checkout namedopenxFactorywith CI's submodules):mainand this tree each report 31 critical, 26 error, 69 warning, 19 info, and the reports are byte-identical. No finding names any file of this packet.-m "not postgres"over the corpus-reading directories, includingdoc-health, in that same checkout: 3872 passed, 2 skipped, 0 failed. In the authoring worktree, which is not namedopenxFactoryand has no submodules, the same 7 checkout-name and submodule tests fail onmainand on this tree alike. All 7 pass in the CI-shaped checkout.Copilot review not requested (Brett Heap, 2026-10-06)
🤖 Generated with Claude Code
Summary by Sourcery
Replace hard-coded naming-family counts and whole-set assumptions with references to the families declared by the pinned naming policy, and record the ratified documentation change.
New Features:
Bug Fixes:
Enhancements:
Documentation:
Tests: