Skip to content

feat: ActionIntent adopts CNP-0-JCS (Trinity half) #27

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
s0fractal merged 4 commits into from
Aug 26, 2026
Merged

feat: ActionIntent adopts CNP-0-JCS (Trinity half) #27

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
fdf76b5
feat(x5E10): ActionIntent commits over CNP-0-JCS canonical bytes
s0fractal Aug 26, 2026
a92addf
chore(projections): regenerate for the ActionIntent adoption
s0fractal Aug 26, 2026
2db7056
fix(x5E10): strict raw-byte intake, one snapshot, and a cross-stored E2E
s0fractal Aug 26, 2026
87274a2
docs(rfc-0003): reconcile adoption status
s0fractal Aug 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,23 @@ jobs:
if: steps.subm.outputs.present == 'true'
run: ./t court --live | jq -e '.law_bridge.omega_native != null and .law_bridge.trinity_witnessed != null and .law_bridge.consistent == true'

# With the submodule present the ActionIntent commitment must be verified by
# RUNNING both implementations, not by comparing two constants. Trinity
# vendors MYC's contract byte-for-byte; a vendored copy that drifted while
# both suites kept the same expected string would otherwise pass.
- name: Verify ActionIntent cross-substrate parity exercised
if: steps.subm.outputs.present == 'true'
Comment on lines +155 to +156

@qodo-code-review qodo-code-review Bot Aug 26, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Parity gate never runs 🐞 Bug ☼ Reliability

The new parity step is guarded by steps.subm.outputs.present == 'true' inside verify, but that
job explicitly checks out with submodules: false, so the condition is always false and
implementation drift can merge undetected. The separate cross-substrate job initializes MYC but
never runs this test.
Agent Prompt 
## Issue description
The live ActionIntent parity gate is unreachable because it is conditional on submodules being present in the `verify` job, while that job deliberately checks out without submodules.

## Issue Context
The `cross-substrate` job initializes all public submodules and sets up Deno, making it the effective location for this mandatory adoption gate. Run the parity command there unconditionally after initialization, retaining the checks that reject `SKIPPED` output and require all four tests to pass.

## Fix Focus Areas
- .github/workflows/ci.yml[155-166]
- .github/workflows/ci.yml[321-365]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

run: |
out=$(deno test --allow-all src/action_intent_parity_test.ts 2>&1)
echo "$out"
# The live cases skip themselves when the submodule is absent; here it
# is present, so a SKIPPED line means the gate passed vacuously.
if echo "$out" | grep -q "SKIPPED"; then
echo "::error::parity skipped while submodules are present"
exit 1
fi
echo "$out" | grep -q "4 passed"

- name: Verify recipes detail lookup
run: ./t recipes show recipe.metacognition.field-cycle --json | jq -e '.type == "recipes" and .position == "3/C" and .action == "show" and .recipes[0].id == "recipe.metacognition.field-cycle"'

Expand Down
2 changes: 1 addition & 1 deletion conformance/cnp-0-jcs-v0/MANIFEST.sha256
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
bfdc30247c4c399f9b9ab6ccd04c9de56785d5850f881b48064a1a69a8c6aa3d CONTRACT.md
b040b943c3cd4b13e1e18fd776b8ceef98c43272ef264344b7d2cb715ad7c172 INTERFACE.md
b19a92a73cbec859a853e4ed12c11dde7ab9c77269e311e16a4d901d9ba12e52 README.md
4f289ee10fcb3e5698b8823af6241291b34b326406354a40d79708371b39ab0d SPEC-EXTRACT.md
941acc21d2c1c59e928733e401c2083dc9ebebe1adcb72df6b745114a67a2d6a SPEC-EXTRACT.md
17aaf7ed6d92040b0d1c4b88f4157912c95029368b6d28e56f2144c103082e5a corpus/extended.ndjson
dde58a183fa746900cc82de3f1935a09177483297ab16a650c2cba25c07e9e19 corpus/required.ndjson
7c7fee476b75768345e882c27bc24066a7f3896472de3b3023750c8221248041 run_conformance.py
Expand Down
34 changes: 20 additions & 14 deletions conformance/cnp-0-jcs-v0/SPEC-EXTRACT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ RFC, not so it can replace it.

