kagan-sh · aorumbayev · Jul 11, 2026 · Jul 10, 2026 · Jul 10, 2026 · Jul 10, 2026
diff --git a/.githooks/pre-commit b/.githooks/pre-commit
@@ -1,6 +1,3 @@
 #!/bin/sh
 set -e
-# git exports GIT_DIR/GIT_INDEX_FILE into hooks (always, in linked worktrees),
-# which hijacks the real-git test repos the suite creates under tmpdir.
-unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE GIT_OBJECT_DIRECTORY GIT_COMMON_DIR GIT_PREFIX
-bun run verify
+bun run verify -- --check
diff --git a/.github/workflows/check.yml b/.github/workflows/check.yml
@@ -1,8 +1,6 @@
 name: check
 
 on:
-  push:
-    branches: [main]
   pull_request:
 
 permissions:

diff --git a/.specs/kagan-supervision-board/design.md b/.specs/kagan-supervision-board/design.md
@@ -218,14 +218,17 @@ commands are ignored.
 `@latest` resolve npm `latest`; exact pins and file installs return before network access. A newer
 clean release is classified only after its manifest supplies a valid `engines.opencode` range.
 Compatible latest is prepared exactly through `api.plugins.add`, which independently performs the
-host compatibility check and imports the package without activating a duplicate `kagan` plugin id.
-The manager proves that the current and prepared targets are non-symlinked
+host compatibility check and imports the package without activating a duplicate `kagan` plugin id
+(the host dedupes by module id).
+The manager verifies that the current and prepared targets are valid
 `opencode/packages/@kagan-sh/kagan@…/node_modules/@kagan-sh/kagan` wrappers before writing one
 sibling marker. Its disposal callback renames current to one backup, promotes prepared to
-`kagan@latest`, and restores current if promotion fails. The next successful load of the marker's
-version removes only that validated backup and marker. Ready/blocked status is a dedicated store
-signal: home/session routes receive one host toast, while the board renders persistent footer text
-and never consumes Notice capacity.
+`kagan@latest`, and restores current if promotion fails in-process. If promotion was interrupted by
+process exit, the host re-downloads `latest` on the next launch (requiring network) and Kagan's
+cleanup then removes the leftover backup, marker, and prepared directory. The next successful load
+of the marker's version removes only that validated backup and marker. Ready/blocked/broken status is a dedicated store signal: home/session routes
+receive one host toast for ready/blocked, while the board renders persistent footer text and never
+consumes Notice capacity.
 
 ## Configuration
 

diff --git a/.specs/kagan-supervision-board/requirements.md b/.specs/kagan-supervision-board/requirements.md
@@ -483,8 +483,9 @@ me when OpenCode blocks one, so that updating requires only a restart and no com
 6. IF Kagan was loaded from an exact npm pin or a local/file source THEN Kagan SHALL NOT query npm,
    prepare a release, or mutate its wrapper.
 7. IF a registry request, manifest validation, download, import, or cache-path validation fails THEN
-   Kagan SHALL remain quiet and SHALL leave the current wrapper unchanged.
-8. WHEN promotion of the prepared wrapper fails after the current wrapper was moved to backup THEN
-   Kagan SHALL restore the current wrapper immediately.
+   Kagan SHALL leave the current wrapper unchanged; WHEN cleanup or preparation fails due to local cache
+   state THEN Kagan SHALL persistently show that automatic updates are unavailable on the board
+   footer.
+8. WHEN promotion of the prepared wrapper fails in-process after the current wrapper was moved to backup THEN Kagan SHALL restore the current wrapper immediately; WHEN promotion was interrupted by process exit THEN the host SHALL re-download `latest` on the next launch (requiring network) and Kagan's cleanup SHALL then remove the leftover backup, marker, and prepared directory.
 9. WHEN the prepared version loads successfully after restart THEN Kagan SHALL remove its validated
    backup and marker without deleting any broader OpenCode cache path.
diff --git a/AGENTS.md b/AGENTS.md
@@ -9,10 +9,11 @@ spec authority and read order. `src/domain/task/metadata.ts` is the authoritativ
 - Use Bun 1.3 or newer; CI pins 1.3.14. Run `bun install`, then `bun run setup` once after cloning to
   enable the `.githooks/pre-commit` hook.
 - `bun run verify` is the merge gate and the exact CI command. It runs all built-in `verifyx`
-  checks, project overrides, tests, and package validation in parallel. Local runs fix formatting;
-  CI only checks it.
-- Run one project check with `bun run verify:format`, `bun run verify:lint`,
-  `bun run verify:check-types`, or `bun run verify:package`.
+  checks (lint, format, type-check, unused-code, circular-deps, duplicate-code, and native gates),
+  project overrides, tests, and package validation in parallel. Local pre-commit runs check-only via
+  `bun run verify -- --check`; CI runs the same gate under `CI`, which also selects check-only.
+- Run one built-in check with `bunx verifyx lint`, `bunx verifyx check-types`, or `bunx verifyx duplicate-code`.
+  Use `bun run verify:format` or `bun run verify:package` for project checks.
 - Run the full suite with `bun run test`, not bare `bun test`. The script supplies
   `--conditions browser`; `bunfig.toml` supplies the Solid preload. Bun positional test filters can
   also match a local gitignored `references/` checkout because its exclude applies only to test

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -32,8 +32,10 @@ update checks; only a published bare/`@latest` npm install exercises that path.
 bun run verify
 ```
 
-This runs every built-in `verifyx` check plus formatting, linting, type-checking, tests, build, and
-package validation — the exact same thing CI runs. If it passes, your change is ready. One helper:
+This runs every built-in `verifyx` check (including unused-code, circular-deps, and duplicate-code)
+plus formatting, linting, type-checking, tests, build, and package validation — the exact same
+thing CI runs. The pre-commit hook runs `bun run verify -- --check` so it fails on dirty staged
+content instead of rewriting files mid-commit. If it passes, your change is ready. One helper:
 
 - `bun run test` — just the tests (use this, not a bare `bun test`).