It set `git config --local credential.helper "store --file=$HOME/..."`, which
PERSISTS in the repository. The repo is a bind mount the host also uses, so the
host's git inherited `store --file=/sylph-home/port/.git-credentials` -- a path
that exists only inside the container -- and every host push then failed with
`unable to get credential storage lock: No such file or directory`.
Same root as the EBUSY credential error, from the other side: a tool that
configures a shared repository to suit itself breaks every other user of that
repository. Now applied with `-c` to the single push invocation.
Cleared the leaked setting from both checkouts by hand. Syplheed-Reborn had it
too, from the RE container's copy of this script.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three fixes from the port agent's first infrastructure report.
**A. The credential file is written, so it cannot be a read-only mount.**
`credential.helper=store` rewrites its file after a successful auth: temp file,
then rename over the target. Renaming onto a bind-mount point gives EBUSY, which
surfaces as `fatal: unable to write credential store: Device or resource busy`.
The push succeeds anyway, and that is the real hazard -- a `fatal:` line that is
routinely wrong teaches the reader to ignore the one that is real. It also fired
intermittently, so it read as flakiness rather than as a mount.
Fixed by mirroring the pattern already used for .claude.json: mount it as
`.git-credentials.host:ro` and have the entrypoint copy it to a writable
~/.git-credentials at 600. Mounting rw would also silence it, but then the
container can clobber the host's real credential file; copying cannot.
**B. `git -C /reborn pull` can never work, and should not.** /reborn is a live
read-only mount of the RE agent's working tree -- it updates itself, and pulling
would move another agent's checkout. The prompt now says so, and adds the
consequence the agent found the hard way: because the mount is live, HANDOFF can
move mid-iteration, so anything copied out of it (BLOCKED.md especially) may
already be stale and must be re-checked rather than trusted.
**C.** CARGO_HOME moves to a named volume; it was on the container overlay, so
the pinned decoder source was re-fetched from the network on every fresh start.
Also adds SYLPH_PORT_REPO, so this launcher can be run from a worktree without
repointing the agent's checkout -- which is how these edits were made, the agent
being mid-iteration on auto/p0-exporter in the shared tree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The port agent's first published arc. Merged from auto/p0-exporter so the image
build below carries its docker/bin fixes -- build-export follows the exporter's
new subcommand shape, and build-reference-cli makes the pinned reference CLI
reproducible rather than a hand-built artifact in a volume.
Two tooling fixes, both needed before P1 can diff anything.
`build-export` was calling `sylpheed-export --disc ... --out export`, which P0
broke when it moved the exporter behind `export` / `check` subcommands. It is a
regression from 8dd0577 and this is the fix. It now also runs `check` after
exporting, because `export` writes a tree and `check` is the only thing that
says the tree is readable by something other than the program that wrote it.
`build-reference-cli` is new. `sylpheed-cli screen render` is the reference the
Godot port gets diffed against, and the only copy of it in the container is
/reborn/target/release, which has two problems: the release binary predates the
`screen` subcommand entirely, and /reborn is a LIVE mount of the other agent's
working tree -- it moved from e81dcad to f5e7426 during a single iteration. A
reference renderer that runs different decoders than the exporter puts a free
variable in every pixel diff, so this builds the CLI from the same pinned
revision the exporter uses and drops it on the persistent target volume.
Both are COPY'd into the image at Dockerfile:76, so neither takes effect in a
running container until the image is rebuilt. The reference CLI is already built
into the target volume by hand, so P1 is not blocked in the meantime.
FORMAT is bumped to v2 with a "Changes from v1" table giving a reason per row.
v1 was written before HANDOFF answered Q1 and Q3 and before the two-colour
modulate was known; each change is a thing v1 could not have said. The paint
order moves from `unresolved` into the export, because Q3 decoded it — a u16
layer key at +0x0A, stable-sorted — and a decoded answer is read in the
exporter. `paint_order_ties` replaces it, because the tie-break is still
unknown.
Where a layer key is not in the file it comes from the decoders' table of keys
measured off the running game. That is a different kind of fact, so it is
labelled: `layer_source` is "sprite", "implied" or "none".
BLOCKED is reconciled against HANDOFF at /reborn e81dcad. Seven of its ten rows
are answered and are moved out; what remains is Q8 (no cue-to-event binding),
the two Q10 unknowns (which BGM, and where a loop restarts), Q9's unsettled
skippability, Q4's untested NEW GAME, and Q6's undecoded boot driver.
It also raises one question back, found by counting the export rather than by
reverse engineering anything: the decoders document a .t32 element's pivot as
"exactly half the decoded texture's dimensions (verified 7/7 on the tutorial
bundle)", and on GP_TITLE that holds for 55 of 93 sprite-bearing .t32 elements.
38 do not, some grossly — ptlogo_back2 is 1118x262 with pivot (500,117) where
half is (559,131). It changes nothing today, because the exporter emits the
declared pivot and the pivot only matters when scale != 100%. But scale IS
animated here — 177 keyframes across GP_TITLE are not 100%, including on the
title screen P1 has to draw — so the question of what the running game anchors a
scale to is worth an answer before P2. Noted there that the port and
`sylpheed-cli screen render` make the same choice, so a P1 diff cannot
distinguish them and their agreement is not evidence.
`sylpheed-export export` reads `dat/GP_TITLE.pak`, enumerates its twelve screen
builds, and writes each as one `sylpheed.screen/2` document with its sprite PNGs
beside it. `sylpheed-export check` validates that tree against docs/FORMAT.md
with no disc in hand — the P0 gate is "validates against FORMAT.md", which is
not something anyone can confirm by reading, so it is a program.
Two readings from FORMAT v1 turned out to be wrong and are corrected here rather
than carried:
* The focus sprite does NOT come from the element's `opt ` link. That was
measured and refuted upstream, and this export shows why plainly: on the main
menu `opt ` chains ptloop01 -> ptloop02 -> ptbtn01, two decorations and then a
button. The highlight pairs by sprite NAME instead (ptbtn01.t32 <->
ptbtn01f.t32), which is the convention HANDOFF blesses and which resolves all
five main-menu buttons. The raw link is still exported, renamed `opt_link` so
nothing downstream mistakes it for navigation.
* There are TWO modulate colours in different byte orders, and they multiply.
v1's single `#rrggbbaa` could not carry both and silently dropped the alpha
that every fade ramps. They are now `tint_rgba` and `fade_argb`, with the byte
order in the key name, because getting it backwards is silent and reads as an
art bug rather than a parse bug.
The exporter takes exactly one authored input: `authored/screen_names.json`,
because the disc does not name its builds and "build 5 is the main menu" is a
measurement (HANDOFF Q2), not a field. Every name it applies is stamped
`name_source: "authored"` with the evidence in `name_why`, and `check` rejects
an authored name that has no `why` — so the derived tree stays honest about
which of its fields is a decision.
Sprites are per screen, not a flat pool: `main_menu` and `extras` both ship a
`ptbase.t32` and they are different pictures.
Checked, not assumed:
* two exports of the same disc are byte-identical;
* five mutations of a valid main_menu.json — a broken paint_order permutation,
a dangling focus_sprite, a reversed buttons list, a `#rrggbbaa` colour and an
invented name_source — are each caught with a specific message.
`t` stays raw. Q1 is answered, but the seconds conversion is measured off the
running game and its own finding flags the frame-rate measurement as the part
worth re-testing; if the game presents at 60 Hz every duration halves. One
constant, at P2, in a file that says it is a decision.
`sylph-port remote` never returned. Two bugs, one behind the other.
The glob `/sylph-home/port/.claude/**/*.jsonl` ran under `sh`, which has no
globstar, so it stayed literal and matched nothing -- the lookup could not have
succeeded however long it waited.
Fixing that exposed the real problem: the session transcript records every
command run inside the container, including this lookup, so grepping it matched
our own pattern string back and returned a truncated URL. The container log is
the right source and has no such feedback loop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`loose` exited 126 with "File name too long": the entrypoint ended in
`exec "$@"`, so the whole loop-task.md prompt was handed to exec as a command
and the markdown was tried as a filename.
The launcher was modelled on the RE container's but the entrypoint was written
fresh and simpler, and it left out the half that matters -- the block that turns
a `/loop ...` argument into a Claude Code invocation. Ported it over, with the
two gates that make an unattended run possible: seeding ~/.claude.json so the
first-run wizard does not stop on the theme picker, and claude-autonomous, which
answers the Bypass Permissions disclaimer that has no config key to skip it.
Also mounts the host's Claude credentials, which the container had no way to
reach, and passes SYLPH_AUTONOMOUS=1 from `loose`.
Verified: container stays up, display :97 ready, /reborn mounted read-only,
Remote Control registered, Claude Code started in /work.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The pin was 4.3, chosen without checking; 4.7.2 is the current stable (released
2026-08-18). Getting this right matters more here than usual because the project
diffs Godot screenshots against a reference renderer, so the engine version is
part of the measurement.
No Godot MCP server. Not because they are bad -- the mature ones need a LIVE
editor plus a WebSocket plugin and a Python server, which is a daemon, an editor
process and a second runtime added to an unattended loop. And their headline
feature, scene-tree introspection and node manipulation, is built for someone
hand-authoring scenes in the editor. This port GENERATES screens from exported
JSON: the agent writes a loader, not a scene tree, so the feature that justifies
the complexity does not apply. What it actually needs to verify itself -- run
headless, screenshot, diff against sylpheed-cli screen render -- is already a
bash job.
Third-party skill packs are the opposite trade: pure context, no runtime. Worth
revisiting, deliberately not installed now, because a skill is instructions
injected into an agent running with approvals disabled -- a supply-chain
decision, not a default -- and because P0/P1 need no advanced GDScript. The
agent may propose one, naming the milestone it unblocks, for a human to vendor
and review.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The port is deliberately separate from the reverse-engineering project: its own
repository, its own clone, its own container. Two writers in one working tree
means files change under whoever is mid-edit and a `git add -A` by one sweeps up
the other's work -- which happened today in the Reborn tree, so this is set up
not to repeat it.
The wall: Godot never reads a disc format. An offline Rust exporter converts the
user's disc into JSON + PNG + Ogg, and the Godot project reads only that. No
GDExtension, no Rust in port/. Beyond the practical reason -- Godot cannot read
IPFB, RATC, T8aD, XMA or WMV -- there is the design one: modding is a goal, and
if the runtime reads the original formats then modding means reverse
engineering, whereas if it reads JSON it means opening a file.
The decoders come from sylpheed-formats PINNED BY REVISION (8b6dbcf), not
vendored and not reimplemented. `sylpheed_formats::media` in particular already
owns every case where one playable thing is not one archive entry: entries that
span segment files, banks with several sub-waves, and the cutscene voices, which
are one continuous XMA stream chunked into VOICE_*.slb entries whose boundaries
do NOT match the cues. That last one is the easiest thing in this project to get
subtly wrong, so the mission says outright not to re-derive it.
docs/MISSION.md is the objective (P0-P7, each gated by an artifact rather than
by compiling). docs/BLOCKED.md lists what cannot proceed until the RE agent
answers Q1-Q10, and says plainly that none of it may be guessed -- this agent
has no emulator and no oracle, so a value it invents is indistinguishable from a
decoded one a month later.
The container is deliberately small: 3 cpus / 4 GB against the RE container's
6 / 7, and an image with no C++ toolchain, no Vulkan stack and no emulator. Two
full-size containers do not fit on this box beside a desktop.
Its launcher sets the git identity through GIT_AUTHOR_*/GIT_COMMITTER_* rather
than writing [user] into .git/config -- the config route captures every commit
made in that tree, including a human's, which is how six of today's commits
ended up attributed to the RE agent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