## §5.1.1 — Canonical encoding is normative, not an implementation detail

<!-- quoted §5.1.1 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:474ffd5c40eceb59… bytes 8911..10131 region-sha256:f4b3f491e7c94a51… -->
<!-- quoted §5.1.1 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:678f77e030afd225… bytes 8911..10131 region-sha256:f4b3f491e7c94a51… -->

The encoding MUST satisfy:

Expand Down Expand Up @@ -43,7 +43,7 @@ The encoding MUST satisfy:

## §5.1.2 — Floating point

<!-- quoted §5.1.2 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:474ffd5c40eceb59… bytes 10468..11642 region-sha256:223959e79c0a546e… -->
<!-- quoted §5.1.2 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:678f77e030afd225… bytes 10468..11642 region-sha256:223959e79c0a546e… -->

In canonical form:

Expand Down Expand Up @@ -72,7 +72,7 @@ In canonical form:

## §5.1.2 — Non-integer values inside an integers-only domain

<!-- quoted §5.1.2 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:474ffd5c40eceb59… bytes 11975..13806 region-sha256:8fab8eaf939924bd… -->
<!-- quoted §5.1.2 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:678f77e030afd225… bytes 11975..13806 region-sha256:8fab8eaf939924bd… -->

Two patterns are admissible. Both keep every number in the integer domain and
both are exact. Each is a **tagged form**, carrying the reserved discriminator
Expand Down Expand Up @@ -117,7 +117,7 @@ independent implementations will agree on.

## §5.1.2.1 — CNP-0-JCS: the ratified selection

<!-- quoted §5.1.2.1 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:474ffd5c40eceb59… bytes 14233..17860 region-sha256:40b14adf274f9acf… -->
<!-- quoted §5.1.2.1 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:678f77e030afd225… bytes 14233..17860 region-sha256:40b14adf274f9acf… -->

##### 5.1.2.1 CNP-0-JCS: the ratified selection

Expand Down Expand Up @@ -190,7 +190,7 @@ the path does not do and not what it is given.

## §5.1.2.2 — Fixed-point scale identity

<!-- quoted §5.1.2.2 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:474ffd5c40eceb59… bytes 18650..19528 region-sha256:142acb574999e19c… -->
<!-- quoted §5.1.2.2 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:678f77e030afd225… bytes 18650..19528 region-sha256:142acb574999e19c… -->

A fixed-point domain MUST bind one content-addressed scale descriptor of this
shape:
Expand Down Expand Up @@ -223,7 +223,7 @@ simplex, `Σ value_i` MUST equal `radix^places` exactly.

## §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:474ffd5c40eceb59… bytes 23833..28604 region-sha256:f37dce7dae936ef3… -->
<!-- quoted §5.1.3 from docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md sha256:678f77e030afd225… bytes 23833..29137 region-sha256:118b4e42c2686f13… -->

#### 5.1.3 Parity is proven, not assumed

Expand Down Expand Up @@ -294,9 +294,13 @@ That list is the whole of A3. Two further states sit outside it, and neither
blocks it, because ratifying a specification, running it, and having someone
else run it are three different acts:

**Adoption-evidenced** — at least one substrate computing real references under
`hsp-jcs@v0` on a path that matters. Until it holds, no document may claim the
encoding is in use.
**Adoption-evidenced — TRUE since 2026-08-27.** `ActionIntent.intentCommitment`
computes its commitment over CNP-0-JCS canonical bytes in both Trinity
(`src/x5E10_warrant.ts`) and MYC (`myc/src/x5820_action_intent.ts`), and that
commitment is the authority gate: `actionBoundAuthority` permits actuation only
when a committed proposal's `action_grant.intent_commitment` equals it exactly.
A live end-to-end test authorizes the proposal MYC actually wrote to disk. This
is one path, not the whole substrate, and it is named rather than generalised.

