assay · walkthrough · one request, every gate
One request, all the way through
One request becomes a merged, verified change on a real repository, and you can check every gate yourself. This is a seekable walkthrough of a single work item, a real defect on the public methodology repository, as it moves through the Assay lifecycle: report, brief, draft pull request, a failing test shown red first, review, repair, independent verification, and the human merge.
The walkthrough
It opens on a cover (Beat 00) that states the promise, the two evidence modes, and that navigation is read-only; the work path then runs Beat 1 to 11. Each frame labels its two numbering axes (Beat and Chapter) so neither is read as an Assay lifecycle stage, and a footer key explains every mark. Use the transport below, click any chapter or scene, or use the keyboard: arrows step, space plays or pauses, C toggles captions, number keys jump to a chapter, Home/End go to the ends. Autoplay is off when your system prefers reduced motion; step through by hand. Navigation is read-only: it runs nothing.
Static transcript
The whole walkthrough in text, beat by beat, with the same evidence labels the player draws on every frame. If the player above does not run, this is the walkthrough.
Overview
FRAMING Cover (Beat 00). What is this, and how do you read it?
A seekable walkthrough of one request moving through the whole Assay lifecycle. Play it, or step through by hand; nothing you do here runs a command.
orientation, not evidence
The problem
ILLUSTRATIVE Beat 1. What breaks, and who notices?
The issue board goes blind. One decision-owed issue with a very long comment thread makes the whole board return an error, every scanned repo, unreadable at once.
evidence: none (authored sample state)
RECORDED Beat 2. How does a defect enter the pipeline?
It becomes one tracked request. The defect is filed as an issue; that issue is the single work item this walkthrough follows all the way to a merged fix.
`issueboard` exits 6 (whole-board could-not-check) on every invocation as soon as ONE decision-owed issue's comment thread grows past a single page (100 comments).
One over-long thread must never take the whole board down again.
evidence: issue #1447
The brief
ILLUSTRATIVE Beat 3. What will count as done, before any code is written?
A brief states the acceptance up front as a Verify table. Each row is a check a later, independent run must reproduce, the finish line is written before the work starts.
evidence: traces to issue #1447
The work
ILLUSTRATIVE Beat 4. What does the agent do first, and can a human see it?
A worker opens a draft pull request. Request became decision; decision is now a visible change on the forge, open for review and not yet merged.
evidence: PR #1449 (draft)
ILLUSTRATIVE Beat 5. Does the new test actually catch the bug?
The test is shown failing on the unfixed code first. Run against the old board, the over-long thread propagates exit 6 and the assertion fires, the test is proven to have teeth before any fix is claimed.
run(issues) with an overflowed decision-owed thread = exit %d, want 0 (one long thread must not take the whole board down)
evidence: fail-first test, PR #1449
RECORDED Beat 6. What is the actual fix? Assay stage: implemented
The clock now reads the whole thread through a bounded, paginated read; a thread too long even for that degrades that one row to could-not-check while the rest of the board renders. The same test now passes against the fix.
The clock now reads the WHOLE thread through a new bounded, paginated forge read (Forge.IssueContentEvents): GitHub walks a cursor'd comment query to a hard page cap; GitLab reuses the existing paginated notes reader.
The trust gate keeps its deliberate single-page fail-closed bound, untouched.
evidence: merged commit 38086e64d on main
The gates
ILLUSTRATIVE Beat 7. Who checks the change, and what happens when a check goes red?
The reviewer App reviews, and a required check goes red. Review is its own gate: the change does not advance while a required check is red or a finding is open. This is not the human approval and not the merge.
evidence: PR #1449 checks
ILLUSTRATIVE Beat 8. How is the finding cleared?
The worker pushes a follow-up commit that fixes exactly what the finding named, brings the branch current with main, and the required check turns green. Only then does the reviewer approve.
The doc comment said the notes dropped at the page cap "are the OLDEST"; with the oldest-first (sort=asc) listNotes walk the cap actually drops the NEWEST notes.
the stated premise was inverted, which a future edit could have trusted into a fail-open.
Comment-only; addresses reviewer follow-ups on #1449.
evidence: follow-up commit, PR #1449
Independent verification
ILLUSTRATIVE Beat 9. Does someone other than the author re-run the acceptance? Assay stage: verified
An independent verifier re-runs the brief's Verify table on merged main and records the result as Evidence. Approval said the change looks right; verification shows it behaves right, kept as two distinct acts.
evidence: build 38086e64d on main
The human gate
ILLUSTRATIVE Beat 10. Who actually merges? Assay stage: done
The maintainer merges. A person performs the merge, the pipeline runs unattended between gates and waits at this one for a human's act.
evidence: merged to main as 38086e64d
The payoff
ILLUSTRATIVE Beat 11. Is the original problem actually gone?
The board reads the long thread without going blind. The over-long row shows ESCALATE and could-not-check; every other row renders; the board exits clean. The behaviour matches the Verify table you read at the start.
evidence: product state on build 38086e64d
Evidence ledger
The demonstrated build is medici-finance/assay at 38086e64d, captured 2026-09-22. The label follows the pixels: a beat whose visible copy is authored synthesis reads ILLUSTRATIVE even when its authorities are recorded.
| Beat | Scene | Mode | Assay stage | Evidence |
|---|---|---|---|---|
| 00 | cover | FRAMING | n/a | orientation |
| 1 | board-blind | ILLUSTRATIVE | n/a | n/a |
| 2 | defect-report | RECORDED | n/a | issue #1447 |
| 3 | brief-verify | ILLUSTRATIVE | n/a | traces to issue #1447 |
| 4 | draft-pr | ILLUSTRATIVE | n/a | PR #1449 (draft) |
| 5 | fail-first | ILLUSTRATIVE | n/a | fail-first test, PR #1449 |
| 6 | implementation | RECORDED | implemented | merged commit 38086e64d on main |
| 7 | review-finding | ILLUSTRATIVE | n/a | PR #1449 checks |
| 8 | repair | ILLUSTRATIVE | n/a | follow-up commit, PR #1449 |
| 9 | independent-verify | ILLUSTRATIVE | verified | build 38086e64d on main |
| 10 | human-merge | ILLUSTRATIVE | done | merged to main as 38086e64d |
| 11 | board-renders | ILLUSTRATIVE | n/a | product state on build 38086e64d |
What is recorded and what is drawn
The artifact trail is real and public on medici-finance/assay: the defect is issue #1447, the fix is pull request #1449, and it merged to main as 38086e64d. The fail-first test TestEscalate_LongThread_BoardRenders and the fix's own description are quoted verbatim where a scene is marked RECORDED.
The UI chrome in every scene, the board, the pull-request page, the terminal excerpt, the verification run, is an authored reconstruction drawn to match the recorded behaviour; no invented timing, metric, or passing-test output is presented as if it were measured. A scene is marked RECORDED when the event it depicts is directly evidenced by the cited public artifact (an issue filed, a draft pull request, a test shown red, a commit, a merge) and any text shown in quotes is verbatim from that artifact. A scene is marked ILLUSTRATIVE when it is an authored representative state (the brief, the specific review finding, the verification table, the final board): drawn to match the behaviour, not captured from one artifact. Approval and independent verification are shown as two distinct acts, and the merge is a person's.