instar 1.3.143 → 1.3.145

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-05-31T04:44:08.984Z",
-  "instarVersion": "1.3.143",
+  "generatedAt": "2026-05-31T05:20:35.246Z",
+  "instarVersion": "1.3.145",
   "entryCount": 193,
   "entries": {
     "hook:session-start": {
@@ -11,7 +11,7 @@
       "domain": "identity",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/session-start.sh",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "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": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "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": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "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": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "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": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "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": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:post-action-reflection": {
@@ -65,7 +65,7 @@
       "domain": "evolution",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/post-action-reflection.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:external-communication-guard": {
@@ -74,7 +74,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/external-communication-guard.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:scope-coherence-collector": {
@@ -83,7 +83,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/scope-coherence-collector.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:scope-coherence-checkpoint": {
@@ -92,7 +92,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/scope-coherence-checkpoint.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:free-text-guard": {
@@ -101,7 +101,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/free-text-guard.sh",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:claim-intercept": {
@@ -110,7 +110,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/claim-intercept.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:claim-intercept-response": {
@@ -119,7 +119,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/claim-intercept-response.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:stop-gate-router": {
@@ -128,7 +128,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/stop-gate-router.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "hook:auto-approve-permissions": {
@@ -137,7 +137,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/auto-approve-permissions.js",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "job:health-check": {
@@ -1489,7 +1489,7 @@
       "type": "subsystem",
       "domain": "updates",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
-      "contentHash": "41126b695ee560ee55679931cb2ab2f98e0b2bcdce2195d6cfaf57ef395a3cd4",
+      "contentHash": "670633a7fa7c3dbb761a454ff75d87c85aaff82eae0fcc824f15011be032705b",
       "since": "2025-01-01"
     },
     "subsystem:scheduler": {
@@ -1521,7 +1521,7 @@
       "type": "subsystem",
       "domain": "communication",
       "sourcePath": "src/lifeline/TelegramLifeline.ts",
-      "contentHash": "03f9fc147f3e520e114e32df64fe6ba2a69f58664c3cb94f495532d47f5bcded",
+      "contentHash": "6105f8a126654011c81e900be2c049ff52dc1b9b369831432ad910a9650dc84e",
       "since": "2025-01-01"
     },
     "subsystem:orphan-process-reaper": {

package/upgrades/1.3.144.md

@@ -0,0 +1,53 @@
+# Upgrade Guide — vNEXT
+
+<!-- bump: patch -->
+
+## What Changed
+
+**Agent hard-sleep can now actually stop and wake the server (dark + dry-run).**
+The previous step taught an idle agent how to DECIDE whether it is safe to sleep but
+never acted. This step builds the mechanism that acts on that decision: when sleep is
+enabled and the agent is deeply idle and safe, its heavy background server is
+stopped to save the machine's resources, and it wakes the instant a message arrives.
+
+The handshake reuses the proven restart lifecycle: the decision layer writes a
+sleep-request file, the supervisor stops the server and marks it intentionally
+asleep (so it is NOT treated as a crash and is NOT auto-restarted), and an inbound
+message makes the lifeline write a wake-request that the supervisor honors by
+respawning the server. The waiting message is held in the existing durable queue and
+delivered once the server is healthy, so nothing is lost. A safety marker means that
+even if an outside watchdog force-restarts the agent mid-sleep, it reads the marker
+on startup and stays asleep instead of fighting it. The existing crash-recovery
+behavior is unchanged except in the one case where the agent chose to sleep, proven
+by the existing supervisor tests staying green.
+
+## What to Tell Your User
+
+Nothing changes on any normal agent — this ships off by default, and the file that
+triggers a sleep is only ever written when sleep is explicitly turned on. The future
+ability it builds toward: a completely idle agent quiets its server to save your
+machine, then wakes the moment you message it, holding your message until it is back
+up. Turning it on is a deliberate step we would validate on one test agent first.
+
+## Summary of New Capabilities
+
+- ServerSupervisor honors a sleep-request by stopping the server and entering an
+  intentionally-asleep state that suppresses auto-respawn; honors a wake-request by
+  respawning. A slept-marker keeps a rebooted (or watchdog-bounced) supervisor asleep.
+- The decision layer writes a TTL-stamped sleep-request only in live mode.
+- The lifeline writes a wake-request on the next inbound message when the server is
+  asleep; the existing forward-retry queue replays the held message after wake.
+- All gated by the existing monitoring.agentSleep config — OFF + dry-run by default.
+
+## Evidence
+
+- `tests/unit/ServerSupervisor-sleep-wake.test.ts` — sleep stops + marks + enters
+  slept; no-request no-op; expired-request ignored; wake respawns + clears; wake-when-
+  not-slept no-op; idempotent re-sleep; boot-marker signal.
+- `tests/unit/agentSleepWake.test.ts` — marker present writes the wake-request; no
+  marker is a no-op (steady-state awake never writes).
+- `tests/unit/SleepController.test.ts` — sleepRequestWriter writes the TTL-stamped flag.
+- Regression: the existing ServerSupervisor-handshake / supervisor-health-check /
+  supervisor-cpu-starvation suites stay green — the slept short-circuit is the only
+  loop-flow change and is a no-op until a live sleep-request is honored.
+- Side-effects: `upgrades/side-effects/agent-hard-sleep-mechanism.md`.

package/upgrades/1.3.145.md

@@ -0,0 +1,54 @@
+---
+review-convergence: complete
+approved: true
+approved-by: echo (standing 12h deploy mandate, topic 13435; live-test-found bug blocking #28 enablement — Justin watching)
+---
+
+# Upgrade Guide — vNEXT
+
+<!-- bump: patch -->
+
+## What Changed — codex autonomous-loop Stop hook no longer fails on approve (stdout must be JSON)
+
+Live-test finding (2026-05-31): when the codex autonomous-loop driver (#28) flag is on and a
+codex session reaches a terminal stop (e.g. it finished the task and met its completion
+promise), the shared `autonomous-stop-hook.sh` printed a human-readable approve message
+("✅ Autonomous mode: Completion promise detected…") to **stdout**. Codex treats ANY non-JSON
+on a Stop hook's stdout as a failure and logged "Stop hook (failed) — invalid stop hook JSON
+output" on every such stop. The unit test missed it because it only exercised the flag-on path
+WITH an active job that BLOCKS (the one path that legitimately prints JSON) — never an
+approve/exit path.
+
+The fix: in codex mode the hook routes all human-facing approve/status text to **stderr**
+(new `emit()` helper); the only thing it ever writes to stdout is the `{"decision":"block"…}`
+JSON. Claude behavior is unchanged (it still surfaces those messages on stdout to the user).
+
+## Summary of New Capabilities
+
+- `emit()` in `autonomous-stop-hook.sh`: codex mode → stderr, Claude mode → stdout. Applied to
+  the duration-expired, emergency-stop, completion-condition, and completion-promise approve
+  paths (the 4 places that wrote plain text to stdout).
+- Migration marker bumped `CODEX_LOOP_ENABLED` → `codex-stdout-json-safe` so existing #28
+  installs (which already carry `CODEX_LOOP_ENABLED`) re-deploy the FIXED hook. Customized
+  hooks (no stock fingerprint) are still left untouched.
+
+## What to Tell Your User
+
+If you run a codex agent with the autonomous-loop driver turned on, it will no longer log a
+failed Stop hook when a run finishes — the hook now keeps its codex output strictly to the
+machine-readable form codex expects. Nothing to configure.
+
+## Evidence
+
+- Repro (live): a codex session completed a 3-step task, hit its completion promise, and the
+  pane showed "Stop hook (failed) — error: hook returned invalid stop hook JSON output".
+- Fix: `emit()` routes approve/status text to stderr in codex mode; stdout carries only the
+  block-decision JSON.
+- Regression test: `tests/unit/autonomous-stop-hook-codex-gate.test.ts` — codex approve-path
+  (emergency stop) emits NO non-JSON to stdout; Claude approve-path STILL writes it to stdout
+  (both sides; 6 tests pass).
+- Migration parity: `tests/unit/PostUpdateMigrator-autonomousStopHook.test.ts` (7 tests pass);
+  marker bump re-deploys the fixed hook to existing codex agents.
+- `tsc --noEmit` + `npm run lint` clean.
+- Spec: `docs/specs/codex-stop-hook-stdout-json-safe.md` (+ `.eli16.md`).
+- Side-effects: `upgrades/side-effects/codex-stop-hook-stdout-json-safe.md`.

package/upgrades/side-effects/agent-hard-sleep-mechanism.md

@@ -0,0 +1,115 @@
+# Side-Effects Review — Agent hard-sleep stop+wake mechanism (Stage B, slice 2)
+
+**Version / slug:** `agent-hard-sleep-mechanism`
+**Date:** `2026-05-31`
+**Author:** `echo`
+**Second-pass reviewer:** `adversarial review performed — found a critical brick (wake-trigger gated on health) + a broken manual escape hatch; BOTH fixed + tested before commit. Concurs the dark code is inert. Enablement remains the reviewed gate (live on a test agent with Justin watching).`
+
+## Summary of the change
+
+Acts on the slice-1 SleepController verdict: in live mode it writes
+`state/sleep-requested.json`; the ServerSupervisor honors it by stopping the server
+tmux session and entering a `slept` state; the health loop then short-circuits
+(suppressing auto-respawn) and only watches for `state/wake-requested.json`, which
+the TelegramLifeline writes on the next inbound message → the supervisor respawns
+the server and the existing forward-retry queue replays the buffered message. Files:
+`SleepController.ts` (+`sleepRequestWriter`), `ServerSupervisor.ts`
+(checkSleepRequest/checkWakeRequest/`slept` guard/boot-marker), `TelegramLifeline.ts`
+(+`requestWakeIfSlept` via the pure `agentSleepWake.ts` helper). No new config (the
+slice-1 `monitoring.agentSleep` gates it), no new route, no agent-installed file.
+
+## Decision-point inventory
+
+- `ServerSupervisor` health-loop control flow — modify — adds ONE short-circuit: `if (slept) { checkWakeRequest(); return; }` at the loop top.
+- `ServerSupervisor.checkSleepRequest` / `checkWakeRequest` — add — the stop/respawn handlers (mirror checkRestartRequest).
+- `ServerSupervisor` boot — modify — reads `slept-marker.json` to stay asleep across a supervisor reboot.
+- `SleepController.requestSleep` consumer — add — `sleepRequestWriter` (live-mode only).
+- `TelegramLifeline.forwardToServer` — pass-through — prepends a non-blocking `requestWakeIfSlept()` side-call.
+
+---
+
+## 1. Over-block
+
+No block/allow surface over messages. The only "blocking-like" behavior is the
+`slept` short-circuit suppressing auto-respawn — which is exactly intended and gated
+on `slept`, set only after a live sleep-request is honored. A genuine crash (slept
+=== false) still flows through the unchanged `evaluateUnhealthyServer` path.
+
+## 2. Under-block
+
+Could the server fail to wake (the brick risk)? **The adversarial second-pass review
+caught a real brick in the first cut and it was fixed:** the wake-trigger was
+originally placed inside `forwardToServer()`, which is gated on `supervisor.healthy`
+— but a slept server is not healthy, so an inbound message took the "server down →
+queue" path and never wrote `wake-requested.json` → the server would never wake.
+**Fix:** `requestWakeIfSlept()` now runs at the TOP of `processUpdate()`, before any
+health gate, so EVERY inbound update writes the wake flag when slept (covered by the
+helper test + the corrected call-site). The review also caught that `/lifeline
+restart` (the manual escape hatch) didn't clear the slept-marker, so a manual restart
+re-read the marker and re-slept — **fixed** via `ServerSupervisor.wakeFromSleep()`,
+called from both `/lifeline restart` and `/lifeline reset` (tested).
+
+Remaining wake robustness: the supervisor checks the wake flag every 10s while slept;
+a single missed flag write self-heals on the next inbound; a fleet-watchdog mid-sleep
+bounce stays asleep via the boot-marker AND wakes on the next inbound. The
+scheduler-wake (a cron job due during sleep) is the one tracked gap (conservative-null
+for now), enablement-gated — dark default means no real agent is affected.
+
+## 3. Level-of-abstraction fit
+
+Correct. The mechanism reuses the proven `restart-requested.json` lifecycle shape
+(file flag consumed in the health loop) rather than inventing a new lifecycle; the
+stop is the existing tmux `kill-session`, the wake is the existing `spawnServer()`.
+The lifeline wake-trigger is extracted into a pure, unit-tested helper
+(`writeWakeRequestIfSlept`) rather than buried in the un-testable heavy class.
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+- [x] No — the SleepController remains the decision-maker (signal, with all guards);
+  this slice is the mechanism it drives. The stop IS an authority (stops a process),
+  but it is gated exactly like a planned restart: positive proof (the slice-1
+  would-sleep verdict with every guard), ships OFF + dry-run, never fires unless
+  enabled && !dryRun, and KEEPs-awake on any ambiguity upstream.
+
+## 5. Interactions
+
+- **Shadowing:** the `slept` short-circuit runs before the health/restart logic; it
+  is a no-op when `slept===false` (always, until a live sleep-request lands), so it
+  cannot shadow the existing restart/health paths in normal operation. Verified by
+  the unchanged `ServerSupervisor-handshake` + `supervisor-health-check` suites.
+- **Double-fire:** sleep is idempotent (`checkSleepRequest` early-returns when
+  already slept); wake is idempotent (early-returns when not slept). The
+  `sleep-requested`/`wake-requested` flags are consumed on read.
+- **Races:** the fleet watchdog vs sleep — resolved by the boot-marker (reboot stays
+  asleep). The lifeline writing a wake flag while the supervisor is mid-respawn —
+  harmless (the supervisor clears `slept` first, so a redundant wake flag is consumed
+  next tick as a no-op).
+- **Feedback loops:** none — the flags are one-shot, consumed by the consumer.
+
+## 6. External surfaces
+
+- **Install base:** pure additive source, no config/route/agent-installed-file
+  change → every agent picks it up on update; behavior is byte-identical until
+  `monitoring.agentSleep` is enabled live. The slice-1 dark default holds.
+- **Other agents / external systems:** none.
+- **Persistent state:** three transient `state/*.json` flags + one `slept-marker.json`
+  (best-effort, consumed/removed by the supervisor).
+- **Timing:** the existing 10s health tick; no new timer.
+
+## 7. Rollback cost
+
+Pure additive code, no config/migration. Revert → `checkSleepRequest` /
+`checkWakeRequest` / the `slept` guard / the lifeline side-call disappear; the
+supervisor + lifeline behave exactly as before. No persistent state needs cleanup
+(the flags are transient). No user-visible change during rollback (dark by default).
+
+## Conclusion
+
+This review confirmed the mechanism is a tightly-scoped, additive layer on the
+proven restart lifecycle, with ONE load-bearing change (the `slept` short-circuit)
+that is a no-op until a live sleep-request is honored and is regression-covered by
+the existing supervisor suites. The brick risk is closed at multiple layers
+(per-forward wake re-write, 10s wake poll, boot-stay-asleep marker). It ships dark;
+the enablement (turning sleep ON) is the reviewed validation step on a test agent.

package/upgrades/side-effects/codex-stop-hook-stdout-json-safe.md

@@ -0,0 +1,40 @@
+# Side-effects — codex Stop hook stdout JSON-safe (emit())
+
+## 1. What files/state does this change touch at runtime?
+The shared `.claude/skills/autonomous/hooks/autonomous-stop-hook.sh` (a built-in skill hook).
+On update, `migrateAutonomousStopHookTopicKeyed` re-writes the deployed copy for stock agents.
+No config keys, no new files, no new state.
+
+## 2. Does it change any decision (block vs approve)?
+No. The hook's keep-going-vs-stop logic is untouched. Only the CHANNEL of human-facing
+approve/status text changes, and only in codex mode (stdout → stderr). The block-decision JSON
+is unchanged and still on stdout.
+
+## 3. Does it affect the Claude path?
+No — Claude behavior is byte-for-byte preserved (approve messages still print to stdout). A
+dedicated test asserts the Claude approve-path still writes "Emergency stop detected" to stdout.
+
+## 4. Migration parity — do existing agents get it?
+Yes — that's the point. The marker is bumped `CODEX_LOOP_ENABLED` → `codex-stdout-json-safe`,
+so every existing #28 install re-deploys the fixed hook on its next update (the old marker
+would have skipped them since they already carry it). Customized hooks (no stock fingerprint)
+are left untouched. Idempotent (re-running sees the new marker → skips). Covered by 7 migration
+tests.
+
+## 5. Could it spam / flood / burn resources?
+No. The change is a stdout→stderr redirect of a few echo lines in approve paths. No loops, no
+network, no new process, no message send.
+
+## 6. Rollback / off-switch?
+The #28 driver itself remains flag-gated (`autonomousSessions.codexLoopDriver`, default off) —
+this fix just makes the hook safe to run when that flag IS on. Reverting this PR restores the
+prior hook (and the bug); no residual state. The fix is inert for Claude agents and for codex
+agents with the flag off (they hit the early `exit 0` dark-gate before any approve path).
+
+## 7. Concurrency / ordering?
+None — the hook is a short-lived per-stop process; no shared state introduced.
+
+## Blast radius
+Minimal + targeted. One built-in hook script (4 approve paths: stdout→stderr in codex mode) +
+one migration-marker bump + test coverage. No runtime route, sentinel, schema, or decision
+path changes. Unblocks safe enablement of the already-shipped (dark) #28 driver.