**Interop-confirmed** — at least two independently _maintained_ implementations,
or adoption by a party outside this project, with parity evidence in both
Expand All @@ -310,12 +314,14 @@ party _has_ verified, and the difference is exactly what this level names.
That is a statement about the specification, not about the world it is meant to
run in. The honest status is:

> **A3: RATIFIED. adoption-evidenced: false. interop-confirmed: false.**
> **A3: RATIFIED. adoption-evidenced: true (one authority path — ActionIntent).
> interop-confirmed: false.**

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.
One authority path computes real references under `hsp-jcs@v0`; nothing else in
either substrate does. `adoption-evidenced` says the encoding is in use, not
that it is used everywhere, and no document may read it as the latter.
`interop-confirmed` remains **false**: both implementations are under one
maintainer, which is exactly what that level exists to distinguish.

<!-- end quoted §5.1.3 -->

Expand Down
46 changes: 25 additions & 21 deletions docs/rfc/0003-heterogeneous-state-protocol/00-architecture-and-ratification-map.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,18 +53,19 @@ on 2026-08-26** (Part 01 §5.1.3, Part 07 §17): the contract, the CNP-0 corpus,
reference encoder, a verifier-only rejection path sharing no code with it, and a
standalone conformance kit all exist, and the steward closed the tranche.

**Three independent states, and only the first has changed:**
**Three independent states; the first two have now changed:**

| state | value | what it licenses |
| ---------------------- | ------------ | ----------------------------------------------------------------------------------- |
| **A3** | **RATIFIED** | the encoding is determined and checkable |
| **adoption-evidenced** | **false** | nothing may claim the encoding is in use |
| **adoption-evidenced** | **true** | the named ActionIntent authority path may claim the encoding is in use |
| **interop-confirmed** | **false** | nothing may claim independent interoperability or multi-implementation confirmation |

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, and A3 being closed moves neither of the other two.
`adoption-evidenced` became **true** on 2026-08-27:
`ActionIntent.intentCommitment` computes over CNP-0-JCS canonical bytes in both
Trinity and MYC, and that value gates actuation. It says the encoding is in use
on one named path, not that it is used everywhere. `interop-confirmed` stays
**false** — both implementations are under one maintainer.

**Substrate adoption was never a ratification condition.** It is its own state,
`adoption-evidenced`, for the same reason the second encoder stopped being one:
Expand Down Expand Up @@ -710,7 +711,8 @@ rather than "proved" for that reason.
with it, a standalone conformance kit, and steward ratification. All six
exist, and **the steward ratified A3 on 2026-08-26** — see Part 07 §17 for the
statement. Federation adoption was **not** among them and remains tracked
separately as `adoption-evidenced`, which is false.
separately as `adoption-evidenced`, which became true for the named
ActionIntent authority path on 2026-08-27.

**Restated 2026-08-26: two levels, not one.** This entry previously required
**two independent encoders** for A3. That conflated four separable things —
Expand Down Expand Up @@ -793,9 +795,9 @@ specification, not the world it runs in. Specifically:
2. **Ratification is not adoption authority.** Part 01 selects CNP-0-JCS and the
steward ratified it. That does not make Warrant the owner of federation
encoding, import its governance, or bind substrates that have not adopted and
implemented the contract. `adoption-evidenced` is **false**: no substrate
computes references under `hsp-jcs@v0` today, and A3 being closed does not
change that.
implemented the contract. `adoption-evidenced` is **true only for the named
ActionIntent authority path**: it does not license a claim that either
substrate generally computes references under `hsp-jcs@v0`.
3. **Version pinning is mandatory if adopted.** `ski@v1` names Book I v0.5
specifically, and `GOV-ANCHORS` pins its dependencies by content hash for the
stated reason that a STANDARD must not rest on a moving target. Any adoption
Expand Down Expand Up @@ -1474,10 +1476,10 @@ where a reference resolves:
raw input and non-canonical ratios, and a reproducible conformance kit all
exist, and the steward ratified the tranche. This settles the specification;
it settles neither of the two states below.
- **Adoption-evidenced: false** (a state, not a tranche, and never a blocker on
A3). At least one substrate computing real references under `hsp-jcs@v0` on a
path that matters. Until it holds, no document may claim the encoding is in
use.
- **Adoption-evidenced: true** since 2026-08-27 (a state, not a tranche, and
never a blocker on A3). The named ActionIntent authority path computes real
references under `hsp-jcs@v0`; this licenses that bounded adoption claim and
no substrate-wide one.
- **Interop-confirmed: false** (a level above both, and never a blocker on
either). Two independently maintained implementations, or adoption by a party
outside this project, with parity evidence in both directions. Until it holds,
Expand All @@ -1488,10 +1490,10 @@ where a reference resolves:
content-addressed principal and custody records, and fail unresolved or shared
custody closed against double-counting (§22.1).

