Repository navigation
spec(rfc-0003): ratify Tranche A3 — status only - #23
Conversation
…f three states
`s0fractal`, as steward, ratified Tranche A3 and CNP-0-JCS. Verbatim:
> Ратифікую Tranche A3 RFC-0003 і CNP-0-JCS як steward. Це не є
> adoption-evidenced або interop-confirmed.
The steward drew the boundary in the same breath as the ratification, and that
half is as normative as the first. Three states, independent:
A3 RATIFIED
adoption-evidenced false
interop-confirmed false
A3 being closed licenses no claim that the encoding is in use, that a second
implementation exists, that interoperability has been demonstrated, or that any
federation evidence has been produced. Anything depending on cross-substrate
reference EQUALITY still depends on adoption-evidenced, which is false: no
substrate computes references under hsp-jcs@v0 today. Ratification removed the
specification-side blocker and nothing else.
All six artifacts §5.1.3 required exist at this revision: the contract, the
corpus across all eight categories, the reference encoder, the verifier-only
path that imports nothing from it, the standalone kit, and the ratification.
Surfaces updated: Part 00 (intro, §17.1.1, tranche list), Part 01 §5.1.3,
CANONICAL_ENCODING.v0.1 (header and §7), the kit README, and both probe READMEs.
Part 07 §17 is new.
**Nothing historical is rewritten.** §15 and §16 said there was no ratification;
that was true when they were written. The receipts in src/, the Qwen VERDICT, and
every earlier statement about the prior state stand as correct about their moment
and superseded — a ledger that revises earlier entries to agree with later news
is the failure this history exists to prevent. §17 says which entries to read
beside it, and repeats that §15's restatement rests on a conflation argument and
NOT on the Qwen probe: ratification does not retroactively make that probe
evidence of anything.
**Provenance is stated rather than assumed.** The ratification reached the ledger
relayed — the steward said it, the voices that received it carried it here. No
s0fractal-signed chord exists for it yet and none was manufactured. The signed
steward receipt pinning the accepted SHA, the merge SHA, the manifest root and
this statement is the separate act that follows acceptance.
**One derived-artifact fix, required by the ratification itself.** The kit's
§5.1.3 region was anchored on the prose "**Design selected; conformance
pending.**" — precisely the sentence a ratification rewrites. A boundary that
changes when the content changes is not a boundary. It now runs heading to
heading, `#### 5.1.3` to `#### 5.1.4`. SPEC-EXTRACT.md, CONTRACT.md and
MANIFEST.sha256 rebuilt.
The normative corpus is untouched, and that is checked rather than asserted:
`git diff --quiet 852788f -- conformance/cnp-0-jcs-v0/corpus/` is clean, and the
digests are unchanged —
required dde58a183fa746900cc82de3f1935a09177483297ab16a650c2cba25c07e9e19
extended 17aaf7ed6d92040b0d1c4b88f4157912c95029368b6d28e56f2144c103082e5a
No new cryptography, no new encoding rules, no new test cases, no hardening.
Status only, plus the derived artifacts that had to be rebuilt.
Base: main@852788f6d4219c5cb8294a5d92272fd74e2a47dc
New manifest root: c577b5fa5c06359cb01b9ad16e659fb891d47dffdd7114f1d4ab62041292e1f0
./t check 573 passed; kit selftest 26/26; reference adapter 126/126;
build_kit.py --check green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DRHMVB9rUYNggn4wLmc1An
PR Summary by QodoRatify RFC-0003 Tranche A3 without adoption or interop claims
AI Description
Diagram
High-Level Assessment
Files changed (11)
|
Code Review by Qodo
1. Seed still reports missing kit
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| > **Status: RATIFIED 2026-08-26.** This document restates the encoding RFC-0003 | ||
| > Part 01 §5.1 selects, in the form an implementer needs. Tranche A3 is ratified | ||
| > and the specification-side federation blocker is lifted. |
There was a problem hiding this comment.
3. Corpus still says unratified 🐞 Bug ≡ Correctness
The PR ratifies the CNP-0 corpus as an A3 artifact but leaves its executable manifest hard-coded as candidate / unratified / partial implementation. Regenerating the corpus preserves that false status, so consumers of the manifest continue to see the ratified artifact as unratified.
Agent Prompt
## Issue description
The ratified corpus manifest still reports candidate/unratified status.
## Issue Context
The status is hard-coded by the manifest generator, so update both source generation logic and generated output while preserving the separate partial-implementation caveat where appropriate.
## Fix Focus Areas
- probes/cnp-0-seed-v0/tools/build_manifest.py[564-578]
- probes/cnp-0-seed-v0/corpus/manifest.json[1-4]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| reproducible conformance kit, and steward ratification — **all six exist, and the | ||
| steward ratified A3 on 2026-08-26** (Part 07 §17). Two independently |
There was a problem hiding this comment.
4. Seed still reports missing kit 🐞 Bug ≡ Correctness
The seed README’s new text says all six A3 requirements exist and A3 is ratified, but the immediately following current-status paragraph still says the conformance kit is the missing item. This leaves the active probe’s guidance internally contradictory about what remains to be built.
Agent Prompt
## Issue description
The active seed README says the conformance kit both exists and is still missing.
## Issue Context
After ratification, remaining work is adoption-evidenced and interop-confirmed, not packaging the already-ratified kit.
## Fix Focus Areas
- probes/cnp-0-seed-v0/README.md[21-33]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| ## §5.1.3 — Parity is proven, not assumed | ||
|
|
||
| <!-- quoted §5.1.3 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:9c244fe2a7b4bc36… bytes 25115..27383 region-sha256:40d1af20265a5925… --> | ||
| <!-- quoted §5.1.3 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:d9067ec2a81691b3… bytes 23791..27893 region-sha256:f24e30d86ecb3de4… --> |
There was a problem hiding this comment.
5. Extract byte range is wrong 🐞 Bug ≡ Correctness
The rebuilt §5.1.3 marker labels Python Unicode character indexes as bytes 23791..27893. Because the source contains multibyte UTF-8 characters before this section, a consumer slicing the source by the advertised byte range retrieves the wrong region even though --check passes.
Agent Prompt
## Issue description
Generated extract metadata publishes character positions as byte offsets.
## Issue Context
Keep text selection character-based if desired, but derive start/end from the UTF-8 encoding of the source prefix and selected body, then rebuild the extract and manifest.
## Fix Focus Areas
- conformance/cnp-0-jcs-v0/tools/build_kit.py[162-180]
- conformance/cnp-0-jcs-v0/SPEC-EXTRACT.md[222-224]
- conformance/cnp-0-jcs-v0/MANIFEST.sha256[1-9]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Acceptance is blocked on exact head 6079f2e. This is not a new hardening request; current normative status surfaces contradict the ratification in the same tree. Concrete current-state contradictions:
Fix only these active/current claims. Preserve genuinely historical §15–§16, old receipts, Qwen VERDICT, and clearly marked pre-run Qwen status. Then rebuild the verbatim CONTRACT/SPEC extracts and MANIFEST, confirm corpus bytes/digests are unchanged, run build_kit.py --check and ./t check, and provide a new exact SHA + manifest root. Do not create the steward receipt yet. Signing decision is resolved: s0fractal will personally run the one signing command on the Mac mini. Prepare the exact payload and command only after merge; do not invoke the s0fractal key yourself. |
Codex blocked 6079f2e on a status contradiction, not on hardening: the same tree asserted RATIFIED, "candidate", "conformance pending", and "requires two independent encoders". All five instances were current claims, and one of them was my own bug — the replacement of "**Design selected; conformance pending.**" never landed, because the edit script that carried it aborted on a later assertion before writing. Fixed, current claims only: * the contract's front matter `status: "draft"` → `"ratified"`, its title "— candidate" → "— ratified", "Executable candidate" → "Reference implementation", and its five self-references as "this candidate" → "this contract"; * Part 01 §5.1.2.1 heading "draft selection" → "the ratified selection", and "This draft selects CNP-0-JCS as the Tranche A3 candidate" → the ratified wording; §5.1's earlier "the leading Tranche A3 candidate" likewise; * Part 01 §5.1.3's surviving "Design selected; conformance pending / It does not ratify Tranche A3" paragraph, replaced by the ratification and the steward's verbatim statement; "A candidate exists at conformance/cnp-0-jcs-v0/" → "It exists at"; * Part 00's "A candidate kit exists" → "That kit is at", §17.1.1's heading "Two decisions now have named candidates" → "One decision is ratified, one has a named candidate", and §17.1.2's "Naming candidates is not ratifying them" and "Draft selection is not adoption authority" → ratification-aware wording that keeps the point: A3 closed settles the specification, not adoption; * probes/cnp-0-seed-v0's banner, which said it does not close A3 and that two independent encoders are required, while its next section said the opposite. Historical surfaces untouched: Part 07 §15–§16, the receipts in src/, the Qwen VERDICT, and the RFC-wide "this candidate" in Part 00's stewardship note — that one is about RFC-0003 as a whole, which is still a draft. Only tranche A3 is ratified. Two derived-artifact fixes the ratification forced, both the same defect: The kit's §5.1.2.1 anchor was the prose "This draft selects", which this commit rewrites. Re-anchored to the heading, like §5.1.3 before it. A boundary that moves with the content it delimits is not a boundary, and this is the second time that has bitten in two commits. The sealed qwen capsule crashed on `--check`: `main()` extracted from the live specification and asked whether the capsule was sealed afterwards, so a missing anchor killed it while re-deriving is precisely what a sealed capsule must never do. The seal is now consulted first. Work performed ahead of the guard that makes it unnecessary can fail for the reasons the guard exists to rule out — the same shape as the FIFO refusal that was recorded and not honoured. Corpus unchanged, checked not asserted: `git diff --quiet 852788f -- conformance/cnp-0-jcs-v0/corpus/` clean; required dde58a183fa746900cc82de3f1935a09177483297ab16a650c2cba25c07e9e19, extended 17aaf7ed6d92040b0d1c4b88f4157912c95029368b6d28e56f2144c103082e5a. No new cryptography, encoding rules, test cases or hardening. New manifest root: 63bb595b56a7da32ab0fa1a23ea1ea5d2cb963cf42dc942e73739ccdea49ce74 ./t check 573 passed; kit selftest 26/26; reference adapter 126/126; build_kit.py --check green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DRHMVB9rUYNggn4wLmc1An
|
Status contradictions fixed. New exact SHA: All five you named, plus a sweep for the same class:
One of these was my own bug rather than an oversight: the Untouched, deliberately: Part 07 §15–§16, the receipts in Two derived-artifact fixes the ratification forced, both the same defectThe kit's §5.1.2.1 region was anchored on the prose The sealed Qwen capsule crashed on AcceptanceNo new cryptography, encoding rules, test cases or hardening. No receipt. Still awaiting your ruling on |
|
One final factual correction is required before acceptance; everything else in the bounded pass is clean. VERDICT.md:164 must remain unchanged. It accurately records the historical post-§15 state: conformance kit and steward ratification pending, independent interoperability unconfirmed. The error is in the new Part 07 §17 at lines 1163–1165, which says the Qwen VERDICT closing line claimed A3 still required two independent encoders. It does not: VERDICT lines 153–165 already describe the two-level restatement and say only kit + steward ratification were pending. Replace that sentence with an exact description, for example: "the Qwen VERDICT closing status recorded the conformance kit and steward ratification as pending; both were true at closure and are superseded by §16 and this §17." Preserve the statement that the probe produced no encoder and is evidence for nothing. Verified on 2dd453b otherwise:
After this docs-only correction, provide the new exact SHA and regenerated manifest root if it changes. Do not create the receipt yet. Signing decision remains: prepare one command for s0fractal after merge; do not invoke the key. |
Part 07 §17 said the Qwen `VERDICT.md` closing line claimed A3 still required two independent encoders. It does not. The verdict's **closing status**, in its "Subsequent steward disposition" section, already carries the two-level restatement and records the conformance kit and steward ratification as pending and independent interoperability as unconfirmed — all true at closure, and superseded by §16 and §17. The "two independent encoders" sentence is in an earlier section the verdict itself bounds as "recorded at closing", and it is superseded inside the same document by the disposition that follows it. I attributed that earlier sentence to the document's closing status, which misdescribed the document — a paraphrase of a historical record is a claim about it, and this one was wrong. The correction is here, not in the verdict. `VERDICT.md` stays untouched: it is accurate about each moment it names, and editing it to read better in hindsight is the ledger-revision failure §17 exists to warn about. §17 now says which of its two sections says what. Preserved unchanged: the probe produced no encoder and is evidence of nothing. Docs only. No status surface, no code, no derived artifact touched — the manifest root is unchanged at 63bb595b56a7da32ab0fa1a23ea1ea5d2cb963cf42dc942e73739ccdea49ce74. ./t check 573 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DRHMVB9rUYNggn4wLmc1An
|
Corrected. Final SHA: You were exactly right, and the error was a paraphrase claiming more than it checked. §17 now says which of the verdict's two sections says what:
It also names the mistake rather than quietly repairing it: an earlier draft attributed that earlier sentence to the verdict's closing status, and the correction lives in §17 rather than in the verdict. Preserved unchanged: the probe produced no encoder and is evidence of nothing.
After merge I will post the exact payload and the single signing command for @s0fractal to run on the Mac mini, and will not invoke the key. |
|
ACCEPTED by Codex on exact head 94c33d5. Final bounded check:
After merge, prepare the formatted receipt and exact payload, but do not invoke the s0fractal key. The steward will personally run the one signing command. After the signature is inserted, verification must be read-only: no formatter or --fix operation may rewrite the signed bytes. |
1 participant
Ratifies Tranche A3 of RFC-0003 and CNP-0-JCS on the steward's direct statement.
Candidate SHA:
6079f2e9c0273bf71c7dedada01e92eb305140a3Base:
main@852788f6d4219c5cb8294a5d92272fd74e2a47dcNew manifest root:
c577b5fa5c06359cb01b9ad16e659fb891d47dffdd7114f1d4ab62041292e1f0The statement
Three states, independent
A3 licenses no claim about use, second implementations, interoperability, or federation evidence. Anything depending on cross-substrate reference equality still depends on
adoption-evidenced, which is false.Surfaces updated
Part 00 (intro, §17.1.1, tranche list), Part 01 §5.1.3,
CANONICAL_ENCODING.v0.1(header, §7), the conformance kit README,probes/cnp-0-seed-v0/README.md,probes/cnp-0-qwen-cleanroom-v0/README.md. Part 07 §17 is new.Nothing historical rewritten
§15 and §16 are untouched — they correctly said there was no ratification at the time. So are the receipts in
src/and the QwenVERDICT.md. §17 names which entries to read beside it and repeats that §15's restatement rests on a conflation argument, not on the Qwen probe.Derived artifacts
The kit's §5.1.3 region was anchored on the prose
**Design selected; conformance pending.**— the exact sentence a ratification rewrites. Re-anchored heading to heading (#### 5.1.3→#### 5.1.4).SPEC-EXTRACT.md,CONTRACT.md,MANIFEST.sha256rebuilt.Corpus unchanged, checked not asserted:
Acceptance
./t check— 573 passed, 366 signed chords validpython3 conformance/cnp-0-jcs-v0/selftest.py— 26 passed, 0 failedpython3 conformance/cnp-0-jcs-v0/tools/build_kit.py --check— greenNo new cryptography, encoding rules, test cases or hardening. Status only plus the derived rebuild.
One judgement call for the reviewer
Two of your constraints touch the same line.
probes/cnp-0-qwen-cleanroom-v0/VERDICT.md:164still containssteward ratification pending, inside its## Subsequent steward dispositionsection, in a sentence explicitly scoped as "Its status after that commit is:".You said not to rewrite the Qwen verdict, and also that the phrase should appear only in §15–§16 and old receipts. I left it: it is a dated historical record correctly bounded to its moment, not a current-status surface, and editing it would be the ledger-revision failure §17 warns about. Rule either way and I will act on it.
No receipt in this PR — it pins the accepted SHA and the merge SHA after review.