instar 1.3.631 → 1.3.632

package/dashboard/subscriptions.js

@@ -457,13 +457,18 @@ export function renderAccountMatrix(doc, target, poolScope, pendingScope, transi
     tr.appendChild(el(doc, 'th', 'sub-matrix-acct', sanitizeForDisplay(row.account.email, 'label')));
     for (const c of row.cells) {
       const td = el(doc, 'td', `sub-matrix-cell sub-matrix-${c.state}`);
-      if (c.state === 'empty' || c.state === 'held' || c.state === 'cant-resolve') {
-        // An actionable cell → a "Set up" button (held/cant-resolve let the operator retry).
-        const btn = el(doc, 'button', 'sub-matrix-setup', c.state === 'empty' ? 'Set up' : 'Retry');
+      if (c.state === 'empty' || c.state === 'needs-reauth' || c.state === 'held' || c.state === 'cant-resolve') {
+        // An actionable cell → a button that runs the SAME in-dashboard sign-in flow (PIN → link →
+        // paste code). empty → "Set up"; needs-reauth (an existing account whose login expired) →
+        // "Sign in"; held/cant-resolve → "Retry". A needs-reauth account already resolves to its
+        // email, so the start-cell orchestrator drives a real re-auth — never a cosmetic button.
+        const label = c.state === 'empty' ? 'Set up' : (c.state === 'needs-reauth' ? 'Sign in' : 'Retry');
+        const btn = el(doc, 'button', 'sub-matrix-setup', label);
         btn.setAttribute('data-matrix-setup', '1');
         btn.setAttribute('data-account-id', sanitizeForDisplay(c.accountId, 'label'));
         btn.setAttribute('data-machine-id', sanitizeForDisplay(c.machineId, 'label'));
         if (c.state !== 'empty') {
+          // Show the status word ("⟳ Needs sign-in" / "⚠ Didn't match…") ABOVE the button.
           td.appendChild(el(doc, 'div', 'sub-matrix-glyph', `${MATRIX_CELL_GLYPH[c.state]} ${MATRIX_CELL_WORD[c.state]}`));
         }
         td.appendChild(btn);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.631",
+  "version": "1.3.632",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-20T13:47:07.338Z",
-  "instarVersion": "1.3.631",
+  "generatedAt": "2026-06-20T18:23:55.492Z",
+  "instarVersion": "1.3.632",
   "entryCount": 202,
   "entries": {
     "hook:session-start": {

package/upgrades/1.3.632.md

@@ -0,0 +1,31 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The Subscriptions dashboard's account × machine matrix had a dead-end. A cell whose login had expired showed only the grey text "⟳ Needs sign-in" with **no button to act on** — so you could see an account needed re-authentication but had no way to do anything about it from the dashboard. Every other cell-state was already actionable: an empty cell gets a "Set up" button, a failed cell gets a "Retry" button. The `needs-reauth` state was simply left out of the branch that renders a button and fell through to the "just draw text" path.
+
+This fix moves `needs-reauth` into the actionable branch in `dashboard/subscriptions.js`. The cell now shows the status word "⟳ Needs sign-in" **and** a "Sign in" button directly below it. The button carries the same `(account, machine)` ids as the "Set up" button and runs the exact same in-dashboard flow (PIN → provider sign-in link → paste code). Because a needs-sign-in account already resolves to its email, the `start-cell` orchestrator drives a genuine re-authentication — the button is real, not cosmetic. No server route, authority, or data model changed; the PIN gate on starting a login is untouched.
+
+## What to Tell Your User
+
+If you saw an account in your Subscriptions grid marked "Needs sign-in" with no way to fix it, that's now a one-tap action. The cell shows "Needs sign-in" with a **Sign in** button right below — tap it, enter your PIN, open the sign-in link, and paste the code back, exactly like setting up a new account. Everything stays inside the dashboard; nothing changed about who's allowed to start a login.
+
+## Summary of New Capabilities
+
+- The account × machine matrix's "Needs sign-in" cell is now actionable: it renders the status word **plus a "Sign in" button** that runs the existing in-dashboard re-authentication flow (PIN → link → paste code).
+- The button works for an account whose login expired on this machine OR on a peer machine — it rides the same PIN-gated, mesh-delivered `start-cell` path the "Set up" button already uses.
+- No change to authorization: starting a login still requires the operator's dashboard PIN.
+
+## Evidence
+
+- New regression unit test in `tests/unit/subscriptions-render.test.ts`: asserts a `needs-reauth` cell renders the "Needs sign-in" word AND a `.sub-matrix-setup` "Sign in" button wired to the start-cell flow (`data-matrix-setup`, correct account/machine ids). 34/34 in that file pass.
+- Related front-end tests green: `follow-me-controller-wiring.test.ts` (8) and `account-follow-me-locally-executable.test.ts` (9) — confirms the existing tap-handler/flow this button re-uses is unchanged.
+- Traced root cause directly in `renderAccountMatrix`: `needs-reauth` was absent from the actionable-cell branch condition; the server `start-cell` route resolves an existing account's email and drives a real re-auth, so the new button is functional.
+- Side-effects review: `upgrades/side-effects/matrix-needs-signin-button.md` (no block/allow surface; no new authority; machine-local render of an existing pool-scope flow). Tier 1.
+
+## ELI16
+
+The Subscriptions screen has a grid showing which account is signed in on which machine. Empty squares had a "Set up" button you could tap. But a square for an account whose login had run out just said "Needs sign-in" in grey — with no button. So you could see the problem but couldn't fix it from the screen. Turns out the code that decides "should this square have a button?" simply forgot to include the "needs sign-in" case, so it drew plain text instead. This fix adds the button: the square now says "Needs sign-in" with a "Sign in" button right under it, and tapping it runs the same sign-in steps as setting up a new account (enter your PIN, open the link, paste the code). It actually signs the account back in — it's not a fake button — and it works whether the account expired on this machine or another one.

package/upgrades/side-effects/matrix-needs-signin-button.md

@@ -0,0 +1,70 @@
+# Side-Effects Review — Account matrix "Needs sign-in" → actionable Sign-in button
+
+**Version / slug:** `matrix-needs-signin-button`
+**Date:** `2026-06-20`
+**Author:** `Instar Agent (echo)`
+**Second-pass reviewer:** `not required (no block/allow surface, no lifecycle/gate/sentinel)`
+
+## Summary of the change
+
+The account × machine matrix in the Subscriptions dashboard had a cell-state, `needs-reauth` ("Needs sign-in"), that rendered as static text with no actionable control — a dead-end. This change (one branch condition + a button label in `dashboard/subscriptions.js`, plus one unit test in `tests/unit/subscriptions-render.test.ts`) moves `needs-reauth` into the actionable rendering branch so it draws the status word "⟳ Needs sign-in" AND a "Sign in" button directly below it. The button carries the same `data-matrix-setup` / `data-account-id` / `data-machine-id` attributes the empty-cell "Set up" button does, so it routes through the EXISTING, unchanged PIN-gated `start-cell` → sign-in-link → code-paste flow. No server route, authority, or data model is touched.
+
+## Decision-point inventory
+
+This change touches NO decision point. It is presentation logic only: it decides which DOM (a button vs plain text) to render for an already-computed cell state. The authority that gates starting a login (the dashboard-PIN check on `POST /subscription-pool/matrix/start-cell`) is unchanged and continues to be the sole gate.
+
+- `renderAccountMatrix` cell rendering (`dashboard/subscriptions.js`) — modify — adds `needs-reauth` to the set of cell-states that render an actionable button; pure view logic, no gating.
+
+---
+
+## 1. Over-block
+
+No block/allow surface — over-block not applicable. The change ADDS an affordance; it rejects nothing.
+
+---
+
+## 2. Under-block
+
+No block/allow surface — under-block not applicable. The PIN gate on `start-cell` is unchanged, so this adds no new path that bypasses authorization: tapping "Sign in" still requires the operator's PIN to actually start a login, exactly as "Set up" does.
+
+---
+
+## 3. Level-of-abstraction fit
+
+Correct layer. This is a view-rendering concern living in the dashboard front-end, exactly where the sibling "Set up"/"Retry" button logic already lives. It re-uses the existing `start-cell` orchestrator rather than re-implementing any email-resolution / mandate / login logic — it feeds the smart gate that already exists instead of running parallel to it.
+
+---
+
+## 4. Signal vs authority compliance
+
+Compliant. The change adds NO blocking authority and NO brittle decision logic. It renders a button that, when tapped, calls an existing PIN-gated authority (`start-cell`). The button itself holds no authority; the server endpoint remains the single authority and is untouched.
+
+---
+
+## 5. Interactions
+
+- The new button uses the SAME delegated tap handler (`wireMatrixSetup` → `onSetupTap` → `onConfirmTap` → `start-cell`) as the empty-cell "Set up" button, so it cannot double-fire or shadow another handler — it is the same code path keyed on `data-matrix-setup`.
+- `start-cell` already handles an existing account: it resolves the account email from the accountId (`resolveFollowMeEnrollTarget`) and has self-target idempotency that reuses an in-flight pending login. A needs-reauth account resolves to its email, so the flow drives a real re-auth and does not mint a duplicate when one is already pending.
+- No race with adjacent cleanup: the cell re-renders from durable state each poll; an in-progress login transitions the cell to the in-progress (◷) state with its Cancel button, exactly as a "Set up"-initiated login does.
+
+---
+
+## 6. External surfaces
+
+The only external surface is the dashboard UI: a `needs-reauth` cell now shows a "Sign in" button. No change to any API response, agent-to-agent surface, or other system. No new timing/conversation-state dependency — rendering is a pure function of the already-fetched pool/pending state.
+
+### 6b. Operator-surface quality
+
+This change EXISTS to improve operator-surface quality: it converts a non-actionable status into a one-tap action, matching the operator's directive that everything be actionable from the dashboard. The button label ("Sign in") matches the flow's existing vocabulary; the status word remains visible so the operator still understands WHY the action is offered.
+
+---
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+Machine-local rendering of a pool-scope read, BY DESIGN. The matrix already reads `scope=pool` (peers merged) and the `start-cell` flow already delivers the mandate over the mesh for a peer-target cell. A needs-reauth cell on a PEER machine (e.g. the account expired on the Laptop while the Mini fronts the dashboard) routes its "Sign in" through the same proven cross-machine `start-cell` → peer enroll/start path the "Set up" button uses. No new replication or per-machine state is introduced; the change rides the existing cross-machine plumbing.
+
+---
+
+## 8. Rollback cost
+
+Trivial. Revert the single commit (one branch condition + label + one test) — the cell returns to showing static "Needs sign-in" text. No data migration, no agent-state repair, no release coordination. Dashboard files ship static (no compiled artifact), so a revert is immediately effective on next deploy.