Work the Project Sylpheed reverse-engineering backlog, one item at a time.

## Read these first, every iteration, before proposing anything

They are short on purpose, and they are the reason this prompt is short:

1. `Syplheed-Reborn/docs/re/REFUTED.md` — **claims already tested and dead.**
   If your idea is on that list, it is finished; pick another. Grep it for your
   nouns before you design anything.
2. `Syplheed-Reborn/docs/re/METHOD.md` — the traps this corpus has already paid
   for. Most wasted iterations are one of these repeated.
3. `Syplheed-Reborn/docs/re/INDEX.md` — what is already **decoded**. Do not
   re-derive a row that is already ✅. Re-deriving a known format is not a
   finding; asking whether its values *resolve* is.
4. `Syplheed-Reborn/docs/re/BACKLOG.md` — the open items. It is long; skim the
   `##` headings and open only the one you pick.
5. `Syplheed-Reborn/docker/agent/AGENT.md` — the container's tooling.

**These files are the memory.** If a finding, a dead end or a trap lives only in
your context, it is lost at the end of the run. Write it down where the next
iteration will find it — that is what makes this a corpus rather than a
transcript.

## Each iteration

1. **Pick one item** from `BACKLOG.md`, preferring the one whose "first step" is
   cheapest and most decisive. If you are mid-item, 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. **Write the result down** in `docs/re/` under the ✅/🟡/❔ convention, with the
   evidence and the *reach* of any negative. A withdrawn result is a real
   result — record it, with the reasoning.
   * If you **refuted** something, add a line to `REFUTED.md`.
   * If you were bitten by a general trap, add a line to `METHOD.md`.
   * If you **closed** a format, update its `INDEX.md` row.
4. **Commit** to `auto/<topic>`, one logical change per commit.
5. **Publish**: `push-work`. Your branch must leave the container or the work
   dies with it. See "Publishing" below.
6. **Say plainly what you did not settle**, and stop the iteration.

## 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.

## Hard rules

* **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.** An iteration that reasons about the
  game without running it is a red flag unless it is a pure static-format task.
* **Verify with an artifact**, not with "it compiles": `build-reborn test` (it
  wires up `SYLPHEED_DISC` — without it the disc tests silently self-skip and a
  green run means almost nothing), `sylpheed-cli mesh render` / `screen render` /
  `save info`, a screenshot. A regenerated artefact that comes out
  byte-identical is a strong check that a change is additive; when it does
  change, check that every diff line pairs exactly.

## When you are blocked

If an item needs something the container cannot do — hardware Vulkan, a decision
only the user can make — **do not improvise around it**. Write what you found,
note the blocker in `BACKLOG.md`, and move to the next item.

## 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.