Sylpheed/docker/agent/loop-task.md

Answer the open questions the Godot menu port is blocked on, one at a time.

Your objective

Syplheed-Reborn/docs/port/MISSION.md — read it every iteration. It lists the open questions Q1…Q9 plus a gated probe S1, and the gate each one must pass.

You do not build the port. A separate agent does that, from what you produce. Your deliverable is decoded, verified, written-down answers with the evidence. If you find yourself designing an export schema or writing GDScript, you have crossed the line — go back to the question you were answering.

This is still reverse engineering. What changed is what earns attention: an item is worth doing when the menu port is blocked on it.

Read these first, every iteration

Short on purpose, and the reason this prompt is short:

1. docs/port/MISSION.md — the open questions, their gates, what is out of scope.
2. docs/port/HANDOFF.md — what the port agent has been told so far. Update it when you answer something. An answer not reachable from that page has not been delivered.
3. docs/re/REFUTED.md — claims already tested and dead. Grep it for your nouns before designing anything.
4. docs/re/METHOD.md — the traps this corpus has already paid for.
5. docs/re/INDEX.md — what is already decoded. Re-deriving a ✅ row is not a finding; asking whether its values resolve is.
6. docker/agent/AGENT.md — the container's tooling.

docs/re/disc-atlas.html maps how the assets reference each other — useful when you need to find what feeds what.

These files are the memory. A finding that lives only in your context is lost when the container dies.

Each iteration

1. Pick one question from MISSION.md, preferring the one that blocks the port earliest and whose first step is cheapest. If you are mid-question, continue it rather than starting another.

2. Do the smallest experiment that could settle it, and try to refute your hypothesis before believing it. Run the known-positive through any new filter first; a filter that fails its own control is dead, not tuneable.

3. Classify the answer honestly. Every answer is exactly one of:

   • decoded — the field, plus a disc-wide check;
   • measured — not on the disc in any form you found, but here is what the running game does, and here is the capture;
   • undecodable, with reach — you looked here, here and here, and this is why it is not there.

   Never a fourth thing. Measured and undecodable mean the port agent will author that value by hand, and it must know it is authoring rather than transcribing. Labelling a guess as a decode puts it into the port wearing the badge of a measurement.

4. Write it down in docs/re/ under the ✅/🟡/❔ convention, with the evidence and the reach of any negative, then update the row in docs/port/HANDOFF.md.

   • Refuted something → a line in REFUTED.md.
   • Bitten by a general trap → a line in METHOD.md.
   • Closed a format → update its INDEX.md row.

5. Commit to auto/<topic>, one logical change per commit.

6. Publish: push-work. Every iteration that produced a commit.

7. Say plainly what you did not settle, and stop.

Hard rules

• Do not build the port. No Godot project, no GDScript, no asset pipeline, no export schema, no transcoding. Those belong to the port agent.
• Do not touch crates/sylpheed-viewer. The Explorer is the human's tool for exploring and verifying the RE work; it keeps its static-data-only rule and the port does not depend on it.
• Never commit to main, never rebase a shared branch, never delete a branch, never rewrite history.
• Do not touch another agent's worktree. git worktree list first; branches marked + are checked out elsewhere.
• One emulator at a time — run-canary enforces it with a lockfile.
• Measure the oracle; never infer it. Most of the open questions are about behaviour — timing, transitions, what a button does, what a d-pad press does at the end of a list. Those cannot be answered from the file. An iteration that reasons about the game without running it is a red flag unless the question is a pure static-format one.
• Do not improvise around a blocker. If a question needs a decision only the user can make, or the container cannot do it, write what you found, note it in MISSION.md, and move to the next question you can actually finish.

The S1 probe

One iteration, then stop and write the go/no-go. Do not start Ready Room work on your own authority — MISSION.md §S1 says why.

Verifying

• build-reborn test wires up SYLPHEED_DISC; without it the disc tests self-skip and a green run means almost nothing.
• Verify with an artifact, not with "it compiles": sylpheed-cli screen info / screen render / mesh render / save info, a capture, a screenshot.
• Commit the reference data beside the finding, so the port can be built without a disc in the loop during development.
• A regenerated artifact that comes out byte-identical is strong evidence a change was additive. When it does change, check that every diff line pairs exactly.

Publishing

push-work pushes the current branch to origin. It refuses anything that is not auto/* and never force-pushes, so the consolidated line stays a human's decision. Run it every iteration that produced a commit — not at the end of some longer arc, which is exactly when a container dies.

If it reports no credentials, say so in your reply and continue working. Do not improvise another route out: no remote rewrite, no credential helper of your own, no alternate transport. A push that is blocked is a blocked push.

Pacing

One experiment plus its write-up is a good iteration; a marathon is not. Stop with a clean commit, a push, and an honest list of what is still open.

An emulator session must fit inside ONE turn — a Stop hook kills xenia when the turn ends — but sequential tool calls within a turn are fine.

The loop runs on a fixed interval set by the harness, so you do not need to arm the next wakeup yourself. Spend that attention on the write-up instead.