Release gate: full Amulet-retrieval playthrough at a real terminal (needs a human) #8

New Issue

clawbot · 2026-08-09T03:42:13+02:00

clawbot commented

2026-08-09 03:42:13 +02:00

What this is

TODO.md Future Step 1 is the repo's own release criterion:

> Tag a release once a full game (Amulet retrieval and score entry) completes
> without defects.

This is the last gate before a release tag, and it cannot be automated by an
agent. The playtest-hardening step (2026-07-23) already took the automatable
part as far as it goes and said so explicitly:

> The interactive "play several games at a real tcell terminal" portion needs
> a human at an 80x24 terminal and is left to the maintainer.

The automated suite reaches depth 8 with save/restore and mashes 200 turns of
movement across four seeds without a panic — but it can never validate what
the game actually looks and feels like, and by design it pins HP/food/exp
(fortify()) so it never experiences real death, real hunger, or the real win
condition. Nothing in CI has ever retrieved the Amulet.

Definition of done

A human plays at a real 80x24 tcell terminal and confirms:

A complete game: descend to the Amulet, retrieve it, ascend, escape, and
land on the score screen with the entry recorded in ~/.rogue.scores.
Death path: die at least once and confirm the RIP screen renders correctly
and the score is recorded.
Save/restore across a real process boundary: S, quit, relaunch with the
save file, confirm state is intact and the save file is deleted on restore.
Screen integrity throughout — no corruption, no stuck message lines, no
misplaced cursor, correct --More-- handling.
ROGUEOPTS handling (name=, terse, jump, fruit=) behaves.
Any defect found gets its own issue; a regression test is added where the
defect is reproducible headlessly.

Why it's assigned to you

It needs a person at a terminal — I can't do it, and I'd rather say so than
quietly mark the release gate green off the back of headless tests that
deliberately avoid the win and death paths.

If you'd prefer, I can narrow the scope first (for example: build the binary,
confirm -s and -d render correctly, and hand you a short scripted
checklist to work through) so your time at the keyboard is minimal. Say the
word and I'll prep that.

Blocks

Tagging any release beyond v0.0.1.

## What this is `TODO.md` Future Step 1 is the repo's own release criterion: > Tag a release once a full game (Amulet retrieval and score entry) completes > without defects. This is the last gate before a release tag, and **it cannot be automated by an agent.** The playtest-hardening step (2026-07-23) already took the automatable part as far as it goes and said so explicitly: > The interactive "play several games at a real tcell terminal" portion needs > a human at an 80x24 terminal and is left to the maintainer. The automated suite reaches depth 8 with save/restore and mashes 200 turns of movement across four seeds without a panic — but it can never validate what the game actually *looks and feels like*, and by design it pins HP/food/exp (`fortify()`) so it never experiences real death, real hunger, or the real win condition. Nothing in CI has ever retrieved the Amulet. ## Definition of done A human plays at a real 80x24 tcell terminal and confirms: 1. A complete game: descend to the Amulet, retrieve it, ascend, escape, and land on the score screen with the entry recorded in `~/.rogue.scores`. 2. Death path: die at least once and confirm the RIP screen renders correctly and the score is recorded. 3. Save/restore across a real process boundary: `S`, quit, relaunch with the save file, confirm state is intact and the save file is deleted on restore. 4. Screen integrity throughout — no corruption, no stuck message lines, no misplaced cursor, correct `--More--` handling. 5. `ROGUEOPTS` handling (`name=`, `terse`, `jump`, `fruit=`) behaves. 6. Any defect found gets its own issue; a regression test is added where the defect is reproducible headlessly. ## Why it's assigned to you It needs a person at a terminal — I can't do it, and I'd rather say so than quietly mark the release gate green off the back of headless tests that deliberately avoid the win and death paths. If you'd prefer, I can narrow the scope first (for example: build the binary, confirm `-s` and `-d` render correctly, and hand you a short scripted checklist to work through) so your time at the keyboard is minimal. Say the word and I'll prep that. ## Blocks Tagging any release beyond `v0.0.1`.

sneak was assigned by clawbot

2026-08-09 03:42:13 +02:00

clawbot referenced this issue

2026-08-09 19:18:51 +02:00

test: drive the autosave race test to a condition, not a turn count (closes #36) #40

clawbot referenced this issue

2026-08-10 14:29:40 +02:00

Terminal QA harness: drive the real binary under tmux at 80x24 and assert on screen contents #42

clawbot commented

2026-08-10 14:29:49 +02:00

I was wrong that this needs you for most of what it lists, and I am taking it off your plate until it genuinely does.

I filed this asserting the interactive portion "cannot be automated by an agent". I inherited that claim from the 2026-07-23 playtest-hardening note and did not test it. Testing it takes about a minute: tmux is on this host, tmux new-session -d -x 80 -y 24 is a real 80x24 PTY, send-keys feeds it keystrokes and capture-pane -p returns the exact rendered cell grid. A probe using a raw cursor-position escape came back at the expected row and column. So the death path, save/restore across a real process boundary, screen integrity, --More-- handling and ROGUEOPTS are all mechanically checkable here, and so is Amulet retrieval.

That work is now #42 , itself blocked on #19 for a make build target.

What I am not claiming is automated: whether the game feels right, and whether an honest unassisted game — not a wizard-mode descent — completes. Those stay here. Unassigning you meanwhile; I will reassign this with a short concrete checklist once 42 has taken the mechanical cases and I can tell you exactly what is left, which should be a few minutes at a keyboard rather than a full playthrough.

**I was wrong that this needs you for most of what it lists, and I am taking it off your plate until it genuinely does.** I filed this asserting the interactive portion "cannot be automated by an agent". I inherited that claim from the 2026-07-23 playtest-hardening note and did not test it. Testing it takes about a minute: `tmux` is on this host, `tmux new-session -d -x 80 -y 24` is a real 80x24 PTY, `send-keys` feeds it keystrokes and `capture-pane -p` returns the exact rendered cell grid. A probe using a raw cursor-position escape came back at the expected row and column. So the death path, save/restore across a real process boundary, screen integrity, `--More--` handling and `ROGUEOPTS` are all mechanically checkable here, and so is Amulet retrieval. That work is now https://git.eeqj.de/sneak/rgoue/issues/42 , itself blocked on https://git.eeqj.de/sneak/rgoue/issues/19 for a `make build` target. What I am **not** claiming is automated: whether the game *feels* right, and whether an honest unassisted game — not a wizard-mode descent — completes. Those stay here. Unassigning you meanwhile; I will reassign this with a short concrete checklist once 42 has taken the mechanical cases and I can tell you exactly what is left, which should be a few minutes at a keyboard rather than a full playthrough.

sneak was unassigned by clawbot

2026-08-10 14:29:53 +02:00

clawbot referenced this issue

2026-08-10 15:59:00 +02:00

Terminal QA harness: drive the real binary under tmux at 80x24 and assert on screen contents #42

clawbot referenced this issue

2026-08-10 16:17:58 +02:00

Terminal QA harness: drive the real binary under tmux at 80x24 and assert on screen contents #42

Sign in to join this conversation.