instar 1.3.1169 → 1.3.1171

package/dashboard/index.html

@@ -3541,8 +3541,8 @@
         What the internal AI calls cost, and where the paid-door caps sit. The dollar figures are a
         <b>reporting</b> view — immutable token counts priced against a reviewed price list on read, so a
         price correction reflows automatically. <b>No paid door is live yet</b>, so metered spend is $0;
-        subscription/CLI doors are <b>$0 (not per-token billed)</b>. This is read-only — money caps and the
-        go-live control are a later increment.
+        subscription/CLI doors are <b>$0 (not per-token billed)</b>. The spend figures above are a report;
+        the controls below set a door's ceilings and take it live, and each of those takes your PIN.
       </div>
 
       <!-- Glance floors F10/F11 (topic 29836, Phase 3): the shared component renders
@@ -3550,6 +3550,12 @@
            became plain words at the glance ("pay-per-use"); the per-model math and the
            paid-door caps moved one drill down. -->
       <div id="spendGlance" class="glance-root"></div>
+
+      <!-- Paid-door arming (Increment B UI). Two PIN-committed steps: set both ceilings,
+           then take the door live. The server renders the exact wording of each step and
+           the commit sends back only the plan id + nonce, so a field the operator never
+           saw rendered cannot land. Freeze needs no PIN — halting money is always cheap. -->
+      <div id="spendArming" class="spend-arm-root"></div>
     </div>
 
     <!-- Evidence Tab (WikiClaim Phase 4) — per-entity evidence + reverse "what cites this?" view.
@@ -3634,6 +3640,33 @@
 
     <!-- subscriptions tab (Subscription & Auth Standard P2.2 — live quota + pending logins) -->
     <style>
