id: hf-2026-10-05-merge-and-deploy-the-handoff-in-progress-page-with-supervisor-conversation-links url: url://handoff/handoffs/hf-2026-10-05-merge-and-deploy-the-handoff-in-progress-page-with-supervisor-conversation-links title: Merge and deploy the Handoff 'In progress' page with supervisor-conversation links summary: Land AiCliSupervisorManagerEmbedded PR 32 (0.0.71, tests passed 158/158) once kotlin-build-ci concludes its check run (CI app stopped concluding finished buildtest runs ~02:30 UTC 2026-10-06), then publish embedded 0.0.71, bump the AiCliSupervisorManagerServiceServer pin, deploy the manager. Handoff side is done: all 5 Handoff PRs merged and deployed, /in-progress live. created: 2026-10-05T14:27:45.368Z completed: null blocked-reason: kotlin-build-ci stopped concluding finished buildtest runs (~02:30 UTC); manager PR 32 check stuck in_progress after passing; awaiting user decision on investigating CI dependencies:

Merge and deploy the Handoff "In progress" page (work in progress with conversation links)

Written 2026-10-05 ~14:30 UTC. RE-VERIFY: everything below is a write-time snapshot. Re-check each PR with gh pr view <n> --repo CodexCoder21Organization/<repo> --json state,mergeStateStatus,mergedAt before acting.

Mission

User request (verbatim): "We should update https://www.handoff.wasmserver.com/ to have a page showing work in progress (active/claimed handoffs / active conversations), and include links to the relevant/associated aiclisupervisor conversation like https://aiclisupervisor.wasmserver.com/conversation?supervisor=sup-e6b06a2bfb08&id=conv-c05a01dd168cb764d9a26cbfbf18ab022bfb8f1b6394fad3e8cbc7c9f6688045"

The user chose:

the full chain: a manager catalog sessionIds filter → a Handoff service projection → a WUI page;
"deploy after merge": deploy only once the user has approved the merges.

What was built

AiCliSupervisorManagerEmbedded: listConversationsJson accepts sessionIds (1–200 non-blank strings) and returns only rows with those harness-native session ids. This is version 0.0.62, not yet published. The API PR documents the field.
HandoffApi 0.0.21 (published): adds WorkInProgressProjection / WorkInProgressItem / WorkInProgressClaim / ConversationTranscriptRecord, and HandoffService.getWorkInProgressJson(). The latter is a default method that throws UnsupportedOperationException on older services.
HandoffEmbedded 0.0.27 (published): getWorkInProgressJson() lists open handoffs that have claims or an ACTIVE attached conversation. It resolves each claim's ConversationReference against the manager catalog as follows:
- One batched read: chunks of 200, at most 4 pages per chunk.
- Time-bounded by supervisorSnapshotTimeoutMs, on a 2-thread pool; when that pool is full, the call answers "unavailable" immediately rather than queueing.
- Answers are cached for 15 seconds.
- A row links only when both harness and sessionId match exactly. This guards against older managers that ignore the filter.
- When the catalog is unavailable or incomplete, the projection carries the reason, and the page shows it as a warning.
- The constructor signature is unchanged on purpose: Java cold-start launchers call the 7-argument constructor.
HandoffServiceServer 0.0.26: adds the getWorkInProgress RPC and the sandbox client method.
HandoffWui 0.0.26: the /in-progress page.
- It is linked from the top of the sidebar.
- Cards are ordered by recent activity.
- Each claim links to the "Live terminal ↗" (/session) and/or the "Transcript ↗" (/conversation, when indexed).
- A "Claims left open" section holds stale claims.
- There is an empty state, and a notice when transcript lookup is unavailable or not configured.
- Screenshots are in the PR description.

Relevant PRs / refs

All five Handoff-side PRs are green on required checks and have passed my final review. They are not merged, because merging waits for explicit user approval (Opus-mode rule).

