feat: show delegation wake messages as a notice, and add client pair state

[rynfar]

Problem

When a delegated thread or a pair executor changes state, Pylon sends its parent an automatic message written for the agent: a preamble, one JSON line per child, and a paragraph of rules. Web and mobile both showed it as a user bubble, so the user saw a wall of JSON in their own voice, with the edit and rewind actions of a real message.

Separately, neither client had a way to tell whether a thread is paired, to find its executor, or to build the command that turns a pair on.

What changed

The notice

• parseDelegationNotice in client-runtime reads only a user-role message whose id has the server's delegation-follow-through: prefix, so a person who pastes similar text still sees their own words. It keeps each child's thread, title, status, and one-line failure reason, skips malformed lines, and returns null when nothing usable was read, which falls back to the original text rather than an empty box. Its tests are built from the exact text formatDelegationFollowThroughPrompt produces.
• Plain wording: "Executor finished", "Executor needs your approval", "Executor has a question", "Executor was stopped", "Executor failed", and the same for an ordinary delegated thread.
• Web: DelegationNoticeRow replaces the bubble with one quiet line per thread (status dot, headline, title, failure reason, Open link). It has role="status", an info outline when something is waiting on the user, and none of a message's actions. UserTimelineRow is split so the message row's hooks stay unconditional.
• Mobile: the same notice in the thread feed, using the feed's existing tokens; each row opens its thread.

Client pair foundations, which the notice uses to tell an executor from a fan-out child and which the pair control builds on next

• @t3tools/shared/delegatedThreads: a synchronous pairExecutorThreadId and isPairExecutorThreadId, tested against the server's formula, including lead ids that contain colons.
• @t3tools/client-runtime/state/pair: whether a lead can pair and the reason if not, whether the pair is on, what the executor is doing (reusing the client's existing delegated-child status rule, now exported), hiding executors from thread lists, and the thread.create fields that turn a pair on.

Evidence

Verified in an isolated dev server with a seeded thread holding two real wake messages. Before: the raw JSON bubble, as reported by the maintainer. After: "Executor finished · Executor · Fix the parser · Open" as one quiet row, and a second notice with the info outline listing "Delegated thread needs your approval" and "Executor failed" with its reason in red. The agent-facing text is absent from the page. Before and after images were shown to the maintainer in the working thread; they are not committed.

Verification

• client-runtime state tests, DelegationNoticeRow, MessagesTimeline, MessagesTimeline.logic, and mobile threadActivity: all passed on the lead's independent run; after the hooks fix, MessagesTimeline and DelegationNoticeRow: 67 passed.
• vp run -F typecheck for client-runtime, shared, web, and mobile: 0 errors. vp run knip:check: exit 0.
• Contract and tests were written by the lead first: 3 shared tests, 10 pair state tests, 7 parser tests, and 3 row tests, all failing against stubs. Lead-owned files were byte-identical after implementation (blob hashes checked).

Not covered

• The mobile notice was typechecked and its tokens and navigation call were checked against existing usage, but it was not run on a simulator.
• The pair control itself. It is the next pull request.

Part of #622.

Contracts, tests, hooks fix, and review by Claude Fable 5.1 in Claude Code; implementation by Gemini 3.8 Flash (High) in Antigravity, as a Pylon delegated child.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pylon-marketing	Ready	Preview	Sep 18, 2026 4:23pm UTC

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	14.0 KiB	13.9 KiB	−73 B (−0.5%)	15.1 KiB	✅
Codex	Thread snapshot wire	7.2 KiB	7.2 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.7 KiB	6.7 KiB	−72 B (−1.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	58.0 KiB	58.0 KiB	−88 B (−0.1%)	66.4 KiB	✅
Codex	Live turn messages	10	8	−2 (−20.0%)	21	✅
Claude	Total thread wire	14.0 KiB	14.0 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.2 KiB	7.2 KiB	+9 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.8 KiB	6.7 KiB	−11 B (−0.2%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.9 KiB	58.9 KiB	−44 B (−0.1%)	66.4 KiB	✅
Claude	Live turn messages	10	9	−1 (−10.0%)	21	✅

Baseline: dd7189c · PR result: f7da650 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 115.7 KiB
• Claude decoded thread snapshot: 116.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.