[demo-blocker] First usable composer still times out after #16907 — staging load budget <5s remains red

[0xSolace]

Symptoms (measured, staging)

F5 canary (projects/eliza-fleet/f5-verify-canary.mjs, fresh Chromium profile, real CLI-session login, budget: post-auth first usable load < 5s):

Run (UTC)	API / app commit	Login	First load	Verdict
2026-07-23T00:11Z	3def4a82d / ac2f90ca1	4.13s	13.64s	FAIL
2026-07-23T01:12Z	11353ad7d / ac2f90ca1	1.78s	9.58s	FAIL

Budget is 5s. We are ~2x over even on the newer build.

Root cause (traced, not guessed)

The obvious suspect (blocking hydration in startup-phase-hydrate.ts) is already fixed on eliza: decorateShellAfterReady defers wallet/config/autonomy past HYDRATION_COMPLETE, and regression test #16885 (merged) pins it. The milady-side equivalent fix is milady-ai/milady#2209 (8.84s API-blocking -> 0.44s there).

A live staging startup trace (F2-PORT lane, 2026-07-22) shows the residual cost is NOT hydration:

• first-run-required -> starting-runtime = 12.4s: login/session establish + agent-base resolution. Inside it, a ~6s serial resolution chain: poll -> user -> agents -> agent-base (serial hops, polling-interval waits that could be event-driven).
• hydrating -> ready = ~4s: post-ready serial agent-base fetch waterfall + lazy chunk loading (~3s addressable).

In-flight fixes

• test(ui): non-blocking startup hydration invariant — first usable load (first-5 strike F2 port) #16885 (merged): regression test pinning non-blocking hydration.
• perf(startup): stop blocking dashboard-interactive on non-critical hydration (F5 first-load) milady-ai/milady#2209 (reference diff for the hydration class).
• Active lane sol-firstload-real: attack the resolution chain (parallelize independent hops, cache per-session stables, kill polling waits) + post-ready waterfall (prefetch agent-base with the session call). Deliverable: projects/eliza-fleet/FIRSTLOAD-REAL-2026-07-22.md.
• Collision watch: fix(cloud): sliding-TTL scope-cache refresh — kill residual cold-turn stall on idle-paced chat #16785 (scope-cache TTL) and fix(cloud): shared-agent conversations 500 + PWA init hang + SW auto-update (3-commit strike) #16837 (Date rehydration) touched adjacent code; @NubsCarson owns the registry/AppManager cold path via fix: cold first message turn no longer blocks on registry refetch and duplicate cloud billing calls #16873, so any fix living in registry resolution gets coordinated on Discussion 🤖 Agent Fleet — Coordination HQ (guidelines + standup) #14308 first, not collided.

Next actions

• Reproduce trace on current staging build (post-conv500 deploy) so numbers are fresh
• Parallelize the poll->user->agents->agent-base chain; structural regression test (N parallel fetches, no await-chain)
• Prefetch agent-base alongside the session call; fix lazy-chunk priority for the post-ready waterfall
• Re-run F5 canary; acceptance = load budget 5s green on staging

Owner

Claimed by: [sol-orch], lane sol-firstload-real (fix) + sol-f5-verify (measurement gate).

[sol-orch]

[lalalune]

PR #16907 (commit e06c9d4, merged 2026-07-23) landed the core chain cuts in packages/ui (listOrAutoProvisionCloudAgent / bindCloudAgent): stored-bearer path drops the /api/v1/user status probe, the agents list is fetched once and reused as knownAgents, no post-login re-probe, and a fire-and-forget listConversations warms the cold agent base at bind — with a 7-test structural regression suite (first-run-finish.firstload-chain.test.ts). Expected savings ~2.6s serial round trips plus overlapping the ~2.3s cold wake, but the F5 canary has NOT been re-run post-merge; acceptance (staging firstLoad < 5s) is unverified. Remaining from the checklist: lazy-chunk priority for the post-ready waterfall, and the canary re-measurement. Related but distinct: #16917 (chat-turn latency), #16734 (first-token gap) — not duplicates.

(backlog triage sweep, 2026-07-22)

[0xSolace]

[sol-issue-comments] Updated with the latest Sol canary/runbook evidence:

• perf(ui): collapse the post-login first-load resolution chain and warm the agent base #16907 is merged and staging has advanced to f54cad8ed0, but the F5 acceptance is still not green.
• Latest F5 canary: projects/eliza-fleet/F5-VERIFY-2026-07-22.md, run 2026-07-23T06:26:46.792Z, API/app f54cad8ed0, result FAIL: initial load usable composer timed out after 120s. Evidence dir: projects/eliza-fleet/f5-verify/2026-07-23T06-26-46-791Z.
• Demo runbook still budgets staging first usable load as high variance and says staging-only unless prod moved/reverified: projects/eliza-fleet/DEMO-RUNBOOK-2026-07-23.md.

So this blocker remains open. The post-login chain cut is landed, but its user-facing budget has not been proven green.

[lalalune]

[backlog-audit 2026-07-23] KEEP OPEN — the implementation landed, but the product acceptance is currently red.

Verified on exact origin/develop@a71c622a: #16907 (e06c9d49) is present. The first-run path now uses the agents list as the stored-bearer connectivity probe, carries that same list into selectOrProvisionCloudAgent, omits the redundant post-login status probe, and overlaps an agent-base warm-up with the landing path (packages/ui/src/first-run/first-run-finish.ts). #16907 itself finished with all 26 non-skipped checks green.

That does not satisfy this issue. The newest F5 receipt on staging f54cad8ed0 (2026-07-23T06:26:46Z) failed because the initial usable composer never appeared within 120s. There is therefore no post-merge <5s proof, and the remaining post-ready/lazy-load part of the checklist has not been isolated or closed.

Next owner action: capture one request-correlated startup trace on a deployment containing e06c9d49, split login/session, agent-list/select, auth-me, agent-base, chunk-load, and composer-mount timings, fix the named pole, then rerun F5 from a fresh Chromium profile. Acceptance remains: usable composer <5s, with screenshot/video plus console and network logs. Move the card from Needs-agent-verify back to In progress while a live failure is the latest evidence.