@elizaos/plugin-agent-orchestrator 2.0.0-beta.1 → 2.0.11-beta.7

package/docs/multi-account-orchestration.md

@@ -0,0 +1,76 @@
+# Multi-account coding-agent orchestration
+
+Goal: an Eliza orchestrator agent that runs **multiple Claude Code + Codex
+subscriptions** (and rotates OpenCode across pooled Cerebras accounts), picks
+the **least-used** account for each new
+sub-agent, tracks per-account **session + weekly usage**, manages those
+sub-agents in a **shared task room**, and decides **when to interrupt** a
+running sub-agent vs. let it keep working.
+
+## What already existed (do not rebuild)
+
+| Layer | Location | Status |
+|---|---|---|
+| Account contracts (`LinkedAccountConfig`, `LinkedAccountUsage`, 12 provider ids) | `packages/contracts/src/service-routing.ts` | ✅ |
+| Credential storage (`<stateDir>/auth/{providerId}/{accountId}.json`) | `packages/agent/src/auth/account-storage.ts` | ✅ |
+| OAuth flows (Anthropic + Codex) + coding-plan keys + API keys | `packages/agent/src/auth/oauth-flow.ts`, `credentials.ts` | ✅ |
+| `AccountPool` — priority / round-robin / **least-used** / quota-aware, affinity, health | `packages/app-core/src/services/account-pool.ts` | ✅ |
+| Usage probes (`pollAnthropicUsage`, `pollCodexUsage`) + JSONL day counters | `packages/app-core/src/services/account-usage.ts` | ✅ |
+| Accounts REST API (`/api/accounts/*` incl. OAuth SSE) | `packages/agent/src/api/accounts-routes.ts` | ✅ |
+| Settings UI (AccountList / AccountCard / AddAccountDialog / RotationStrategyPicker) + `useAccounts` | `packages/ui/src/components/accounts/*` | ✅ |
+| Multi-account API-key routing for the *main agent* | `credential-resolver.ts` → `resolveProviderCredentialMulti` | ✅ |
+| Orchestrator tasks, sessions, task-rooms, event bridge, usage rollup, REST + SSE | `plugins/plugin-agent-orchestrator/*` | ✅ |
+| `shouldRespond` (RESPOND/IGNORE/STOP) + per-room `TurnControllerRegistry` abort | `packages/core/src/*` | ✅ |
+
+## The keystone gap
+
+The `AccountPool` was wired into **API-key model routing** but **not into the
+coding-agent spawn path**. Coding agents authenticate by *subscription*, not API
+key: `applySubscriptionCredentialsLocal` never injects Claude/Codex tokens into
+`process.env`, and `AcpService.buildEnv` even *strips* an OAuth
+`ANTHROPIC_API_KEY` so Claude Code falls back to the single machine login
+(`~/.claude`). So every spawned sub-agent used one account, with no rotation and
+no per-account attribution.
+
+The orchestrator plugin depends only on `@elizaos/core`, so it cannot import the
+pool. `account-pool.ts` already solves this with `globalThis`-symbol **bridges**
+(Anthropic + subscription-selector). We add a third: a **coding-agent selector
+bridge**.
+
+## Hitlist
+
+### P0 — Keystone: account selection on spawn (round-robin / least-used)
+- [x] `coding-account-bridge.ts` (app-core): install `Symbol.for("eliza.account-pool.coding-agent.v1")` bridge — `select(agentType)`, `markRateLimited`, `markNeedsReauth`, `recordUsage`, `describe()`.
+- [x] Per-agent credential injection: claude → `CLAUDE_CODE_OAUTH_TOKEN`; codex → per-account `CODEX_HOME/auth.json` + minimal `config.toml`; opencode → `CEREBRAS_API_KEY` (pooled Cerebras); direct API providers → their env key.
+- [x] Wire into `AcpService.spawnSession`: select before transport branch, merge `envPatch` into `customCredentials`, stamp `session.metadata.account*`, surface on `SpawnResult.metadata`.
+- [x] `buildEnv`: when `CLAUDE_CODE_OAUTH_TOKEN` is injected for claude, drop `ANTHROPIC_API_KEY` so the selected subscription wins.
+- [x] `OrchestratorTaskSession` carries `accountProviderId` / `accountId` / `accountLabel`; populate from `result.metadata`.
+- [x] Exclude-on-failure retry: on auth/rate-limit error, mark account + re-select excluding it.
+
+### P1 — Usage attribution + stats
+- [x] `recordUsage` also calls the bridge → pool `recordCall` + `account-usage` JSONL keyed by the serving account.
+- [x] `/api/orchestrator/accounts` route: connected accounts + live usage + which sub-agents are on which account.
+- [x] Settings already shows per-account usage; orchestrator dashboard widget adds the accounts + usage summary.
+
+### P2 — Room system + interruption decider
+- [x] Per-participant interruption decider: a running sub-agent keeps working; a new room message is classified (deliver / queue / interrupt / ignore) before it is injected. The "busy" check covers `tool_running` (the dominant mid-turn state), not just `busy`; queued messages flush when the session returns to `ready`. An Eliza participant's `shouldRespond` verdict threads through unchanged when a caller supplies it; coding sub-agents use the structural decider. `multiParty` (more than one live sub-agent in the room) is computed in the forward handler so ambient-chatter suppression is live.
+- [x] Task-room participant **view**: the "Coding accounts" sidebar widget shows the live sub-agent → account assignment map + per-account usage (the flat global map). The dedicated per-room participant roster (orchestrator + owning user + each sub-agent grouped by room, with `activeAgentCount` / `multiParty`) now ships as `GET /api/orchestrator/rooms` (`OrchestratorTaskService.getRoomRoster`), the room-scoped counterpart to `/accounts`. Rooms with no sub-agent sessions are omitted.
+
+### P3 — Tests + mocks + live E2E
+- [x] Mock account fixtures (multi-account, multi-provider) + an in-memory pool for unit tests.
+- [x] Unit tests: selection strategy, per-agent env injection + API-key drop (Claude & Codex), intra-provider retry, usage attribution, interruption decider, route registration.
+- [x] Live E2E (gated `ORCHESTRATOR_LIVE_MULTI_ACCOUNT=1`): validates the selector bridge + usage probe against ≥2 **real** linked accounts (distinct-account rotation via the exclude set; live session/weekly usage).
+- [x] **Composed offline E2E** (`bun run --cwd plugins/plugin-agent-orchestrator test:e2e:multi-account`): real app-core `AccountPool` (real-format mock accounts in a temp state dir) → installed selector bridge → orchestrator `AcpService.spawnSession` → a REAL spawned subprocess (a fake "acpx" standing in for the subscription CLI). Asserts 10/10: two Claude spawns pick **distinct** accounts (least-used round-robin), each subprocess receives its account's `CLAUDE_CODE_OAUTH_TOKEN`, the parent `ANTHROPIC_API_KEY`/`OPENAI_API_KEY` are dropped, Codex gets a per-account `CODEX_HOME/auth.json` with the right token+account_id. Point `ELIZA_ACP_CLI` at the real binary + connect real accounts for true live-key validation. (This harness caught a real cli-transport bug: `runAcpx` rebuilt the env without `agentType`, re-adding the parent keys — now fixed.)
+
+### P4 — Connect-accounts window
+- [x] The connect-accounts window (Settings → Accounts: `AddAccountDialog` OAuth / API-key / coding-plan-key flows, `AccountList`, `RotationStrategyPicker`) pre-exists and is the surface for linking multiple accounts of each type.
+
+## Known constraints / follow-ups
+- **OpenCode pool-rotates across Cerebras accounts only.** OpenCode resolves a pooled key for exactly one backend — Cerebras (`CEREBRAS_API_KEY`, see `buildOpencodeSpawnConfig`) — so `opencode` is a multi-account selector type mapped to `cerebras-api`: it least-used-rotates across linked Cerebras accounts (the bridge injects the selected `CEREBRAS_API_KEY`, which OpenCode's config reads) and no-ops when none are linked (Eliza Cloud / single-key setups are unchanged). OpenCode's other backends (Eliza Cloud, local, user-configured opencode.json) are not pooled. Precedence: a `CEREBRAS_API_KEY` runtime **setting** still wins over a pooled injection — pooling is authoritative only when no single key is configured.
+- **z.ai / Kimi / GLM have no first-party coding CLI.** Their linked accounts serve the main runtime's API-key routing (`resolveProviderCredentialMulti` for `zai-api` / `moonshot-api`) and OpenCode's provider config — there is no `zai`/`kimi`/`glm` spawnable agent type, so they are not advertised as coding-agent selector candidates.
+
+## Quality bar
+- No regression when zero accounts are linked (bridge returns null → today's behavior).
+- Selected account is **observable** (session metadata + structured log + dashboard), never assumed.
+- Subscription tokens only ever flow to the first-party coding subprocess (TOS), never into runtime `process.env`.
+- Per-agent credential precedence is enforced: a selected Claude subscription drops `ANTHROPIC_API_KEY`; a selected Codex subscription (per-account `CODEX_HOME`) drops a forwarded `OPENAI_API_KEY` — so the chosen account always authenticates.

package/docs/orchestrator-buildout-followups.md

@@ -0,0 +1,124 @@
+# Orchestrator (`/orchestrator`) build-out — status & follow-ups
+
+Date: 2026-05-29. Companion to [`research/orchestrator-view-research-report.md`](./research/orchestrator-view-research-report.md).
+
+This records what was finished in the `nubs/orchestrator-view-feature` branch and the
+exact, code-grounded plan for the remaining design-heavy work. The earlier research
+report is largely **out of date**: the durable task model, SQL store, `/api/orchestrator/*`
+routes, central goal-wrapper, validation-gated completion, token aggregation, the
+`OrchestratorWorkbench` view, and the real (non-stub) client methods all already exist
+(Shaw shipped most of it on 2026-05-29). Verify against current code, not the report's
+line numbers.
+
+## Done in this branch (verified)
+
+1. **Mounted the sub-agent credential bridge** (`plugin-agent-orchestrator/src/api/routes.ts`).
+   `handleBridgeRoutes` was built+tested but never dispatched. + dispatcher regression test.
+2. **Unified the goal-wrapper** so the `TASKS` planner action uses the central
+   `buildGoalPrompt`/`buildGoalFollowUp` (`goal-prompt.ts`, `actions/tasks.ts`) instead of a
+   divergent inline envelope. Workspace-routing / URL-mapping / swarm-room content preserved
+   via new optional `GoalPromptInput` fields. + equivalence test (action env == API env).
+3. **Folded durable task threads into `getCodingAgentStatus`** (`packages/ui` client) — was
+   hardcoded to `taskThreadCount:0`. Documented the two genuinely-vestigial ACP stubs
+   (`/metrics`, `/workspace-files`) pointing at the real `/api/orchestrator/*` usage surface.
+4. **Declared capability param schemas** for the 15 orchestrator view capabilities so
+   voice/NL routing can pass `taskId`/`title`/`goal`/etc. **Mounted the sensitive-request
+   REST routes** (`packages/app-core/src/api/server.ts`) — the secret create/submit/fulfill
+   path that orchestrator provider setup will use.
+5. **Locked capability manifest↔dispatch parity** with a regression test
+   (`plugin-task-coordinator/__tests__/unit/orchestrator-capability-parity.test.ts`) + a
+   `test` script so CI runs it. The declared capabilities (`ORCHESTRATOR_CAPABILITIES` in
+   `index.ts`) must exactly match the ids `runOrchestratorCapability` dispatches; this drift
+   previously reopened (`orchestrator-update-task`/`-validate-task`).
+
+## App-shell hardening (this branch)
+
+**Stale/unreachable saved server can no longer wedge first-run.** A persisted
+`elizaos:active-server` pointing at a now-dead / CSP-blocked remote backend pinned the
+client to that address; the startup poll (`packages/ui/src/state/startup-phase-poll.ts`)
+retried it until `BACKEND_TIMEOUT` and onboarding hung forever (clearing cookies didn't
+help — the pointer lives in localStorage). Fix: on a *connection-level* failure (the request
+never received an HTTP response) against a non-loopback, non-same-origin base on an http(s)
+page — never on native mobile, where the remote IS the agent — clear the saved server,
+re-point the client at the local origin, and reach the backend (one-shot). The decision is a
+pure exported `shouldFallBackToLocalOrigin` covered by a unit matrix, plus an end-to-end
+recovery test.
+
+**Onboarding boot issues we hit that are environmental, not code bugs (no regression test
+applies):**
+- *"No provider registered for TEXT_EMBEDDING" → agent won't boot* — caused by a local
+  `ELIZA_DISABLE_LOCAL_EMBEDDINGS=1` in `.env.worktree` with no cloud route, i.e. *zero*
+  embedding providers. With local embeddings enabled the agent boots degraded-but-non-fatal
+  (the intended behavior). A graceful-degradation guard for the "no embedding provider at
+  all" edge would live in agent/runtime bootstrap, not here; flagged for the runtime owner.
+- *Dev service-worker / HTTPS-upgrade theories* — investigated and **disproven** by
+  reproduction; the actual cause was the stale active-server above. The dev SW renders fine
+  with caching active. An optional dev-only self-unregistering SW remains available as a
+  hygiene improvement but guards no confirmed bug.
+
+## Remaining work (specced, not yet built)
+
+Ordered by leverage. `[BE]` backend, `[FE]` frontend, `[T]` tests.
+
+### A. `orchestrator-open-task` should navigate the workbench `[FE]` — S/M
+`runOrchestratorCapability` ("open-task") fetches detail but does not call `setSelectedId`,
+so a voice "open task X" returns data without visually navigating. `interact()` is a
+module-level function with no handle to the live component state. Fix: have the workbench
+register a navigation callback (e.g. a module-scoped `setSelectedTaskHandler` the mounted
+`OrchestratorWorkbench` sets in a `useEffect`, called by the open-task capability), or route
+selection through the existing `?task=` deep-link that `readInitialTaskId` already reads.
+
+### B. Bridge-backed provider setup `[BE][FE]` — M (design-touching)
+Today `LlmProviderSection`/`CodingAgentSettingsSection` write `ANTHROPIC_API_KEY` etc.
+straight into agent env via `client.updateConfig({ env })` — not the vault. Now that the
+sensitive-request REST routes are mounted, wire missing-key flows to fire `SECRETS
+action=request` (or POST `/api/sensitive-requests`) so secrets land in `sharedVault`. Reuse
+the existing `ProviderCard`/`ProviderPanels`/`useProviderSelection` components rather than the
+bespoke password inputs. Needs a decision on which providers/scopes/validation; do not change
+secret-storage policy without the design owner. Secure-cloud / secure-local / insecure-local
+fallbacks + redaction tests per the report's "Secret And OAuth Flow" section.
+
+### C. Workbench UX gaps `[FE]` — small each, need visual iteration
+From the fidelity review of `OrchestratorWorkbench.tsx` (largely complete; these are the gaps):
+- **Jump-to-latest / autoscroll** in the timeline — no scroll ref/affordance today (net-new).
+- **Change-provider control** — no UI and no `orchestrator-change-provider` capability/backend; provider policy is read-only. Needs a backend capability first.
+- **Branch display** in the sub-agent roster (only repo/workdir shown).
+- **System-event collapse**: only a global show/hide toggle, not expandable clusters.
+- **Verification checklist**: only per-artifact status pills, no dedicated pass/fail surface.
+- **Per-task USD spend** in the left rail (rail shows tokens; cost only in header + inspector).
+- **Provider "state"**: shows policy/identity, not live health/availability.
+
+### D. Remote / mobile for the orchestrator `[BE][FE]` — L (separate design)
+Pairing primitives exist (`auth-pairing-routes`, `tunnel-to-mobile-client`) but **no `tunnel`
+runtime service is registered** (so `runtime.getService("tunnel")` lookups and
+`tunnel_authenticated_link` delivery are inert). The workbench is **polling-only**
+(`POLL_INTERVAL_MS = 5000`); there is no SSE/WS for task updates. Needs: a registered tunnel
+service (`getStatus/isActive/getUrl`), a relay decision (cloud gateway vs Headscale/ngrok per
+the tunnel-to-mobile design), remote-API auth, and SSE/WS to replace the 5s poll so remote/
+mobile clients aren't hammering. Do not attempt blind — design + visual iteration required.
+
+### E. Test depth `[T]`
+Add the report's e2e workflow matrix with mocked providers (create/fork/pause-all/archive/
+search/secret-flows/validation-failure-reopen), keeping live Claude/Codex tests env-gated.
+Also add an integration-level test that drives a `/credentials/*` request through the runtime
+route matcher (`matchPluginRoutePath`), not just the in-process dispatcher, so the
+registry-registration gap (fixed in this branch) can't silently reopen.
+
+### F. Deferred from adversarial review (low priority, not regressions)
+- **Bridge loopback hardening** `[BE]` — `bridge-routes.ts:isLoopback` trusts only
+  `req.socket.remoteAddress` (same model as the existing parent-context bridge). If the
+  runtime is ever fronted by a loopback-bound reverse proxy, mirror the extra checks from
+  `isTrustedLocalRequest` (reject forwarded/proxy-client headers and cross-site
+  `sec-fetch-site`). The single-use scopedToken remains the per-request defense regardless.
+- **Re-anchor follow-ups to the durable goal** `[BE]` — `buildGoalFollowUp` reads
+  `metadata.goal`, but the planner spawn paths in `tasks.ts` never stamp a `goal` key, so
+  follow-ups currently re-anchor to the latest message rather than the original objective.
+  Stash `goal: task` (or the durable goal) onto session metadata at spawn time to realize
+  the intended re-anchoring. Not a regression — the old code sent raw text.
+
+## How to work this branch
+Isolated worktree `/home/nubs/Git/iqlabs/eliza-labs/eliza-orchestrator-feat`, branch
+`nubs/orchestrator-view-feature`. Fresh worktrees need `@elizaos/core` built first
+(`cd packages/core && bun run build`) or vitest can't resolve `@elizaos/core`; building the
+full plugin set is required to run app-core integration tests. Rebase onto the active branch
+before merging (file sets don't overlap with the desktop/local-inference work in flight).

package/docs/orchestrator-dashboard-task-widget-secrets-assessment.md

@@ -0,0 +1,174 @@
+# Slice 1 critical assessment — chat task widget + OAuth secrets widget
+
+Companion to
+[`orchestrator-dashboard-task-widget-secrets-design.md`](./orchestrator-dashboard-task-widget-secrets-design.md).
+Recorded after the first implementation pass, before any UI screenshot.
+
+## What landed
+
+| Area | Files | Net change |
+|---|---|---|
+| `[TASK:id]title[/TASK]` parser | `packages/ui/src/components/chat/message-task-parser.ts` (new) + test (new) | Pure parser, strict UUID-shaped threadId, truncates titles, ignores unterminated tags. 9/9 tests green. |
+| `TaskWidget` component | `packages/ui/src/components/chat/widgets/task-widget.tsx` (new) + test (new) | One-line title + one-line status (status · agents · relative · tokens). Polls `getCodingAgentTaskThread` every 5s, stops on terminal status, silent on 404 ("Task removed."), click dispatches `eliza:navigate:view` → `/orchestrator?taskId=…`. 6/6 tests green. |
+| Wire-up in chat | `packages/ui/src/components/chat/MessageContent.tsx` (edit) + integration test (new) | New `kind: "task-widget"` segment + dispatch. Prose around the block continues to render. 4/4 integration tests green. |
+| Sensitive-request OAuth | `packages/ui/src/components/chat/MessageContent.tsx` (edit) + extended test | New `OAuthRequestPanel` rendered when `form.kind === "oauth"`. Opens authorization URL in a popup; on popup block, surfaces "Pop-up blocked" without falling back to the chat stream. Scopes are visible; the URL itself is never substituted into chat text. The secret form keeps its current behavior. |
+| Type widening | `packages/ui/src/api/client-types-chat.ts` (edit) | `SensitiveRequestForm.kind` widened to `"secret" \| "oauth"` with three optional fields: `provider`, `scopes`, `authorizationUrl`. |
+| Tests added | 4 vitest files | Parser (9), Widget (6), MessageContent integration (4), OAuth in SensitiveRequestBlock (3 new). Whole `src/components/chat` suite: 49/49 green. |
+| Lint / typecheck | — | `bun run --cwd packages/ui lint` clean. `bun run --cwd packages/ui typecheck` clean. |
+
+## Honest gaps
+
+These are not "in the design doc but I forgot" — they were called out as
+follow-ups in the doc itself. Listing here so the next pass knows the
+priority order:
+
+1. **No emission point in `TASKS_CREATE`.** The widget RENDERS, but no
+   production action yet emits `[TASK:<id>]<title>[/TASK]` after a successful
+   durable-task creation. `runCreate` in
+   [`tasks.ts`](../src/actions/tasks.ts) spawns ACP sessions, not durable
+   task threads — the link between an action callback and a durable
+   `taskId` is not in place. Without that, the widget only renders if
+   the agent text already contains the block, which is the e2e seam used
+   in tests. The natural next step is wiring `OrchestratorTaskService`'s
+   `createTask` (or a separate `TASKS_CREATE_THREAD` sub-action) so that
+   on success it returns a `taskId` and the callback text concatenates the
+   block. That is a one-line emission change + a unit test in the plugin,
+   but it touches the create flow's wiring and was scoped as a separate
+   slice.
+2. **No OAuth backend adapter yet.** The UI widget works, but no
+   `SensitiveRequest` with `target.kind === "oauth"` is produced by the
+   policy classifier today; the inline adapter rejects non-secret. A
+   sibling `owner-app-oauth-adapter.ts` (and a `target.kind: "oauth"`) is
+   the next backend step. See `orchestrator-buildout-followups.md` section B.
+3. **No Playwright spec yet for the chat path.** Component-level tests cover
+   the rendering, dispatch, and event contract; an end-to-end "send chat
+   → assistant emits block → widget appears → click → workbench task
+   detail visible" would need MSW-style routes for the chat backend plus a
+   way to inject the assistant turn. The existing
+   `orchestrator-gui-workbench.spec.ts` already covers the create-flow and
+   the rail → inspector path. The chat-side spec is in slice 4 of the
+   design doc; it didn't land in this pass.
+4. **`OrchestratorGlanceStrip` was descoped.** On second read of
+   [`WorkbenchHeader`](../../../plugins/plugin-task-coordinator/src/OrchestratorWorkbench.tsx#L597),
+   the header already reads "12 tasks · 1 active · 3 done" with the same
+   minimal language the design called for, and adds a usage chip on the
+   right. A separate strip would have been redundant and added a second
+   row that competes with the same information. The right follow-up if a
+   user calls this out specifically is making the inline counts
+   click-to-filter, NOT introducing a new pinned tile.
+5. **Inspector terminal-task cleanup (slice 5) was descoped.** It's a
+   handful of `if (TERMINAL_STATUSES.has(status)) return null;` guards in
+   `TaskInspector`; not landed because the inspector is 4142 LOC and I
+   prioritized the user-visible chat gap. Worth a follow-up.
+
+## Security audit of what landed
+
+- **Secret form (`SensitiveRequestBlock`)** — submission still goes
+  through `client.updateSecrets`, never through the chat message stream.
+  Existing test asserts the raw secret never appears anywhere in the
+  rendered DOM. Added a `data-testid="sensitive-request-submit"` so
+  Playwright can target the submit cleanly; behavior unchanged.
+- **OAuth widget (`OAuthRequestPanel`)** — three guards:
+  1. The authorization URL is only consumed inside `window.open()`. It is
+     never substituted into the visible chat text. The new test asserts
+     the URL substring is not present anywhere in `container.textContent`.
+  2. Popup is opened with `noopener,noreferrer` so the consent page can't
+     `window.opener.*` back to chat.
+  3. A blocked popup surfaces "Pop-up blocked. Allow pop-ups for this
+     site to continue." rather than silently falling back to a chat
+     message that would re-render the URL.
+- **TaskWidget** — only reads structured status fields (`status`,
+  `sessionCount`, `activeSessionCount`, `latestActivityAt`,
+  `usage.totalTokens`). It does not render `metadata` or `messages`. A
+  regression test asserts secret-shaped strings smuggled through `metadata`
+  do not appear in the rendered DOM.
+
+## Test coverage table
+
+| File | Suite | Count | Status |
+|---|---|---|---|
+| `message-task-parser.test.ts` | parser unit | 9 | green |
+| `widgets/task-widget.test.tsx` | component unit | 6 | green |
+| `MessageContent.task-widget.test.tsx` | integration | 4 | green |
+| `MessageContent.sensitive-request.test.tsx` | sensitive widget (extended) | 7 | green |
+| Whole `src/components/chat` suite | — | 49 | green |
+
+`bun run --cwd packages/ui lint` clean. `bun run --cwd packages/ui typecheck` clean.
+`bun run --cwd packages/app-core typecheck` shows two pre-existing
+`@elizaos/plugin-commands` resolution errors unrelated to this change.
+
+## What a screenshot pass would look for (next session)
+
+Not run in this session because there is no live UI to capture. The
+checklist for that pass:
+
+- **Chat surface, message with a task block** —
+  - Title line truncates without ellipsis-jitter at 320px width.
+  - Status line wraps gracefully; the dot/label/agents/tokens chips
+    never wrap mid-chip.
+  - Pulse animation is visible on `active` and `validating`, absent
+    on terminal states.
+  - Click → orchestrator workbench shows the matching task selected.
+- **Chat surface, OAuth request** —
+  - "Connect <provider>" button reads exactly like the surrounding chat
+    accent (no accidental blue).
+  - Scopes line truncates at small widths.
+  - Pop-up blocked state surfaces inline, not modal.
+- **Chat surface, secret request** — unchanged, but confirm the new
+  `data-testid` didn't shift any spacing.
+- **Orchestrator workbench, `?taskId=…` arrival** — task is selected,
+  inspector visible without scrolling.
+
+## Post-review fixes (second pass)
+
+After fanning out independent code-review + aesthetic + verification agents, four
+findings were addressed in this same change-set:
+
+1. **`window.open(..., "noopener,noreferrer")` bug** — per the HTML spec
+   `noopener` forces `window.open` to return `null`, so the popup-blocked
+   detection misfired in every real browser. Removed `noopener` from the
+   features string, kept `noreferrer`, and added an explicit
+   `popup.opener = null` immediately after open as a belt-and-suspenders
+   measure. Test asserts `noreferrer` is present and `noopener` is not, and
+   that `opener` is nulled.
+2. **`TaskWidget` infinite poll on auth error** — added a
+   `MAX_CONSECUTIVE_ERRORS = 3` cap on the silent-error counter; after three
+   consecutive 401/403/etc the widget freezes on the last good state and
+   stops polling. Counter resets on the next successful fetch.
+3. **Slop pass — `ExternalLink` decorative icon removed** from `TaskWidget`.
+   The whole card is already a `<button>` with `hover:bg-bg-hover`; the icon
+   added zero info at a glance.
+4. **Slop pass — "The value will not be sent as a chat message." removed**
+   from the secret-form widget. A `type="password"` input is its own
+   signal; the trust copy stays on the OAuth panel where the user is
+   genuinely navigating to a third-party origin.
+5. **OAuth panel testid** — added `data-testid="sensitive-request-oauth"`
+   to the panel wrapper for parity with `sensitive-request`.
+
+Reopen-on-terminal was reconsidered and intentionally left as-is: done/failed
+tasks have an Archive button that transitions them to `archived`, which
+exposes Reopen. The path exists — it just isn't a single-click escape from
+done → reopened. Acceptable.
+
+The legacy `SensitiveRequestOauthTarget` (lowercase `a`) coexists with the
+new `SensitiveRequestOAuthTarget` (capital `A`) in the
+`SensitiveRequestTarget` union. The new OAuth adapter defends with an
+`isOAuthTarget` runtime narrower, so downstream consumers that already
+relied on the loose shape are unaffected. Consolidating these two into a
+single tight type is a follow-up (it widens the blast radius beyond this
+change-set).
+
+## What to revisit if a user looks at this and says "still too busy"
+
+- The header's `12 tasks · 1 active · 3 done` line already aims at
+  minimal/dense. If that still reads as cluttered, the next reduction
+  is dropping `tasks` (just show counts and labels) and making the
+  divider thinner.
+- The widget's status line is four chips by default. If three of the
+  four are zero (e.g. fresh task, no agents, no tokens), only `status`
+  + `relative` render — that's already the case via the existing
+  conditional renders.
+- The OAuth panel intentionally explains *why* it's safe ("token is
+  stored securely and never shown in chat"). That sentence is the only
+  prose in the panel and it's important for trust; it should not be
+  cut.