Repository navigation
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Link cards stop keeping a thread on Input after a newer agent-authored user-role message, matching the existing behavior for human messages. Cards remain answerable, and existing settlement safeguards are unchanged. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
Wladefant
left a comment
There was a problem hiding this comment.
Refs Wladefant/superboard#1477 #1773 #1778 #1798 #1899 #2233; #32473 — bounded separate nonauthor status/reconciliation review, 7 Nov 2026 UTC
Verdict: APPROVED for the source correction at exact e0aa293590aaf565a41d33a645b351921431daf1 (OPEN, unmerged, original author eyeveil). Reviewing GitHub principal Wladefant differs from source author; review is separate under the current #1899 same-family allowance. This does not authorize upstream merge, installed runtime, changed operator session, fleet watcher cutover, or physical peer-link acceptance.
Concrete source contract: Previously, a pending link card remained in the shell's Input state when a later user-role message was agent-authored (createdBy=agent, e.g. t3 thread send), despite zero pending requests; a fleet watcher could repeatedly report a question. The two-file patch consistently uses the latest non-idle-compaction user-role message regardless of creator in (a) projection shell, (b) SQL shell pending-link query and (c) settlement-candidate filtering. Secret-card and actual pending-runtime-request ownership are unchanged. The existing real PeerLinkRequests fixture now advances via an agent-created user-role message and verifies the shell card no longer blocks and settlement becomes eligible. No additional P1/P2 was demonstrated in the bounded source patch. A later unrelated agent-authored user-role message may intentionally count as “moved past”; this is the explicit semantics of the proposed change, not proof that the actual link request was fulfilled.
Actual exact-head workflow: normally triggered CI #42376250124 COMPLETE/SUCCESS. Original server shard job logs checked out synthetic merge 972e01d explicitly containing the exact candidate merged into e455200077ce60806a01c8f28435b58860dcfc74. Original changed PeerLinkRequests.test.ts ran 19/19 PASS (Test Server 2 job #128414316965); ProjectionSettlement.test.ts 5/5 PASS (Test Server 3 #128414316991); ThreadSettlementService.test.ts 34/34 PASS (Test Server 6 #128414316805), 58/58 across the three selected suites. Lint, 8 server shards, Test, Build/Typecheck and aggregate Check succeeded; Agent Context Budget #42376250031 succeeded. Test Web, Rust, Release Smoke and Mobile Native Static Analysis SKIPPED. No live two-machine peer flow or installed T3 watcher measured. Commit-workflow lookup is PR-event first-page limited; this is not a claimed complete all-event run inventory.
Next custody: original eyeveil/T3 maintainers handle protected source merge, then original Superboard #1773 fleet-watch owner checks selected pinned revision and t3 thread show/thread-shell status under authorized pilot fixture. Do not automatically restart operators, replay uncertain work or replace a working route to adopt this change. This approval is source-level only; #1773/#1778 fleet integration and human browser control remain open.
Problem
When an agent calls
t3_environment_link, its link card marks the thread as waiting for input. #28491 made the card stop counting once the user writes in the thread again, but it counts only messages withcreatedBy: "user". Threads that agents drive, through subagent notifications, coordination messages from other threads, or a thread started over MCP, may never get one. They stay on Input for good while every pending-request list is empty.To reproduce, have an agent ask for a link and end its turn. Then start another turn with an agent-authored message, for example
t3 thread send. The thread finishes but still shows Input, andt3 thread showreportspendingRequestCount: 0. In the thread where this surfaced, a card asked 53 runs earlier kept the thread on Input. A watcher keyed on that status also re-reported "asks a question" on every new run.Change
The card now stops counting once any user-role message newer than it arrives, whoever sent it. Idle compactions still don't count. Both shell paths (
threadShellFromProjectionand the SQL shell row) and the auto-settle query from #29847 use the same rule. A thread that reads as done can therefore also settle. The card stays pending and answerable in the timeline. Secret cards are unchanged.Scope and approval
This is a very small, focused fix for an obvious bug. It finishes the rule #28491 introduced for threads that no person types into, and it changes one comparison in three places that must agree. It is server-only. Web, desktop, and mobile read
pendingRuntimeRequestfrom the shell, so they pick it up with no client changes. #26944 is related but separate. It ends a card after a matching retry links, and in this case no retry happened.Verification
the agent asks without waiting…case inPeerLinkRequests.test.tsnow writes an agent-authored message past the card. Onmainit fails withexpected { …(4) } to be nullat the shell assertion. With the fix, it passes, and the settlement assertion after it passes too.PeerLinkRequests.test.ts,ProjectionSettlement.test.ts, andThreadSettlementService.test.tspass 58/58.PeerLinkRequestsservice against a served peer.Moved from #32470, which came from an organization-owned fork that maintainers can't push to. This copy comes from a personal fork with maintainer edits allowed.
Model and harness: Claude Opus 5.5 (lead, implementation) via Claude Code in T3 Code.