Repo	Branch	Remote head SHA	PR	State
HandoffApi	work-in-progress-page	b5aab7e595baa091575d4e8e993df1225abf8454	https://github.com/CodexCoder21Organization/HandoffApi/pull/17	CLEAN, green; 0.0.21 published
HandoffEmbedded	work-in-progress-page	cc999d69e390870140f28caeb18cf47441e34d87	https://github.com/CodexCoder21Organization/HandoffEmbedded/pull/20	CLEAN, green; 0.0.27 published
HandoffServiceServer	work-in-progress-page	901463769cfe0d5872301697462971708fae237d	https://github.com/CodexCoder21Organization/HandoffServiceServer/pull/28	CLEAN, green; full suite 54/54 locally
HandoffWui	work-in-progress-page	78a97d266e431fd3751519a0b59b9b12a7224eaa	https://github.com/CodexCoder21Organization/HandoffWui/pull/32	required `kotlin.build (remote)` green
AiCliSupervisorManagerApi	document-conversation-session-id-filter	9093293be8d0d86ada3fb47efb3364a02748d961	https://github.com/CodexCoder21Organization/AiCliSupervisorManagerApi/pull/17	CLEAN, green; docs only
AiCliSupervisorManagerEmbedded	conversation-list-session-id-filter	2c97b5d556cd92c86e903e8a7b57cac6aaf6bbb9	https://github.com/CodexCoder21Organization/AiCliSupervisorManagerEmbedded/pull/32	DIRTY (conflicts with main); see below
AiCliSupervisorManagerEmbedded	session-id-filter-stacked-on-exact-id-search	b681c9d38e366beb1c1cb3ee0ddc5ff572e065e1	no PR	the same change rebased onto sibling PR 30's branch; only the build.kts/README version conflicts were resolved

Notes on the WUI PR's non-required check, kotlin.build (kompile-remote-build):

It failed without running any test. Run dae54786 hit "Provisioning deadline exceeded … UrlResolver is closed; cannot fetch sandbox bytecode for 'url://digitalocean-droplets/'".
The same check is green on main.
Only that check run was re-requested (check-run 111778015219), so the green required check in the same suite was not wiped.

Notes on the manager embedded PR 32:

Sibling https://github.com/CodexCoder21Organization/AiCliSupervisorManagerEmbedded/pull/30 (0.0.61, exact-id search) is already published and deployed, but not merged.
0.0.62 must contain PR 30's change. So: wait for PR 30 to land, rebase PR 32 (the stacked branch already shows the resolution), publish 0.0.62, then bump the embedded pin in AiCliSupervisorManagerServiceServer. That repo currently pins embedded 0.0.61 at server version 0.0.44, and its PR 36 is open.
PR 32's red CI comes from four heavy tests (process-halt, large-state, notes convergence) that also fail on unmodified main today.

Deployed or published but not merged:

Published to kotlin.directory: handoff:api:0.0.21 and handoff:embedded:0.0.27. Both are built from the branch heads above and are not yet on main.
Nothing in this effort has been deployed to production. HandoffServiceServer and HandoffWui are still running their previous versions.

Next steps

Get user approval to merge the five Handoff-side PRs. Then merge in this order: HandoffApi 17 → HandoffEmbedded 20 → HandoffServiceServer 28 → HandoffWui 32, plus AiCliSupervisorManagerApi 17. These repos use merge queues (GraphQL enqueuePullRequest). Never use --delete-branch.
Deploy HandoffServiceServer first, then HandoffWui (container-nursery-deploy skill; see the memory "Handoff ContainerNursery deploy recipe"). Then verify https://www.handoff.wasmserver.com/in-progress live and check that the first frame has no error banners.
Without the manager redeploy, the page still works but degrades: the manager ignores sessionIds, so only exact matches on the catalog's newest page get links, and the page shows the "does not support the sessionIds filter yet" warning.
Restarting the manager causes an ~80-minute conversation-search outage (a 2 GB SearchableBucket replay holds the search lock), so the user must choose when it happens. Once they agree: after PR 30 lands, rebase PR 32, publish 0.0.62, bump the ServiceServer pin, then deploy.

Operational knowledge

gh pr edit silently fails on these repos; use gh api -X PATCH repos/<o>/<r>/pulls/<n> -f body=....
The url://buildtest/ remote test service was flaky today: persistent RPC connections closed mid-request. This was recorded as a challenge. Retry on transport errors only; use --local for small targeted runs.
The /code box has only ~1 GB free; parallel local test runs got OOM-killed.