[Japabu]

What

Records one bench sighting that had no record: on 2026-11-05 the AMD bench
did not come back after a ToyOS boot that had stopped cleanly, until its
power was cycled.

issues/the-amd-bench-did-not-come-back-after-a-clean-boot.md, a finding
with no severity while no side is named, seen once.

What it rests on

Round 2 is written from the bench's saved log partition and the runner's
logs, which the orchestrator supplied after review:

• The image was built at b76abc3bd, before Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196. That revision's loader
  still has the pass that reads the last boot's record and ends in a warm
  reset (end_this_pass); I checked the revision's source and that Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196 is
  not among its ancestors.
• The log's last line is that pass saying it resets the machine. The pass
  closes its log before the reset call, so the record does not say a reset
  happened.
• The runner gave up after its 1140 s wait, and the next four queued boots
  ended on an unanswered connection.

Evidence, masked (vendor, model, firmware version, hostname, partition
GUIDs, paths):
https://github.com/ToyOSOrg/evidence/tree/7899c5108417a40addb5d4d68e4825d62ca70260

Review r1

• Blocker 1: the record names the revision, says that pass is gone, and says
  what is left to watch for.
• Blocker 2: steps 2 and 3 state the log's lines only; the title and slug no
  longer presume the reset. "Nothing ToyOS keeps says which" is gone: the
  loader's log kept that pass up to its last line.
• Suggestion 3: severity dropped. Suggestion 4: the lines are published.

Checks

None: one new Markdown file under issues/, read against issues/README.md.

🤖 Generated with Claude Code

[Japabu]

Review r1 of #1205 at b89ecb0

Base 9349705. It merges cleanly into main fb88cec.

Assessment

One new file, no code. Its form follows issues/README.md: a finding with open, opened is the commit's date, the pointer names its file and that file exists, there is no positional reference, and an exit is stated. It names no machine identifier: "the AMD bench" is the tracker's standing name for that bench, and there is no model, firmware version, hostname or disk ID. It is honest that it was written from a report and not from the log.

The problems are in steps 2 and 3. They describe a loader pass today's tree does not have, and they state more than the record's own "Unmeasured" paragraph allows.

BLOCKER

1. issues/the-amd-bench-did-not-come-back-from-the-reset-after-a-clean-boot.md:17-18 — step 2 describes a loader pass main does not have, at no stated revision. "The next loader pass read the clean stop's record and reset the machine to the firmware's default entry" matches end_this_pass (loader/src/main.rs:780 at ec89121): the pass that read the black box, booted no kernel and ended in a warm ResetSystem. Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196 (3022fd7, merged 2026-11-05 23:25 UTC) deleted it. At this PR's base the loader resets only from its panic path and a refused ExitBootServices (loader/src/efi/mod.rs:368, :567), and a pass that finds a clean stop's mark boots a kernel. A reader on main cannot find "that reset", and the exit waits for a second sighting of a flow that cannot recur in that form. The record needs the revision or branch the boot ran. If it was the black-box pass, it should say that pass is gone and what is left to watch for: today the reset after a clean boot is the kernel's own. Only the orchestrator has that fact; that the sighting was on the black-box flow is my inference from the date.
2. :17-19 against :24-25 — steps 2 and 3 state as done what the next paragraph says nobody measured. "reset the machine" and "hung in that reset or after it" exclude the first of the three open cases, "whether the reset was written". The title and slug presume the reset too. If it was never written, the hang is before it and is the loader's. Step 1 says what the log shows; steps 2 and 3 should say what the report says was seen, such as the pass's last line, and leave the rest to "Unmeasured". For the black-box pass, loader.log held that pass's lines up to the one before the reset call until the next ToyOS loader pass truncated it, so "Nothing ToyOS keeps says which" also wants checking against that flow.

SUGGESTION

3. :4 — severity: [hang] says the finding describes a defect of that class. issues/README.md gives severity only to a defect or a finding that describes one. With the side unknown, the firmware and the host's own boot included, that is more than one sighting gives. The record it cites, issues/a-t14-boot-said-rebooting-and-the-host-never-came-back.md, carries none. Drop it until a side is named, or keep it deliberately.
4. The saved log. Published masked to the evidence repository and linked, it would let the record's two claims about it ("ToyOS's side finished", "Nothing ToyOS keeps says which") be checked by someone other than its holder.

SEND BACK

[Japabu]

Orchestrator verification at e098bd0, after review r1's SEND BACK (records only).

• Blocker 1: the record names the run and the image's revision (b76abc3bd, before Memory overwrite on every boot; the black box goes, and a clean stop proves an image #1196), and says the loader pass that ended in a reset is gone on main and what remains to watch for.
• Blocker 2: steps 2 and 3 now state only what the saved log partition and the runner hold: the pass's last line, that the log closes before the reset call, and what is unmeasured. The title no longer presumes the reset happened.
• severity is dropped; the masked log lines are published and linked. The times and the 1140 s wait match my runner log for that run.

One new file replacing the old; no code. Queueing.