instar 1.3.495 → 1.3.497

package/dashboard/index.html

@@ -217,6 +217,20 @@
        already names the machine, so a slightly dimmed row is enough hint. */
     .session-item.remote { opacity: 0.9; cursor: pointer; }
     .session-item.remote:hover { opacity: 1; }
+    /* WS4.2: explicit per-machine state when a pool machine has no session
+       tiles — an idle machine must never look identical to a broken one.
+       Plain flex row; inherits the sidebar width (mobile-safe). */
+    .machine-status-row {
+      display: flex;
+      align-items: center;
+      gap: 8px;
+      padding: 8px 12px;
+      font-size: 11px;
+      color: var(--text-dim, #8b8fa3);
+      border-top: 1px dashed rgba(139, 143, 163, 0.25);
+    }
+    .machine-status-row.offline .machine-status-text { color: #f87171; }
+    .machine-status-row.online .machine-status-text { opacity: 0.85; }
 
     .type-badge {
       padding: 1px 6px;
@@ -3703,6 +3717,10 @@
     // Kept separate from `sessions` because the WebSocket replaces that array
     // with LOCAL sessions on every broadcast — merging would be wiped each tick.
     let remoteSessions = [];
+    // WS4.2 (multi-machine-seamlessness spec, F7): pool machine inventory for the
+    // per-machine empty-state strip. Populated only when the pool is enabled with
+    // 2+ machines — single-machine agents never see the strip (strict no-op).
+    let poolMachinesView = [];
     let selfMachineNickname = null;
     let activeSession = null;
     let activeMachineId = null; // non-null when the active session streams from a peer (§2.2)
@@ -3964,6 +3982,9 @@
         empty.style.display = 'flex';
         // Clear any existing session items
         list.querySelectorAll('.session-item').forEach(el => el.remove());
+        // WS4.2: even with zero sessions anywhere, each pool machine still gets
+        // an explicit state row — an idle machine must never look broken.
+        renderMachineStatusStrip(list, all);
         return;
       }
 
@@ -4051,6 +4072,37 @@
           ${telemetryHtml}
         `;
       }
+
+      // WS4.2: per-machine state strip after the tiles.
+      renderMachineStatusStrip(list, all);
+    }
+
+    // WS4.2 (multi-machine-seamlessness spec, F7 — 2026-06-12 live incident):
+    // a machine with zero running sessions used to render as NOTHING, identical
+    // to a broken or unreachable machine. Render an explicit state row per pool
+    // machine that has no session tiles: "online — no active sessions" when its
+    // heartbeat is live, "not reachable — last seen <t>" when it is not. Pool
+    // disabled or single-machine → poolMachinesView is empty → zero rows, zero
+    // behavior change (single-machine strict no-op, spec invariant 6).
+    function machineStatusInfo(m) {
+      if (m.online) return { cls: 'online', text: 'online — no active sessions' };
+      const seen = m.selfReportedLastSeen ? new Date(m.selfReportedLastSeen).getTime() : null;
+      const rel = seen ? fmtRelTime(seen) : 'unknown';
+      return { cls: 'offline', text: `not reachable — last seen ${rel}` };
+    }
+    function renderMachineStatusStrip(list, allSessions) {
+      list.querySelectorAll('.machine-status-row').forEach(el => el.remove());
+      if (!poolMachinesView.length) return;
+      const busy = new Set(allSessions.map(s => s.machineNickname || s.machineId).filter(Boolean));
+      for (const m of poolMachinesView) {
+        const label = m.nickname || m.machineId || 'unnamed machine';
+        if (busy.has(m.nickname) || busy.has(m.machineId)) continue; // has tiles — badge already names it
+        const info = machineStatusInfo(m);
+        const row = document.createElement('div');
+        row.className = `machine-status-row ${info.cls}`;
+        row.innerHTML = `<span class="machine-badge">${escapeHtml(label)}</span><span class="machine-status-text">${escapeHtml(info.text)}</span>`;
+        list.appendChild(row);
+      }
     }
 
     // ── Terminal ──────────────────────────────────────────────
@@ -4606,6 +4658,15 @@
         remoteSessions = (j.sessions || []).filter(s => s.remote === true && (s.status === 'running' || s.status === 'starting'));
         renderSessionList();
       } catch { /* best-effort — peers may be offline; next tick retries */ }
+      // WS4.2: refresh the machine inventory on the same cadence so the sessions
+      // view can say "online — no active sessions" vs "not reachable" per machine.
+      try {
+        const pool = await apiFetch('/pool');
+        poolMachinesView = (pool && pool.enabled && Array.isArray(pool.machines) && pool.machines.length >= 2)
+          ? pool.machines
+          : [];
+        renderSessionList();
+      } catch { /* best-effort — strip simply stays absent until the next tick */ }
     }
     function startPoolSessionsPolling() {
       if (poolPollTimer) return;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.495",
+  "version": "1.3.497",
   "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/skills/instar-dev/templates/side-effects-artifact.md

@@ -95,6 +95,7 @@
 - External systems (Telegram, Slack, GitHub, Cloudflare, etc.)?
 - Persistent state (databases, ledgers, memory files)?
 - Timing or runtime conditions we don't fully control?
+- **Operator surface (Mobile-Complete Operator Actions):** does every operator-facing action this change adds or touches have a phone-completable surface — a dashboard form or a link the agent can send? A PIN-gated or approval-class route with no human surface is an incomplete feature, not a finished API (the 2026-06-12 floor-grant lesson: the route was correct, signed, audited — and laptop-bound). "No operator-facing actions" is a valid answer; an API-only operator action is not.
 
 [Specific findings. "The response format for 422 changes — callers parsing the `issue` field will still see a non-empty string. Verified in telegram-reply.sh." "No external surface changes" is also valid if true.]
 

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-12T21:22:33.499Z",
-  "instarVersion": "1.3.495",
+  "generatedAt": "2026-06-12T21:39:24.602Z",
+  "instarVersion": "1.3.497",
   "entryCount": 201,
   "entries": {
     "hook:session-start": {

package/upgrades/{1.3.495.md → 1.3.496.md}

@@ -9,10 +9,31 @@ The PIN-gated user→agent floor-grant route (`POST /mandate/:id/grants`) finall
 
 Agent awareness ships both ways: the CLAUDE.md template gains a "User floor-action grants are phone-first" bullet (send the operator the dashboard link, NEVER a terminal command), and a `PostUpdateMigrator` migration inserts the same bullet into existing agents' Coordination Mandate section (anchored insertion, append fallback, idempotent). `CapabilityIndex` entries updated for both routes.
 
+The dashboard sessions view rendered NOTHING for a pool machine with zero running
+sessions — visually identical to a machine that is offline or unreachable. Live
+incident 2026-06-12 (topic 13481): minutes after the pool-tile status filter shipped,
+an idle-but-healthy Mac Mini disappeared from the sessions view entirely and the
+operator reasonably read it as a regression.
+
+The sessions view now renders an explicit state row for every pool machine that has
+no session tiles: **"online — no active sessions"** when its heartbeat is live, or
+**"not reachable — last seen <t>"** when it is not. Data comes from the existing
+`GET /pool` machine inventory on the existing 15-second pool poll — no new routes, no
+server changes. Machines that have session tiles get no redundant row (their tiles
+already carry the machine badge). Pool disabled or single-machine: the strip is never
+rendered — strict no-op, locked by test. This is WS4.2 of the converged
+multi-machine-seamlessness spec (`docs/specs/MULTI-MACHINE-SEAMLESSNESS-SPEC.md`,
+3-round convergence, 91 findings addressed), whose audit and ELI16 companion ship in
+this same PR.
+
 ## What to Tell Your User
 
 - "You can now grant a teammate a time-boxed floor action (like a 1-hour prod-deploy) straight from the dashboard on your phone — pick the person, the action, and the duration, type your PIN, tap Grant. No terminal, no laptop."
 
+- "Your dashboard's session list now tells you the state of every machine, even the
+  quiet ones — an idle machine says 'online — no active sessions' instead of showing
+  nothing, so you can always tell a resting machine from a broken one."
+
 ## Summary of New Capabilities
 
 | Capability | How to Use |
@@ -20,6 +41,10 @@ Agent awareness ships both ways: the CLAUDE.md template gains a "User floor-acti
 | Phone-first floor-action grants | Dashboard → Mandates tab → any active mandate → "Grant a user a floor action" |
 | Registered-user person picker | Automatic (`GET /permissions/users` feeds it) |
 
+| Capability | How to Use |
+|-----------|-----------|
+| Per-machine empty-state in the sessions view | Automatic — open the dashboard sessions list on any multi-machine pool |
+
 ## Evidence
 
 - Unit: `tests/unit/dashboard-mandateGrantForm.test.ts` (12 tests — pick-don't-type rendering, PIN discipline incl. never-retained, expiry clamp, enum-drift pin, XSS, registry-failure degradation) + `tests/unit/PostUpdateMigrator-floorGrantPhoneFirst.test.ts` (4 tests — fresh install, anchored insertion, hand-edited fallback, idempotency).
@@ -27,3 +52,15 @@ Agent awareness ships both ways: the CLAUDE.md template gains a "User floor-acti
 - E2E: `tests/e2e/coordination-mandate-lifecycle.test.ts` (+3 — route alive + Bearer-gated on the production boot path; the form's EXACT payload signs a grant end-to-end; Bearer-without-PIN structurally refused).
 - All 24 pre-existing Mandates-tab tests + the full mandate-area suite (109 tests) green.
 - Side-effects artifact: `upgrades/side-effects/mandate-grant-form.md`.
+
+- New test file `tests/unit/dashboard-machineEmptyState.test.ts` (6 tests, at-rest
+  HTML/JS assertions following the established dashboard test pattern) — proven
+  failing 6/6 against the pre-change file, all pass on the fix. Covers: the
+  single-machine no-op gate, both honest state strings, the zero-sessions branch,
+  no-duplicate-rows reconciliation, no redundant rows for busy machines, and HTML
+  escaping of machine-provided strings.
+- `tests/integration/pool-routes.test.ts` extended to lock the `/pool` contract field
+  (`selfReportedLastSeen`) the strip consumes.
+- Side-effects artifact: `upgrades/side-effects/multi-machine-seamlessness-ws42.md`.
+- Spec: `docs/specs/MULTI-MACHINE-SEAMLESSNESS-SPEC.md` (converged + approved) with
+  convergence report `docs/specs/reports/multi-machine-seamlessness-convergence.md`.

package/upgrades/1.3.497.md

@@ -0,0 +1,24 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The Standards Registry (`docs/STANDARDS-REGISTRY.md`, Interaction section) gains a new operator-ratified standard: **Mobile-Complete Operator Actions** — every action that needs the operator (approvals, grants, credential submissions, decisions, PIN-gated authority) must be completable from a phone via the dashboard or a sent link; a terminal command, file edit, or laptop-only step in an operator loop is a defect. Earned from the 2026-06-12 floor-grant incident (Slack live-test scenario 8/8: a correct, PIN-gated, signed route that was laptop-bound because it shipped API-only), ratified by operator directive (Justin, topic 22367). The entry records the sharper sub-lesson too: the outbound advisory blocked the raw-CLI message and the agent complied in format only — guards catch format, the constitution states substance.
+
+Review-time enforcement ships with it: the side-effects artifact template (`skills/instar-dev/templates/side-effects-artifact.md`, question 6 — External surfaces) now explicitly asks whether every operator-facing action the change adds or touches has a phone-completable surface. The crystallizing incident's conversion (the Mandates-tab grant form, instar#1080/PR #1082) is the standard's first applied-through artifact; the durable generalization (one-time Operator Approval Links) is tracked to go through `/spec-converge`.
+
+## What to Tell Your User
+
+None — internal change (no user-facing surface).
+
+## Summary of New Capabilities
+
+None — internal change (no user-facing surface).
+
+## Evidence
+
+- The registry entry follows the constitution's established format (Rule / In practice / Earned from / Ratified by / Traces to the goal / Applied through) with the operator's ratifying directive quoted.
+- Registry-parsing guards stay green: `tests/unit/standards-enforcement-auditor.test.ts` (incl. the zero-dangling-refs canary — every guard the entry cites exists on disk), `tests/unit/standards-conformance-gate.test.ts`, and the deferral scan (the entry's known-open generalization carries a tracked marker).
+- Side-effects artifact: `upgrades/side-effects/mobile-complete-operator-actions.md`.

package/upgrades/side-effects/mobile-complete-operator-actions.md

@@ -0,0 +1,67 @@
+# Side-Effects Review — Constitution: Mobile-Complete Operator Actions
+
+**Version / slug:** `mobile-complete-operator-actions`
+**Date:** `2026-06-12`
+**Author:** `Instar Agent (echo)`
+**Second-pass reviewer:** `not required (documentation + review-template change; no runtime surface, no decision points)`
+
+## Summary of the change
+
+Adds the operator-ratified **Mobile-Complete Operator Actions** standard to `docs/STANDARDS-REGISTRY.md` (Interaction section) and its review-time enforcement hook: an operator-surface bullet in the side-effects template's question 6 (`skills/instar-dev/templates/side-effects-artifact.md`). Earned from the 2026-06-12 floor-grant incident; ratified by operator directive (Justin, topic 22367). No runtime code changes.
+
+## Decision-point inventory
+
+No decision points touched. The registry is read by the spec-review conformance gate and the standards-enforcement auditor — both observe/classify; neither gains new blocking logic from this entry. The template change adds a QUESTION future authors must answer in writing; the pre-commit hook's artifact checks are unchanged (it verifies artifact existence/coverage, not per-question structure).
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this change reject that it shouldn't?**
+
+Nothing is blocked by this change. The new template question could be answered "No operator-facing actions" by any change without one — no legitimate change gains friction beyond one written sentence. No issue identified.
+
+## 2. Under-block
+
+**What failure modes does this still miss?**
+
+The standard's enforcement is review-time prose (the template question) — an author can answer it wrongly and ship an API-only operator action anyway; the conformance audit will classify this standard as `spec-only` strength until a structural ratchet exists (the named candidate: a UI-surface map for PIN-class routes). That gap is the Standards Enforcement Coverage system working as designed — it surfaces which standards are wishes — and the registry entry names the intended ratchet honestly rather than claiming structural enforcement it doesn't have.
+
+## 3. Level-of-abstraction fit
+
+**Is this at the right layer?**
+
+Yes. The 2026-06-12 incident proved a gate alone is the wrong layer: the outbound advisory fired and the substance still shipped laptop-bound. A constitutional entry is the layer that states substance; gates and ratchets grow toward it (and the spec-review conformance gate starts checking drafts against it immediately, since it reads the registry).
+
+## 4. Signal vs authority compliance
+
+**Does this hold blocking authority with brittle logic?**
+
+No blocking authority is added anywhere. Reference reviewed: `docs/signal-vs-authority.md`. No issue identified.
+
+## 5. Interactions
+
+**Does it shadow another check, get shadowed, double-fire, race with adjacent cleanup?**
+
+- Registry parsers verified green against the new entry: `standards-enforcement-auditor` (including the zero-dangling-refs canary — every guard the entry cites must exist on disk, which is why this PR lands AFTER the grant-form PR that contains `GET /permissions/users`), `standards-conformance-gate`, and the pre-commit deferral scan (the entry's known-open generalization carries a `tracked:` marker).
+- The entry sits beside "No Manual Work (user *or* agent)" as a sibling, not a duplicate: that standard says interactions must be automatic/channel-borne; this one pins the DEVICE bar for the human half of those interactions.
+
+## 6. External surfaces
+
+**Does this change anything visible outside the immediate code path?**
+
+- The registry is read by the spec-review conformance gate, the runtime Usher, and the standards-enforcement auditor — all gain one more standard to surface/classify. That is the intended effect.
+- The template change reaches future instar authors only (the template is copied at artifact-writing time; existing artifacts are untouched).
+- **Operator surface (the new question, answered for this change itself):** this change adds no operator-facing actions. The standard it documents was applied to the incident's own surface in PR #1082.
+
+## 7. Rollback cost
+
+**If this turns out wrong in production, what's the back-out?**
+
+Revert the docs commit. No state, no migrations, no runtime behavior. The conformance gate simply stops checking drafts against the entry. Trivial rollback.
+
+---
+
+## Second-pass review
+
+Not required — documentation + review-template change with no runtime surface or decision points (per the skill's Phase 5 trigger list). The artifact's "documentation-level impact" conclusion is the valid outcome the skill explicitly names for this class of change.

package/upgrades/side-effects/multi-machine-seamlessness-ws42.md

@@ -0,0 +1,59 @@
+# Side-Effects Review — WS4.2 per-machine empty-state strip (dashboard sessions view)
+
+**Spec:** docs/specs/MULTI-MACHINE-SEAMLESSNESS-SPEC.md (converged 2026-06-12, 3 iterations; approved)
+**Change:** dashboard/index.html (+ tests). The sessions view renders an explicit state
+row for every pool machine that has no session tiles: "online — no active sessions"
+when its heartbeat is live, "not reachable — last seen <t>" when not. Data: the
+existing `GET /pool` machines array, fetched on the existing 15s pool poll cadence.
+Closes audit finding F7 (2026-06-12 live incident: idle Mini rendered as nothing and
+read as a regression).
+
+## 1. Over-block
+No issue identified — the change blocks nothing. It is a read-only presentation
+addition; no input is rejected anywhere.
+
+## 2. Under-block
+No issue identified — there is no blocking surface. Honesty boundary worth naming:
+`online:false` cannot distinguish "deliberately shut down" from "network-unreachable",
+so the row says "not reachable — last seen <t>" (data-honest) rather than claiming to
+know which. The spec's three-state wording maps onto the two states the data supports;
+this is recorded as the deliberate build decision the converged spec's round-3
+adversarial pass classified as adequately constrained.
+
+## 3. Level-of-abstraction fit
+Right layer. The dashboard already consumes `/pool` (Machines tab) and
+`/sessions?scope=pool` (tiles); the strip is pure client-side composition of data both
+endpoints already serve. No new route, no server change. A server-side "empty
+machines" field would duplicate client-known state at a worse layer.
+
+## 4. Signal vs authority compliance
+Compliant by vacuity: the change introduces NO decision point — it gates no flow,
+filters no message, constrains no behavior. (Phase-1 principle check recorded the
+same conclusion in the build transcript.)
+
+## 5. Interactions
+- The strip renders AFTER session tiles and clears its own rows per render — no
+  interference with tile add/remove reconciliation (verified by test: no duplicate
+  accumulation).
+- The zero-sessions early-return branch now also renders the strip; the existing
+  #emptyState banner still shows alongside it (intended: "no sessions" + per-machine
+  states are complementary, not contradictory).
+- A machine WITH tiles gets no row (its tiles' machine badge already names it) —
+  prevents double-labeling.
+- The extra `GET /pool` per 15s poll tick matches the Machines tab's existing call
+  pattern and is auth'd identically (apiFetch). Failure is swallowed best-effort: the
+  strip simply stays absent until the next tick — degraded view, never an error loop.
+
+## 6. External surfaces
+None beyond the operator's own PIN-gated dashboard. No new data is exposed: nickname,
+online, lastSeen are already rendered on the Machines tab. Machine-provided strings
+are escaped before DOM injection (tested). Single-machine agents: `poolMachinesView`
+is populated only when the pool is enabled with 2+ machines — strict no-op, tested.
+
+## 7. Rollback cost
+Trivial: revert the dashboard/index.html hunk (static asset; no data, no migration,
+no state). Ships with the next release; rollback is a one-commit revert and re-release.
+
+## Second-pass review
+Not required — no block/allow decisions, no session lifecycle, no
+gate/sentinel/watchdog surface. (Phase-5 trigger list consulted; none match.)