instar 1.3.1169 → 1.3.1170

package/dashboard/index.html

@@ -3634,6 +3634,11 @@
 
     <!-- subscriptions tab (Subscription & Auth Standard P2.2 — live quota + pending logins) -->
     <style>
+      /* 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; }

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.1170",
   "guards": [
     {
       "ref": "docs/audits/phase-b/f10-triage.md",

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

@@ -1,5 +1,5 @@
 {
-  "sha256": "ee1555f5e0d6589d8b1b4fdf24ebe91f6435aca13c9e8f4df5edeebb1338e196",
+  "sha256": "a280711e801cac1066b109eb5400956a867d0028f6b5825ad21b7b1ccde1f49f",
   "registrySha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
-  "packageVersion": "1.3.1169"
+  "packageVersion": "1.3.1170"
 }

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.1170"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.1169",
+  "version": "1.3.1170",
   "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-16T03:47:55.829Z",
+  "instarVersion": "1.3.1170",
   "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.1170",
   "guards": [
     {
       "ref": "docs/audits/phase-b/f10-triage.md",

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

@@ -1,5 +1,5 @@
 {
-  "sha256": "ee1555f5e0d6589d8b1b4fdf24ebe91f6435aca13c9e8f4df5edeebb1338e196",
+  "sha256": "a280711e801cac1066b109eb5400956a867d0028f6b5825ad21b7b1ccde1f49f",
   "registrySha256": "81b53363a440e832672618965540b3e507ae0d93adcc67ec2b93daf7933b3ab4",
-  "packageVersion": "1.3.1169"
+  "packageVersion": "1.3.1170"
 }

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.1170"
 }

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/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.