Written for the other machine, which asked. Everything in it was read off the
running host rather than remembered.
Also adds docker/ci/ -- the CI image recipe and a capped runner -- because the
image existed on exactly one host and its Dockerfile was in a scratch directory
under /tmp, which was swept. That is the same shape as every other thing this
consolidation has turned up: something correct that exists in one place.
docker/ci/Dockerfile rust 1.98.1 + the apt list copied from ci.yml
docker/ci/Dockerfile.ffmpeg + ffmpeg, which sylpheed-export shells out to
docker/ci/run 6 CPUs / 7 GB / NO SWAP, named cargo volumes
The rule the runner exists to enforce: every heavy command goes in the capped
container. CARGO_BUILD_JOBS caps codegen units, not rustc's threads, not the
linker, not the test harness -- a bare host build is unbounded and has frozen
this box repeatedly.
The document also records the two agent defects the other machine will meet:
a brief change does not reach a RESUMED session, and nothing brought an agent
back to its own red PR (fixed in #24, which is itself subject to the first).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`mesh_consistency_disc.rs` had the only conflict: this branch added a
`Sightings` type alias where #22 replaced the file's private `disc_root()`
with the shared `common::disc_root`. Both kept — they are unrelated edits
that happened to land in the same lines.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two gaps the first post-migration decoder iteration exposed, both in the same
place — the loop ends before it can observe its own result.
1. Step 1 read notifications but never looked at the agent's own open PRs. It
opened #23, labelled the issue `state/needs-human`, and stopped; nothing in
the brief would ever bring it back to a red check. Next iteration it planned
to start a new question on top.
2. It called the merge resolved on `cargo build -p sylpheed-cli` — the crate the
conflict was in. The break was in `sylpheed-viewer`, which neither side of
the merge edited: one branch added a `ComposeOptions` field, the other had a
literal construction of it. The crate you just fixed is the one place the
breakage cannot be.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GITEA-SETUP.md listed `propose-work` as unbuilt, and this PR builds it without
touching that list, so merging would leave the doc describing a tool as missing
that exists. Strike it the way `gitea-verify` already is: say what was built,
then say what is still missing — here, an end-to-end run, which only the agent
box can do because only it holds a token that can make the POSTs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`decoder-loop.md` has had `## Each iteration` since 2026-09-04, ending in
7. Commit, `push-work`, open the PR, label the issue `state/needs-human`,
and stop.
`port-loop.md` has never had that section at all. It states the rules -- "you
cannot close your own work", "you move an item to state/needs-human", work
reaches main "through pull requests" -- but nowhere gives the STEPS that carry
them out. The Port agent was told the rule and never the procedure.
Two steps were missing entirely, and both are Phase 7 check items:
* READ YOUR NOTIFICATIONS first. They are polled and nothing pushes them, so
an agent that skips this never receives anything addressed to it -- and the
symptom is silence, not an error. That is GITEA-SETUP.md Phase 7 check 1.
* OPEN THE PR AND SET THE LABEL. That is Phase 7 check 2.
The second carries a trap worth naming in the brief rather than in a runbook:
`docker/port/bin/push-work` ONLY PUSHES. Verified by reading it -- no /pulls
call, no `Closes #`, no label; its refusals (no main, no force-push) are
intact. `propose-work`, which would do all three, is still unbuilt --
GITEA-SETUP.md's own words are "the other two thirds being manual is how they
get skipped". The capability is there (`pull_request_write` and `issue_write`
are both in the pinned MCP tool set), so this is an instruction gap, not a
permissions one.
Written to mirror the Decoder's shape while using the Port's own vocabulary --
a gate is an artifact, verify against captures rather than our renderer, state
the expected number first, `authored/` entries carry a `why`, never an invented
number where a measured one is pending.
Found by the Pi agent while answering a Phase 7 readiness question. My own
check had been decoder-only, which is why the asymmetry survived it.
Refs #11
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
§§1-9 were written on fabi-Hyrican-PC. On the other desktop the ~/.sylph-*
credentials do not exist, the Pi does not resolve, and stable is 1.90.0 rather
than the 1.98.1 §8 records -- so §8.2 (fetch the WASM bundle) and §8.4 (Phase 7)
cannot be run from here at all. Says which of the four steps can.
Measured rather than carried over: protection holds (10/10), fmt is 774 hunks
across 154 files, check-citations is 19, and the tests are 207/0/14 across 30
suites. Two of those need reading carefully:
* clippy DIVERGES. The runner is rustc 1.98.1 -- read out of job 794's log,
not assumed -- and is clean; here 1.90.0 exits 101 on only_used_in_recursion
at vfs.rs:85. That is #15 ceasing to be theoretical. It is NOT evidence that
CI's green is fake, which is the §7 lesson-5 inference in the other
direction.
* the test tally matches to the unit while measuring something else. 15
*_disc.rs files resolve disc_root() through a hardcoded absolute path, so
unsetting SYLPHEED_DISC does not skip them: the disc suites RAN here (1936 s,
mesh_consistency_disc alone 1220 s) and skipped on CI (2.4 s total) -- and
both report 207/0/14, because the skip path returns from a test that still
passes. Good news for #14, since this run is the stronger evidence; and worth
an issue, since SYLPHEED_DISC looks like a control and is not one.
I got that last one wrong first -- inferred "the counts cannot match" from "the
fallback resolves", which is §7's shape a sixth time, recorded as such.
Also: a plain `git clone` of this repo fails three ways on the pack that still
carries the 545 MB; --filter=blob:none works. And §6's tokio claim was
challenged and survived -- every use is inside a #[cfg(test)] module.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Written to be read cold by a session with no context: what is established
versus what is someone's claim, which of the four actors the gate actually
binds, and what is in flight but unpushed.
The transferable part is §7 -- one failure shape recurred five times in two
days across two agents and the assistant: a property inferred from something
ADJACENT to it rather than tested directly. Protection from a settings page,
reachability from a DNS record, a label count from a grep that matched the
function definition, Gitea's host from a DNS lookup, and a clippy version from
rustfmt output parity. The last is the sharpest: rustfmt 1.8.0 and 1.9.0, nine
months apart, both emit 774 hunks here, so formatting parity carries no
information about which clippy ran -- and the conclusion drawn from it (that
CI's green was cached or ungated) was wrong in a way that would have sent
someone chasing a phantom.
The two instances already in "Checks that were kind once" were correct
when written and decayed. The third was wrong on its first commit, and it
arrived by a different route: the check and the tree's failure to pass it
land in the same change, so the softening writes itself.
Concretely — the Clippy step had never run (no component in the
toolchain), and the tree is not clippy-clean, so fixing the step and
turning it red are the same commit. The first draft paired the fix with
`continue-on-error: true` and a comment promising removal once the debt
was paid: an expiry date nobody set, in the shape #12's closing line had
already ruled out for rustfmt. Reverted on reading it.
Adds the distinction, a table separating decay from dirty authorship, and
an earlier tell than the mechanical test:
If you are writing the softening in the same commit as the check,
the thing you want is an issue, not a flag.
The mechanical test is unchanged and still correct; this only catches the
same failure sooner, at the keyboard rather than at review.
Refs #12, #13
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
Two rules that look unrelated and are one failure, plus the change that makes
the second enforceable.
1. A FINDING REACHES `main` BEFORE THE CODE THAT CITES IT. A citation resolving
only on a peer branch is dead the moment it merges. Not hypothetical: 495
decoder and 366 port commits sit off `main`, and `port/scripts/boot.gd`
already cites two docs/re pages present on neither its own branch nor main.
2. A CHECK MAY ONLY SOFTEN AGAINST A CONDITION IT CAN TEST -- the Pi agent's
wording, and better than mine, because it is applicable while writing rather
than a call to be vigilant. The mechanical form:
Can this branch tell the difference between "not yet" and "no longer"?
`gitea-protect --verify` printed ⚪ "not a collaborator (yet)" and continued,
so the only instrument checking Write-not-Admin could not report that gate
being REMOVED. `check-citations` reported peer citations instead of failing
them, because under the old topology that was unfixable from the container.
Both were correct AND kind when written; neither recorded that the kindness
had a scope. Nobody edits these into being wrong -- the world moves and the
allowance stays, which is why they survive review. The smell is leniency with
an expiry date nobody set; the fix is the testable-condition rule.
check-citations gains `--for-merge`, which turns the peer class into a failure.
A flag rather than a new default because BOTH readings are still live: mid-work
on a topic branch the peer class really is unfixable noise. What the old code
could not express is where the code is GOING, and that is a condition the caller
can state. Measured on this tree: 19 citations resolve only on a peer branch --
which is the size of the #7-depends-on-#8 edge, not the 2 I had counted in
boot.gd.
The selftest gains that third class, because a flag whose classification is
unexercised is the shape this rule exists to catch. Controlled: emptying
PEER_REFS makes the peer case collapse into "nowhere" and the selftest reports
🔴 BROKEN, rc=2.
⚠️ Pre-existing and NOT from this change: the default run already exits 1 on 4
citations of `export/...` paths. Those are the generated tree, gitignored by
design, and main's copy of the tool fails identically. The CITE regex treats
`export/` as a repo prefix. Reported, not fixed -- it is the port's file and its
call whether the regex or the citations are wrong.
Phases 1-4 and 6 are done on the instance. This file still opened with "Nothing
exists on the instance: no agent users, no API tokens, no labels, no milestones,
no branch protection" -- every clause of which was false by the time the merge
that carried it landed.
Replaced with a table of measured state, and each row says what was MEASURED
rather than what was run:
* protection is verified behaviourally -- a real push to main refused with
`pre-receive hook declined`, as the repository owner -- not read off a
settings page. That distinction is the whole subject of this file.
* the tokens are probed: right identity, 403 on branch_protections for both
agents, so the Write-not-Admin carve-out is demonstrated and not asserted.
* the labels are 11 because the instance holds 11.
And a standing note that this block is the part most likely to be wrong, with
what to believe instead: `gitea-protect --verify` and the issue list MEASURE,
this block REMEMBERS. A remembered status is a cache with no invalidation, which
is the same failure as a 1,227-line BLOCKED.md and as the two documents this
runbook was split across an hour ago.
Caught by the Pi agent against the live instance after Phase 4 ran. The tool
creates 5 state/*, 2 agent/*, 4 kind/* = 11.
Where the 12 came from is worth a line, because it is a shape that recurs:
$ grep -c '^mklabel' tools/gitea-setup
12
$ grep -n '^mklabel' tools/gitea-setup | grep -v ':mklabel "'
74:mklabel() { # name colour description
I counted the function DEFINITION as a call. A measurement taken one token away
from the thing being measured -- the same shape as reading protection off a
settings page and reachability off a DNS record, which is now three today. The
version that cannot make this mistake is counting what the instance holds, and
that is what found it.
Two things that read as protection while being none.
Phase 2's rule binds everyone who reaches Gitea through the API or the web, and
does not bind anyone with `gitea admin` in the container -- which includes the
supervising agent that created the agent accounts and minted their tokens. From
that shell the rule is editable and an admin token is one command away. That is
the boundary of what the phase buys, not a hole to plug there, and the document
read as though the gate were universal. Phases 1 and 2 gate the two CONTAINERISED
agents, whose design assumption is that policy lives where they cannot reach it;
a supervisor with a host shell is not in that set.
And `gitea-setup` finished by telling the reader to go and build a Gitea project
board by hand, four sections after the doc explains that a board is a second copy
of the state to hand-sync and is precisely the failure that produced a 1,227-line
BLOCKED.md. A tool instructing you to do the thing its own documentation argues
against is the drift this whole surface exists to end.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
The runbook existed as two documents -- a published page and this file -- with
no mechanism keeping them equal, only an intention to remember. Two versions was
the predicted outcome of that, not an accident on top of it. This is the fold,
and the rule that follows it: THIS FILE IS THE SOURCE, the page is derived from
it. When something is urgent enough to push to the page first, it lands here in
the same turn, not "shortly after".
Four things the file did not carry:
* YOUR OWN PUSHES TO main STOP. `enable_push: false` compiles to CanUserPush,
which returns false with no bypass for admins or the owner -- quoted from
the source. Three commits went in by direct push the day this was written,
so the first notice would have been mid-task. Now a check step.
* the token files' MACHINES, which the table had lost.
* do NOT add `write:repository` to the `fabi` token. That scope IS a push
credential. Written down because that advice was given, in chat, by the
author of this file.
* Gitea 1.25.5 confirmed from the desktop too, not just the Pi.
And one thing deliberately NOT folded in: the page said the desktop's outbound
HTTP was blocked, and that is false. `python3 -c 'urllib...'` returns
200 {"version":"1.25.5"} from this box. What is refused here is `curl`, by a
local permission prompt -- which I read as a network constraint and then
published as one. The Phase 3 locations stand; the reason given for them did not.
The "not verified" section now separates WRONG from UNCHECKED. Four entries are
wrong -- requiring an approval does not close the gate, the check could not have
caught that, the token scope, the reachability -- and the pattern in all four is
identical: a property inferred from something ADJACENT to it (protection from a
settings page, reachability from a DNS record) instead of tested directly. That
is the frozen-splash failure, committed in the document about avoiding it. The
first two were caught by the other agent, which is the argument for the review
gate this file exists to build.
Phase 2 as a file. Six settings where two are load-bearing and both were missing
from the first draft is the shape of thing that gets mis-clicked at 1am, so it
goes through the API: what was applied is readable in a diff, and `--verify`
can re-check it later instead of it being checked once.
--verify states its expectations INDEPENDENTLY of what the apply path sends.
A check derived from "whatever we posted" cannot fail -- it re-derives the
expectation from the thing under test, which is the same instrument-shaped
failure as a check that passes on an instance with no rule at all.
It also asserts both agents are still Write and not Admin, because an agent
promoted to Admin can edit the rule and then merge, so a green rule proves
nothing on its own. That is the `gitea-verify` card from "Still to build";
what is left of it is only putting it on a timer.
`block_admin_merge_override` stays false on purpose, and the reasoning is in
the file: approvals are whitelisted to `fabi`, and Gitea will not let `fabi`
approve a `fabi` PR -- so with the override blocked, a human-authored PR could
never reach one approval and could never merge at all. The override is not a
hole in the agent gate because the agents are Write, not Admin. Phase 1.2 pays
for that; this is where it is spent.
Reads the repository-scoped credential that already exists on the agent box
(~/.sylph-git-credentials) rather than the issue-only ~/.sylph-gitea-api-token,
which every branch-protection endpoint refuses. That keeps the setup needing no
new credential, and keeps push rights on one machine.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
Phase 5 of docs/agents/GITEA-SETUP.md, plus a correction to Phase 2 that the
runbook could not have known it needed.
gitea-mcp v1.7.0 goes into both images, pinned by the sha256 the release
publishes and smoke-tested with `--version` at build time, so a bad pin fails
the build instead of the agent. Each entrypoint registers it at user scope for
that container's own identity, remove-then-add so a restart is idempotent.
The token is passed BY PATH. `-e GITEA_ACCESS_TOKEN=$(cat …)` would write it in
cleartext into ~/.claude.json, which every session in the container reads;
GITEA_ACCESS_TOKEN_FILE is new in the pinned version and leaves the secret in
its read-only mount. Verified against the binary's own --help, not assumed.
The tool filter stops being an experiment. The names are in the release README:
each agent gets issues, notifications, labels, milestones and pull requests, and
NOT `pull_request_review_write`. That one matters because separate identities
open a hole the runbook did not name: Gitea refuses to let an author approve
their own pull request, and does nothing about sylph-decoder approving
sylph-port's. Two agents could satisfy `required_approvals = 1` between
themselves and then merge, since branch protection blocks pushes to main and
never blocked merges.
Withholding the tool is defence in depth; the controls are in branch protection,
and both docs now say so: approvals whitelisted to the human so an agent's
approval does not count, merges whitelisted to the human so an approved PR is
still merged by a person. Phase 2's check gains the step that actually tests it
-- approve the throwaway PR yourself, then confirm the agent STILL has no merge
button. Without that step, the check passes on an instance where the agents can
merge each other's work.
Also settles two entries on the runbook's own "not verified" list: the tool
filter names, and the Gitea version (1.25.5, whose API schema carries
enable_merge_whitelist and enable_approvals_whitelist under those names).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
WORKFLOW-gitea.md said what the working surface is and why. It did not say how,
in what order, or how to know a step worked -- so it was a destination with no
route. This is the route.
Seven phases, each with a check, each marked 👤 human or 🤖 me:
1 identities two agent users, Write NOT Admin
2 protection main behind a PR + 1 approval -- BEFORE tokens exist
3 tokens three principals, three tokens, three files
4 structure labels and bundles, and deliberately NO Kanban board
5 MCP gitea-mcp v1.7.0, per-agent identity, user scope not .mcp.json
6 items migrate the live findings only -- not 1,227 historical lines
7 restart and verify the three things that must be true
Phase 1 leads because it is not hygiene: Gitea does not let a PR's author
approve it, so while an agent IS `fabi` either the human cannot approve its work
or it can approve its own. The review gate does not exist until the agents are
distinct people. (It also fixes 495 commits of agent work attributed to the
human's email.)
Phase 2's check is a real push and a real PR, not a reading of the settings
page. The reason protection lives in the server rather than in a brief is that
it should not depend on good behaviour -- so verifying it should not either.
Phase 5's install facts are checked, not remembered: gitea-mcp v1.7.0,
`gitea-mcp_Linux_x86_64.tar.gz`, `-t stdio -H <host>`, `GITEA_ACCESS_TOKEN`.
The `--tools` filter is flagged as an EXPERIMENT that might exclude the merge
tool as defence in depth -- explicitly not a substitute for phase 2.
Ends with what is still to build (propose-work, an attachment uploader,
gitea-verify, the wiki landing page) and a "what I have not verified" section:
the approve-your-own-PR behaviour, the --tools names, the Projects API, and the
Gitea version -- the API was unreachable from my sandbox three times running.
The two loop files ARE the prompts -- `sylph-port` and `sylph-decoder` read them
off the host at launch -- so the workflow change had to land here or it would
not reach the agents at all.
PROTOCOL.md gains four sections:
* Work items -- issues, milestones as bundles, the state labels, and that
`state/blocked` uses DEPENDENCY EDGES, never prose. A prose blocker is what
let a 1,227-line BLOCKED.md go stale.
* Messages -- an ask is a `kind/ask` issue, not a SendMessage. With the part
that matters: 🔴 NOTHING PUSHES. Notifications are polled, at the top of
every iteration, and therefore an agent must NEVER wait on an ask -- set the
edge, take the next item. The channel this replaces dropped 21 consecutive
messages to a stale session id and reported success each time.
* Pull requests -- one item per branch, `Closes #N`, and you may not merge
your own. Branch protection enforces it; the rule is written down so the
agent knows it, not so it depends on the agent.
* Each iteration, in order -- notifications, sync, one unit, hand over, stop.
Also: evidence a human must look at now attaches to its issue, and a blunt
"never commit game content, under any directory name" with the 545 MB that
prompted it.
The two briefs shrink 697 -> 298 lines. They had accreted five dated focus
blocks between them -- sole-focus orders, F1-F6 queues, one-off "merge this
branch on your first iteration" instructions -- which is a queue, and a queue
belongs in the tracker. What is KEPT is what outlives its bug:
* ask of any check, what would this still report if the feature were absent?
Three instruments passed a splash that never animated.
* the instrument must sit at or above the thing that can break -- the
InputEventAction / input-map miss.
* R1, and grep REFUTED.md before proposing.
* the .pe is primary and the database is somebody's analysis of it.
* the oracle is the real game in Canary, not any renderer of ours.
⚠️ NOT YET TRUE when this lands: the agents have no Gitea users, no API tokens
and no MCP server, so the issue tooling these briefs assume does not exist yet.
The agents are stopped. Setting that up is the prerequisite for restarting them.
Takes the port branch up to 77320d5e -- the state the human play-tested on
2026-09-02 -- for SOURCE paths only. Not a branch merge: `auto/port-p6-audio`
is 366 commits and 938 files, and most of that must not land.
WHAT COMES IN (76 files, all human-confirmed working):
* the logo splash animation. 08ed3dd1 found it: `pose_at` ASSIGNED the settle
instant instead of clamping to it, so the splash never animated at all --
and the same bug manufactured a passing harness result, because the harness
photographed t past the settle. Confirmed by play-test: "cannot notice any
obvious difference from the actual game."
* gamepad input -- (A)/(B) bound additively (`ui_accept` ships with NO joypad
binding), stick latched with hysteresis at the game's own 61% digitise
threshold. This is what made (A), video-skip and Extras work at all.
* menu navigation and flow, menu audio, the exporter, the authored
declarations, and 23 verification tools under tools/port/.
WHAT IS DELIBERATELY LEFT ON THE BRANCH:
* everything after c0ae460a -- the F5/F6 title-timing investigation, whose own
tip commit calls itself a "hand-off for one-minute human checks". Unchecked
by definition; it goes through the new review gate like anything else.
* the OPTIONS menu work of 2026-09-03. Real, probably good, NOT play-tested.
* the F1 repeat mechanism, which its own commit calls "deliberately inert".
WHAT MUST NOT LAND, AND WHY THE .gitignore CHANGED:
545 MB of extracted game content was committed on that branch -- 850 sprite,
audio and transcoded video files under `export-probe/` and `export-probe2/`,
plus 246 MB of loose .wav and .tsv at the repo root. This repository's own
rule, in this file, is "never game content".
The rule was not missing. It was written, and it was tightened on that very
branch, with a careful comment explaining why BOTH `export/` and `data/base/`
had to be listed -- while the exporter was writing to a third name that
nobody had thought to list. Enumerating names is the thing that failed. So
the ignore rules now describe the SHAPE: any top-level `export*/`, game media
by extension, and loose capture output at the root. Verified both ways -- it
catches all four offenders and ignores nothing currently tracked.
Verified: `cargo check --workspace` clean; all nine GDScript files parse in
project context, with a positive control (an injected syntax error is detected,
3 lines) so the clean result means something. `tools/port/check-all` was NOT
run -- it needs the container, the export tree and a display.
The human wants to direct this project from a web UI rather than chat or Remote
Control, so Gitea becomes the working surface. No new store: adding a second
copy of the truth is this project's defining failure mode, and Gitea already
holds the code. Its first-party MCP server (gitea/gitea-mcp v1.7.0, checked) has
issues, labels, milestones, PRs, attachments and notifications.
ISSUES replace BLOCKED.md. Milestones are bundles the human defines; issues are
items agents propose and the human approves. The state labels end in
`needs-human`, which is the state the whole model turns on and the one no
off-the-shelf tool models -- the market has converged on removing the human.
`blocked` uses Gitea's DEPENDENCY EDGES rather than prose, so "the Port is
blocked on the Decoder answering X" becomes queryable and closes itself.
PULL REQUESTS, the human's proposal, adopted -- and a bigger improvement than it
looks. Today's long-lived auto/* branches have drifted 280 and 373 commits apart,
which is unreviewable by construction. One PR per item makes the human gate
NATIVE rather than a label convention, binds the change to its item, and enforces
the sizing rule: an item too big to review in one sitting was too big to be an
item.
🔴 Agents must not merge their own PRs, and pull_request_write includes merge --
so this goes in BRANCH PROTECTION on main, not in a document asking them not to.
Same principle that fixed the build-jobs cap: policy where the agent cannot reach
it.
WIKI -- the human suggested it for RE findings, and that half is declined with
reasons. A finding's value is that it sits beside its evidence, versioned with
the code that consumes it; the wiki is a separate git repo, so a decode
correction and the exporter change depending on it could never be one reviewable
PR. And wiki edits bypass review: the REFUTED.md reclassification changed the
file both agents read to decide what not to try, and as a wiki edit it would have
been an unreviewed mutation of shared ground truth. The wiki takes human-facing
orientation instead -- runbook, navigation, container notes, and a landing page,
which closes the real gap that there is no view of what is happening except
container logs.
FILES: three needs, three homes. Agent-to-agent transient stays in /exchange.
Evidence a HUMAN must look at attaches to the issue it belongs to -- it travels
with the item and cannot be orphaned from the claim. Evidence a finding cites
stays in git. Note the MCP exposes attachment_read only; upload needs a direct
REST call.
tools/gitea-setup creates the labels and bundles, idempotently, with --dry-run.
Blocked on a token with write:issue -- the push credential is write:repository
and every issue endpoint refuses it, checked rather than assumed.
Two new findings from the human, both about WHEN a title animation starts, and
both handed over rather than guessed:
F5 Does (A) SNAP the title to finished, or ACCELERATE it? The human says they
cannot tell and is right that they cannot -- a three-frame acceleration and a
one-frame cut look identical to an eye. Two routes that should agree: a
per-frame capture (acceleration shows intermediate alphas, a cut shows none)
and the code (assigning a target time and raising a rate multiplier are
different instructions). Their "looks more like a snap on multiple attempts"
is recorded as a PRIOR, not a result.
F6 The title's sweeping white glow -- ptloop01/ptloop02, the blue PCB-like lines
-- starts only when the plate appears in the real game, and starts earlier in
the port. A lead from the exported declaration, mine and unverified: those
elements are keyed at t = 0, 70, 100, 238, 250 while the plate reaches full
alpha at 236, with pteff02 keyed at exactly 236 and ptlogo_back2eff and
ptcopyright at 238. 236-238 is a synchronisation point in the declared data
and a human just reported a behaviour change there. Flagged AGAINST itself
too: 238...250 looks equally like an exit ramp -- ptcopyright uses that shape
and starts nothing -- and the sweep lives in a nested .rat leaf with its own
timeline.
F6 bears on clock: "shared" and on F4: if a title element does not move until
the plate arrives, either the declared data says so and our keyframe reading is
wrong, or something at the plate's arrival STARTS it, which is a mechanism
nobody has proposed.
And the process change, which is the human's and outlives this item:
"attacking the 'whole' mission was too big for them to handle. Split the given
missions and tasks into even smaller tasks which they can tackle and give to
a human for feedback."
PROTOCOL.md gains "Work in units a human can check in a minute". A milestone is
not a unit of work, it is a bag of them. A unit is right-sized when it ends in
something a person can judge in under a minute WITHOUT READING ANYTHING, and
each one states its question, what the human looks at, and what it does NOT
cover. Do one, hand it over, stop -- an unverified fix under a second change
makes a regression two-variable.
The evidence for the rule is this week: the splash sat through a whole milestone
and took one day once scoped to "does it animate?". The bar is a HUMAN check,
not a green tool -- three instruments passed a frozen screen.
I wrote "whether the game snaps both clocks forward" into yesterday's F4 and the
human asked which clocks. There are none: authored/flow.json sets
`clock: "shared"`, so the title's two composited builds -- build 4 the artwork
(finishes t~=118) and build 2/3 the plate (full alpha t=236) -- run on ONE clock
started together. Left standing, that phrasing sends an agent hunting for a
second clock this corpus says does not exist.
Corrected in both briefs and in the playtest page, marked as a correction rather
than silently edited.
And the question is better than I first framed it. `clock: "shared"` is
AUTHORED, and the port's own plate-arrival-halves.md calls it "not falsified...
not confirmed to better than ~20 % either", with an unresolved anchor
disagreement inside one binary: the reconciliation picked t=118 while
settle_time() returns 160 and the boot prints "settles at t=160".
So F4 is a TEST OF THAT PREMISE, and the discriminator is observable -- press (A)
early, while the wordmark is still building in, and watch the ARTWORK rather
than the plate:
advances the shared clock -> the artwork SNAPS to finished
only forces the plate -> the artwork KEEPS ANIMATING its build-in
Both briefs now say to answer F4 before building on `shared`, and tell the port
not to choose what "jump" means.
"Menu walk and navigation is fine. Video skips too. Extras open. New Game
shows new game intro video." -- 2026-09-02
P5 is done. Its gate was "a human clicks through it", the retro said it had been
waiting on that and not on code for the whole milestone, and it has happened.
PORT-MISSION.md updated. The NEW GAME gap is accepted as-is.
Four findings, three of them the Decoder's:
F1 THE MENU REPEATS ON A HELD DIRECTION AND OURS DOES NOT. One step per
deflection was authored as the conservative choice because nobody knew; a
human has now watched the real game and it repeats, "at a medium pace... slow
enough to see which item is selected". That settles the existence half of H1
against us. The RATE is still unmeasured and must not be guessed -- the
description bounds it and supplies no number. Decoder measures initial delay
and repeat interval as frame counts; the port implements the mechanism and
waits for the numbers.
F2 THE SFX ARE TOO LOUD BECAUSE THERE IS NO MIX AT ALL. Measured: confirm
-17.7 dB mean / -0.0 dB peak, 3 dB hotter in mean than the music and 6.4 dB
above move. No volume or gain value exists anywhere in export/ or authored/,
so every clip plays at unity on one bus. Decoder: is per-cue or per-bus gain
on the disc -- the cue table is the obvious place and cue 1103 is already
decoded. Port: gains at PLAYBACK as data, and explicitly NOT normalisation in
the exporter, which destroys the relationship between clips and cannot be
undone by a modder.
F3 SOMETHING IS MISSING ON THE TITLE SCREEN. The export carries one music file
and the port plays nothing on the title. Which cue does the title play, and
is there a sting on the plate or on accept? A negative needs a positive
control: find the menu's cue by the same method first.
F4 (A) SKIPS FORWARD THROUGH THE BOOT AND WE IMPLEMENT TWO OF THREE PRESSES.
In the game: skip video, reveal plate immediately, accept plate. The middle
one is missing here. Whether the game snaps both clocks forward or only
reveals the plate is a question, not a detail -- and it is a cheap second
route to the plate-arrival question, since a press that skips to the plate
says where the game thinks the plate belongs.
H3, the plate delay, is ACCEPTED -- "feels the same... sufficient". Left
unattributed rather than closed green.
"Looks good! Cannot notice any obvious difference from the actual game.
Mark logos as done." -- 2026-09-02
Not "the check passes": a person compared the port against the real game and
could not tell them apart. That is the oracle, and it is the strongest result
this port has produced. The sole-focus order is lifted; both agents return to
their milestones.
The fix was one word -- pose_at ASSIGNED the settle instant instead of clamping
to it, so every query returned the settled pose whatever the clock said. The
same line manufactured the false green: the capture harness shoots after two
frames, so it was photographing t~=2 units, which looked settled only because
everything looked settled. The 0.01 % agreement that closed H2 was measured
through the accident. One bug produced the defect AND the evidence of its
absence.
Verified here before it went to the human, by film rather than by claim:
motion 16.4 % -> 27.7 %, distinct luma states 26 -> 43, the publisher ramp 6
steps -> 13 in one continuous run, and the developer splash's interrupting
0.50 s freeze gone. The publisher trajectory rises to a peak and settles back --
the crossfade signature.
The port then closed a gap motion-census names in its own header ("a wrong ramp
that moves every frame passes here") with a shape check pre-registered from the
disc, measured off a film, on a non-overlapped strip, in ratios so the texture
divides out: rise:last declared 1.20, measured 1.20 exact.
Kept as the standing lesson, because it is the fourth instance: an instrument
that sits below the thing under test cannot see it fail. Ask of any new check
what it would still report if the feature were entirely absent.
Explicitly NOT claimed: P5's gate is "a human clicks through it" and nobody has
said the milestone is met. The briefs say so, and say not to record it on the
human's behalf.
The decoder's end-to-end pipeline work returns to normal priority rather than
being dropped -- it is what decides whether the port's 60 units/s matches the
game. The ramp is now right in SHAPE and unverified in DURATION.
A human on a GPU at ~140 fps: "the logos just switch, there is no animation at
all." Measured from a real boot with --film at 0.05 s, then per-frame change:
splash moves 1.30 s of 7.95 s = 16.4 %
publisher splash 0.30 s of motion, then 3.20 s FROZEN
developer splash 0.35 s + 0.25 s, then 2.40 s FROZEN
distinct luma states in 7.95 s 26
A 45-unit build-in cannot be drawn in 26 states, and a fade does not hold one
picture for 3.20 s. The frame counter says 24.8 fps achieved; both are true --
the port is DRAWING 25 times a second and CHANGING almost never.
🔴 Why every check passed, which matters more than the bug:
frozen sweep drives the clock BY HAND -- proves the renderer can draw
pose N, never that the poses are drawn in sequence
settled compare 0.01 % against the capture -- a screen frozen 84 % of the
time matches a settled reference PERFECTLY, that is what
frozen means
achieved fps counts frames DRAWN -- the same pixels 25x/s scores
identically to animating
Every one measured throughput or a pose. None measured CHANGE. Same shape as
InputEventAction bypassing the input map: the instrument sat below the thing
that was broken, so the break could not appear in it.
tools/motion-census closes the class. It measures change and nothing else, and
its --selftest asserts it separates a fade (97.4 % moving) from a switch (2.6 %)
from a frozen film (0.0 %) -- a detector that cannot tell those apart would
report the same green line on all three.
Both briefs: this is the SOLE focus. The port reproduces before changing
anything and gates every fix on a film rather than a still. The decoder maps the
whole pipeline end to end -- disc bytes, the game's per-frame update (does it
interpolate between keyframes or hold?), what is submitted per frame, and what
Canary does to it before a capture records it -- delivered as a SERIES, not a
settled value.
The port should also record the refutation against itself: H2 reads ANSWERED on
the strength of the frozen sweep. The mechanism half stands, the blur is a baked
companion texture. The behaviour half does not.
Both are pushed. The decoder's carries the R1 register reclassification and
tools/stale-instrument; the port's carries the two input fixes, verify-input
and BLOCKED H1-H3. Each branches from that agent's own tip, so it is a
fast-forward on the line they are already on -- and the port must merge before
touching input or it will re-derive a fix that is already asserted.
A human played the port on real hardware for the first time (2026-09-01) and
found four things. Two were port defects, fixed. Two are open and are now both
agents' focus: the PRESS (A) plate arrives late, and the splash fade/blur is
weaker than the game's.
Their verdict on method is the reason this is a brief change and not a ticket:
"the agents were essentially guessing and trying to copy what one would see,
but while they did get close it still is not quite right"
Close-but-not-right is the signature of reproducing APPEARANCE instead of
deriving MECHANISM. So the Decoder's focus block asks, in order: is there a
post-process pass at all, what is it, where do its parameters come from -- and
only then what curve. Both routes, dynamic (GPU state, shader constants, render
targets; add logging to Canary, it is theirs read-write) and static (.pe, the
DB, the paks), with each fact labelled by which produced it.
TEMPORAL-VERIFICATION.md is the other half, and it generalises past the
splashes. We have been photographing the game at time t, and t is never the
same twice: emulator speed varies with host load, Canary presents at ~28.1 fps,
the capture path costs a variable 0.1-10.8 s, and a long-lived x11grab stream
degrades and then freezes. The register already carries FOUR refutations of
exactly this shape. The replacement rule: record a film, not a photograph;
align by CONTENT, not by clock, and report the lag as a measurement rather than
minimising it away; prefer ordering, counts, durations and shape over any value
at a wall-clock instant; anchor on an event; report achieved fps against
requested fps.
Also into both briefs: the input set. The port had no joypad binding for (A) or
(B) and nobody noticed for a whole milestone, because --script sends
InputEventAction, which BYPASSES the input map -- so every check asserted the
code below the map and nothing about the map. The Decoder is asked to DECODE
the full set the game reads rather than discover it by pressing buttons; the
Port is told input is verified at the device level or not at all.
And both briefs now point at the R1 register reclassification, because two of
the ten re-opened entries land on this focus: "the declared keyframe timeline
reproduces the captured splash" is 🟡 our-reader, and the rest() pair is open
in BOTH directions -- while the two splashes are the only screens that reach
that fallback.
Both agents asked for this and neither could do it: the register is the file
they both read to decide what NOT to try, so two agents agreeing is not the
authority for changing it (RETRO-2026-08-31-agreed §7.1).
R1: a refutation whose instrument is one of our renderers is not a refutation,
it is "our renderer disagrees" -- 🟡, not ❌. The motivating case was not
careless work. "Blending those sprites additively worsens every measure against
the capture" killed a real disc field for weeks, and read exactly like a
publishable negative; the renderer behind it had a stale keyframe association,
no leaf geometry and no rotation. Nothing in the entry could have told you.
All 222 entries now end with ⟨instrument⟩, read off each entry's OWN stated
evidence -- never inferred. An entry that states none gets `unrecorded`, which
is 83 of them.
Ten moved ❌ -> 🟡, each naming what would settle it: 8 render-vs-capture,
1 our-reader, 1 harness.
Three things the pass turned up:
* The rest() question is OPEN and had been reading as settled in both
directions -- "rest = last keyframe" was refuted by a sibling argument, and
that refutation refuted by correlating our render against captures. Both legs
are our renderer. Which one you believed depended on which entry you found
first, and it decides the pose every plateau-less element is drawn at.
* A withdrawal never reached its sibling: "2 391 frames, max glyph 0" was
withdrawn because a long-lived x11grab stream freezes and repeats a stale
frame; the 1 674-sample negative three lines above it, same probe, was left
standing as a reinstated measurement.
* 83 of 222 -- 37 % -- record no instrument at all. Not disputed, not safe:
unauditable, and larger than every other group combined.
tools/stale-instrument is the --stale query the rule needs, because a colour
alone re-opens nothing: the failure was that nothing re-opened a claim when the
instrument that killed it improved. Its own --check found a real bug on the
first run -- sys.exit("text") exits 1, so three faults documented as exit 2
were reporting the same code as an ordinary miss.
R1 is now standing text in PROTOCOL.md, with R5's exception: our tool is the
right instrument for a question about our tool.
The R11 self-catch existed only in a commit message and a script comment. §5's
own rule says the file carries the finding, so it belongs in the retro.
Writing the BLOCKED.md pointer, the obvious form -- git show || { echo missing;
exit 4; } -- prints "the file is missing" for a file it has just printed in full,
because piping into head closes the pipe and git dies of SIGPIPE. An error path
that fires on success is worth no more than one that never fires.
Same family as the port's MIX default and my vertex cap, with one difference
worth keeping: both of those needed an outside observer, and this one did not,
because all four paths were exercised rather than the happy one. A script with
three failure branches has three tests and they cost a line each.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The human asked both agents for a critical retro; it reached me relayed through
sylpheed-port, and I am treating it as a message rather than as their word while
staying paused on RE iterations.
Worst failure first: I READ the refutation that mattered and routed around it
instead of auditing it. REFUTED.md killed the blend bit with our own renderer as
its instrument, and I quoted the 'a claim resting on our renderer is a claim
about our renderer' rule at the port in the same session while not applying it to
my own register.
Underneath it is the sharper one: I twice accepted render-derived labels for a
disc-side question. My 'no field separates them' negative was tested against a
partition that was wrong in six places, all six of which the oracle later called
additive.
Also recorded: the silent vertex truncation, a coverage claim written rather than
computed and wrong by four, a batching generalisation refuted by the log it was
written from, and navigation whose fix was worse than the bug.
Two additions to the port's list of shared costs: neither of us has ever given a
negative a positive control, so 'absent' and 'my search does not work' are
indistinguishable in every undecodable page I have written; and we keep
attributing a three-way residual to whichever leg we happen to be looking at.
Their eight proposals attacked one by one -- P2 sharpened into a
re-classification rather than bookkeeping, P5 pushed back on ('suppression
localises disagreement; only the oracle labels it'), the rest agreed with
amendments.
And the check the retro forced: my rival sweep covered the T8aD header and not
the 60-byte declaration entry, whose earlier hunt used the corrupted labels. Swept
properly, 16 of the 35 measured elements have no declaration entry at all and 0
declaration bits separate the other 19. The decode is not underdetermined -- run
because it could have gone the other way.
The PROTOCOL delta is presented, not applied.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
CONTAINER-NOTES said a Canary source change costs a full reconfigure against
/canary and a full compile, and told the reader to budget a session for it. It
was right about the defect -- the warm build tree at /sylph-home/re/canary-build
is configured with CMAKE_HOME_DIRECTORY=/work/xenia-canary, which does not exist
here -- and wrong about the consequence.
Symlinking /work/xenia-canary -> /canary restores the path the tree was
configured with. A one-file edit to command_processor.cc then rebuilt and
relinked xenia_canary in under 10 minutes at -j4, exit 0, no reconfigure and no
OOM. This is how the blend-state logging in the same session got built.
The symlink is untracked inside the repository, so the note also says to remove
it afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port found this in their own §6 and it is in mine identically. I stated the
pass condition as 'exit 0' but left the command silent, so a reader running it as
written sees an empty line and cannot tell success from failure. Worse than a number
without a pass condition, because there is no number.
Now carries '; echo $?' and says why.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port's standard, applied here: a documented command nobody has executed is
the same class as a control that does not execute. Mine did execute, but they were
published without expected outputs, and a command with no pass condition is half a
check -- a reader gets a number and no way to know whether it is the right one.
Each command now carries its pass condition, the placeholders are real shell
variables rather than <branch>, and the last run's results are recorded: 330, exit
0, 0, 1.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port re-derived this the same day and read 329 for my branch where I had
written 328, because a commit landed between the measurement and the check. The
counts rise with every commit on either branch, so they are not the claim.
What does not move with them: main is an ancestor of both, the change sets touch
zero files in common, and the dry-run merge is clean. The document now says that and
carries the commands to re-derive all of it.
A number that goes stale the moment it is written, sitting in a document meant to
inform a decision, is the same shape this week has been full of -- and this one was
mine, one message after recording the class.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
PROTOCOL says a human merges, and both agents have been blocked behind that while
describing it rather than measuring it.
Decoder branch is 328 ahead of main and 0 behind; port branch 257 ahead and 0
behind. main is an ancestor of both, so each is individually a fast-forward.
And they do not conflict with each other: from their merge base the two change sets
touch ZERO files in common, and git merge-tree --write-tree of the two heads exits
clean with no conflict markers. Both can be merged in either order with zero
conflicts.
Nothing was merged. merge-tree is read-only and no branch was modified -- this is a
measurement, and merging remains the human's.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The copy of sylpheed-cli in this container was built 2026-08-29 12:38, before the
keyframe-record-layout fix. The old parser shifted every time by one slot and
could not time a group's final pose, printing a trailing '-':
stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0]
fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0]
Both outputs are well-formed and neither announces its age.
That refutes the premise of screen-transitions.md's 2026-08-29 section, which
argued from 'there is exactly one untimed keyframe, and every element has it'.
There is no untimed keyframe, so the question it answered -- is 0.4 s the missing
duration of that keyframe -- has lost its subject. The ratio test in the same
section is untouched.
And it decodes the number the port asked about: pteff00.prm's final ramp is
70 -> 80 = 10 units, about 0.167 s, not the ~24 this page authored. I tried to
refute the port's 10 against the bytes and could not.
So the measured ~0.4 s is NOT the ramp alone -- 24 units measured against 10
decoded. That the remaining ~14 units are exactly the black hold is arithmetic
that fits (0.233 s, inside this corpus's own 0.17-0.23 s plateau) and is NOT a
measurement; the decomposition stays open.
CONTAINER-NOTES gains the trap. Renders are byte-identical across the two
binaries (max per-channel difference 0 on GP_TUTORIAL build 0), so element
identity, pivots, keyframe counts and screen render output are unaffected -- it
is the times that move.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
Recorded per 'do not improvise around a blocker'. The question is what the game
does at BGM_103's loop seam, where the corpus has 'not a seamless loop, no
loop-point field found, so the menu loop is authored' and the port measures a
3.4 s near-silent seam.
Audio needs the ALSA tee; detecting the title needs video, so --gpu=null was
unavailable. Measured twice: the guest runs at ~0.20x real time (76.5 s of audio
in 378 s of wall clock) and the title is not reached in 300 s even after tapping
A to skip the movie, with the tee's slave ending in a broken pipe and Xenia in
underrun recovery. Not a crash -- rss 701 MB with 9.5 GB free, and the 'Killed'
line is this harness's own cleanup.
REFUTED along the way: CONTAINER-NOTES says --gpu=null runs here die at ~70 s.
The intro-audio capture ran 148.02 s under --gpu=null and ended on its probe's
timer with the emulator alive and the whole ADV movie decoded. More than twice
the quoted lifetime. That note had been the reason not to use --gpu=null for
anything long, which is exactly what a clean audio capture needs.
The route left, written down rather than attempted: use the XMA probe log as the
screen oracle instead of video. Sitting on the main menu decodes exactly BGM_103's
two waves, so their byte_sizes appearing IS the menu -- which is better
provenance for an audio question than a screenshot anyway.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
The port refuted the stronger half of the last claim and was right. I wrote that
the units/frame drift explained the publisher splash's 4.1% error against its
declared dwell. It explains the sign only.
Their test verified exactly here: the publisher/developer dwell ratio is 1.2143
declared, 1.2784 as the corpus's three cold boots measure it, and 1.3678 as this
container's drift predicts -- so the drift's direction is right and real evidence,
but its magnitude is about 2.4x too strong.
One refinement, because the means are being compared more finely than n=3
supports: the corpus's three boots individually give excesses of +0.89%, +8.24%
and +6.79%, a spread of 7.3 percentage points -- WIDER than the 5.30 pp gap under
test -- and boot 1's ratio (1.2251) is essentially the declared 1.2143. This run
sits 2.3 sigma above their mean: suggestive, not established.
Not closable without a frame log from the corpus's instrument, which was
screenshot timing and has none. An attempt to give this side an n of 3 failed on
tooling and is recorded: ARM=early loses its F10 about 40% of the time -- two of
five runs logged "ARMED EARLY" and produced no draw log at all, with nothing in
the session log distinguishing them.
Also fences the 33% drift against a misreading the port flagged: it is
PRESENTATION pacing and cannot reach keyframe_units_per_second = 60, which is the
game's logical rate, decoded under Q1, and which a renderer converts through at
its own frame rate.
And records a cross-check neither side went looking for: the batch counts are 1
and 2 on the publisher against 3 and 6 on the developer, and the port reports a
count restricted to SPRITE-BEARING elements reproduces that exactly from the
export -- so palogo_eff0, the layerless forced backdrop, is not in the batched
draw, confirmed from the file. Two instruments that disagreed about that element
in every previous iteration now agree on which one it is.
New tool splash_boundaries.py carries the corrected counting method.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Measured in the title draw capture, re-read with the per-quad parser.
GP_TITLE build 4 declares t = 0..269, about 120 presented frames at this run's
pacing. The title dwell lasted ~1100. ptcopyright declares alpha >= 1 for 106
units (t=138..244) and is drawn for 1050 frames; ptlogo1 declares an exit at
t=264 and is drawn for 1095. Both vanish within three frames of the dwell
ending.
So the top-level clock advances through the build-in, stops inside the settle
window [160,236], and holds. The exit ramp is not played on a timer -- it plays
when something makes the screen leave. That is ui-settle-time.md's decode seen
from the other side and observed in the running game rather than inferred from
the file. A nested record keeps looping on its own clock throughout.
This closes the 114-vs-120 gap, and it was my arithmetic rather than a
discrepancy in the decode. The 2.231 units/frame was regressed over BUILD-IN
events -- the only stretch in which the top-level clock advances -- and applied
to a period measured over the settled dwell, where that clock is frozen and
only the plate's own record is running. Two different clocks. The declared 120
was never in doubt from the calibration-free dark-fraction test.
The 51.158-frame period is now confirmed by a second independent estimator:
autocorrelation returns lag 51 with clean harmonics at 102 and 154. Its FIRST
version failed its control, returning 48 for a period known to be 51.158,
because it indexed by sample position where the log's frame numbers have gaps.
Recorded, because the failure is the reason the second version can be trusted.
Not settled: the sweeps' period. The same validated estimator disagrees between
two dwells of one screen -- 515 vs 452 frames for the same family -- and a 14%
disagreement within one screen is not a period. The +0x08 field cannot settle
it either, since ptloop01/ptloop02 have zero slack.
Blocker recorded in CONTAINER-NOTES: a single A press on the title faults the
guest. Three menu-capture attempts, two ending in register dumps of 223 MB and
519 MB, against three no-input runs in the same session that all completed. And
a guest fault writes an UNBOUNDED register dump to stdout on a filesystem at
91%, so any scripted button press needs a size guard.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
Found while checking what "Reborn" names. build-reborn line 15 is
SRC="${PROJECT_DIR:-/work}/Syplheed-Reborn" -- transposed letters -- and no such
directory exists; the workspace is at /work itself. It fails immediately with
cd: /work/Syplheed-Reborn: No such file or directory, so the documented way to
run the disc-gated tests is broken in this container.
Records the direct alternative, setting SYLPHEED_DISC by hand, which is what this
session has actually been doing.
This is the second wrapper here pointing at a source root that does not exist --
build-canary has the same defect and blocks the audio tap. Worth checking a
wrapper s SRC before trusting that a green or a failure came from your own code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
The distinction is the port s and it is sharper than the framing this page had.
PulseAudio s monitor SUBSTITUTES: audio that existed is replaced by silence to
keep the wall clock, so information is destroyed and deleting the holes only
compresses time unevenly. Xenia s padding is ADDITIVE: the silence is inserted
between samples the guest emitted, so nothing is lost and every real sample is
present and in order.
So stripping all-channel-zero runs from an ALSA-tee capture is exact rather than
a repair, which means even the 0.70x rendered capture at 9.98 percent padding is
usable for correlation, where none of the PulseAudio-monitor captures ever were
however they were tuned. Recorded as unverified: the port is controlling it by
padding a known source to match and checking the stripped result correlates back.
Consequence for check-capture recorded too: its silence and gap-rate rule was
built when only damage existed and cannot distinguish genuine emulator padding
from capture damage, so a FAIL on an ALSA-tee capture is a statement about the
recording path rather than the file s usability.
Also promotes the runaway guard to a first-class CONTAINER-NOTES entry at the
port s request -- 7.34 GB in 50 seconds at about 250x real time is not a
footnote -- and adds --gpu=null there, which is what takes the guest from 0.70x
to 0.96x and stops the padding, with its two caveats: no video for provenance,
and runs die at about 70 s with PM4_DRAW_INDX failures.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
