instar 1.3.577 → 1.3.578

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-15T19:37:21.883Z",
-  "instarVersion": "1.3.577",
+  "generatedAt": "2026-06-15T19:52:27.554Z",
+  "instarVersion": "1.3.578",
   "entryCount": 201,
   "entries": {
     "hook:session-start": {
@@ -11,7 +11,7 @@
       "domain": "identity",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/session-start.sh",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:dangerous-command-guard": {
@@ -20,7 +20,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/dangerous-command-guard.sh",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:grounding-before-messaging": {
@@ -29,7 +29,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/grounding-before-messaging.sh",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:compaction-recovery": {
@@ -38,7 +38,7 @@
       "domain": "identity",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/compaction-recovery.sh",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:external-operation-gate": {
@@ -47,7 +47,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/external-operation-gate.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:deferral-detector": {
@@ -56,7 +56,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/deferral-detector.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:self-stop-guard": {
@@ -65,7 +65,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/self-stop-guard.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:post-action-reflection": {
@@ -74,7 +74,7 @@
       "domain": "evolution",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/post-action-reflection.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:external-communication-guard": {
@@ -83,7 +83,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/external-communication-guard.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:scope-coherence-collector": {
@@ -92,7 +92,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/scope-coherence-collector.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:scope-coherence-checkpoint": {
@@ -101,7 +101,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/scope-coherence-checkpoint.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:free-text-guard": {
@@ -110,7 +110,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/free-text-guard.sh",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:claim-intercept": {
@@ -119,7 +119,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/claim-intercept.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:claim-intercept-response": {
@@ -128,7 +128,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/claim-intercept-response.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:stop-gate-router": {
@@ -137,7 +137,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/stop-gate-router.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "hook:auto-approve-permissions": {
@@ -146,7 +146,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/auto-approve-permissions.js",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "job:health-check": {
@@ -1554,7 +1554,7 @@
       "type": "subsystem",
       "domain": "updates",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
-      "contentHash": "0ed164972ade364a81d33b54524f4893d080b86bdb37af6a1f9304fe7b5600e8",
+      "contentHash": "79f741ce474e9e82ba385484e7d587f07d8279f9dfcf41b9b53a797bb890c717",
       "since": "2025-01-01"
     },
     "subsystem:scheduler": {

package/src/scaffold/templates.ts

@@ -422,6 +422,7 @@ This routes feedback to the Instar maintainers automatically. Valid types: \`bug
 - **Mid-work resume queue** (ships observe-only/dry-run by default): a session reaped MID-WORK (strong work evidence at kill time) is queued for ordered automatic revival once the machine recovers — at most one resume per minute, only after sustained calm + quota headroom. \`GET /sessions/resume-queue\` shows entries, paused/breaker state, and lastTickAt; \`POST /sessions/resume-queue/:id/cancel\` · \`/:id/requeue\` (gave-up entries only) · \`/resume\` (unpause) · \`/drain\` (manual single step). Emergency stops pause the queue; an explicit per-topic stop cancels that topic's entries. Jobs only auto-resume when their definition sets \`resumeOnReap: true\`.
 - **A stale emergency-stop pause self-heals**: an emergency-stop pauses the WHOLE revival queue, and that pause used to never lift — silently stranding later, unrelated active-run revivals (the 2026-06-14 4-hour-silent-strand). Now: while the queue is paused with sessions waiting, you get ONE plain-English heads-up that revival is paused (Layer 1, always on); and if the pause is a stale emergency/sentinel stop AND an active autonomous run has since been recycled and queued well after the stop, the queue auto-resumes itself (Layer 2, on by default — \`monitoring.resumeQueue.autoResumeStalePause: false\` to disable; \`staleEmergencyPauseAutoResumeMin\` tunes the window, default 60). Any topic you actually stopped stays blocked by its per-topic operator-stop record even after the queue resumes, and a deliberate \`autonomous stop-all\` halt is NEVER auto-cleared. Proactive: user asks "why did my session restart by itself after a stop?" / "why is revival paused?" → GET /sessions/resume-queue (paused state) and the resume-queue audit log, then explain in plain words.
 - Proactive: user asks "where did my session go?" / "why did X disappear?" / "did something get killed?" → GET /sessions/reap-log and explain the most recent reaped/skipped entries for that session. User asks "did my interrupted work come back?" / "is a restart queued?" → GET /sessions/resume-queue and report the entry's status in plain words.
+- **An autonomous run must outlive its session** (standard; dev-enabled, fleet-default-OFF self-heal): the revival queue takes a host-local lock so two machines can't share its state. A machine RENAME used to leave a stale lock the queue mistook for a shared-volume conflict → it silently disabled the whole revival guard (the 2026-06-15 incident). Now: on the dev agent, a stale FOREIGN-host lock that is provably a single-host rename (host-local disk + dead pid + ≥5min-stale heartbeat) is AUTO-HEALED instead of disabling (fail-closed on any uncertainty; \`monitoring.resumeQueue.autoHealStaleHostLock\`, fleet-default false). And a disabled revival queue now self-reports to the guard-posture inventory — it shows as \`off-runtime-divergent\` on \`GET /guards\` and raises one aggregated attention item, never silently inert. Proactive: user asks "why didn't my autonomous run come back after a restart/rename?" → GET /guards (is the resume queue off-runtime-divergent?) and GET /sessions/resume-queue (disabled reason), then explain.
 - **Build-Session Yield Safety** (ACT-839; ships dev-enabled, dark on the fleet, per the Maturation Path standard): a session reaped while its WORKTREE holds uncommitted work (a build that died "standing by for tests") is resume-eligible on that alone — the killer collects a bounded, fail-open dirty-check pre-kill and tags \`uncommitted-worktree-work\`. On revival the continuation prompt leads with a commit-first directive, and a durable beacon-enabled commitment (\`GET /commitments\`) re-surfaces the obligation if the revived session stalls. An explicit operator/user kill is NEVER auto-revived on a dirty worktree alone. The die-again case is caught by the OrphanedWorkSentinel (\`GET /orphaned-work\`). Proactive: user asks "why did my build come back / why am I being told to commit?" → it was revived because its worktree had unsaved work; commit it or deliberately discard it.
 
 ### Guard Posture — which safety systems are genuinely on (\`GET /guards\`)

package/upgrades/1.3.578.md

@@ -0,0 +1,64 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+A new constitutional standard ("An Autonomous Run Must Outlive Its Session") plus the
+fix behind it. The mid-work resume queue (the system that revives a reaped autonomous
+run, #1157) takes a host-local lock so two machines can't corrupt its shared state.
+A machine RENAME used to leave a stale lock the queue mistook for a shared-volume
+conflict — so it silently disabled the entire run-revival guard and never said so
+(the 2026-06-15 incident). Two changes:
+
+- **Rename-aware lock (GAP-D).** When the lock shows a different host, the queue now
+  distinguishes a single-host rename (provably host-local disk + dead pid + ≥5min
+  stale heartbeat → auto-heal the lock via an O_EXCL first-writer-wins takeover) from
+  a genuine shared-volume conflict (stay disabled). FAIL-CLOSED on any uncertainty
+  (unknown filesystem, `df` failure, live pid, fresh heartbeat). The original HARD
+  INVARIANT — never pid-probe a foreign-host lock — is fully preserved when auto-heal
+  is off. Ships **fleet-default OFF** (`monitoring.resumeQueue.autoHealStaleHostLock`),
+  dev-agent dryRun-first (logs "would auto-heal" without rewriting) before going live.
+- **A disabled revival queue is now LOUD (D2).** The queue self-reports to the
+  guard-posture inventory (`GUARD_MANIFEST` entry + `guardStatus()` + an unconditional
+  registration), so a disabled revival queue reads `off-runtime-divergent` on
+  `GET /guards` and raises one aggregated attention item — never silently inert.
+
+No new route. New code-defaulted config key (kept out of ConfigDefaults to preserve
+the fleet flip, consistent with #1157). Signal-only surfacing; the only authority is
+the queue refusing to start itself (bounded self-recovery, fail-closed).
+
+## What to Tell Your User
+
+- **Your autonomous work survives a machine rename now** (dev agent): "If I rename or
+  restore this machine, the system that brings a reaped autonomous run back no longer
+  quietly switches itself off. On a provable same-machine rename it heals its own lock
+  (carefully — only on a local disk, with the old process gone); on anything uncertain
+  it stays cautious. And if that revival system is ever genuinely disabled, you'll see
+  it flagged on the guards view with one alert instead of silence." ⚗️ Experimental —
+  the self-heal ships dark on the fleet (dev-agent first) and rolls out more widely
+  only after it's proven safe.
+
+## Summary of New Capabilities
+
+| Capability | How to Use |
+|-----------|-----------|
+| A machine rename auto-heals the resume-queue lock instead of silently disabling revival | Automatic on the dev agent (`monitoring.resumeQueue.autoHealStaleHostLock`; fleet default off) |
+| A disabled revival queue surfaces as `off-runtime-divergent` | `GET /guards` (automatic) |
+| Diagnose "why didn't my autonomous run come back?" | `GET /guards` + `GET /sessions/resume-queue` (disabled reason) |
+
+## Evidence
+
+- Unit (`tests/unit/resume-queue-autoheal-lock.test.ts`, 11): the FD1 device-source
+  truth-table (local `/dev/*` → local; `//host`/`host:/path` → not; unknown/tmpfs/map →
+  fail-closed); auto-heal fires only on local-FS + dead-pid + stale-heartbeat; stays
+  disabled on a non-local FS or a live pid; dryRun logs-but-does-not-rewrite; auto-heal
+  off preserves today's behavior; `guardStatus()` reporting.
+- Integration (`tests/integration/resume-queue-guard-posture.test.ts`, 3): a
+  runtime-disabled queue classifies `off-runtime-divergent` through the real
+  GUARD_MANIFEST entry + `deriveGuardRow`; a healthy queue does not.
+- Regression: the full resume-queue unit + route suite (100 tests) stays green —
+  including the existing HARD-INVARIANT test that a foreign-host lock is never
+  pid-probed (which guards against re-introducing the cross-host probe). tsc clean;
+  `lint-guard-manifest` clean. Independent Phase-5 second-pass review concurred.

package/upgrades/side-effects/autonomous-run-outlives-session.md

@@ -0,0 +1,114 @@
+# Side-Effects Review — autonomous-run-outlives-session
+
+Spec: `docs/specs/autonomous-run-outlives-session.md` (converged + approved).
+Change: GAP-D — the resume-queue host-lock distinguishes a single-host RENAME
+(auto-heal) from a genuine shared-volume conflict (stay disabled), fail-closed;
+a disabled revival queue self-reports to the guard-posture inventory; + the
+constitutional standard "An Autonomous Run Must Outlive Its Session".
+
+Files:
+- `src/monitoring/ResumeQueue.ts` — `classifyDfSourceLocal` + `isStateDirHostLocalDefault` (FD1), foreign-host rename-vs-conflict classifier (FD2), `takeOverLockAtomic` (FD4), `guardStatus()` (D2), `autoHealStaleHostLock` config field (FD5).
+- `src/monitoring/guardManifest.ts` — `GUARD_MANIFEST` entry `monitoring.resumeQueue.enabled` (component `ResumeQueue`).
+- `src/commands/server.ts` — dev-gate resolves `autoHealStaleHostLock`; UNCONDITIONAL `guardRegistry.register` for the queue.
+- `src/core/types.ts` — `autoHealStaleHostLock?` config field.
+- `docs/STANDARDS-REGISTRY.md` — the new standard.
+- `src/scaffold/templates.ts` + `src/core/PostUpdateMigrator.ts` — Agent Awareness line (new + deployed agents).
+- Tests: `tests/unit/resume-queue-autoheal-lock.test.ts` (11), `tests/integration/resume-queue-guard-posture.test.ts` (3).
+
+## 1. Over-block (what legitimate inputs does this reject that it shouldn't?)
+The auto-heal is STRICTLY ADDITIVE and gated: it can only turn a currently-DISABLED
+foreign-host case into an enabled one. It never disables a case that previously
+worked. The risk direction is "fails to heal a legitimate rename" → the queue
+stays disabled exactly as today (no regression), just with a louder surface.
+Fail-closed on any uncertainty (unknown FS, df failure, live pid, fresh heartbeat)
+means some genuine renames won't auto-heal — acceptable: the operator clears the
+lock manually as before, and the guard-posture alert now tells them to.
+
+## 2. Under-block (what failure modes does this still miss?)
+- pid recycling (FD3, accepted): a recycled dead pid that maps to a live unrelated
+  process reads as a live conflict → stays disabled + LOUD (safe direction; worst
+  case a false escalation, never corruption).
+- The narrow double-boot unlink race in `takeOverLockAtomic` (two server boots on
+  one machine within ms of each other post-rename): O_EXCL gives EEXIST to the
+  loser in the common case; the residual double-unlink window is backstopped by
+  the next-acquire live-pid + heartbeat check. Not corruption — at worst a
+  transient re-evaluation.
+- Genuine shared-volume setups where `df -P` reports a device string we don't
+  recognize as network: classified unknown → NOT local → stays disabled (correct).
+
+## 3. Level-of-abstraction fit
+Correct layer. The lock classifier lives IN `ResumeQueue.acquireLock` (the only
+place that owns the lock), and the surfacing rides the EXISTING guard-posture
+inventory (GUARD_MANIFEST + GuardRegistry + GuardPostureProbe) rather than a new
+parallel alert path. No new notification surface invented — it feeds the one that
+already aggregates and dedups (Bounded Notification Surface).
+
+## 4. Signal vs authority compliance (docs/signal-vs-authority.md)
+COMPLIANT. The auto-heal is bounded SELF-RECOVERY of the queue's own lock with a
+fail-closed default — not a brittle gate holding blocking authority over agent
+behavior or message flow. The guard-posture surfacing is a pure SIGNAL-producer
+(it reports a disabled state; it never blocks, delays, or rewrites anything). The
+default `autoHealStaleHostLock:false` keeps the behavior change off the fleet until
+proven; the dev-agent runs it dryRun-first (logs intent without rewriting).
+
+## 5. Interactions
+- Preserves the original HARD INVARIANT (never pid-probe a foreign lock) when
+  auto-heal is OFF — verified by the existing `resume-queue.test.ts:417` invariant
+  test (which initially regressed and was fixed by gating all probing behind
+  `autoHealStaleHostLock`).
+- The new GUARD_MANIFEST entry passes `lint-guard-manifest` (the drainer is not
+  auto-flagged, so no orphan NOT_A_GUARD entry — which would itself fail the lint).
+- `guardRegistry.register` is UNCONDITIONAL (even when start() returns false) so a
+  lock-disabled queue reads `off-runtime-divergent`, not `missing`.
+- Does NOT touch `evidenceEligible` / the #1157 revival path — strictly the lock
+  gate. No double-fire with the existing same-host stale reclaim (that path is
+  unchanged; this is the foreign-host branch only).
+
+## 6. External surfaces
+- New config key `monitoring.resumeQueue.autoHealStaleHostLock` (fleet default
+  false). No new route. `GET /guards` and `GET /sessions/resume-queue` gain a
+  truthful disabled-state read; no schema break (additive).
+- CLAUDE.md template + migrator add one awareness bullet (new + deployed agents).
+- No external network/timing dependence beyond a single bounded (3000ms) `df -P`
+  at lock-acquisition.
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+MACHINE-LOCAL BY DESIGN, and that is the whole point: the resume-queue lock + its
+state dir are deliberately host-local (a shared volume across two hosts is
+unsupported — the invariant this change PROTECTS). The fix makes the host-local
+assumption ROBUST to a rename of the SAME machine without ever weakening the
+cross-host protection (a genuine foreign live host still disables). guardStatus is
+read per-machine; each machine's `/guards` reports its own queue. No replication
+needed or wanted (a lock is intrinsically local).
+
+## 8. Rollback cost
+Cheap and immediate. `monitoring.resumeQueue.autoHealStaleHostLock:false` (the
+fleet default) fully disables the new auto-heal — reverting to today's
+disable-on-mismatch behavior — with no restart-data implications (config read at
+queue construction; next server start picks it up). The guard-posture surfacing is
+inert when the queue is healthy and harmless when disabled (it only reads state).
+No migration, no data repair. The constitutional-standard doc + CLAUDE.md lines are
+documentation (no runtime surface).
+
+## Test coverage (Testing Integrity)
+- Unit: `resume-queue-autoheal-lock.test.ts` — FD1 truth-table; auto-heal on
+  provable rename; stays-disabled on non-local FS / live pid / fresh heartbeat;
+  dryRun no-rewrite; auto-heal-off preserves original behavior; guardStatus.
+- Integration: `resume-queue-guard-posture.test.ts` — a runtime-disabled queue
+  classifies `off-runtime-divergent` through the real GUARD_MANIFEST entry +
+  `deriveGuardRow` (the route's path); a healthy queue does not.
+- E2E: the existing `tests/e2e/resume-idle-autonomous-lifecycle.test.ts` exercises
+  the queue alive end-to-end; this change is additive and those pass. (A dedicated
+  boot-with-stale-lock E2E is a candidate enhancement; the unit+integration tiers
+  cover the new logic and its wiring.)
+- Regression: full resume-queue unit + route suite (100 tests) green; tsc clean;
+  lint-guard-manifest clean.
+
+## Second-pass review
+**Concur with the review.** Independent Phase-5 audit (guard/recovery path) verified, citing code:
+1. Auto-heal can NEVER fire on a genuine shared volume with a live remote holder — `fsLocal` is dispositive and `&&`-short-circuits before any pid probe; `df -P` on a network mount never reports `/dev/*`.
+2. The HARD INVARIANT (never pid-probe a foreign lock) is preserved when auto-heal is OFF (the fleet default) — all probing is gated behind `if (this.cfg.autoHealStaleHostLock)`; the existing invariant test (default config) still asserts `probed===false`.
+3. `takeOverLockAtomic` O_EXCL first-writer-wins is correct; the only residual is the documented narrow double-boot unlink window, backstopped by the next-acquire live-pid+heartbeat check — transient/self-correcting, never durable corruption.
+4. Signal-vs-Authority compliant — the only authority is the queue refusing to start itself (bounded self-recovery, fail-closed); `guardStatus()` is a pure signal producer.
+5. No common-path regression — a healthy boot never enters the foreign-host branch and never calls `df`.
+Verdict: sound, fail-closed in the right direction, well-tested on both sides of every decision boundary, safely gated.