Run #28 ended with a person rejecting the release gate over a contradiction that six artifacts had already recorded. It also ended with two defects named and traced: the Architect's structured result was dropped in storage before it could reach the gate, and a generic approval had been quoted downstream as consent to rewrite the request. Run #29 was the first run on the fixes for both.
What we did to prepare
One change landed between the runs, merged forty minutes before Run #29 launched, with a production migration applied twelve minutes ahead of it.
The first part was provenance. Every role's request now carries a section of recorded human decisions, drawn from the durable approval records alone: which gate, the outcome, the comment verbatim or none, and a fixed statement of what that decision authorises. For an approval, that is continuing the Flight past that gate and nothing more, explicitly not approval of any change to the request. When nobody has decided anything, the section says so, so silence is never left for a model to fill. The record's shape has no field capable of expressing consent to a requirement change.
The second was the dropped signal. The artifact table gained a column for the Architect's grounding result
and the row mapper now reads and writes it. The migration was applied to production at 01:49 UTC, before the
code that depends on it merged at 02:01. That ordering mattered after Run #23,
where code ran against storage that hadn't caught up. When the result is contradicted, the approve action is
now labelled "Continue despite contradiction" and asks for a deliberate confirmation. No "approve revised
requirement" action was built: the engine has no concept of a revised request, and the change deliberately
doesn't pretend otherwise. Someone who wants a different requirement starts a new Flight with it stated.
The third was how a Flight describes itself. Status is now three separate questions: did the step run, what did BinChicken find, and what did a human decide. Completed doesn't mean good, and approved doesn't mean passed. A new amber means "take a look and make a decision." Gates are named for their subject, so "Release approval" rather than "approval approval," and each shows its evidence and its human decision as two independent facts. The rendered screens have no automated tests, and the record says so plainly: a human visual check is still owed.
Run #29's request happened to ask for exactly this vocabulary somewhere new: green for completed runs, amber for runs that need attention or human judgement, red for failed, rejected or blocked, neutral for everything else, applied to "the Runs page."
What happened
Scope took 45 seconds on 976 tokens of input, the request and little else, since by design it reads no repository files. Nothing then happened for about 13 and a half minutes.
Architecture came back unresolved. Its stored result says it could not locate the responsible
implementation. Its open questions ask for the exact path of the Runs page, how status is currently rendered
there, and whether the new amber token exists: "has ADR-050 been merged?" The design record's own status
line, as it stands on main, still reads "not merged." It was written before the merge and never updated.
The Architect also proposed a new shared utility for the colour mapping. UX and later Build both rejected it
in favour of the existing status configuration as the single source of truth.
Another five and a half idle minutes passed. UX (47 seconds, confidence 0.4) asked whether
blocked_governance_intervention should be amber or red, which "requires a recorded human decision before
implementation." Security took 50 seconds and came back at 0.7. The security gate was requested at 03:03:28
and approved at 03:06:04, 2 minutes 36 seconds later, with no comment.
Build declined to invent anything. Its notes say: "Since the Runs page files are absent from the supplied context, I cannot produce a minimal diff against existing content." It began by saying it would create skeleton pages. What it committed was one file, a documentation note recording the correct pattern for when the files become available. Run #27's Builder, in the same position, had written a component that nothing imported.
Review, Test and the Approval step all came back at 0.4. Review called it a "request_changes situation"
that delivers "zero functional change," and asked: "Should the task be retried with these files included?" It
also caught two errors in the Architecture: it had mapped blocked_governance_intervention to amber when the
configuration treats it as red, and carried skipped into its mapping, a status the request names but the
run-status schema doesn't contain.
The release gate was rejected 43 seconds after it opened, with no reason recorded. The Release step was
skipped, the run ended failed at 03:10:52, and no pull request was created.
What we found tracing it
There is no Runs page. The app's run routes are runs/[id] and runs/new. There is no index at /runs,
in the real application or the demo. Run status renders on the Dashboard, Repository Detail and Workflow
Detail pages, and in the Flight header and step cards. Three roles named app/(app)/runs/page.tsx and
app/demo/runs/page.tsx outright, and two more asked for "the Runs page files," all as though they existed
and were merely missing from context. Review's suggested retry would not have helped: those paths aren't in
the repository. What the author meant, perhaps the
Dashboard's list of runs, we don't know. It is the second task in a row whose request describes something the
repository doesn't contain, the first being the footer's copyright year.
The persistence fix is confirmed in production. The Architect's unresolved result sits on the
architecture artifact in the database. This is the first run where the signal survived storage, which is
exactly what Run #28 found missing. Whether the gate screen rendered it, we can't see.
No artifact in this run claims a human approved anything. A search of the architecture, patch, review, test plan and release notes for approval claims found none, where Run #28 had three. One run is thin evidence and a model can still misquote, as the design record itself says, but the specific failure didn't repeat.
The gates behaved as their evidence suggested. By the new mapping, the security gate's evidence was amber (an unresolved grounding result and a 0.7 review) and the release gate's was red (a code review at 0.4). The amber gate was approved and the red one rejected. That is inferred from stored values and the design, not observed.
Twenty-two open questions had nowhere to go. The Architect, UX, Review, Test and the Releaser raised at least 22 between them, most answerable in a sentence: which page, and should that status be amber or red. A gate offers approve or reject, and rejecting ends the run permanently. A person who wants to answer starts a new Flight. The Flight was well calibrated about what it didn't know, with no way to put that to use.
About nineteen of the twenty-nine minutes were idle. Actual processing took roughly five and a half minutes and the two gates just over three. Most of the rest was two stalls with no safety gate and no approval gate anywhere near them. The platform logs show the first request to advance the run at 02:41. The next came at 02:55, 13 and a half minutes after Scope finished. After Architecture finished, the next came about five and a half minutes later. Two reads of the run's status fell inside those windows, neither followed by a request to advance it. From 03:06 onward the run advanced within 8 to 14 seconds of each wave finishing, so the loop works when something is driving it. The cause is unknown. We think the likeliest candidate is a client that stopped driving the run, but the logs can't show it, and nothing on the server resumes a run on its own.
What the evidence actually supports
Both Run #28 defects are closed on production evidence at the storage and provenance layers. The grounding result persists, and the specific fabricated-consent claims didn't recur. Neither claim reaches as far as the screens, which are unobserved.
An honest "I can't find it" is only as useful as what follows it. unresolved was the correct answer and
every role echoed it, but six more roles ran, roughly three and a half minutes of processing, after the first
signal that the premise couldn't be located. The design makes that signal advisory, and the only human
decision before Build was the security gate. That's the design working as written.
Detection is not resolution. The Architect could tell that the page wasn't there. Nothing yet turns that into a question a person can answer without ending the run.
Where this leaves things
- The grounding result and its storage are confirmed working. Whether the gate surfaces it was not observed.
- The question channel is still missing. Twenty-two questions, one permanent-stop action. Nothing is proposed here; what a Flight should do with a question is a decision for outside this post.
- Idle time with no gate and no processing is real and unexplained. About nineteen minutes of one run. Server-side, nothing resumes a run that its client isn't driving.
- The rejection left no reason on record. The new gate explains why a reason helps. Here, the only account of why is what the roles themselves wrote.
- The
@testing-library/reactimport didn't come up, since this run never produced a test file, so that question stays where Run #28 left it.