+      /* Paid-door arming controls (Spend tab). Mobile-first: full-width stacked fields
+         and 44px touch targets, since the operator reaches this from their phone. */
+      .spend-arm-root { display:flex; flex-direction:column; gap:12px; margin-top:8px;
+        border-top:1px solid var(--border,#2a2a2a); padding-top:16px; }
+      .spend-arm-h { margin:0; font-size:16px; }
+      .spend-arm-field { display:flex; flex-direction:column; gap:6px; font-size:13px; opacity:.9; }
+      .spend-arm-input { width:100%; box-sizing:border-box; min-height:44px; padding:10px 12px;
+        font-size:16px; /* 16px stops iOS zooming the page on focus */
+        border:1px solid var(--border,#2a2a2a); border-radius:8px; background:transparent; color:inherit; }
+      .spend-arm-hint { font-size:12px; opacity:.6; }
+      .spend-arm-btns { display:flex; flex-wrap:wrap; gap:8px; }
+      .spend-arm-btn { min-height:44px; padding:10px 14px; font-size:14px; border-radius:8px;
+        border:1px solid var(--border,#2a2a2a); background:transparent; color:inherit; cursor:pointer; flex:1 1 auto; }
+      .spend-arm-btn-freeze { border-color:#b45309; color:#f59e0b; }
+      .spend-arm-btn-commit { border-color:#16a34a; color:#22c55e; width:100%; margin-top:10px; }
+      .spend-arm-plan { display:flex; flex-direction:column; gap:8px; }
+      .spend-arm-plan-label { font-size:12px; font-weight:700; letter-spacing:.05em; text-transform:uppercase; opacity:.6; }
+      .spend-arm-plan-text { font-size:14px; line-height:1.5; padding:12px; border-radius:8px;
+        border:1px solid var(--border,#2a2a2a); white-space:pre-wrap; word-break:break-word; }
+      .spend-arm-plan-expiry, .spend-arm-note { font-size:12px; opacity:.7; }
+      @media (max-width:520px) { .spend-arm-btn { flex:1 1 100%; } }
+
+      /* Provider group heading — only rendered when more than one provider is
+         enrolled, so a single-provider install looks exactly as it did before. */
+      .sub-provider-heading { font-size:12px; font-weight:700; letter-spacing:.06em; text-transform:uppercase;
+        opacity:.6; margin:14px 0 8px; padding-bottom:6px; border-bottom:1px solid var(--border,#2a2a2a); }
+      .sub-provider-heading:first-child { margin-top:0; }
       .sub-account { border:1px solid var(--border,#2a2a2a); border-radius:10px; padding:14px 16px; margin-bottom:12px; }
       .sub-account-inuse { border-color:#16a34a; box-shadow:0 0 0 1px #16a34a44; }
       .sub-account-inuse-badge { font-size:11px; font-weight:600; color:#22c55e; margin-right:auto; }
@@ -6005,6 +6038,10 @@
 
       const spec = glance.spendGlanceSpec(document, summary, caps);
       glance.renderGlance(document, glanceRoot, spec);
+      // The arming controls sit below the read-only glance. Rendered from the SAME caps
+      // payload, so the door list and its live/frozen wording cannot drift from the view
+      // above it.
+      renderSpendArming(caps);
     }
 
     async function loadResources() {
@@ -8630,6 +8667,217 @@
       return __glanceModule;
     }
 
+    // ── Spend tab — paid-door arming (Increment B UI) ──
+    // Two PIN-committed steps (set both ceilings, then go live), each previewed as the
+    // SERVER's rendered wording before the PIN box appears. The commit posts only the
+    // plan id + nonce + PIN, never the form fields.
+    let __spendArmModule = null;
+    async function loadSpendArmModule() {
+      if (!__spendArmModule) {
+        try { __spendArmModule = await import('/dashboard/spend-arming.js'); }
+        catch (e) { console.error('[spend-arming] module load failed', e); return null; }
+      }
+      return __spendArmModule;
+    }
+
+    // The plan currently awaiting approval. Cleared whenever inputs change, so a PIN can
+    // never be applied to a plan the operator has since edited away from.
+    let __spendPendingPlan = null;
+
+    async function renderSpendArming(caps) {
+      const root = document.getElementById('spendArming');
+      if (!root) return;
+      const M = await loadSpendArmModule();
+      if (!M) { root.textContent = 'Loading the money controls failed — refresh to retry.'; return; }
+      root.replaceChildren();
+
+      const h = document.createElement('h3');
+      h.textContent = 'Paid doors';
+      h.className = 'spend-arm-h';
+      root.appendChild(h);
+
+      const rows = M.armableDoors(caps);
+      if (rows.length === 0) {
+        const n = document.createElement('div');
+        n.className = 'spend-arm-note';
+        n.textContent = 'No pay-per-use doors are configured on this agent.';
+        root.appendChild(n);
+        return;
+      }
+
+      const sel = document.createElement('select');
+      sel.id = 'spendArmKey';
+      sel.className = 'spend-arm-input';
+      for (const r of rows) {
+        const o = document.createElement('option');
+        o.value = r.keyRef;
+        // textContent — keyRef/provider are server data, never markup.
+        o.textContent = `${r.provider} · ${r.door} — ${M.doorStateWords(r)}`;
+        sel.appendChild(o);
+      }
+      const selWrap = document.createElement('label');
+      selWrap.className = 'spend-arm-field';
+      selWrap.appendChild(document.createTextNode('Which door'));
+      selWrap.appendChild(sel);
+      root.appendChild(selWrap);
+
+      const mkNum = (id, label, hint) => {
+        const w = document.createElement('label');
+        w.className = 'spend-arm-field';
+        w.appendChild(document.createTextNode(label));
+        const i = document.createElement('input');
+        i.id = id; i.type = 'number'; i.min = '0'; i.step = '0.01';
+        i.className = 'spend-arm-input'; i.inputMode = 'decimal';
+        i.addEventListener('input', () => { __spendPendingPlan = null; renderSpendPlan(null); });
+        w.appendChild(i);
+        const hn = document.createElement('div');
+        hn.className = 'spend-arm-hint'; hn.textContent = hint;
+        w.appendChild(hn);
+        return w;
+      };
+      root.appendChild(mkNum('spendArmLifetime', 'Lifetime ceiling (USD)',
+        'The total this door may ever spend. It stops permanently here.'));
+      root.appendChild(mkNum('spendArmDaily', 'Daily ceiling (USD)',
+        'The most it may spend in one day. Both ceilings are required.'));
+      sel.addEventListener('change', () => { __spendPendingPlan = null; renderSpendPlan(null); });
+
+      const btns = document.createElement('div');
+      btns.className = 'spend-arm-btns';
+      const mkBtn = (text, cls, fn) => {
+        const b = document.createElement('button');
+        b.textContent = text; b.className = cls; b.onclick = fn; return b;
+      };
+      btns.appendChild(mkBtn('Preview cap change', 'spend-arm-btn', () => previewSpendPlan('caps-adjust')));
+      btns.appendChild(mkBtn('Preview go live', 'spend-arm-btn', () => previewSpendPlan('go-live')));
+      btns.appendChild(mkBtn('Freeze this door', 'spend-arm-btn spend-arm-btn-freeze', freezeSpendDoor));
+      root.appendChild(btns);
+
+      const planBox = document.createElement('div');
+      planBox.id = 'spendArmPlan'; planBox.className = 'spend-arm-plan';
+      root.appendChild(planBox);
+
+      const status = document.createElement('div');
+      status.id = 'spendArmStatus'; status.className = 'spend-arm-note';
+      root.appendChild(status);
+    }
+
+    function selectedSpendRow(caps, M) {
+      const key = (document.getElementById('spendArmKey') || {}).value;
+      return M.armableDoors(caps).find((r) => r.keyRef === key) || null;
+    }
+
+    function renderSpendPlan(plan) {
+      const box = document.getElementById('spendArmPlan');
+      if (!box) return;
+      loadSpendArmModule().then((M) => {
+        if (!M) return;
+        M.renderPlanPreview(document, box, plan);
+        if (!plan) return;
+        // The PIN box appears ONLY once there is a rendered plan to approve, so the
+        // operator never types a secret against something they have not read.
+        const w = document.createElement('label');
+        w.className = 'spend-arm-field';
+        w.appendChild(document.createTextNode('Dashboard PIN'));
+        const p = document.createElement('input');
+        p.type = 'password'; p.id = 'spendArmPin'; p.className = 'spend-arm-input';
+        p.autocomplete = 'off'; p.inputMode = 'numeric';
+        w.appendChild(p);
+        box.appendChild(w);
+        const b = document.createElement('button');
+        b.className = 'spend-arm-btn spend-arm-btn-commit';
+        b.textContent = 'Approve with PIN';
+        b.onclick = commitSpendPlan;
+        box.appendChild(b);
+      });
+    }
+
+    function setSpendArmStatus(text) {
+      const s = document.getElementById('spendArmStatus');
+      if (s) s.textContent = text;
+    }
+
+    async function previewSpendPlan(action) {
+      const M = await loadSpendArmModule();
+      if (!M) return;
+      const caps = await apiFetch('/routing-spend/caps').catch(() => null);
+      const row = selectedSpendRow(caps, M);
+      if (!row) { setSpendArmStatus('Pick a door first.'); return; }
+
+      let fields;
+      if (action === 'caps-adjust') {
+        const num = (id) => {
+          const raw = (document.getElementById(id) || {}).value;
+          return raw === '' || raw === undefined ? '' : Number(raw);
+        };
+        const lifetimeCapUsd = num('spendArmLifetime');
+        const dailyCapUsd = num('spendArmDaily');
+        const v = M.validateCaps({ lifetimeCapUsd, dailyCapUsd });
+        if (!v.ok) { setSpendArmStatus(v.error); return; }
+        fields = { keyRef: row.keyRef, provider: row.provider, lifetimeCapUsd, dailyCapUsd };
+      } else {
+        fields = { door: row.door, keyRef: row.keyRef, enabled: true };
+      }
+
+      try {
+        const plan = await apiFetch('/routing-spend/plan', {
+          method: 'POST',
+          headers: { 'Content-Type': 'application/json' },
+          body: JSON.stringify(M.planRequest(action, fields)),
+        });
+        __spendPendingPlan = plan;
+        setSpendArmStatus('');
+        renderSpendPlan(plan);
+      } catch (err) {
+        __spendPendingPlan = null;
+        renderSpendPlan(null);
+        setSpendArmStatus(M.moneyLayerNote(err && err.message));
+      }
+    }
+
+    async function commitSpendPlan() {
+      const M = await loadSpendArmModule();
+      if (!M || !__spendPendingPlan) { setSpendArmStatus('Preview a change first.'); return; }
+      const pinEl = document.getElementById('spendArmPin');
+      const pin = pinEl ? pinEl.value : '';
+      if (!pin) { setSpendArmStatus('Enter your dashboard PIN to approve.'); return; }
+      try {
+        await apiFetch('/routing-spend/caps/adjust', {
+          method: 'POST',
+          headers: { 'Content-Type': 'application/json' },
+          body: JSON.stringify(M.commitRequest(__spendPendingPlan, pin)),
+        });
+        if (pinEl) pinEl.value = '';
+        __spendPendingPlan = null;
+        renderSpendPlan(null);
+        setSpendArmStatus('Applied.');
+        loadRoutingSpend();
+      } catch (err) {
+        if (pinEl) pinEl.value = '';
+        setSpendArmStatus(M.moneyLayerNote(err && err.message));
+      }
+    }
+
+    async function freezeSpendDoor() {
+      const M = await loadSpendArmModule();
+      if (!M) return;
+      const caps = await apiFetch('/routing-spend/caps').catch(() => null);
+      const row = selectedSpendRow(caps, M);
+      if (!row) { setSpendArmStatus('Pick a door first.'); return; }
+      try {
+        // No PIN: halting money is always cheap and always available. UNfreezing is the
+        // PIN-gated direction.
+        await apiFetch('/routing-spend/freeze', {
+          method: 'POST',
+          headers: { 'Content-Type': 'application/json' },
+          body: JSON.stringify({ keyRef: row.keyRef }),
+        });
+        setSpendArmStatus('Frozen. Spending on that door is halted.');
+        loadRoutingSpend();
+      } catch (err) {
+        setSpendArmStatus(M.moneyLayerNote(err && err.message));
+      }
+    }
+
     async function loadCommitments() {
       const glanceRoot = document.getElementById('commitmentsGlance');
       const countBadge = document.getElementById('tabCommitmentCount');

package/dashboard/spend-arming.js

@@ -0,0 +1,170 @@
+/**
+ * Spend tab — the paid-door arming controls (Routing Control Room, Increment B UI).
+ *
+ * The money layer's routes existed but had no screen, while the Spend tab told the
+ * operator that caps and go-live were "a later increment". So an operator told the
+ * arming was "one tap in the Spend tab, enter your PIN" went looking for a PIN box
+ * that had never been built. This is that screen.
+ *
+ * Three things this module refuses to do, because each one caused or repeated that
+ * failure:
+ *
+ * 1. It never claims a control is available when the server says the money layer is
+ *    off. A 503 renders the REASON — that enabling it is the operator's own switch,
+ *    reserved to them by design — not a generic "something went wrong".
+ * 2. It never sends the PIN anywhere except the commit call. The plan/preview call
+ *    is deliberately PIN-free, so the operator sees exactly what they are approving
+ *    BEFORE any secret leaves the page.
+ * 3. It never derives what will be committed from the form. The server renders the
+ *    plan text; the commit sends back only the plan id and nonce. A field the
+ *    operator never saw rendered cannot land.
+ *
+ * Every dynamic value is written with textContent (same contract as subscriptions.js).
+ */
+
+/** Element helper — textContent ONLY, never innerHTML. */
+function el(doc, tag, cls, text) {
+  const n = doc.createElement(tag);
+  if (cls) n.className = cls;
+  if (text !== undefined && text !== null) n.textContent = String(text);
+  return n;
+}
+
+/**
+ * What to tell the operator when a money-layer call fails.
+ *
+ * The 503 case is the one that matters. "Money controls are unavailable" would repeat
+ * the original confusion — the operator would go looking for what they did wrong. The
+ * money layer being off is not a fault and not something they can fix from this screen;
+ * it is a switch deliberately reserved to them, and saying so is the whole point.
+ */
+export function moneyLayerNote(message) {
+  const m = message === undefined || message === null ? '' : String(message);
+  if (/503|not enabled|money layer/i.test(m)) {
+    return 'Money controls are switched off on this agent. Turning them on is your decision — ' +
+      'it is deliberately not something an agent or a developer can flip. Once it is on, these ' +
+      'controls work; until then nothing here can arm a door.';
+  }
+  if (/caps store unreadable/i.test(m)) {
+    return 'The caps record could not be read, so money controls are refusing to act rather ' +
+      'than guess. Nothing has changed.';
+  }
+  if (/pin/i.test(m)) {
+    return 'That PIN was not accepted. Nothing has changed.';
+  }
+  return 'Could not reach the money controls just now. Nothing has changed — try again.';
+}
+
+/**
+ * Validate the two ceilings before asking the server for a plan.
+ *
+ * BOTH are required: the server takes a lifetime ceiling and a daily ceiling, and there
+ * is no monthly figure to fall back on. A monthly intent has to be expressed as both, and
+ * leaving one blank silently produces a very different product — a daily rate with no
+ * lifetime bound is a tap left running, not a budget.
+ */
+export function validateCaps(input) {
+  const { lifetimeCapUsd, dailyCapUsd } = input || {};
+  for (const [name, label] of [['lifetimeCapUsd', 'lifetime'], ['dailyCapUsd', 'daily']]) {
+    const v = (input || {})[name];
+    if (v === '' || v === null || v === undefined) {
+      return { ok: false, error: `Enter a ${label} ceiling — the server requires both.` };
+    }
+    if (typeof v !== 'number' || !Number.isFinite(v)) {
+      return { ok: false, error: `The ${label} ceiling must be a number.` };
+    }
+    if (v <= 0) {
+      return { ok: false, error: `The ${label} ceiling must be greater than zero.` };
+    }
+  }
+  if (dailyCapUsd > lifetimeCapUsd) {
+    return {
+      ok: false,
+      error: 'The daily ceiling is above the lifetime ceiling, so the daily one could never ' +
+        'bind. Lower the daily figure or raise the lifetime one.',
+    };
+  }
+  return { ok: true };
+}
+
+/**
+ * The request body for a plan preview. Deliberately a pure function so a test can prove
+ * the PIN is NOT in it — a preview that carried the secret would defeat the point of
+ * showing the operator what they are approving first.
+ */
+export function planRequest(action, fields) {
+  const f = fields || {};
+  if (action === 'caps-adjust') {
+    return {
+      action: 'caps-adjust',
+      keyRef: f.keyRef,
+      provider: f.provider,
+      lifetimeCapUsd: f.lifetimeCapUsd,
+      dailyCapUsd: f.dailyCapUsd,
+    };
+  }
+  if (action === 'go-live') {
+    return { action: 'go-live', door: f.door, keyRef: f.keyRef, enabled: f.enabled === true };
+  }
+  if (action === 'unfreeze') {
+    return { action: 'unfreeze', keyRef: f.keyRef };
+  }
+  return null;
+}
+
+/**
+ * The commit body. Carries ONLY the plan identity and the PIN — never the form fields.
+ *
+ * This is the load-bearing security shape: the server derives what to apply solely from
+ * the plan it rendered, so a value the operator never saw on screen cannot be committed
+ * by editing the form after previewing.
+ */
+export function commitRequest(plan, pin) {
+  return { planId: (plan || {}).planId, nonce: (plan || {}).nonce, pin };
+}
+
+/** Render the server's plan text for approval. The text is the server's, shown verbatim. */
+export function renderPlanPreview(doc, target, plan) {
+  if (!target) return;
+  target.replaceChildren();
+  if (!plan || !plan.renderedText) {
+    target.appendChild(el(doc, 'div', 'spend-arm-note', 'No plan to approve yet.'));
+    return;
+  }
+  target.appendChild(el(doc, 'div', 'spend-arm-plan-label', 'Approve exactly this:'));
+  target.appendChild(el(doc, 'div', 'spend-arm-plan-text', plan.renderedText));
+  if (plan.expiresAt) {
+    target.appendChild(el(doc, 'div', 'spend-arm-plan-expiry', `This approval expires at ${plan.expiresAt}.`));
+  }
+}
+
+/**
+ * The per-door rows the arming panel offers.
+ *
+ * Only METERED (paid) doors can be armed, so subscription doors are excluded rather than
+ * rendered as inert rows — an unarmable row invites the same "where do I tap?" confusion
+ * this screen exists to remove.
+ */
+export function armableDoors(caps) {
+  const keys = (caps && Array.isArray(caps.keys)) ? caps.keys : [];
+  return keys
+    .filter((k) => k && typeof k.keyRef === 'string' && k.keyRef.length > 0)
+    .map((k) => ({
+      keyRef: k.keyRef,
+      provider: k.provider,
+      door: k.door,
+      lifetimeCapUsd: k.lifetimeCapUsd,
+      dailyCapUsd: k.dailyCapUsd,
+      frozen: k.frozen === true,
+      goLiveState: k.goLiveState,
+      live: k.goLiveState === 'live',
+    }));
+}
+
+/** Plain-language state for a door, so the operator can tell armed from not-armed. */
+export function doorStateWords(row) {
+  if (!row) return '';
+  if (row.frozen) return 'Frozen — spending is halted';
+  if (row.live) return 'Live — this door can spend';
+  return 'Not live — this door cannot spend';
+}

package/dashboard/subscriptions.js

@@ -195,6 +195,47 @@ export function quotaBar(doc, label, pct, resetIso, now = Date.now()) {
   return wrap;
 }
 
+/**
+ * Order accounts so each provider's accounts sit together, interleaving a heading
+ * marker before each group. Returns a flat list of accounts with `{__providerHeading}`
+ * markers spliced in, so the caller keeps ONE loop and one card-rendering path.
+ *
+ * Two deliberate choices:
+ *
+ * - **Groups appear in first-appearance order, and accounts keep their order within a
+ *   group.** Nothing is sorted. The pool's order carries meaning the dashboard cannot
+ *   see (enrolment order, which account is the default), so grouping re-associates
+ *   without re-ranking.
+ *
+ * - **A single-provider list gets NO heading.** Every instar install with one provider
+ *   renders exactly as it did before — the heading only appears once there is genuinely
+ *   something to tell apart, which is the condition that prompted this. That property is
+ *   pinned by a test, because "we grouped everything" would quietly add a redundant
+ *   heading to the common case.
+ */
+export function groupAccountsByProvider(accounts) {
+  if (!Array.isArray(accounts)) return [];
+  const groups = new Map(); // provider key (raw) → accounts, in first-appearance order
+  for (const a of accounts) {
+    const key = a && typeof a.provider === 'string' ? a.provider : '';
+    if (!groups.has(key)) groups.set(key, []);
+    groups.get(key).push(a);
+  }
+  const out = [];
+  const multi = groups.size > 1;
+  for (const [key, members] of groups) {
+    if (multi) {
+      // friendlyProvider maps anthropic→Claude / openai→Codex and SANITIZES anything
+      // else, so an unrecognised or hostile provider string cannot reach the DOM raw.
+      // An absent provider has no honest name, so say so rather than invent one.
+      const label = friendlyProvider(key) || 'Other';
+      out.push({ __providerHeading: label });
+    }
+    for (const m of members) out.push(m);
+  }
+  return out;
+}
+
 /** Per-account rows: nickname, status, provider·framework, 5h + weekly quota bars.
  *  `inUseAccountId` (optional) is the account the agent is CURRENTLY running on —
  *  that card gets an "In use" marker so "active" (healthy) reads distinct from
@@ -206,7 +247,15 @@ export function renderAccounts(doc, target, accounts, now = Date.now(), inUseAcc
     target.appendChild(el(doc, 'div', 'sub-empty', 'No subscription accounts enrolled yet.'));
     return;
   }
-  for (const a of accounts) {
+  for (const a of groupAccountsByProvider(accounts)) {
+    // A group marker, not an account: render the provider heading and continue.
+    // (The operator's complaint was a flat interleaved list — Claude and Codex
+    // accounts mixed together with only a small per-card meta line to tell them
+    // apart. The heading is what makes the split scannable.)
+    if (a && a.__providerHeading) {
+      target.appendChild(el(doc, 'div', 'sub-provider-heading', a.__providerHeading));
+      continue;
+    }
     const inUse = !!(inUseAccountId && a && a.id === inUseAccountId);
     const card = el(doc, 'div', inUse ? 'sub-account sub-account-inuse' : 'sub-account');
     const head = el(doc, 'div', 'sub-account-head');

package/dist/data/standards-guard-index.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "generatedFrom": "source-tree",
   "registrySha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
-  "packageVersion": "1.3.1169",
+  "packageVersion": "1.3.1171",
   "guards": [
     {
       "ref": "docs/audits/phase-b/f10-triage.md",

package/dist/data/standards-guard-index.meta.json

@@ -1,5 +1,5 @@
 {
-  "sha256": "ee1555f5e0d6589d8b1b4fdf24ebe91f6435aca13c9e8f4df5edeebb1338e196",
+  "sha256": "878fad6f61a7948606c4c2d116b92656e0449bab6e005987433fc6bcef6309e6",
   "registrySha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
-  "packageVersion": "1.3.1169"
+  "packageVersion": "1.3.1171"
 }

package/dist/data/standards-registry.meta.json

@@ -2,5 +2,5 @@
   "sha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
   "articleCount": 88,
   "generatedFrom": "docs/STANDARDS-REGISTRY.md",
-  "packageVersion": "1.3.1169"
+  "packageVersion": "1.3.1171"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.1169",
+  "version": "1.3.1171",
   "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-08-16T01:19:21.033Z",
-  "instarVersion": "1.3.1169",
+  "generatedAt": "2026-08-16T04:17:05.922Z",
+  "instarVersion": "1.3.1171",
   "entryCount": 202,
   "entries": {
     "hook:session-start": {

package/src/data/standards-guard-index.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "generatedFrom": "source-tree",
   "registrySha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
-  "packageVersion": "1.3.1169",
+  "packageVersion": "1.3.1171",
   "guards": [
     {
       "ref": "docs/audits/phase-b/f10-triage.md",

package/src/data/standards-guard-index.meta.json

@@ -1,5 +1,5 @@
 {
-  "sha256": "ee1555f5e0d6589d8b1b4fdf24ebe91f6435aca13c9e8f4df5edeebb1338e196",
+  "sha256": "878fad6f61a7948606c4c2d116b92656e0449bab6e005987433fc6bcef6309e6",
   "registrySha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
-  "packageVersion": "1.3.1169"
+  "packageVersion": "1.3.1171"
 }

package/src/data/standards-registry.meta.json

@@ -2,5 +2,5 @@
   "sha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
   "articleCount": 88,
   "generatedFrom": "docs/STANDARDS-REGISTRY.md",
-  "packageVersion": "1.3.1169"
+  "packageVersion": "1.3.1171"
 }

package/upgrades/1.3.1170.md

@@ -0,0 +1,55 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The Subscriptions tab now groups your accounts by provider — Claude accounts together, Codex
+accounts together, each under a heading.
+
+Before, the list was one flat run of cards in enrolment order, so a Codex account could sit
+between two Claude ones. Each card names its provider, but in small text partway down, so
+telling them apart meant reading every card. With a single provider that was fine. With two it
+stopped being fine.
+
+The quota bars live inside the account cards, so grouping the accounts groups the quota view
+along with them.
+
+## What to Tell Your User
+
+- "Your accounts list is grouped by provider now, so your Codex account no longer sits in the
+  middle of your Claude ones."
+- "If you only have one provider, nothing changes at all."
+
+## Summary of New Capabilities
+
+None. This is a presentation change to an existing tab — no endpoint, no configuration.
+
+## Evidence
+
+8 tests in the existing jsdom suite, which exercises the shipped dashboard module against a real
+DOM. Shown capable of failing: restoring the flat list fails exactly the four grouping
+assertions while the four invariant tests keep passing.
+
+The controls carry the weight — a single-provider list is asserted unchanged, and order within a
+group is asserted preserved. Without them, "grouping works" would pass equally well against a
+change that sorted everything alphabetically and added a redundant heading to every
+single-provider install.
+
+The heading is the one new dynamic string reaching the page, so it rides the tab's existing
+sanitize-and-write-as-text contract; a test plants a hostile provider string and confirms no
+live element and no event-handler attribute survives.
+
+## Compatibility Notes
+
+**A single-provider install is untouched**: with one provider no heading is drawn, and the list
+renders exactly as before. That is deliberate — a heading reading "Claude" above a list of only
+Claude accounts is noise — and it is pinned by a test.
+
+Accounts keep their existing order within each group. Nothing is sorted alphabetically, because
+the order accounts arrive in carries meaning the dashboard cannot see (which was enrolled first,
+which is the default). The change re-associates without re-ranking.
+
+An account with no provider is still shown, under a heading reading "Other", rather than being
+dropped or filed under a provider it does not belong to.

package/upgrades/1.3.1171.md

@@ -0,0 +1,56 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The Spend tab gains the screen for arming a paid door — setting its spending limits and taking
+it live. The machinery for this existed and worked; the screen did not, and the tab's own small
+print said caps and go-live were "a later increment". So an operator told arming was "one tap,
+enter your PIN" went looking for a PIN box that had never been drawn. That copy is corrected too.
+
+## What to Tell Your User
+
+- "You can now set a paid door's limits and turn it on from the Spend tab, on your phone."
+- "It asks for your PIN twice on purpose — once to set the limits, once to start spending."
+- "The freeze button needs no PIN. Stopping money should always be immediate."
+
+## Summary of New Capabilities
+
+| Capability | How to Use |
+|-----------|-----------|
+| Set a paid door's ceilings | Spend tab → Paid doors → enter both ceilings → Preview → PIN |
+| Take a paid door live | Spend tab → Paid doors → Preview go live → PIN |
+| Freeze a door immediately | Spend tab → Paid doors → Freeze (no PIN) |
+
+## Evidence
+
+31 unit tests against the shipped module in a real DOM, plus wiring tests asserting that every
+dashboard module the page imports exists on disk — the guard against the "built but unreachable"
+shape this feature is fixing.
+
+Shown capable of failing, independently: leaking the PIN into the preview request fails exactly
+the security test; replacing the honest switched-off message with a generic one fails exactly the
+two tests pinning it. A control asserts an ordinary network failure does not claim the money layer
+is off.
+
+Not yet proven live: the money layer is off on this agent, so the end-to-end arming path cannot be
+exercised until an operator enables it. That is stated rather than implied away.
+
+## Compatibility Notes
+
+**The controls cannot arm anything until the money layer is switched on, and that switch is
+reserved to the operator** — deliberately not something an agent or a developer can flip. Used
+while it is off, the screen says exactly that, rather than showing a generic error that would
+send someone hunting for a mistake they did not make.
+
+**Both ceilings are required.** A door has a lifetime ceiling and a daily ceiling, and there is
+no monthly setting, so a monthly intention must be expressed as both. The screen refuses a blank
+rather than choosing one silently: $100 lifetime with $3.30/day is a hard budget that also cannot
+burn in an afternoon, while $3.30/day with a large lifetime is a tap left running.
+
+**You approve rendered words, not a button.** The server writes out what it is about to do and
+the screen shows that sentence before the PIN box appears. What commits is that plan, not the
+form — so editing a number after previewing invalidates the approval, and a figure never read
+cannot land.

package/upgrades/side-effects/spend-arming-ui.md

@@ -0,0 +1,86 @@
+# Side-Effects Review — paid-door arming UI
+
+## Summary
+
+The routing-spend money layer's routes (`/routing-spend/plan`, `/caps/adjust`, `/freeze`) had no
+screen, while the Spend tab's own copy said caps and go-live were "a later increment". This adds
+the two-step arming flow and corrects that copy.
+
+## How this arose
+
+An operator was told arming was "one tap in the Spend tab, enter your PIN". It was not — the tab
+was read-only and said so. They went looking for a PIN box that had never been drawn. That is the
+same class as the enrolment failures earlier tonight: a capability described as reachable that
+had no reachable surface.
+
+## Decision-point inventory
+
+None added. The screen holds no authority: it renders a plan the SERVER composed and posts back
+the plan identity plus the operator's PIN. The server verifies the PIN and derives what to apply
+from its own rendered plan. The UI cannot arm, adjust, or unfreeze anything on its own.
+
+## 1. Over-block
+
+`validateCaps` refuses client-side before asking for a plan: a missing ceiling, a non-number, a
+non-positive value, or a daily ceiling above the lifetime ceiling. The last could arguably be
+allowed (the server may accept it), but a daily ceiling that can never bind is almost certainly a
+typo, and the message says why rather than just refusing.
+
+## 2. Under-block
+
+The client does no authorization at all — deliberately. Every real refusal (bad PIN, money layer
+off, unreadable caps store, expired plan) is the server's, and the UI only renders the reason.
+
+## 3. Level-of-abstraction fit
+
+Plan rendering stays server-side; the client never composes the sentence the operator approves.
+That is what makes "a field you never saw cannot land" true, and it would be false if the UI
+built its own summary text.
+
+## 4. Signal vs authority
+
+The UI is pure presentation plus transport. The PIN gate is unchanged and remains server-side.
+
+## 5. Interactions
+
+The panel renders from the SAME `/routing-spend/caps` payload the read-only glance above it uses,
+so the door list and its live/frozen wording cannot drift from the figures. Editing any input or
+changing the door clears the pending plan, so a PIN can never be applied to a plan the operator
+has since edited away from.
+
+## 6. Multi-machine posture
+
+Machine-local BY DESIGN — the dashboard is served per machine and the PIN is a per-machine
+secret. Go-live already carries a `designatedMachineId` server-side; the UI does not touch it.
+
+## 7. Failure modes
+
+Every money-layer failure routes through `moneyLayerNote`, which distinguishes: money layer off
+(names it as the operator's own switch), caps store unreadable (refusing to guess), rejected PIN,
+and everything else. The default says "nothing has changed", which is true on every path because
+the server fails closed. The module has no I/O and every exported function is total (tested
+against undefined/null/junk).
+
+**Security**: the PIN never appears in a preview request (pure-function test asserts it), is a
+`type=password` field, is cleared on both success and failure, and is never placed in a URL. All
+rendering is textContent; a hostile plan text is tested for.
+
+## 8. Rollback cost
+
+Delete the `spendArming` div and the `renderSpendArming(caps)` call. The module is inert without
+them. No state, no migration, no config.
+
+## Evidence
+
+31 unit tests against the shipped module in a real DOM, plus wiring tests that assert every
+`/dashboard/*.js` the page imports exists on disk — the guard against the "wired but unreachable"
+shape that caused this whole thread.
+
+Shown capable of failing, independently: leaking the PIN into the preview request fails exactly
+the security test; replacing the honest 503 message with a generic one fails exactly the two
+tests that pin it. A CONTROL asserts an ordinary network failure does NOT claim the money layer
+is off — without it, every failure would send the operator to flip a switch that is already on.
+
+**Not yet proven live.** The money layer is off on this agent, so the arming path cannot be
+driven end-to-end until the operator enables it. That is stated rather than papered over: this
+review does not claim live-channel proof it does not have.

package/upgrades/side-effects/subscriptions-group-by-provider.md

@@ -0,0 +1,70 @@
+# Side-Effects Review — group the accounts list by provider
+
+## Summary
+
+`renderAccounts` drew accounts in a flat pool-ordered run, interleaving providers. It now draws
+each provider's accounts together under a heading, via a new pure `groupAccountsByProvider`.
+
+## Decision-point inventory
+
+None. This is presentation ordering. It gates nothing, grants nothing, and reads no state
+beyond the accounts array it is already handed.
+
+## 1. Over-block / 2. Under-block
+
+Not applicable — no admission decision. The nearest analogue is dropping an account from the
+list, which a test forbids explicitly (every account renders exactly once; count asserted).
+
+## 3. Level-of-abstraction fit
+
+Grouping belongs in the renderer, not the API. The pool's order is meaningful and the server
+should keep returning it as-is; how it is PRESENTED is a dashboard concern. Sorting server-side
+would have imposed one view on every consumer.
+
+## 4. Signal vs authority
+
+Not applicable — no decision logic.
+
+## 5. Interactions
+
+The in-use marker, quota bars, status, email and the no-quota fallback all render through the
+unchanged card path; grouping only reorders and interleaves headings. The heading marker is a
+sentinel object (`__providerHeading`) consumed at the top of the same loop, so there is one
+card-rendering path, not two. A test asserts the in-use marker survives grouping.
+
+## 6. Multi-machine posture
+
+Machine-local BY DESIGN — this is dashboard rendering of data the server already merged.
+Nothing replicates. The pool view's own machine tagging is untouched.
+
+## 7. Failure modes
+
+`groupAccountsByProvider` handles a non-array (returns []), a missing provider (grouped under
+`Other`), and a non-string provider (coerced to the empty key). It has no I/O and cannot throw
+for any accounts array the existing renderer would have accepted.
+
+**Security**: the heading is the only new dynamic string reaching the DOM. It goes through
+`friendlyProvider`, which maps known providers and sanitizes everything else, and is written
+via the module's `el()` textContent helper. A test plants `<img src=x onerror=...>` as a
+provider and asserts no live element and no `onerror` attribute survives.
+
+## 8. Rollback cost
+
+Change one call site back to `for (const a of accounts)`. No state, no migration, no config.
+
+## Evidence
+
+8 new tests in the existing jsdom suite, which drives the SHIPPED `dashboard/subscriptions.js`
+against a real DOM. Shown capable of failing: reverting the call site fails exactly the 4
+grouping assertions while the 4 invariant tests keep passing — the correct signature, since
+those describe behaviour that must hold either way.
+
+Controls carry the weight here: a single-provider list is asserted UNCHANGED (no heading), and
+account order within a group is asserted preserved. Without those, "grouping works" would pass
+equally well against a change that sorted everything alphabetically and added a redundant
+heading to every single-provider install.
+
+One test was WRONG on first run and the code was right: it asserted `innerHTML` lacks the
+substring "onerror", but correctly-escaped text still reads `&lt;img src=x onerror=...&gt;`.
+The assertion now tests the real property — no live element, no such attribute, heading has no
+element children — rather than the absence of characters.