Files

3.8 KiB

Row 80 round 1 (#1574), Filbert: approve.

Candidate manifest SHA-256: 52c4152603c3e783f887c2cca17912289ae7f74acc201589c66ea018fff22ee5. Base: 57a2ddc5. Packet: agents/researcher/work/queue-80/r1/ (3182fdf1). This answers request 28185.

I rebuilt the candidate in my own worktree at 57a2ddc5 and applied build.patch. All three manifest hashes match. Nothing under packages/bus/ changed from 57a2ddc5 to the current origin/refactor. Row 93 will change that, and Sage's gate on the rebased tree covers it.

Static findings against the brief:

  1. Definition. The query at broker.mjs:1048 matches the brief's definition: addressed to the role, with a delivered row whose run isn't the current holder, and no read row. It's scoped by business and role, ordered by m.seq, and capped at STRANDED (50). delivered rows come only from message.receive (:847), which skips any message that already has one, so each message has at most one delivered row and the join can't list a message twice.
  2. Stranded and working split the role's delivered, unread messages. The working count (:1030) takes holder_run = current and stranded takes IS NOT current. If a run releases and later reclaims the role under the same run name, its old deliveries count as working, not stranded. message.read checks the latest delivered row's run, so that run can still read them, which keeps this consistent.
  3. No writes. It's one SELECT followed by a .map to plain objects. The first new test compares the whole deliveries table before and after the release, the claim and two listings. Routing and receive are unchanged, so nothing is redelivered.
  4. Exposure. Only the human and reader branch adds stranded. Role sessions still get only the claim keys, which :62 pins, and M13 checks.
  5. Tests cover each bullet in the brief: released unread and then listed; a read message not listed; the current holder's unread message not listed; the 50 cap and oldest-first order; [] for a role with none (:58-59); and per role and per business. They also add the not-yet-received case from Sage's ruling.
  6. The README delivery paragraph and the Agent state section say what a release without a read leaves behind, where to see it, and that a vacant role's messages show once a run claims the role.

Brief item not in the packet:

  • R1. The brief's "What ships" list says "The packet names what the Console would need to show the list." BUILD.md has no such note. The candidate doesn't need to change for this. A few lines in the packet would cover it, for example: webui/src/public/bus.js reads inputNeeded at :425 and would read stranded the same way, and the control board would need the same field. Sage can have it added before landing or record it as the follow-up row itself. I don't hold the verdict on it because the manifest is unaffected.

Notes, not blocking:

  • N1. M12's mechanism. BUILD.md says the TypeErrors at :203 and :221 fire "before the L58 key-list assertion runs". They're in different tests. out/M12.log shows :58 failing too, as comment 28186 says, so the expected killer holds and BUILD.md's explanation is wrong.
  • N2. BUILD.md's title and headings say "round 2", and its "Round 1 (superseded)" section is an earlier phase A attempt. The queue round is 1. That's only a labeling difference, but it's confusing next to the request.
  • N3. The brief still names Darkwing as owner and agents/darkwing/work/ as the packet path. Decisions 122 and 129 moved it to Researcher, and BUILD.md cites them. Nothing to change in the candidate.

My review is static. I ran no suites, mutants or queue-commit.sh. The packet reports bus 120/120, all 14 node suites and nine scripts/test-*.sh at exit 0, and 15/15 mutants killed with a green baseline. Sage's gate rerun on the rebased tree after row 93 is the check of record.