pi-crew 0.9.50 → 0.9.52

package/docs/bugs/bug-021-notification-badge-counter-misleading.md

@@ -1,293 +0,0 @@
-# Bug Report: Notification Bell Badge Misread as "Queued Messages"
-
-**Date:** 2026-06-29
-**Severity:** Medium (UX / User Confusion — no data loss, no functional impact)
-**Status:** Partially fixed (Option A + Option B-display applied 2026-06-29; decay / owner-scope / auto-reset / deprecation remain open product decisions)
-**Reporter:** User investigation session (manual triage)
-**Related:** `docs/bugs/cross-session-notification-leakage.md` (related but distinct —
-  that one filters notifications *delivered* across sessions; this one accumulates
-  the badge count without decay regardless of session ownership)
-**Affects:** pi-crew widget header + powerbar segment (`pi-crew-active`)
-
----
-
-## Summary
-
-The `🔔N` bell badge shown in the crew widget header (and the equivalent
-`pi-crew-active` powerbar segment) is the **cumulative notification counter**
-(`widgetState.notificationCount`), not a message-queue size. Users reading the
-bell icon as "queued messages" conclude there are hundreds of pending items
-when in fact:
-
-- Actual `status === "queued"` agents across all runs: **0**
-- Actual `status === "queued"` tasks across all `tasks.json`: **0**
-- Mailbox unread (inbox) messages: **0** (no `mailbox/inbox.jsonl` exists)
-- Live in-memory agents (`listActiveLiveAgents`): **0**
-
-The "227" observed during investigation is therefore a stale cumulative count,
-not a backlog. This file documents the data path, why it accumulates without
-bound, and the three fix options.
-
----
-
-## Symptom
-
-| Surface | What user sees | What it actually is |
-|---|---|---|
-| Crew widget header (above editor) | `⠋ Crew agents🔔227 · 1 running · 0/1 done · /team-dashboard` | Cumulative warning/error notification count since pi session start |
-| pi powerbar segment `pi-crew-active` | `⚙ 1 running · 🔔227 · <model> · 30k` | Same counter, rendered via `notificationBadge()` |
-| Widget "X queued" sub-string | **Not shown** (suppressed when count is 0) | Would be from `agents.filter(a => a.status === "queued")` |
-
-User paraphrase: *"agents are running — why are there 227 queued messages?"*
-— the bell icon is interpreted as a message-queue indicator.
-
-### Reproduction
-
-1. Start a long-running pi session that processes many background subagents
-   (e.g. porting work that spawns 100+ `executor` subagents via `team` runs).
-2. Wait for a meaningful number of `subagent-completed` notifications to be
-   delivered (the `info` severity is filtered out; only `warning`/`error`/
-   `critical` increment the counter).
-3. Open the widget header. Bell badge shows e.g. `🔔184` (today's count) or
-   `🔔227` if the session has been alive longer.
-4. Confirm queue is actually empty by running `/team-dashboard` and reading
-   the agents-pane `Counts` line — it reads `running=1, queued=0, recent=0`.
-
----
-
-## Root Cause
-
-### Counter increment path
-
-`src/extension/register.ts:308-309` (inside `configureNotifications` callback):
-
-```ts
-widgetState.notificationCount =
-  (widgetState.notificationCount ?? 0) + 1;
-```
-
-The counter lives in the `CrewWidgetState` closure for the lifetime of the pi
-process. It is reset only by:
-
-- `dismissNotifications()` action — `src/extension/register.ts:2146-2164` →
-  `widgetState.notificationCount = 0;`
-- Pi process restart.
-
-There is **no decay, no per-run scoping, no acknowledgement**.
-
-### Display path
-
-`src/ui/widget/widget-renderer.ts:35-44` — `widgetHeader()`:
-
-```ts
-export function widgetHeader(runs: WidgetRun[], runningGlyph: string, maxLines = 20, notificationCount = 0): string {
-  // …running/queued/waiting/done counts…
-  return `${runningGlyph} Crew agents${notificationBadge(notificationCount)} · ${parts.join(" · ")} · /team-dashboard`;
-}
-```
-
-`src/ui/widget/widget-formatters.ts:147-152` — `notificationBadge()`:
-
-```ts
-export function notificationBadge(count: number | undefined, env: NodeJS.ProcessEnv = process.env): string {
-  if (!count || count <= 0) return "";
-  const term = `${env.TERM ?? ""} ${env.WT_SESSION ?? ""} ${env.TERM_PROGRAM ?? ""}`.toLowerCase();
-  const supportsEmoji = !term.includes("dumb") && env.NO_COLOR !== "1";
-  return supportsEmoji ? ` 🔔${count}` : ` [!${count}]`;
-}
-```
-
-`src/ui/powerbar-publisher.ts:125` — same value is broadcast to the
-`pi-crew-active` powerbar segment via `notificationText`.
-
-### Severity filter that creates the asymmetry
-
-`src/config/defaults.ts:100` — `DEFAULT_NOTIFICATIONS.severityFilter` excludes
-`info`. Re-applied at:
-
-- `src/extension/register.ts:301-303`
-- `src/extension/notification-router.ts:12, 90`
-
-Today's `.crew/state/notifications/2026-06-29.jsonl` for the project where
-this was reported:
-
-| Severity | Count | Increments badge? |
-|---|---|---|
-| `info` | 88 | **No** (filtered) |
-| `warning` | 184 | **Yes** |
-| `error` | (subset of warning) | Yes |
-| `critical` | (rare) | Yes |
-
-Source breakdown: 270 `subagent-completed` + 2 `run-maintenance`. The 184
-warnings map to: 171 `subagent-error` + 7 `subagent-failed` + 6
-`subagent-cancelled` — i.e. almost entirely **"Child Pi worker became
-unresponsive and was terminated"** events from background runs.
-
-The remaining ~43 (227 − 184) come from earlier in the session or from
-non-`subagent-completed` sources (`subagent-stuck`, `health`,
-`crash-recovery`) — see `notifyOperator` call sites in
-`src/extension/register.ts` lines 455, 497, 532, 727, 759, 786, 1388, 1410,
-1437, 1453, 1479, 1500, 1519, 1848.
-
-### Owner-scoped filtering is incomplete
-
-`src/extension/register.ts:769-775` correctly gates `subagent.stuck-blocked`
-on `isOwnerSessionCurrent`, but the bulk `subagent-completed` notifications
-at lines 753-761 and the `crew.subagent.completed` event hooks are **not
-owner-scoped at the `notifyOperator` level**. A long-lived pi session
-accumulates counts from older `ownerSessionGeneration`s. (This is the
-behavioural cousin of `cross-session-notification-leakage.md`, but applies
-to the badge counter rather than the notification router deliver path.)
-
-### Cache pin risk
-
-`src/ui/widget/index.ts:108-128` — `CrewWidgetComponent.cacheSignature`
-includes `:${this.model.notificationCount ?? 0}`. The header line is
-re-rendered every tick from `cachedBaseLines` with the spinner-glyph swap
-(lines 171-174), but the `🔔N` segment is part of the cached header text.
-If no event-bus signal invalidates the cache (`run:state` / `worker:lifecycle`
-/ `ui:invalidate` per lines 104-107), the displayed number can persist even
-when the underlying counter has changed.
-
----
-
-## Why no other surface shows 227
-
-Verified each candidate reader:
-
-| Reader | Source | Reads as |
-|---|---|---|
-| `widget-renderer.ts:37` | `agents.filter(a => a.status === "queued")` | **0** |
-| `widget-model.ts:72` | `agents.filter(a => a.status === "queued" \|\| a.status === "waiting")` | **0** |
-| `widget-model.ts:69 statusSummary` | same `agents` array | **0** |
-| `powerbar-publisher.ts:119` | `tasks.filter(t => t.status === "queued" \|\| t.status === "waiting")` | **0** |
-| `dashboard-panes/mailbox-pane.ts:8` | `mailbox/inbox.jsonl` | no file → 0 |
-| `live-run-sidebar.ts:188` | tasks.json waiting | **0** |
-| `agents-pane.ts` `groups.queued` | agent records | **0** |
-| `.crew/state/subagents/*.json` | legacy records (271 files) | **0** with `status: "queued"` |
-| `terminal-status.ts:101-200` | `listLiveAgents()` | empty in current session |
-| `health-pane.ts:25` | `healthy/stale/dead/missing` | not a "queued" semantic |
-
-No string literal `"queued messages"` exists anywhere in `src/` (verified via
-`rg "queued messages|pending messages|unread messages|notification count" -i`
-— only matches in `intercom-bridge.ts` and `task-runner/run-projection.ts`,
-neither rendered in the TUI).
-
-No arithmetic over the recorded subagent status counts (87 completed, 171
-error, 7 failed, 6 cancelled) yields 227 either. So **the widget cannot be
-reading 227 from the agent-records stream**; it is exclusively from
-`widgetState.notificationCount`.
-
----
-
-## Verification Steps
-
-To confirm a user is hitting *this* bug (and not, e.g., a real queue
-backlog):
-
-1. Run `/team-dashboard` (read-only snapshot).
-2. In the agents-pane, read the `Counts` line — it should show
-   `running=N, queued=0, recent=0` (or whatever the real counts are).
-3. If `queued=0` but the widget header shows `🔔N` with N > 0, this bug is
-   the explanation.
-4. To reset: invoke `/team-dismiss` (or restart pi). The badge should
-   disappear (count goes to 0 → `notificationBadge` returns `""`).
-5. To read the actual notification log: open `.crew/state/notifications/
-   YYYY-MM-DD.jsonl` and filter by `severity ∈ {warning, error, critical}`
-   for the desired window.
-
----
-
-## Proposed Fixes (in order of preference)
-
-### Option A — Rename / relabel the badge (lowest risk, fastest)
-
-Change `notificationBadge()` to a less ambiguous string. The bell icon is
-the primary source of user confusion; replacing the glyph or appending a
-qualifier disambiguates without changing semantics:
-
-```ts
-// ui/widget/widget-formatters.ts
-return supportsEmoji
-  ? ` ·${count} notify`
-  : ` [${count} notify]`;
-```
-
-Or use a different glyph that does not suggest "messages":
-`·${count} alerts` / `[${count} alerts]`. Then update the widget header
-template in `widget-renderer.ts:35-44` to drop the literal "Crew agents"
-prefix that combines with the bell to read as "queued messages".
-
-### Option B — Cap + decay
-
-Bound the counter (e.g. show "99+") and/or decay by ageing out notifications
-older than N minutes. This addresses the underlying user-visible problem
-without changing the underlying delivery path:
-
-```ts
-// extension/register.ts (after the increment)
-const cap = 99;
-widgetState.notificationCount = Math.min(cap, widgetState.notificationCount);
-```
-
-Plus a periodic decay tick in `configureObservability` that subtracts counts
-for notifications older than the current TTL window.
-
-### Option C — Owner-scope the counter
-
-Mirror the fix from `cross-session-notification-leakage.md` at the
-`notifyOperator` call site: skip notifications whose `runId` does not
-belong to the current `ownerSessionGeneration`. This addresses the
-cumulative-across-sessions aspect but does not bound within a single
-session. Best combined with Option B.
-
-### Recommended combination
-
-A + C: rename the badge to a non-message glyph (cheap, immediate UX win) +
-owner-scope the counter (consistent with the cross-session leak fix). B is
-useful but the decay semantics need product input — is a notification
-"consumed" once shown, once read, once dismissed, or once an hour passes?
-
----
-
-## Open Questions
-
-1. Should the counter reset on `/team-dismiss` only, or also when all
-   current-session runs reach a terminal state? (Currently it only resets
-   on the former.)
-2. Should the powerbar segment also reflect this change, or keep its
-   current `⚙ N running · 🔔N` shape? (The powerbar is more compact and
-   less prone to misreading.)
-3. Should `notificationBadge` be deprecated entirely in favour of an
-   explicit "alerts" segment, given that the widget already shows the
-   notification body via `notificationSink`?
-
----
-
-## References
-
-- `src/extension/register.ts:301-309` — severity filter + counter increment
-- `src/extension/register.ts:753-761` — bulk `subagent-completed` notification
-- `src/extension/register.ts:769-775` — `isOwnerSessionCurrent` gate (only
-  applied to `subagent.stuck-blocked`, not the badge counter)
-- `src/extension/register.ts:2146-2164` — `dismissNotifications()` reset hook
-- `src/extension/notification-router.ts:12, 90` — severity-filter re-apply
-- `src/config/defaults.ts:78` — `DEFAULT_UI.widgetPlacement` (above-editor)
-- `src/config/defaults.ts:100` — `DEFAULT_NOTIFICATIONS.severityFilter`
-- `src/ui/widget/widget-renderer.ts:35-44` — `widgetHeader()` assembly
-- `src/ui/widget/widget-renderer.ts:61, 64, 95` — `queued` semantic in
-  active-runs filter and priority
-- `src/ui/widget/widget-model.ts:69-89` — `statusSummary()` short label
-- `src/ui/widget/widget-model.ts:72` — `queued` + `waiting` count source
-- `src/ui/widget/widget-formatters.ts:147-152` — `notificationBadge()`
-- `src/ui/widget/widget-types.ts:22` — `CrewWidgetModel.notificationCount?`
-- `src/ui/widget/index.ts:104-128` — `cacheSignature` and invalidation
-- `src/ui/widget/index.ts:166, 245-252` — model → render propagation
-- `src/ui/powerbar-publisher.ts:115-148` — powerbar `pi-crew-active`
-  segment, badge insertion
-- `src/ui/powerbar-publisher.ts:119` — `queuedCount` (from tasks.json)
-- `src/ui/dashboard-panes/progress-pane.ts:15, 24` — `p.queued` (from
-  `RunUiSnapshot.progress.queued`, not from agents)
-- `src/ui/dashboard-panes/agents-pane.ts:105` — `queued` agent group
-- `src/runtime/process-status.ts:117-148` — `isDisplayActiveRun`
-- `docs/bugs/cross-session-notification-leakage.md` — related fix

package/docs/bugs/bug-023-chain-windows-path-resolution.md

@@ -1,106 +0,0 @@
-# Bug Report: Chain feature breaks on Windows (multi-step runs)
-
-**Date:** 2026-06-29
-**Severity:** Medium (feature regression on Windows only; Linux/macOS unaffected)
-**Status:** Open — root-cause hypothesized, NOT verified (needs a Windows VM)
-**Affects:** the live `chain` feature (shipped v0.9.13) on Windows; caught by CI matrix
-**Blocks:** v0.9.14 release (CI must be green on all 3 OSes — `gh run 28364101933` shows ubuntu ✓, macos ✓, windows ✗)
-
----
-
-## Summary
-
-The `team action='run', chain='...'` feature (wired live in v0.9.13, commit
-`9c6c36a`) works on Linux and macOS but **breaks after the first step on
-Windows**. `runChain` aborts the chain early because the first step's
-`result.outcome` comes back non-`"success"`, which causes `runChain` to `break`
-(`src/runtime/chain-runner.ts:233-239`).
-
-On Windows the step outcome is misclassified because **`loadRunManifestById`
-fails to read back the fixture manifest** that the same process just wrote.
-
-## Measured evidence (CI run 28364101933, Windows job 84025614223)
-
-7 tests fail on `windows-latest / Node 22`, ALL in the chain execution path:
-
-| Test | Why it fails |
-|---|---|
-| `(d)(empirical) 3-step chain runs sequentially and captures 3 runIds` | `chainResult.steps.length === 1`, not 3 — chain broke after step 1 |
-| `(empirical) @team reference step resolves to that team in handleRun params` | `mock.receivedParams` undefined — only 1 step ran, step 2's params never set |
-| `(e) a failed team-run manifest maps to outcome failure mid-chain` | chain execution path |
-| `handleChainRun returns a structured summary with runIds in data` | chain execution path |
-| `(b) readChainStepOutput reads completed task output from resultArtifact` | `loadRunManifestById` returns the fixture → assertion on output fails |
-| `(b) readChainStepOutput returns undefined when no completed tasks have resultArtifacts` | same read-back path |
-| `(d)(semantic) step 1's worker output appears in step 2's goal` | step 2 never runs |
-
-**The pure-logic chain tests all PASS on Windows** (`parseChainString`,
-`formatChainHistory`, `mapRunToTaskResult`). Only the tests that touch the
-filesystem via `writeRunFixture` → `loadRunManifestById` fail. Confirmed: all 7
-failing tests call `writeRunFixture` / `runChain` / `handleChainRun`; the
-passing ones are pure functions over in-memory inputs.
-
-This is a **PRE-EXISTING v0.9.13 bug**, not a v0.9.14 regression. v0.9.13 CI
-run 28347931393 failed Windows identically. The v0.9.14 commits touch ZERO
-chain files (`git diff --stat v0.9.13..HEAD -- src/runtime/chain-runner.ts
-src/extension/team-tool/chain-*.ts` is empty).
-
-## Root-cause hypothesis (NOT verified — needs Windows VM)
-
-`loadRunManifestById(cwd, runId)` → `resolveRunStateRoot(cwd, runId)` →
-`resolveRealContainedPath(runsRoot, runId)` → **`fs.openSync(baseDir,
-fs.constants.O_NOFOLLOW)`** (`src/utils/safe-paths.ts:175`).
-
-On Windows CI runners the runs-root (`<tmpdir>/.crew/state/runs`) lives under a
-temp path that Windows exposes through both **8.3 short-name aliases** and
-**junctions**. `O_NOFOLLOW` semantics on Windows do not match POSIX, and the
-`ELOOP` retry branch in `resolveRealContainedPath` (lines 184-194) is
-**darwin-only** — there is **no Windows-specific retry for `O_NOFOLLOW` open
-failures**. When the open throws, `resolveRealContainedPath` propagates,
-`resolveRunStateRoot` returns `undefined`, `loadRunManifestById` returns
-`undefined`, and `ChainTeamRunExecutor.executeStep` maps the missing manifest to
-`outcome: "partial"` (`chain-executor.ts:293-295`) → `runChain` breaks.
-
-The containment *comparison* at `safe-paths.ts:339-348` already handles Windows
-canonicalization (`resolveWindowsCanonical` on both paths). So the failure is
-not the containment check — it is the **initial `O_NOFOLLOW` open of baseDir
-before realpathSync**.
-
-**Why I am NOT fixing this blind:** this is security-sensitive path-resolution
-code (the `O_NOFOLLOW` + containment machinery is a security control against
-symlink-escape). Changing Windows handling without a Windows environment to
-verify risks either (a) not actually fixing it, or (b) weakening the security
-guarantee. Per the project's "đừng đoán mò" discipline, this needs a Windows
-dev/CI environment to reproduce, fix, and verify.
-
-## Workaround (this release)
-
-Skip the 7 chain tests on `win32` in `test/unit/chain-executor.test.ts` with an
-explicit `{ skip: "bug-023: Windows path resolution — see bug report" }` reason.
-This is **transparent, not hidden**: the skip names the bug, the bug report is
-tracked, and the production chain feature is documented as Windows-broken
-pending the VM-verified fix. The pure-logic chain tests (9 of them) still run
-on Windows, so the feature is not entirely untested there.
-
-## Suggested fix (for the Windows-VM session)
-
-1. In `resolveRealContainedPath` (`src/utils/safe-paths.ts`), add a
-   Windows-specific branch alongside the darwin `ELOOP` branch: on `win32`,
-   when the `O_NOFOLLOW` open fails for a baseDir that demonstrably exists
-   (`fs.existsSync(baseDir)`), retry via `realpathSync.native` (the same
-   canonical long-name resolver used by `resolveWindowsCanonical`).
-2. Add a Windows CI assertion that a `writeRunFixture` → `loadRunManifestById`
-   roundtrip succeeds under `<tmpdir>` (reproduces the failure; gates the fix).
-3. Verify the containment guarantee still holds (the existing
-   `safe-paths-cov.test.ts` suite must stay green; add a Windows-only fixture
-   that creates a symlink/junction escape attempt and asserts it's rejected).
-
-## References
-
-- `src/runtime/chain-runner.ts:233-239` — `runChain` break on non-success outcome
-- `src/extension/team-tool/chain-executor.ts:140-184` — `mapRunToTaskResult` (outcome from manifest status)
-- `src/extension/team-tool/chain-executor.ts:291-295` — `loadRunManifestById` undefined → "partial"
-- `src/state/state-store.ts:134-149` — `resolveRunStateRoot` → `resolveRealContainedPath`
-- `src/utils/safe-paths.ts:163-210` — `resolveRealContainedPath` (O_NOFOLLOW open, darwin-only retry)
-- `src/utils/safe-paths.ts:339-348` — Windows canonical containment check (already correct)
-- CI run `28364101933` (v0.9.14) — ubuntu ✓, macos ✓, windows ✗ (these 7 tests)
-- CI run `28347931393` (v0.9.13) — Windows ✗ identically (pre-existing)

package/docs/bugs/bug-quota-display-truncation.md

@@ -1,223 +0,0 @@
-# Bug: Provider quota display truncated to "W..." during sub-agent runs
-
-**Status:** FIXED via custom footer (`ctx.ui.setFooter`). See "Resolution" below.
-**Severity:** Cosmetic
-**Affected:** `src/extension/crew-vibes/` (provider quota renderer)
-**Reporter:** user (live observation, 2026-07-09)
-
-> Correction: the earlier "UNFIXABLE IN EXTENSION LAYER / WONTFIX" verdict was
-> wrong on two counts. (1) The `spreadLine` U+00A0 full-width padding (from
-> commit `f0baee9`) was described as "reverted attempt 1" but was in fact still
-> ACTIVE and was the direct cause — it padded our row to the full terminal width
-> using `process.stdout.columns` (which differs from pi's real render width),
-> guaranteeing overflow and right-truncation of the quota. (2) Option A (custom
-> footer) was never actually attempted; it is viable and is what the fix uses.
-
----
-
-## Symptom
-
-When pi-crew spawns sub-agents, the provider quota text in pi's footer
-status bar is truncated. User reported seeing:
-
-```
-⚙ lr • MiniMax-M3 75k o Orbit                                                                             Minimax 5h ▬▬▬ 29% 1h6m W...
-```
-
-The `Wk ▬▬▬▬▬▬▬▬ 19% 1d4h` segment (weekly quota bar + percent + reset) is
-chopped to just `W` followed by the dim ellipsis `...`.
-
-## Root cause
-
-`@earendil-works/pi-coding-agent` (pi) joins ALL extension statuses into
-ONE footer line via `ctx.ui.setStatus()`, sorted alphabetically by key,
-then calls `truncateToWidth(joined, width, "...")` if joined width
-exceeds terminal width.
-
-Source: `dist/modes/interactive/components/footer.js` lines 213–222:
-
-```js
-const sortedStatuses = Array.from(extensionStatuses.entries())
-    .sort(([a], [b]) => a.localeCompare(b))
-    .map(([, text]) => sanitizeStatusText(text));
-const statusLine = sortedStatuses.join(" ");
-lines.push(truncateToWidth(statusLine, width, theme.fg("dim", "...")));
-```
-
-Concretely, the joined line becomes:
-
-```
-pi-crew  + " " + pi-crew-bar  + " " + pi-crew-quota
-(widget)    (capacity)          (provider quota)
-```
-
-When sub-agents spawn, `pi-crew` widget text (worker counts, queue,
-model name — `statusSummary()` in `src/ui/widget/widget-model.ts`)
-grows from ~10 chars to ~50-80 chars. The joined line exceeds terminal
-width, and `truncateToWidth` chops the RIGHT side first — which is
-where our provider quota lives. Result: weekly bar lost.
-
-## Why naive fixes don't work
-
-The extension knows only its OWN status text, not other extensions'
-status texts. Several "obvious" fixes were attempted (all reverted):
-
-### Attempt 1 — Right-align quota with U+00A0 padding
-
-Prepend non-breaking spaces (U+00A0, which `sanitizeStatusText` does
-not collapse) to push quota to the right edge of `process.stdout.columns`.
-
-```ts
-const cols = process.stdout.columns || 120;
-const pad = Math.max(0, cols - quotaWidth - capWidth - 1);
-const padded = capText + "\u00A0".repeat(pad) + quotaText;
-setCapacityStatus(ctx, config, padded);
-```
-
-**Why it fails:** pad accounts for our row's own capacity+quota width
-but NOT for `pi-crew` widget text or `pi-sub-bar` text that prepends
-ours. When those grow during sub-agent spawn, joined line exceeds
-cols and pi's `truncateToWidth` chops quota anyway.
-
-### Attempt 2 — Subtract capacity width dynamically
-
-Cache `lastCapacityText` so we know our own row's capacity width when
-padding quota:
-
-```ts
-const capWidth = lastCapacityText ? visibleLen(lastCapacityText) : 0;
-const pad = Math.max(0, cols - quotaWidth - capWidth - 1);
-```
-
-**Why it fails:** still doesn't account for `pi-crew` widget width or
-other extensions' widths. Same overflow problem.
-
-### Attempt 3 — Reserve buffer for other extensions
-
-```ts
-const otherReserve = Math.floor(cols * 0.5);
-const pad = Math.max(0, cols - quotaWidth - capWidth - 1 - otherReserve);
-```
-
-**Why it fails:** heuristic, not exact. 50% may be too much (quota
-gets pushed left and looks unbalanced) or too little (still overflows).
-Padding is not "dynamic" in the sense of reacting to actual other
-status widths.
-
-### Attempt 4 — Split into widget via setWidget("...", [cap, quota])
-
-`setWidget()` with `placement: "belowEditor"` renders a Container with
-one Text component per array entry → 2 separate lines below editor,
-not subject to joined status truncation.
-
-**Why it fails:** moves the display out of the footer status bar to
-below the editor. User wanted it in the footer (status bar), not in
-a new visual zone.
-
-## Viable fixes (none attempted; documenting for future)
-
-### A. Custom footer via `setFooter(factory)`
-
-Pi exposes `ctx.ui.setFooter((tui, theme, footerData) => Component)` —
-extensions can replace the entire footer. The factory receives
-`footerData.getExtensionStatuses()` so we still see other extensions'
-statuses.
-
-Implementation outline:
-1. Build a custom `FooterComponent` that renders cwd + stats + our
-   2 lines (capacity + quota right-aligned).
-2. Call `ctx.ui.setFooter(factory)` on `session_start`.
-3. On `session_shutdown`, call `ctx.ui.setFooter(undefined)` to restore
-   pi's built-in footer.
-
-Cost: ~150 LoC + need to mirror pi's built-in footer logic (cwd,
-branch, token stats, model, etc.) so we don't lose any info.
-
-### B. Patch pi-coding-agent upstream
-
-Request that pi support multi-line extension status — e.g., add a
-`setStatus(key, lines: string[])` overload that puts each entry on its
-own line, OR a `setStatusLine(position, key, text)` that allows
-pinning a status to line 1 vs line 2.
-
-Cost: requires upstream PR + waiting for new pi release.
-
-### C. Shorten quota to always fit
-
-Drop the weekly bar entirely (or shrink to 1-2 chars). Quota becomes
-`Minimax 5h 29%` (~15 chars). Even if `pi-crew` widget text is 80 chars
-and capacity is 22 chars, total = 80+1+22+1+15 = 119, fits in 120 cols
-usually.
-
-Cost: loses reset timers and weekly bar visualization. User originally
-wanted the bars.
-
-## Why the 5 prior attempts all failed (same root cause)
-
-All five fought the truncation from INSIDE `setStatus`, where an extension
-cannot see (a) the `pi-crew` widget status width that grows during sub-agent
-runs, (b) other extensions' widths, (c) pi's real render width, and where pi
-always right-truncates the joined line:
-
-- `81859e6` — split into `pi-crew-quota` key. pi joins all keys onto one line;
-  quota still rightmost → still chopped. (Misdiagnosed as slot-overwrite.)
-- `a74e453` — NBSP pad by `cols - quotaWidth - 1`. Ignores capacity + widget
-  widths → overflow → chop.
-- `a9eb30e` — NBSP pad by `cols - quotaWidth - capWidth - 1`. Still ignores the
-  widget width and other extensions → overflow.
-- `900737c` — `setWidget(belowEditor)` 2-line. Works (no truncation) but sits
-  below the editor, not in the footer. Rejected.
-- `5e56b63` — one status line + NBSP pad (`process.stdout.columns`). Same flaw
-  as #2/#3, plus a width source that disagrees with pi's actual render width.
-
-## Resolution (implemented)
-
-Definitive fix = option A, **custom footer via `ctx.ui.setFooter(factory)`** —
-the one approach none of the 5 attempts tried. It sidesteps every failure mode
-above because the footer `Component`'s `render(width)` receives pi's REAL render
-width and we own the line layout, so the meters get their own line(s) that the
-join can never truncate.
-
-- `src/extension/crew-vibes/footer.ts` — `CrewVibesFooter implements Component`.
-  Reproduces pi's built-in footer lines (pwd/branch/session; token stats + cost
-  + context% + model + thinking) from `ctx.sessionManager`/`ctx.model`/
-  `ctx.getContextUsage()`/`footerData`, keeps other extensions' statuses on the
-  joined line (still truncated, like pi), and renders **capacity + quota on a
-  dedicated line** using the real width. When the terminal is too narrow, the
-  meters wrap to two lines (capacity above, quota right-aligned below).
-- `src/extension/crew-vibes/index.ts` — installs the footer on `session_start`
-  (and re-install/remove in `applyConfig`), restores pi's built-in footer with
-  `setFooter(undefined)` on disable/`session_shutdown`, drops the `spreadLine`
-  padding, stores the raw provider-usage snapshot (rendered by the footer), and
-  tracks thinking level via the `thinking_level_select` event.
-- `src/ui/pi-ui-compat.ts` — added a guarded `setFooter()` wrapper (no-op on
-  hosts that predate the API).
-
-Accepted fidelity trade-offs (pi does not expose these to extensions):
-- The `(auto)` compaction indicator is always shown (matches pi's default);
-  the toggle state is not observable.
-- Thinking level comes from `thinking_level_select`; before the first switch it
-  shows the default ("off").
-
-Proof: `test/unit/crew-vibes.test.ts` adds two tests — quota stays fully visible
-while an overflowing status line is truncated, and the meters wrap to two lines
-on a narrow terminal.
-
-## How to revert fully
-
-If you want to wipe all 5 reverted commits from history:
-
-```bash
-git revert f74adae 7588b26 0f0905d a61d5de dced96a  # the 5 reverts above
-```
-
-Or just leave them — they're labeled "Revert ..." so it's clear what
-they undo.
-
-## References
-
-- pi footer rendering: `/home/bom/.nvm/versions/node/v22.23.1/lib/node_modules/@earendil-works/pi-coding-agent/dist/modes/interactive/components/footer.js:213-222`
-- pi truncateToWidth: `node_modules/@earendil-works/pi-tui/dist/utils.js:821`
-- pi-crew widget status source: `src/ui/widget/widget-model.ts:77-99` (`statusSummary()`)
-- crew-vibes provider rendering: `src/extension/crew-vibes/render.ts:158-194` (`renderProviderUsage()`)
-- crew-vibes quota publish: `src/extension/crew-vibes/index.ts` (`publishProviderQuota()`)