Skip to content

fix(loop): two things that existed in two places, and nothing comparing either - #434

Merged
gHashTag merged 2 commits into
feat/queen-supervisorfrom
t27/toolchain-path
Sep 5, 2026
Merged

gHashTag merged 2 commits into
feat/queen-supervisorfrom
t27/toolchain-path

Conversation

@gHashTag

@gHashTag gHashTag commented Sep 5, 2026 •

Copy link
Copy Markdown
Owner

Two findings of one shape, in the same afternoon.


1. The toolchain block named a binary that has never existed

which t27c finds nothing on this machine. A search of the whole filesystem on 2026-09-06 returned exactly one binary — the one built into .trinity/t27c-build. The path the skill documented, ~/t27/target/release/t27c, has never existed.

Worse, the command above it was cd /Users/playra/t27/bootstrap && cargo build --release, which writes into the tree L0b says another agent owns.

The Makefile had already learned this and wrote it down at Makefile:913: the ring gate looked for that same path, found nothing, printed [SKIP], exited 0, and make check counted it as passed — "both rings were unchecked the whole time."

The instruction lived in two places, one right, and the wrong one was the one a reader meets first.

A calibration case now fails if a runnable build command carries no CARGO_TARGET_DIR, or if the t27c it names is not on disk. Fenced blocks only — the first version failed on its own explanation, the paragraph quoting the old wrong command in order to explain why it was wrong. Fourth time an assertion in this suite has been written against prose.


2. Seventeen Swift files exist twice, and the audit had the story backwards

rings/SR-00 and agent-server/queen-core/Sources both hold seventeen Swift files. The self-audit has carried this for weeks as finding D1 — "a byte-identical fork of 16 SR-00 files, one diverged" — which reads like a tidying job.

Measured, and it is not one:

17 file(s) exist in both trios/rings/SR-00 and trios/agent-server/queen-core/Sources
  16 identical, 0 forked in history, 1 edited on one side only, 0 unreadable
  ~  QueenLocalisation.swift is identical at HEAD and differs in the working tree

At HEAD all seventeen are byte-identical — including the file the audit calls diverged. The 45-line difference is entirely in the working tree: one copy is being edited right now and the other has not been touched. Nothing anywhere would have said so, and the moment it lands the tree has two files that disagree.

That is exactly the state L0 is written about — "they agree until someone edits one" — caught while it is happening rather than afterwards. So the two are different answers, and the distinction is the tool:

LANDED the copies differ at HEAD. Already in history; every build since has compiled two different rules.
in flight they differ only on disk. Not a defect — an edit nobody has mirrored, and saying so before it lands is worth more than finding it after.

Three rules it keeps:

  • Match by basename. SR-00 is flat; queen-core is split into QueenCore/QueenPolicy/queend. A path match finds nothing and reports a clean bill of health — the failure this directory keeps running into.
  • Unreadable is not identical. A file git cannot show at HEAD is unknown.
  • It never edits. The divergence it found belongs to another agent's uncommitted work; mirroring it would be taking a decision that is not this loop's to take, on a file it does not own.

Runs in the heal chain every round. tri forked-files.

228 calibration cases, each shown failing against the state it is meant to catch.

🤖 Generated with Claude Code

…, and told you to build it where you may not write

`which t27c` finds nothing on this machine, and a search of the whole filesystem
on 2026-09-06 returned exactly one binary - the one built into
`.trinity/t27c-build`. The path the skill documented,
`~/t27/target/release/t27c`, has never existed. Worse, the command above it
was `cd /Users/playra/t27/bootstrap && cargo build --release`, which writes into
the tree L0b says another agent owns.

The Makefile had already learned all of this and written it down at
`Makefile:913`: the ring gate looked for that same path, found nothing, printed
`[SKIP]`, exited 0, and `make check` counted it as passed - "both rings were
unchecked the whole time." The instruction lived in two places, one of them
right, and the wrong one was the one a reader meets first. That is the same
shape as the boundary rule with three implementations and the constant with five
copies: the defect is never the copy, it is that nobody compared them.

A calibration case now reads the skill and fails if a runnable build command
carries no `CARGO_TARGET_DIR`, or if the `t27c` it names is not there.

FENCED BLOCKS ONLY, because the first version of that case failed on its own
explanation - the paragraph quoting the old wrong command in order to explain
why it was wrong. Fourth time an assertion in this suite has been written
against prose; markdown has no comments, so the rule is that a reader copies
what is inside a fence and nothing else counts.

226 calibration cases.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions github-actions Bot added the fix label Sep 5, 2026
…o things

`rings/SR-00` and `agent-server/queen-core/Sources` both hold seventeen Swift
files. The self-audit has carried this for weeks as finding D1 - "a
byte-identical fork of 16 SR-00 files, one diverged" - which reads like a
tidying job.

Measured, and it is not one. At HEAD all SEVENTEEN are byte-identical,
including `QueenLocalisation.swift`, the file the audit calls diverged. The
45-line difference is entirely in the WORKING TREE: one copy is being edited
right now and the other has not been touched. Nothing anywhere would have said
so, and the moment it lands the tree has two files that disagree.

That is exactly the state L0 is written about - "they agree until someone edits
one" - caught while it is happening rather than afterwards. So the two are
different answers and the distinction is the tool:

  LANDED     the copies differ at HEAD. Already in history; every build since
             has compiled two different rules.
  in flight  they differ only on disk. Not a defect - an edit nobody has
             mirrored, and saying so before it lands is worth more than finding
             it after.

Three rules it keeps. Matching is by BASENAME, because SR-00 is flat and
queen-core is split into QueenCore/QueenPolicy/queend - a path match finds
nothing and reports a clean bill of health, which is the failure this directory
keeps running into. A file git cannot show at HEAD is `unknown`, never
`identical`. And it NEVER EDITS: the divergence it found belongs to another
agent's uncommitted work, and mirroring it would be taking a decision that is
not this loop's to take on a file it does not own.

Runs in the heal chain every round. `tri forked-files`. 228 calibration cases,
each shown failing against the state it is meant to catch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gHashTag gHashTag changed the title fix(skill): the toolchain block named a binary that has never existed, and told you to build it where you may not write fix(loop): two things that existed in two places, and nothing comparing either Sep 5, 2026
@gHashTag
gHashTag merged commit 51dcfe7 into feat/queen-supervisor Sep 5, 2026
1 of 2 checks passed
@gHashTag
gHashTag deleted the t27/toolchain-path branch September 5, 2026 20:26
@gHashTag
gHashTag restored the t27/toolchain-path branch September 28, 2026 12:25
@gHashTag
gHashTag deleted the t27/toolchain-path 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