@event4u/agent-config 9.7.0 → 9.9.0

package/docs/decisions/ADR-113-ci-native-release-label-trigger.md

@@ -1,201 +0,0 @@
----
-adr: 113
-status: accepted
-date: 2026-07-08
-decision: ci-native-release-label-trigger
-supersedes: —
-superseded_by: —
-phase: road-to-ci-native-release · Phase 1
----
-
-# ADR-113 — CI-native release path, triggered by a `release` label on a merged PR
-
-## Status
-
-**Accepted** · 2026-07-08.
-
-## Context
-
-`task release` (`src/scripts/release.ts`) is a fully interactive, local
-9-step pipeline: preflight → plan → confirm → branch+bump → commit/push+PR →
-wait for CI → merge → tag → GitHub Release. The back half is already CI
-(`publish-npm.yml`, `cloud-release.yml`, `release-guard.yml` all trigger on
-the pushed numeric tag), but a maintainer must run the front half from a
-terminal. This ADR adds an unattended, CI-native entry point alongside
-`task release` — not a replacement.
-
-## Decision
-
-1. **Trigger: a `release` / `release:major` / `release:minor` /
-   `release:patch` label on a PR, checked at merge time**
-   (`pull_request: types: [closed]`, job-guarded on `merged == true` +
-   an exact label match). `release` auto-detects the bump from
-   Conventional Commits since the last tag (same logic `task release`
-   uses); the `release:*` variants force the bump. `workflow_dispatch`
-   (with `bump` / `version` / `dry_run` / `resume` inputs) is the
-   manual/recovery entry for a release not tied to a PR merge.
-
-2. **The numeric `X.Y.Z` tag stays the pipeline's *output*, never its
-   input.** `publish-npm.yml`, `cloud-release.yml`, and
-   `release-guard.yml` all trigger on `push: tags:
-   [0-9]+.[0-9]+.[0-9]+` and assume the tagged commit already carries
-   the bumped `package.json` / `marketplace.json` / regenerated
-   projections. A tag-shaped trigger (hand-pushed numeric tag, or a
-   `cut-*` intent tag) was considered and rejected — see Alternatives.
-
-3. **One orchestration workflow (`release.yml`), not a prepare/finalize
-   split.** GitHub's `GITHUB_TOKEN` recursion guard means events caused
-   by the default token do not start new workflow runs (with narrow,
-   documented exceptions — see the bot-PR finding below). A
-   bot-auto-merged release PR would never trigger a separate
-   merge-listening "finalize" workflow. `release.yml` instead runs the
-   whole chain synchronously in one job, calling
-   `src/scripts/release.ts --ci` end-to-end — the exact same pipeline
-   `task release` runs locally, just non-interactively.
-
-4. **`release.ts` gains a `--ci` mode, not a rewrite.** `--ci` changes
-   exactly three things relative to the existing interactive path:
-   - the `gh`-auth preflight probe (`gh api repos/{slug} --jq .id`
-     instead of `gh api user --jq .login` — the default `GITHUB_TOKEN`
-     is an installation token and `gh api user` returns 403 for it even
-     when perfectly valid);
-   - a `nothing_to_release_ci` short-circuit (empty commits + no
-     explicit bump/version override → exit 0) so firing the label path
-     twice in a row is a clean no-op, not a spurious empty release;
-   - explicit post-release dispatch of `release-guard.yml`,
-     `publish-npm.yml`, and `cloud-release.yml` via their `tag` input,
-     because a `GITHUB_TOKEN`-pushed tag does not fire their
-     `push: tags:` trigger either.
-
-   Every other code path (bump inference, changelog-era rendering, the
-   10-step `execute()` sequence, all idempotent-resume probes) is
-   shared, unmodified, between `task release` and `release.yml`.
-
-5. **Token: `secrets.RELEASE_PR_TOKEN` with a `GITHUB_TOKEN` fallback.**
-   `release.yml` uses `${{ secrets.RELEASE_PR_TOKEN || secrets.GITHUB_TOKEN
-   }}` for checkout, git push, and `gh` auth. See the bot-PR-approval
-   finding below for why this matters and why the fallback is safe to
-   ship without the secret configured.
-
-## Finding — bot-created PRs need a manual "Approve workflows to run" click (no PAT)
-
-Verified against GitHub's own changelog and community docs (2026-06-11,
-["Bot-created pull requests can run workflows if
-approved"](https://github.blog/changelog/2026-06-11-bot-created-pull-requests-can-run-workflows-if-approved/)):
-when a workflow uses the default `GITHUB_TOKEN` to open or update a PR,
-the resulting `pull_request` events (`opened` / `synchronize` /
-`reopened`) DO create workflow runs for other `pull_request`-triggered
-workflows — but those runs sit in an **approval-required** state until a
-repo collaborator with write access clicks **Approve workflows to run**
-in the PR's merge box. This is a deliberate GitHub security control
-(distinct from, but related to, the fork-first-time-contributor approval
-gate), not a bug in this design.
-
-This repo's branch-protection ruleset (verified live via `gh api
-repos/event4u-app/agent-config/rulesets/17749383`) requires
-**zero** approving reviews (`required_approving_review_count: 0`) and
-exactly **one** required status check, `Sync + Generate Tools
-Consistency` (from `consistency.yml`, `pull_request`-triggered). That
-check does not run automatically on a `GITHUB_TOKEN`-opened release PR
-without the one-time approval click — so without `RELEASE_PR_TOKEN`, a
-release via the label path pauses at "waiting for checks" until a
-maintainer approves the run once per release.
-
-**Accepted as the default**, not worked around, because:
-
-- It requires zero new secrets and zero change to repo-wide security
-  settings (disabling the org-wide first-time-contributor approval
-  setting would lower security posture for every fork/bot PR, not just
-  release PRs — out of proportion to this problem).
-- A release is a production action; per this repo's own engineering
-  safety floor (`engineering-safety-floor` rule) and Hard-Floor stance
-  on deploys, a single human checkpoint before a release's own CI even
-  runs is arguably a feature, not friction.
-- `RELEASE_PR_TOKEN` (a fine-grained PAT or GitHub App installation
-  token with `contents: write` + `pull-requests: write` on this repo)
-  removes the approval requirement entirely — documented as the
-  zero-friction upgrade path in `release.yml`'s header comment. Adding
-  it is a maintainer action, not part of this ADR.
-
-## Verified facts (not assumed)
-
-- Branch protection ruleset `main protection` (id `17749383`):
-  `required_approving_review_count: 0`; required check =
-  `Sync + Generate Tools Consistency`; `bypass_actors` includes a
-  repository-role bypass. No human-review gate blocks a bot merge once
-  checks are green.
-- `consistency.yml` triggers on `pull_request` with path filters that
-  match every file a release PR touches (`package.json`,
-  `.claude-plugin/marketplace.json`, `CHANGELOG.md`, `dist/agent-src/**`,
-  `.augment/**`) — the required check fires (subject to the approval
-  gate above), it is not silently skipped.
-- No `RELEASE_PR_TOKEN`-shaped secret exists in the repo today (`gh
-  secret list`) — the fallback path is the one that ships by default.
-- `softprops/action-gh-release@v2`'s `overwrite_files` input defaults to
-  `true` — re-attaching the same-named cloud-release assets on a
-  dispatch-chain re-run is idempotent by construction, no extra guard
-  needed.
-- `npm publish` hard-rejects re-publishing an existing version — added a
-  `npm view @event4u/agent-config@<tag> version` pre-check to
-  `publish-npm.yml` so a double-dispatch (native tag-push trigger racing
-  the explicit dispatch, when `RELEASE_PR_TOKEN` IS configured) is a
-  clean skip, not a red run.
-
-## Consequences
-
-- Releasing needs exactly one human action: label a PR `release` (or a
-  `release:*` variant) and merge it. Without `RELEASE_PR_TOKEN`, one
-  additional "Approve workflows to run" click is needed once per
-  release on the auto-created release PR.
-- `task release` is unaffected — same script, same flags, same tests.
-  It remains the interactive/local path and the documented fallback if
-  the CI path misbehaves.
-- Three existing workflows (`release-guard.yml`, `publish-npm.yml`)
-  gained a `workflow_dispatch` input / idempotency guard respectively;
-  `cloud-release.yml` needed no change (already idempotent).
-- A future maintainer who configures `RELEASE_PR_TOKEN` gets a fully
-  unattended release with zero code changes required — the fallback
-  expression already prefers it.
-
-## Alternatives considered
-
-- **Hand-pushed numeric tag as the trigger.** Rejected: the tag-triggered
-  workflows require the tagged commit to already carry the bump: a
-  hand-pushed `X.Y.Z` on plain main fires them against the *un-bumped*
-  tree (red `release-guard`, wrong npm tarball), and the tag would then
-  have to be deleted and re-pushed onto the eventual bump-PR merge
-  commit — mutable tags are an anti-pattern (stale fetches, npm
-  provenance binds to the tag commit).
-- **A `cut-*` intent tag** (`cut-X.Y.Z` / `cut-auto` / `cut-major` / …)
-  in a separate namespace from the numeric tags. Functionally workable
-  (does not collide with the publish/guard tag patterns), but the
-  release label keeps the intent visible on the PR itself — reviewable,
-  revocable pre-merge, no second git-tag vocabulary to teach.
-- **`workflow_dispatch` as the sole/primary trigger**, no label. Loses
-  the "the intent to release lives on the PR, and is revocable until
-  merge" property that the label gives for free; kept as the
-  manual/recovery entry, not the primary path.
-- **Prepare + finalize workflow split** (one workflow opens the release
-  PR, a second listens for its merge and finalizes). Needs a
-  `RELEASE_PR_TOKEN`-class token as a *hard* requirement — under plain
-  `GITHUB_TOKEN`, the bot-merged PR's `pull_request: closed` event is
-  the SAME kind of GITHUB_TOKEN-caused event subject to the same
-  approval/recursion nuance, and splitting the pipeline across two
-  workflow boundaries adds a second place idempotency can drift. The
-  single-workflow design collapses this into one synchronous run using
-  the already-battle-tested `execute()` sequence.
-- **Disable the org-wide "require approval for first-time contributors"
-  setting** to remove the bot-PR approval gate without a PAT. Rejected:
-  it is an org-wide security posture change affecting every fork/bot PR
-  in the organization, not scoped to releases — disproportionate to
-  this problem; `RELEASE_PR_TOKEN` is the properly-scoped fix.
-
-## References
-
-- `.github/workflows/release.yml` — the orchestration workflow.
-- `src/scripts/release.ts` — the shared pipeline (`--ci` mode).
-- `docs/contracts/release-pr-gating.md`,
-  `docs/contracts/branch-protection-policy.md` — release-PR shape and
-  required-check contracts this design must keep satisfying.
-- [GitHub Changelog — Bot-created pull requests can run workflows if
-  approved (2026-06-11)](https://github.blog/changelog/2026-06-11-bot-created-pull-requests-can-run-workflows-if-approved/)

package/docs/decisions/ADR-114-commit-policy-iron-law-override.md

@@ -1,85 +0,0 @@
----
-adr: 114
-status: accepted
-date: 2026-07-08
-decision: commit-policy-iron-law-override
-supersedes: —
-superseded_by: —
-phase: kernel-budget overrides (extends ADR-002)
-type: structural
----
-
-# ADR-114 — commit-policy Iron-Law Override (per-rule cap 2.5k → ceiling 4.0k)
-
-- **Status:** Accepted (2026-07-08)
-- **Supersedes:** none — extends the override set locked by
-  [ADR-002](ADR-002-kernel-bucket-overrides.md) under
-  `docs/contracts/kernel-membership.md` § 5.1.
-- **Related:** ADR-002 (kernel-bucket cap raise + the original 6 overrides).
-
-## Context
-
-Commit 259bb1b24 (*feat(commit-policy): one-shot authorization is not a
-standing license*, merged to main 2026-07-07) added a second Iron-Law fence
-to `commit-policy`:
-
-```
-A ONE-OFF AUTHORIZATION IS SPENT ON EXACTLY THAT OPERATION, ONCE.
-IT NEVER BECOMES A STANDING LICENSE FOR LATER COMMITS OR PUSHES.
-EACH FURTHER COMMIT / PUSH NEEDS ITS OWN FRESH, EXPLICIT GO-AHEAD.
-```
-
-plus the prose enumerating which phrasings spend the authorization and the
-canonical failure it prevents. That grew the rule from 2 354 chars (the
-post-ADR-002 trimmed size) to **3 194 chars** — over the 2 500 per-rule hard
-cap, without an entry in `docs/contracts/iron-law-overrides.txt`, so
-`lint-rule-budget` hard-fails on every branch that carries main.
-
-Kernel-bucket state at decision time: **25 393 / 26 000 chars** (9 rules) —
-the bucket cap from ADR-002 still holds with ~600 chars headroom; only the
-per-rule cap is exceeded.
-
-## Decision
-
-1. Add `commit-policy` (3 194 chars) to
-   `docs/contracts/iron-law-overrides.txt` with this ADR as justification.
-   It sits between 2.5k and the 4.0k override ceiling.
-2. The kernel bucket cap (26 000) and the override ceiling (4 000) stay
-   unchanged.
-
-## Rationale
-
-`commit-policy` now carries **three non-externalisable structural
-elements** — the same test ADR-002 applied to the original 6 overrides:
-
-- The primary Iron-Law fence (`NEVER COMMIT. NEVER ASK ABOUT COMMITTING.`)
-  plus the closed 4-exception enumeration — the rule's contract.
-- The new one-shot-authorization fence plus the phrasing enumeration
-  ("commit this", "push it", "open the PR" are spent on exactly that
-  operation). Externalising the enumeration would force a context load on
-  every commit-adjacent turn — i.e. always — defeating the kernel-vs-auto
-  split.
-- The split-into-chunks fence (`COMMIT AUTHORIZED → SPLIT INTO LOGICAL
-  CHUNKS BY DEFAULT`) with its never-ask clauses.
-
-ADR-002 noted commit-policy was trimmable *because* it carried no
-enumeration; 259bb1b24 changed exactly that premise by adding one whose
-misreading (a one-off "commit this" read as standing license) is the
-canonical failure the fence exists to stop.
-
-## Consequences
-
-- **Pro:** `lint-rule-budget` is green again on every branch tracking main;
-  the Iron-Law fences stay byte-preserved in one rule.
-- **Con:** 7 of 9 kernel rules now carry overrides; the 2.5k hard cap
-  disciplines only new/small rules. The 26k bucket (98%+ utilisation
-  headroom per ADR-002) remains the effective backstop.
-- Future commit-policy growth past 4 000 chars is not covered — that would
-  require condensation or an externalisation decision, not another ADR.
-
-## Rollback
-
-Trim the one-shot-authorization prose into
-`contexts/authority/commit-mechanics.md` (keeping only the fence in the
-rule) and remove the allowlist entry — reversible; this ADR does not lock
-that out.

package/docs/decisions/ADR-115-command-cluster-consolidation-phase-4.md

@@ -1,91 +0,0 @@
----
-adr: 115
-status: accepted
-date: 2026-07-08
-decision: command-cluster-consolidation-phase-4
-supersedes: —
-superseded_by: —
-phase: road-to-command-structure-optimization · Phase 0
----
-
-# ADR-115 — Command-cluster consolidation Phase 4 (flat dash commands → nested clusters)
-
-- **Deciders:** maintainer + AI council (anthropic/claude-sonnet-4-5 + openai/gpt-4o, 2-round debate, 2026-07-08)
-
-## Context
-
-After the Phase 1–3 cluster collapses, ~27 flat dash-separated commands
-remained (`bug-fix`, `project-analyze`, `optimize-project`, `quality-fix`, …).
-ADR-044 derives the invoked slug from the physical path by hyphen-joining
-(`fix/ci` → `fix-ci`), which creates a cost asymmetry the earlier phases did
-not exploit: **nesting `bug-fix` as `bug/fix` keeps the invoked slug
-`bug-fix`** — invocation-neutral — while only reorder-moves
-(`quality-fix` → `fix/quality` = `fix-quality`) change the typed name.
-
-## Decision
-
-1. **Nest the remaining coherent families** (council-adopted set):
-   - Extended clusters: `optimize` (+`project`, `prompt`), `fix` (+`quality`),
-     `tests` (+`e2e-plan`, `e2e-heal`), `analyze` (+`reference-repo`).
-   - New clusters: `bug` (fix · investigate), `project` (analyze · health),
-     `review` (changes · routing), `package` (test · reset),
-     `cost` (report · profile), `sync` (agent-settings · gitignore ·
-     gitignore-fix — absorbs the single-sub `sync-gitignore` cluster).
-   - Slug reorders carry `replaces:` aliases: `fix-quality`,
-     `tests-e2e-plan`, `tests-e2e-heal`, `cost-profile`.
-2. **Cluster heads are dispatch menus, not verbs.** ADR-041's controlled-verb
-   allowlist governs the leading token of visible *command slugs* (and the
-   `sub:` head for nested commands). A cluster head named after a noun/scope
-   (`bug`, `project`, `cost`) is a navigation surface — the same shape as the
-   pre-existing `agents`, `memory`, `brand`, `video` heads — and does not add
-   a verb to the allowlist. (Council round 2 explicitly overturned the
-   verb-policy objection on this ground.)
-3. **Co-location rule.** All subs of a cluster live in the same pack directory
-   as the head — slug derivation implies it. Cross-pack members move packs
-   (`optimize-project` eng → meta, `review-routing` meta → eng,
-   `package-test` eng → meta, `sync-gitignore` eng → meta,
-   `analyze-reference-repo` eng → analysis-workbench).
-4. **Bare invocation is deterministic.** Multi-sub head → numbered menu;
-   single-sub head → default-route; documented default-flow exceptions live in
-   the head's `## Dispatch`. Enforced structurally by
-   `scripts/check_cluster_patterns.ts`, which now also resolves every
-   `routes_to:` entry to a real command.
-5. **Tier-0 slugs never change.** Deferred/rejected per council:
-   - `ticket` cluster (implement/estimate/refine/jira) — tier-0
-     `implement-ticket` rename + cross-pack move; revisit with usage
-     telemetry.
-   - `security` cluster — weak cohesion; `security-audit-config` and
-     `threat-model` stay flat.
-   - `prepare-for-review` → `review/prepare` — pre-commit muscle memory.
-   - Demotions (`check-current-md`, `update-form-request-messages`) — need a
-     skill-coverage / pack-boundary audit first.
-
-## Consequences
-
-- 19 commands nested; 15 keep their invoked slug, 4 gain `replaces:` aliases.
-- `review-changes` becomes internal; the advanced surface is the `review`
-  head (eval key moves `review-changes.json` → `review.json`).
-- `lint_no_new_atomic_commands.ts` is repointed from the removed
-  `.agent-src.uncondensed/commands` dir to `src/domains` so the atomic-surface
-  gate has teeth again; the new clusters are registered in the locked table.
-- Consumers invoking old reordered slugs are migrated via `replaces:` +
-  the `migrate` flow; slug-neutral nests need no migration.
-
-## Alternatives considered
-
-- **Colon-namespaced subcommands** — rejected long ago (ADR-044): Claude Code
-  cannot resolve them.
-- **`ticket` cluster now** — rejected by both council members (highest-risk
-  item: tier-0 rename + pack move with unclear ownership).
-- **Keeping `/optimize` agent-layer-only** — council split; maintainer
-  directive adopted the widened scope; the head menu + scope-check rule
-  disambiguates the three scopes.
-
-## References
-
-- `docs/contracts/command-clusters.md` — locked table (Phase 4 rows) + the
-  new "Bare invocation" section.
-- `agents/roadmaps/archive/road-to-command-structure-optimization.md` — inventory,
-  council verdicts, phases.
-- ADR-003 (flat clusters), ADR-041 (controlled verbs), ADR-044 (path-derived
-  hyphen slugs).

package/docs/decisions/ADR-116-memory-tripwire-activation-path.md

@@ -1,144 +0,0 @@
----
-adr: 116
-status: accepted
-date: 2026-07-08
-decision: memory-tripwire-activation-path
-supersedes: —
-superseded_by: —
-phase: road-to-memory-retrieval-economy · Phase 6 (amended — see 2026-07-12 note)
----
-
-# ADR-116 — Memory scale-tripwire activation path: one engine, measured at fire time
-
-> **Amended in practice (recorded 2026-07-12):** the SQLite-FTS5 engine
-> this ADR pre-decided was never built. The activation path was
-> re-resolved by road-to-retrieval-substrate-hardening B2 (done
-> 2026-07-09): a hand-rolled stdlib BM25 + trigram prefilter in
-> `src/scripts/_lib/lexical_index.ts` (no SQLite, ADR-061 honoured),
-> dormant until the `lint_knowledge_scale` tripwire fires (200/type,
-> 500 total). The tripwire thresholds and measurement-at-activation
-> discipline of this ADR stand unchanged; only the engine choice moved.
-
-
-- **Deciders:** maintainer + AI council (anthropic/claude-sonnet-4-5 +
-  openai/gpt-4o; disposition debate 2 rounds + engine tie-break 2 rounds,
-  2026-07-08 — tie-break converged after the in-repo `node:sqlite`
-  precedent was surfaced)
-
-## Context
-
-An external second-opinion review (round 2 of the Obsidian-reference
-comparison) surfaced a real documentation conflict: the memory-scale
-tripwire (>200 files in one memory/knowledge type, or >500 files total —
-guarded by `lint_knowledge_scale.ts`) had **three different pre-decided
-activation paths** across three artifacts, written by two councils one day
-apart:
-
-1. `agents/settings/contexts/second-brain-delta-verdict.md` Q4
-   (2026-07-07): "file-first in-memory BM25 (minisearch-class, re-index at
-   session-start, no persistence)".
-2. `agents/roadmaps/archive/road-to-memory-retrieval-economy.md` Phase 6
-   (2026-07-07/08): "SQLite FTS5 over the memory files … replacing
-   `_score()`'s substring pass".
-3. `docs/decisions/ADR-061-corpus-grounding-layer.md`: "a new domain ships
-   a manifest + data + a named owner — **not a forked engine**", with a
-   tested in-house BM25 (`src/skills/corpus-grounding/scripts/bm25_search.ts`,
-   generic `class BM25` over `Row[]`) as the implied reuse candidate.
-
-The whole point of a pre-decided path is that the tripwire firing needs no
-new debate; in this state, firing would have required one.
-
-Additional evidence for the engine swap (2026-07-10, labelled replay of real
-maintainer queries): `_score()`'s raw-substring match has a
-**separator-recall gap** — hyphen/underscore query keys (`ai_council`,
-`roadmap-progress`, `force-push`) score 0 against space-normalized stored
-keys that spaced variants hit at 0.8. A tokenizing engine (FTS5 unicode61 /
-BM25 tokenizer) splits on separators and closes this class structurally;
-see `docs/second-brain-scope.md` § second named limit for the scoped-out
-claim boundary.
-
-## Decision
-
-1. **One engine: SQLite FTS5 via Node's built-in `node:sqlite`.**
-   - Zero npm dependency — the repo already uses `node:sqlite` in
-     production code (`src/scripts/mcp_telemetry_store.ts` /
-     `mcp_telemetry_query.ts`) with the established pattern: lazy import +
-     runtime guard for Node < 22.5 (`src/scripts/_lib/node_sqlite.d.ts`).
-     `better-sqlite3` and a minisearch dependency are both rejected.
-   - **Persistence economics** decided the tie-break: at tripwire scale the
-     in-memory re-index per session-start is a startup tax that grows with
-     the corpus; FTS5 gives a persisted index plus incremental updates.
-     The in-house `class BM25` lacks a persistence layer; building one
-     (serialization, incremental updates, corruption handling) recreates
-     what SQLite ships.
-   - Index location: `agents/runtime/state/` (gitignored, never tracked).
-   - **Re-index is batch/lazy** — post-session or on first lookup, never
-     inline per write: during active sessions files churn (drafts,
-     rollbacks), and inline indexing would put fsync latency and lock
-     contention inside the write path (council round-2 caveat).
-   - FTS5 availability in the bundled SQLite is verified at implementation
-     time; on absence or Node < 22.5 the runtime guard falls back to the
-     current grep/substring path.
-
-2. **Measurement at activation, no speculative harness.** At today's
-   corpus (~85 auto-memory files / 412 KB) the ranked-retrieval lift over
-   grep is zero by construction — the honest-zero is already recorded in
-   the verdict. No grep-vs-ranked benchmark harness is built now. Instead,
-   the pre-decided path carries a clause: when the tripwire fires, reuse
-   the retrieval-economy Phase-0 replay set to measure the grep baseline
-   vs the FTS5 candidate on the then-current corpus BEFORE building; ship
-   only on measured retrieval lift, else record the honest-null and keep
-   grep.
-
-3. **ADR-061 boundary restated.** Memory lookup is a **Reference**
-   operation in ADR-061's four-operation model — memory is never
-   registered as a grounding corpus ("grounding theater"), and
-   `corpus-grounding`'s engine is not forked per domain. This ADR does not
-   amend ADR-061; it confirms the tripwire path lives outside the
-   grounding layer.
-
-4. **Wording migration.** The verdict Q4 "minisearch-class" sentence and
-   the tripwire-table row are amended in the same change; a grep sweep for
-   `minisearch` / "pre-decided BM25" catches stragglers in stable
-   artifacts.
-
-## Consequences
-
-- Firing the tripwire is now a wiring-plus-measurement task, not a design
-  debate: guard fires → replay-set comparison → on lift, ~30-line
-  `node:sqlite` FTS5 schema + query wrapper replacing `_score()`'s
-  substring pass.
-- No new npm dependency at any point on this path; Layer-2 sunset stands
-  (no vectors, no services, no always-on workers).
-- The rejected review items are recorded here so they are not relitigated:
-  a pre-built grep-vs-ranked harness (speculative — measures a known
-  zero), and a deterministic "next step" hot-context field (feature envy
-  absent a real resume-context gap; the LLM-summary ban from the verdict's
-  REJECT-list is untouched).
-
-## Alternatives
-
-- **In-house `bm25_search.ts` as a library** — rejected in the tie-break:
-  no persistence layer; the "zero new deps" advantage evaporated once
-  `node:sqlite` (also zero-dep) was on the table; retrofitting
-  persistence ≈ 200 LOC of database-shaped code SQLite already provides.
-- **minisearch dependency** (verdict Q4's original wording) — rejected:
-  new npm dependency for a problem the built-in module covers; same
-  missing-persistence shape.
-- **Two-step (in-house now, FTS5 escalation later)** — rejected: a
-  pre-decided path must be single and unambiguous; a conditional two-step
-  re-imports the debate the tripwire exists to avoid.
-- **Pre-building the measurement harness now** — rejected: honest expected
-  lift at the current corpus is zero; the replay set from Phase 0 will
-  exist independently and is reused at fire time.
-
-## References
-
-- `agents/roadmaps/archive/road-to-memory-retrieval-economy.md` § Phase 6 (engine
-  note + measurement-at-activation clause).
-- `agents/settings/contexts/second-brain-delta-verdict.md` Q4 (amended
-  wording + tripwire table).
-- `docs/decisions/ADR-061-corpus-grounding-layer.md` (four-operation
-  model; engine-fork ban).
-- `src/scripts/mcp_telemetry_store.ts`, `src/scripts/_lib/node_sqlite.d.ts`
-  (in-repo `node:sqlite` precedent).

package/docs/decisions/ADR-117-subagents-auto-default-on.md

@@ -1,89 +0,0 @@
----
-adr: 117
-status: accepted
-date: 2026-07-09
-decision: subagents-auto-default-on
-supersedes: —
-superseded_by: —
-phase: auto-subagent-orchestration
-type: structural
-amends: 105 (Decision 2 only — the shipped default; the contract itself stands)
----
-
-# ADR-117 — Flip `subagents.auto` shipped default to `on` (host-gated) on bounded-downside re-evaluation
-
-## Status
-
-**Accepted** · 2026-07-09. Amends ADR-105 Decision 2 ("conservative-until-proven
-shipped default `ask`"). Resolved by a re-evaluation under `decision-revisit-gate`
-plus a deep AI-council round (claude-sonnet-4-5 + gpt-4o, 2026-07-08, 4 rounds).
-
-## Context
-
-ADR-105 shipped `subagents.auto: ask` as the conservative default and gated the
-flip to `on` behind a Phase-6 benchmark. That benchmark was found
-**non-producible** in this package's harness (no runtime executes model
-`Task`/`Agent` tool calls), so the 2026-06-26 verdict
-(`orchestration-default-flip-verdict.md`) took the honest-null branch: keep
-`ask`, re-gate on realized telemetry.
-
-That re-gate was **self-locking**: realized telemetry only accrues when the
-layer is `on`, but `on` was withheld pending telemetry. Meanwhile the package
-evolved:
-
-- **Cost-routing shipped.** `road-to-cost-aware-model-routing` (2026-07-08) landed
-  `inferSliceTier` — delegable slices already run on the cheapest capable tier.
-  The system is not cost-blind; only the default was conservative.
-- **The harness now executes subagents.** Host harnesses (Claude Code) execute
-  `Agent`/`Task` calls, so a directional probe is finally possible.
-
-## Decision
-
-The shipped default for `subagents.auto` is **`on`** on hosts whose capability
-manifest reports `subagent_spawn: true`, and `off` on hosts without a subagent
-primitive. `resolveShippedDefault()` is retained as the telemetry-driven
-**demotion** gate.
-
-This is a **bounded-downside** decision, explicitly **not** a passed rigorous
-benchmark. The basis:
-
-1. **Bounded downside.** `on` auto-dispatches only structurally-signalled,
-   cost-routed, verified slices (per `auto-dispatch-classification`). It cannot
-   delegate unstructured, tiny, or frontier-priced work.
-2. **Directional probe (N=2, real, honest limits).** Two live read-only-fan-out
-   delegations this session (~70k, ~86k Sonnet tokens on real work) → ~80%
-   per-task saving vs the inline-Opus counterfactual, outputs verified usable.
-   Small N, single task-type, arithmetic counterfactual — directional only.
-3. **Reversible + monitored.** A measured telemetry regression demotes back to
-   `ask` via `gateVerdict`/`resolveShippedDefault`.
-
-## Consequences
-
-- On subagent-capable hosts, delegable tasks auto-dispatch without a per-task
-  ask; the choice is surfaced in one line.
-- Realized orchestration telemetry now accrues, breaking the deadlock and
-  feeding the demotion gate.
-- Hosts without `subagent_spawn` are unaffected (`off`, no-op).
-- The delegability floor (`SIZE_FLOOR = 1` in `auto_dispatch.ts`) is unchanged
-  and noted as a follow-up refinement — the structural-signal gate already keeps
-  unstructured/tiny work in-session, so it is not load-bearing for this flip.
-
-## Alternatives
-
-- **Keep `ask`, wait for a rigorous benchmark** — rejected: the benchmark is
-  non-producible here and the telemetry re-gate is deadlocked; this is
-  indefinite inertia, not caution.
-- **Flip `on` universally with no cost-routing / floor argument** — rejected:
-  that is the money-losing "flip on unmeasured claim" the deep council warned
-  against; the bounded-downside basis is what makes this flip responsible.
-- **Per-profile default (`on` only for developer)** — rejected for now: no
-  per-profile-default plumbing exists (would be new code); host-gating already
-  scopes the risk.
-
-## References
-
-- ADR-105 — automatic subagent orchestration (Decision 2 amended here).
-- ADR-109 — subagent-v1 contract; ADR-110 — discipline profile.
-- `agents/settings/contexts/orchestration-default-flip-verdict.md` § 2026-07-09.
-- `src/agent-src/contexts/execution/orchestration-benchmark-gate.md` — demotion gate.
-- `src/agent-src/contexts/execution/auto-dispatch-classification.md` — delegability + cost-routing.