Tranche A is a prerequisite for every other tranche. Until A2 and A3 land,
§5.1's guarantees do not hold across substrate boundaries and nothing that
depends on cross-substrate reference equality should be claimed. A draft choice
reduces design uncertainty; it does not weaken this gate.
Tranche A is a prerequisite for every other tranche. A2 and A3 have landed, but
their guarantees extend only as far as the separately reported adoption and
interoperability evidence. The named ActionIntent path supplies bounded adoption
evidence; independent interoperability remains unconfirmed.

### Tranche B — State-domain typing (depends on A)

Expand Down Expand Up @@ -1615,9 +1617,11 @@ What matters going forward rather than backward:
1. **Ratification is per tranche, per document.** A ratified tranche constrains
something. An unratified complete specification constrains nothing while
looking as though it does, which is the more dangerous of the two states.
2. **Part 01 still blocks conformance.** Its draft encoding is selected; the
missing contract, corpus, independent implementations, rejection path, and
adoption keep every later part non-conforming across substrate boundaries.
2. **Part 01 no longer blocks conformance.** Its encoding is ratified and its
contract, corpus, rejection path, conformance kit, and one named adoption
path now exist. Independent interoperability remains unconfirmed and
therefore cannot be claimed, but it is not a prerequisite for A3 or bounded
adoption.
3. **The first post-erratum artifact is code, not another prose-only revision.**
`probes/hsp-fast-path-debt-scope-v0` makes the debt-locality term of §15.0
executable with eleven fail-closed tests and a local benchmark. It is a
Expand Down
22 changes: 14 additions & 8 deletions docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -493,9 +493,13 @@ That list is the whole of A3. Two further states sit outside it, and neither
blocks it, because ratifying a specification, running it, and having someone
else run it are three different acts:

**Adoption-evidenced** — at least one substrate computing real references under
`hsp-jcs@v0` on a path that matters. Until it holds, no document may claim the
encoding is in use.
**Adoption-evidenced — TRUE since 2026-08-27.** `ActionIntent.intentCommitment`
computes its commitment over CNP-0-JCS canonical bytes in both Trinity
(`src/x5E10_warrant.ts`) and MYC (`myc/src/x5820_action_intent.ts`), and that
commitment is the authority gate: `actionBoundAuthority` permits actuation only
when a committed proposal's `action_grant.intent_commitment` equals it exactly.
A live end-to-end test authorizes the proposal MYC actually wrote to disk. This
is one path, not the whole substrate, and it is named rather than generalised.

**Interop-confirmed** — at least two independently _maintained_ implementations,
or adoption by a party outside this project, with parity evidence in both
Expand All @@ -509,12 +513,14 @@ party _has_ verified, and the difference is exactly what this level names.
That is a statement about the specification, not about the world it is meant to
run in. The honest status is:

> **A3: RATIFIED. adoption-evidenced: false. interop-confirmed: false.**
> **A3: RATIFIED. adoption-evidenced: true (one authority path — ActionIntent).
> interop-confirmed: false.**

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.
One authority path computes real references under `hsp-jcs@v0`; nothing else in
either substrate does. `adoption-evidenced` says the encoding is in use, not
that it is used everywhere, and no document may read it as the latter.
`interop-confirmed` remains **false**: both implementations are under one
maintainer, which is exactly what that level exists to distinguish.

#### 5.1.4 The selection is narrower than it looks

Expand Down
63 changes: 63 additions & 0 deletions docs/rfc/0003-heterogeneous-state-protocol/07-revision-history.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1175,3 +1175,66 @@ correction is here rather than in the verdict, which stays untouched.

None of this changes what the probe produced, which was nothing, or what it is
evidence of, which is nothing.

## 18. adoption-evidenced becomes true on one named path (2026-08-27)

`ActionIntent.intentCommitment` computes its commitment over CNP-0-JCS canonical
bytes in both substrates. This is the first path in either to compute a real
`hsp-jcs@v0` reference rather than an ad-hoc stable stringification.

{"args_commitment":"c1","canonical_encoding":"hsp-jcs@v0",
"input_commitments":["a","b"],"numeric_profile":"cnp-0",
"requested_effects":["receipt","write"],"target_substrate":"myc",
"verb":"apply"}
→ ccc26b8b460fe2debf0ad069d55ec170a78b7b70861f1f54c03e401e4576c3be

Chosen because it is an authority gate rather than a convenient hash:
`actionBoundAuthority` permits actuation only when a committed proposal's
`action_grant.intent_commitment` equals this value exactly.

### What the state now says, and what it does not

**`adoption-evidenced: true`** means the encoding is in use on **one named
path**. It does not mean the substrates have adopted it generally: the
proposal-body digest in the same file still uses the old stringification, and so
do the other `stable()` copies. Nothing may read this state as "Trinity computes
references under `hsp-jcs@v0`".

**`interop-confirmed` remains false.** Both implementations are under one
maintainer, which is exactly what that level exists to distinguish. Trinity
vendors MYC's contract byte-for-byte; agreement between them is internal
consistency, not independent interoperability.

**A3 is unaffected.** It was ratified on 2026-08-26 and this changes nothing
about it. Adoption is a separate state precisely so that running a specification
and ratifying it stay distinguishable.

### The implementation evidence

- both boundaries parse **raw bytes** strictly — UTF-8 decoded fatally,
duplicate member names detected before `JSON.parse` collapses them last-wins,
including escape-equivalent spellings such as `"verb"`;
- one normalization reads every property exactly once into owned copies, and the
encoder uses only that snapshot;
- a **live** parity test executes both implementations and compares canonical
text, canonical bytes and digests across eight divergence-prone inputs;
- a **live end-to-end** test authorizes the proposal MYC actually wrote to disk,
rather than a descriptor built in a test;
- the canonical bytes are judged canonical by the ratified verifier-only path,
which shares no code with the encoder.

### How this was found to be wrong three times first

The reviewer's executed attacks, each of which produced a real commitment or a
written proposal before it was closed: a duplicate `verb` accepted last-wins; an
escape-equivalent duplicate; a `0xff` byte becoming U+FFFD; a getter answering
the validator and the encoder differently; and an encoder that accepted
`requested_effects: [1]` while its own comment said it refused everything
outside the domain.

The first three are the rejection classes §5.1.1 rule 4 exists for, and this
project's own conformance kit documents them as "properties of the input bytes
that a permissive JSON parser resolves before you can see them" — while the
authority boundary used a permissive parser. Adoption is recorded here together
with that, because a state that records only the success is a state that teaches
nothing.
2 changes: 1 addition & 1 deletion myc
Open in desktop
Submodule myc updated 10 files
+44 −0 fixtures/ots/README.md
+1 −0 fixtures/ots/spore-bootstrap-v0.root
+ − fixtures/ots/spore-bootstrap-v0.root.ots
+80 −8 src/x2F80_ots_adapter_test.ts
+7 −4 src/x5800_propose.ts
+182 −1 src/x5800_propose_test.ts
+360 −53 src/x5820_action_intent.ts
+263 −31 src/x5820_action_intent_test.ts
+16 −8 src/x8F00_organism.ts
+49 −2 src/x8F00_organism_test.ts
Loading
Loading