Skip to content

feat(t27): ring 00 generates, compiles, and is proven to answer as the twin production runs - #433

Merged
gHashTag merged 2 commits into
feat/queen-supervisorfrom
t27/ring-00-parity
Sep 5, 2026
Merged

gHashTag merged 2 commits into
feat/queen-supervisorfrom
t27/ring-00-parity

Conversation

@gHashTag

@gHashTag gHashTag commented Sep 5, 2026

Copy link
Copy Markdown
Owner

L0 says every rule below the interface is written once in .t27 and generated, because a rule transcribed into Swift, Rust, Zig and Verilog is four rules that agree until someone edits one. The t27-backend skill then records where that stands, and it is blunt: T27-00 "generates but does not run anywhere, so strictly the plan is blocked at its first ring."

Two-thirds of that was wrong.

question answer how it was checked
does the spec generate? yes, 7 of 7 rules, 121 lines of Rust t27c gen-rust rings/T27-00/queen_core.t27
does the generated Rust compile? yes, zero errors, warnings only rustc --crate-type lib --edition 2021
does it agree with the twin production runs? yes, 460 of 460 tri t27-parity

Generation was never the blocker, and compilation had never been tried. What was actually missing is the thing the law is for: any evidence the generated ring says the same thing as the Swift binary the container actually asks.

The parity harness

Two sides, one question:

  • the ring — rings/T27-00/generated/queen_core.rs, generated by t27c, compiled by bare rustc, driven through rings/T27-00/parity/probe.rs. That probe is stdin, stdout and a match on a verb; if a rule ever appears in it, it has become the fifth copy of the law and the exercise has inverted.
  • the twin — queend, the Swift binary the container asks, taking a JSON question on stdin. Not a re-implementation written for this harness.

Exhaustive, not sampled. Ring 00 is integers and booleans with small ranges, so the whole meaningful space fits: every attempt sequence up to depth 3 for retry (40 cases), and the full review grid with total≤4, judged≤total, unmet≤judged, files≤2, prior≤3 (420 cases). A sampled parity check has a coverage number that has to be defended; an exhaustive one over a bounded space does not.

Shown failing before it was trusted. On a scratch copy that never touched a shipped file, MAX_SEND_BACKS was changed from 2 to 1 in the spec:

disagreements: 30 of 420
first: total=1 judged=1 unmet=1 files=0 prior=1: ring says escalate, twin says sendBack

A parity check nobody has watched catch a divergence might be comparing nothing.

It runs in the heal chain every round, so "they agree" cannot decay into "they agreed when somebody last looked". A missing side is reported as missing and exits non-zero — the one answer this must never give is a green tick for a comparison it did not make.

Five copies of one constant, and two of them were the loop's own

rings/T27-00/queen_core.t27:37                          the spec
rings/SR-00/QueenDelegation.swift:470                   Swift copy 1
agent-server/queen-core/.../QueenDelegation.swift:470   Swift copy 2 (the fork)
.trinity/loop/dash.mjs                                  'bees running (of 4)'
.trinity/loop/snapshot.mjs                              the same string again

The last two are prose inside a dashboard label — which is exactly how a constant escapes every search anyone would run for it. A loop that reports on the swarm's discipline while holding its own copy of the swarm's constant has no standing to.

Both now call ringConst('MAX_CONCURRENT_WORKERS'), reading one line out of the generated artifact. With no artifact the label reads (of ?), never (of 4) — an invented constant that happens to be right is the same defect wearing a correct answer, and it would survive the spec changing. Calibration asserts the positive and both negatives, and a second case fails if any file in the loop writes (of 4) into a string again.

Also measured: there is no JavaScript backend

t27c --help has four language targets — Zig, Verilog, C, Rust. Everything else is silicon tooling. So a .t27 source has no path to a Node module today, and adding one means editing t27/bootstrap, which another agent owns under L0b.

What that does not excuse is a rule living in .mjs. Plumbing is plumbing; a threshold, a verdict or a capacity is law, and law goes in the ring.

Next, in ring order

The ring is proven, not yet running — queend is still the artifact the container executes. So: make the container run the generated ring for the four decisions both implement; then delete a transcription (the two Swift copies are audit finding D1, and this harness is what makes removing one safe rather than brave); only then T27-02.

tri t27-gen, tri t27-parity. 225 calibration cases. The compiler builds into trios/.trinity/t27c-build, so nothing is written into ~/t27.

🤖 Generated with Claude Code

…e twin production runs

L0 says every rule below the interface is written once in `.t27` and generated,
because a rule transcribed into Swift, Rust, Zig and Verilog is four rules that
agree until someone edits one. The t27-backend skill then records where that
stands, and it is blunt: T27-00 "generates but does not run anywhere, so
strictly the plan is blocked at its first ring."

Measured today, and two of those three words were wrong. `t27c gen-rust` emits
all 7 rules from the 209-line spec, and `rustc --crate-type lib` compiles the
result with zero errors. What was missing was not generation and not
compilation - it was any evidence the generated ring says the same thing as the
Swift binary the container actually asks.

It does. 460 cases, exhaustive over ring-00's bounded space - every attempt
sequence up to depth 3 for `retry`, and the whole `review` grid with total<=4,
judged<=total, unmet<=judged, files<=2, prior<=3 - and the generated Rust and
`queend` answer identically on every one. Not sampled: ring 00 is integers and
booleans with small ranges, so the whole meaningful space fits.

AND THE CHECK IS SHOWN FAILING FIRST, on a scratch copy that never touched a
shipped file: changing MAX_SEND_BACKS from 2 to 1 in the spec produces 30
disagreements out of 420, and the harness names the input that separates them -
`total=1 judged=1 unmet=1 files=0 prior=1: ring says escalate, twin says
sendBack`. A parity check nobody has seen catch a divergence is a parity check
that might be comparing nothing.

FIVE COPIES OF ONE CONSTANT, AND TWO OF THEM WERE MINE.
`MAX_CONCURRENT_WORKERS = 4` lives in the spec, in
rings/SR-00/QueenDelegation.swift, in the byte-identical fork under
agent-server/queen-core - and, found while writing this, twice more in this
loop's own tooling, typed as prose inside the label `bees running (of 4)` in
dash.mjs and snapshot.mjs. A loop that reports on the swarm's discipline while
holding its own copy of the swarm's constant has no standing to. Both now read
it out of the generated artifact, and print `(of ?)` rather than `(of 4)` when
the artifact is absent: an invented constant that happens to be right is the
same defect wearing a correct answer.

The comparison runs in the heal chain every round, so "they agree" cannot decay
into "they agreed when somebody last looked". A missing side is reported as
missing and exits non-zero - the one answer this must never give is a green
tick for a comparison it did not make.

The compiler is built into trios/.trinity/t27c-build, so nothing writes into
~/t27, which another agent owns under L0b.

`tri t27-gen`, `tri t27-parity`. 225 calibration cases.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L0's entire argument is that transcribed rules agree until someone edits one.
Until the transcriptions are gone, the parity count is the only thing standing
between "they agree" and "they agreed when somebody last looked" - so it goes
where the round is read, not in a file nobody opens.

A COUNT of agreements, not a percentage. A percentage over a grid whose size can
change reads the same whether the grid shrank or the agreement grew, and the
grid here is bounded by choices in the harness that may widen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gHashTag
gHashTag merged commit 0368ae1 into feat/queen-supervisor Sep 5, 2026
2 of 3 checks passed
@gHashTag
gHashTag deleted the t27/ring-00-parity branch September 5, 2026 19:17
@gHashTag
gHashTag restored the t27/ring-00-parity branch September 28, 2026 12:25
@gHashTag
gHashTag deleted the t27/ring-00-parity branch October 8, 2026 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant