@event4u/agent-config 9.8.0 → 9.10.0

package/docs/decisions/ADR-039-claude-skills-untracked.md

@@ -1,139 +0,0 @@
----
-adr: 039
-status: accepted
-date: 2026-06-01
-decision: claude-skills-untracked
-supersedes: —
-superseded_by: —
-phase: road-to-claude-skills-untrack
-type: structural
-review_date: 2026-06-15
----
-
-# ADR-039 — `.claude/skills/` is untracked; skills resolve from committed canonical sources
-
-## Status
-
-**Accepted** · 2026-06-01. Decision lands **without** soak — all binding
-conditions were verified empirically against a real Claude Code instance
-(v2.1.159) in the same session. Review date 2026-06-15 keeps the revert path
-open; reverting is one `git rm`-reversing commit plus a generator repoint.
-
-## Context
-
-`event4u/agent-config` distributes ~365 skills to Claude Code. Until
-commit `c0e2d897` the package committed `.claude/skills/<name>/SKILL.md`
-(symlinks) and the plugin marketplace (`.claude-plugin/marketplace.json`)
-referenced those committed paths. ADR-030 had established `.claude/skills/`
-as Claude Code's filesystem-channel convention, and the cleanup that
-untracked `.claude/{rules,personas,user-types}/` deliberately **kept**
-`.claude/skills/` tracked, flagging the question for a dedicated
-investigation (`road-to-claude-skills-untrack`).
-
-The question this ADR closes: can the package stop committing
-`.claude/skills/` — so `.claude/` in git reduces to `settings.json` only —
-without breaking skill resolution on any channel?
-
-Three resolution channels exist:
-
-1. **Marketplace plugin** — Claude Code reads `.claude-plugin/marketplace.json`
-   `skills[]` and loads skills from the referenced source paths.
-2. **Consumer filesystem** — `scripts/install.sh` builds `~/.claude/skills/`
-   symlinks at install time.
-3. **Local dev** — `task generate-tools` rebuilds a gitignored local
-   `.claude/skills/` for in-repo auto-discovery.
-
-Commit `c0e2d897` already repointed the marketplace generator (real skills →
-`./.agent-src/skills/<name>` (223), command-as-skill entries →
-`./.claude-plugin/skills/<slug>` (142), both committed), updated
-`lint_marketplace.py` and the pre-commit hook, and gitignored
-`/.claude/skills/`. This ADR is the decision-gate record that the
-investigation reached, backed by a real-instance registration test rather
-than reasoning alone.
-
-## Decision
-
-**`.claude/skills/` stays untracked.** Skills resolve from the committed
-canonical sources (`.agent-src/skills/` + `.claude-plugin/skills/`) for the
-marketplace channel, and from locally-built trees for the consumer and dev
-channels. `.claude/` in git is `settings.json` only.
-
-## Evidence (real Claude Code v2.1.159, this machine)
-
-- **Marketplace manifest validates.** `claude plugin validate
-  .claude-plugin/marketplace.json` → "Validation passed" (sole warning:
-  `metadata.keywords` is ignored at load — cosmetic, see Consequences).
-- **Marketplace registers + installs at runtime.** `claude plugin
-  marketplace add <repo>` → `claude plugin install
-  agent-config@event4u-agent-config` → **enabled**; `claude plugin details`
-  reports **Skills (365)** resolved from `./.agent-src/skills/` (223) +
-  `./.claude-plugin/skills/` (142), with **no committed `.claude/skills/`**.
-- **Runtime execution without a committed tree.** This very session is a live
-  Claude Code runtime in which `git ls-files .claude/skills/` returns `0`
-  yet skills load **and execute** (the `roadmap:process-full` skill was
-  loaded and run from its SKILL.md). Registration → runtime is therefore
-  demonstrated, not inferred, for the filesystem channel.
-- **Consumer filesystem channel.** `scripts/probe_skill_registration.py`
-  shows 365 skills register from user-scope `~/.claude/skills/`, built by
-  `install.sh`, independent of any committed project tree.
-- **Lint green.** `python3 scripts/lint_marketplace.py` → 365 skills, no
-  issues (reverse-completeness scans the two committed sources).
-- **Idempotent regen.** `task generate-tools` produces no tracked diff;
-  `.claude/skills/` stays gitignored (0 tracked files).
-
-## Council convergence
-
-Cross-checked with the AI council (analysis mode, members
-anthropic/claude-sonnet-4-5 + openai/gpt-4o, 2026-06-01). Both members
-converged on a single strongest blind spot: `claude plugin details` proves
-*registration metadata*, not *live runtime execution*, and asked for a live
-session test before closing. That test was then run and is recorded above
-(this session executes skills with zero committed `.claude/skills/`; the
-marketplace plugin was installed + enabled and resolved all 365 skills).
-The council's residual follow-ups are carried into Consequences.
-
-## Consequences
-
-**Positive**
-
-- `.claude/` in git is `settings.json` only — no per-skill-set PR churn from
-  the previously-committed 365 symlinks.
-- Marketplace source paths (`.agent-src/skills/`, `.claude-plugin/skills/`)
-  are **committed**, so marketplace consumers cloning at a tag or with
-  `--depth=1` still resolve every referenced skill — a strict improvement
-  over the old gitignore-adjacent layout.
-
-**Costs / residual risks (from council follow-ups)**
-
-- **Consumer channel depends on `install.sh`.** A consumer who clones the
-  repo but never runs `install.sh` (and never installs the marketplace
-  plugin) gets no `~/.claude/skills/`. This is unchanged from before the
-  untracking and is the documented consumer contract; a CI smoke test
-  (`npm install` → `probe_skill_registration.py` → assert 365) is a sensible
-  follow-up but is out of this ADR's scope.
-- **Channel precedence is undocumented.** When a dev has the repo open
-  (local `.claude/skills/`) *and* the marketplace plugin installed, the
-  precedence of local vs marketplace skills is not formally specified.
-  Day-to-day dev uses the local generate-tools tree; no conflict observed.
-  Follow-up only.
-- **`metadata.keywords` validator warning.** The field holds generic terms
-  (tool names, `php`, `laravel`), not skill names, so it is safe to drop;
-  left in place here to keep this diff minimal (out of scope per
-  `minimal-safe-diff`).
-
-## Alternatives
-
-- **Keep `.claude/skills/` tracked (ADR-030 convention).** Rejected: the
-  registration test shows the convention is satisfied by locally-built and
-  marketplace-resolved trees; committing 365 symlinks adds PR churn with no
-  resolution benefit.
-
-## References
-
-- ADR-030 — Claude Code command-projection strategy (established the
-  `.claude/skills/` filesystem-channel convention this ADR revisits).
-- `scripts/condense.py` — `generate_plugin_command_skills()` emits the
-  `.claude-plugin/skills/<slug>` projection.
-- `scripts/lint_marketplace.py` — reverse-completeness over the two
-  committed sources.
-- `scripts/probe_skill_registration.py` — live install-state probe.

package/docs/decisions/ADR-040-execution-model-projection-time-filtering.md

@@ -1,244 +0,0 @@
----
-adr: 040
-status: accepted
-date: 2026-06-02
-decision: execution-model-projection-time-filtering
-supersedes: —
-superseded_by: —
-phase: v6.0.0 · experience-first rebuild
-type: forward-looking
----
-
-# ADR-040 — Pack-scoped surfacing is projection-time filtering, not a runtime resolver
-
-## Status
-
-**Accepted** · 2026-06-02. Authored as Phase 0 / Step 1 of
-[`road-to-6.0.0-a-positioning-and-validation`](../../agents/roadmaps/road-to-6.0.0-a-positioning-and-validation.md),
-the de-risking front of the experience-first rebuild. It makes the single
-architectural decision the rest of the rebuild
-([`road-to-6.0.0-b-pack-scoped-projection`](../../agents/roadmaps/road-to-6.0.0-b-pack-scoped-projection.md))
-hinges on, **before** any migration code is written. Builds on
-[`ADR-010`](ADR-010-profile-pack-preset-boundary.md) (profile / pack / preset
-boundary), [`ADR-020`](ADR-020-global-only-consumer-scope.md) (global-only
-consumer scope), and [`ADR-016`](ADR-016-installer-architecture.md) (installer
-architecture).
-
-## Context
-
-The external 5.7.0 product review (`agents/tmp/feedback-6.0.0-part1.*`) and the
-first draft of the rebuild plan both described pack-scoped surfacing as a
-**"runtime resolver"** that decides "at runtime" which skills/commands a host
-tool sees. For a package whose entire job is to **project files** into each
-tool's native config tree (`.claude/`, `.cursor/`, `.augment/`, …), that framing
-is architecturally incoherent:
-
-- `agent-config` ships no agent loop, no LLM dispatcher, no daemon, and no
-  request interception. The host tool (Claude Code, Augment, Cursor, Cline,
-  Windsurf, Gemini CLI, Copilot) owns the runtime; the package is a **content
-  layer** (README "What `agent-config` is — and what it isn't").
-- The only mechanism the package controls is **what gets written where** during
-  release (`scripts/build_discovery_manifest.py`) and install / sync
-  (`scripts/install.py` projection of `.agent-src/` into each tool tree).
-- A literal runtime resolver would require a long-lived process between the host
-  tool and the filesystem — exactly the "agent runtime" the package explicitly
-  is **not** (and which `README.md` lists as out of scope).
-
-The AI council (claude-sonnet-4-5 + gpt-4o, 2 rounds + peer-review, 2026-06-02)
-named this the "single most damaging ambiguity" in the rebuild and converged on
-decoding "runtime resolver" as **projection-time filtering**.
-
-Today the projection writes the **full** artefact set regardless of the active
-profile or packs. Profiles (`ADR-010`, six seed profiles) and packs (surface
-caps: commands ≤12, skills ≤15, personas ≤4) already exist as **selection
-metadata**, but nothing yet filters the projected output by them. That gap is
-what 6.0.0-B closes — and this ADR fixes the mechanism it must use.
-
-## Decision
-
-**Pack-scoped surfacing is implemented as projection-time filtering. There is no
-runtime resolver in 6.0.0.**
-
-Concretely, answering the four questions the roadmap requires:
-
-### Where the filtering runs
-
-In the **Node build / install projection** and in an explicit
-**`agent-config use --profile=<id>`** switch. The projector
-(`scripts/install.py` + the discovery/manifest layer) becomes
-profile-and-pack-aware: it writes only the active profile + enabled packs'
-artefacts into the tool trees. The filter is a **build-time set operation** over
-the trusted source (`.agent-src/` → projected tree), not a request-time hook.
-
-### How it integrates with host tools
-
-**Zero integration.** Host tools keep reading the static files in their native
-config directories exactly as they do today. They never learn that a profile
-exists. The behavioural change is entirely upstream of the host tool: a
-narrower set of files lands in `.claude/`/`.cursor/`/`.augment/`. No plugin API,
-no hook, no interception, no protocol change on the host side.
-
-### When projection happens
-
-At two moments, both explicit and user-initiated:
-
-1. **Install / sync** — `agent-config init`, `upgrade`, `refresh`, `sync` write
-   the projected set for the currently-selected profile + packs.
-2. **Profile / pack switch** — `agent-config use --profile=<id>` (wired in
-   6.0.0-A / Step 8) re-runs the projection for the new selection and rewrites
-   the tool trees.
-
-There is **no** mid-session, per-request, or background re-projection. The set a
-host tool reads is fixed between explicit switches.
-
-### What `agent-config use` does in 6.0.0-A (no behavioural change)
-
-The AI council (2026-06-02) flagged a sequencing trap: `use --profile=<id>` is
-wired in 6.0.0-A (Step 8), but filtering does not land until 6.0.0-B. To avoid a
-silent no-op that "succeeds but does nothing", the contract for 6.0.0-A is
-explicit:
-
-- `use --profile=<id>` **writes** `profile:` into `.agent-settings.yml` and
-  re-runs the projection — but the projection still writes the **legacy-all**
-  (full) set, because filtering ships later. It is **not** a silent no-op: it
-  changes persisted selection state and prints what it set, plus a one-line note
-  that surface-narrowing activates in 6.0.0-B.
-- It MUST reject an unknown profile id (validate against the six seed profiles)
-  rather than write garbage.
-- It does **not** change which artefacts a host tool sees in 6.0.0-A. The
-  "no projection-behaviour change" acceptance criterion holds: `use` moves the
-  *setting*, not the *set*.
-
-### Staleness and re-projection hygiene
-
-The projected set is a snapshot taken at the last explicit projection
-(install / sync / `use`). If upstream packs change (a surface cap moves, a pack
-is deprecated) **after** projection, the tool trees are stale until the next
-explicit `sync` / `use`. This is **accepted, not auto-corrected**: there is no
-background watcher. `agent-config validate` already performs drift detection on
-the manifest and is the surface that flags a stale projection; `sync` re-applies
-the current selection. Auto-detection beyond `validate` is out of scope.
-
-### Switching back / undo
-
-The per-user undo for a profile switch is another explicit `use`:
-`agent-config use --profile=<previous-id>` re-projects the prior selection. The
-switch persists the *new* selection in `.agent-settings.yml`; the previous value
-is recoverable from VCS / settings history. A dedicated `--rollback` flag is not
-required in 6.0.0-A (the setting is the single source of truth and re-projection
-is idempotent), but is noted as a possible 6.0.0-B affordance if field use shows
-it is needed. (This per-user undo is distinct from the *release-level*
-rollback criteria for the 6.1.0 default-flip — see the validation-gate note.)
-
-### How a user sees the active selection
-
-The active profile lives in `.agent-settings.yml` (`profile:`), and
-`agent-config validate` / the Settings GUI surface it. `use` echoes the
-resulting selection on every switch. No new per-tool-tree state file is
-introduced — `.agent-settings.yml` stays the single source of truth for "which
-experience is active".
-
-### Trust boundary
-
-The **projector writes**; **host tools read**. The projector
-(`scripts/install.py` and friends, run under the global install per `ADR-020`)
-is the only writer of `.claude/`/`.cursor/`/`.augment/`. Host tools treat those
-trees as read-only inputs. The trusted root remains `.agent-src.uncondensed/` →
-`.agent-src/`; the projection is a deterministic, re-runnable function of
-(trusted source, active profile, enabled packs). This preserves the existing
-trust model (`ADR-018`) — no new write surface, no new privileged process.
-
-### Runtime resolver is scoped OUT of 6.0.0 (conditional)
-
-A **true** runtime resolver — mid-session pack switching, the host tool querying
-a live process for "which skills apply right now" — is explicitly **out of scope
-for all of 6.0.0**. It is recorded as a **conditional** later possibility, gated
-on evidence that users actually want mid-session switching (telemetry or
-recruit-session signal). If it ever ships, it is a separate ADR and lives at the
-tail of [`road-to-6.0.0-c-governance-and-evals`](../../agents/roadmaps/road-to-6.0.0-c-governance-and-evals.md)
-or later — never silently as part of the projection work.
-
-### Supersedes the README "skill-resolver out of scope" line
-
-`README.md` ("What `agent-config` is — and what it isn't") lists **"Opinionated
-skill-resolver algorithm"** in the *Out of scope* column. That line predates the
-profile/pack axis. The AI council (2026-06-02) converged that the line must be
-**refined, not blanket-removed** — there are two distinct things, and only one
-moves:
-
-- **Out of scope (unchanged):** an *opinionated, automatic* resolver that ranks
-  or curates skills *for* the user without their choice (ML-based curation,
-  relevance scoring, "the algorithm decides"). The package still does not do
-  this.
-- **In scope (the refinement):** *user-driven* projection-time **filtering** —
-  the user picks a profile + packs, and the projector writes that subset. This
-  is a deterministic set operation governed by an explicit user choice, not an
-  opinionated runtime ranking.
-
-So this ADR supersedes the *reading* of that line that says "we will never
-select a subset of skills", while preserving the rejection of an automatic
-resolver. The README NOT-table is updated in Phase 1 to draw exactly this
-distinction (and a *runtime* resolver remains out of scope per above).
-
-## Consequences
-
-**Positive**
-
-- The rebuild has one unambiguous mechanism to build against. 6.0.0-B
-  enhances the projector; it does not invent a daemon.
-- No host-tool integration work, no protocol negotiation, no new runtime
-  process — the cheapest possible implementation of "focused command set".
-- Deterministic and testable: the projected set is a pure function of
-  (source, profile, packs); existing determinism checks
-  (`check_discovery_determinism.py`) extend naturally.
-- The trust boundary (`ADR-018`, `ADR-020`) is unchanged — no new attack
-  surface.
-
-**Negative / costs**
-
-- Switching profiles requires an explicit `agent-config use` + re-projection;
-  it is not instantaneous mid-session. Accepted: the council judged mid-session
-  switching an unvalidated want.
-- The projector gains profile/pack-awareness complexity (the set filter, the
-  legacy-all default, the staged rollout flag). Contained to the build layer.
-- Users who expected a "smart resolver" may be underwhelmed; mitigated by honest
-  positioning (Phase 1) that frames **explicit switching as a feature**
-  (predictable, inspectable, reproducible) rather than a limitation, and by the
-  conditional runtime-resolver escape hatch.
-
-**Neutral**
-
-- 6.0.0-A ships **no** projection-behaviour change — only this decision, the
-  positioning rewrite, and the `use` seam. The behavioural flip is 6.0.0-B,
-  staged and opt-in (legacy-all default) per the validation-gate note
-  ([Phase 0 / Step 2](../../agents/roadmaps/road-to-6.0.0-a-positioning-and-validation.md)).
-
-## Alternatives considered
-
-1. **Literal runtime resolver (rejected).** A long-lived process between host
-   tool and filesystem. Incoherent for a content-layer package; would make
-   `agent-config` an agent runtime it explicitly is not; requires per-host
-   integration the package has no surface for. Rejected as architecturally
-   wrong, not merely expensive.
-2. **Host-tool plugin/hook that filters at read time (rejected).** Push the
-   filter into each tool via its plugin API. Multiplies per-tool integration
-   cost across 7+ tools, couples the package to every tool's plugin lifecycle,
-   and breaks tools without a plugin surface. Rejected.
-3. **Ship full set, document "ignore what you don't need" (rejected).** The
-   status quo. Fails the core perception problem the rebuild exists to fix
-   ("520 artefacts, where do I start?"). Rejected — it is the problem.
-4. **Projection-time filtering (accepted).** Filter the projected set by profile
-   + packs in the build/install layer; host tools read a pre-filtered static
-   set. Cheapest, deterministic, zero host integration, preserves the trust
-   boundary.
-
-## References
-
-- [`road-to-6.0.0-a-positioning-and-validation`](../../agents/roadmaps/road-to-6.0.0-a-positioning-and-validation.md) — this roadmap (Phase 0 / Step 1).
-- [`road-to-6.0.0-b-pack-scoped-projection`](../../agents/roadmaps/road-to-6.0.0-b-pack-scoped-projection.md) — consumes this decision.
-- [`ADR-010`](ADR-010-profile-pack-preset-boundary.md) — profile / pack / preset boundary.
-- [`ADR-016`](ADR-016-installer-architecture.md) — installer architecture (the projector).
-- [`ADR-018`](ADR-018-trust-and-safety-layer.md) — trust boundary this ADR preserves.
-- [`ADR-020`](ADR-020-global-only-consumer-scope.md) — global-only consumer scope (where the projector runs).
-- [`profile-system`](../contracts/profile-system.md) — the six seed profiles and pack surface caps.
-- `README.md` § "What `agent-config` is — and what it isn't" — the superseded "skill-resolver out of scope" line.

package/docs/decisions/ADR-041-controlled-command-verbs.md

@@ -1,133 +0,0 @@
----
-adr: 041
-status: accepted
-date: 2026-06-03
-decision: controlled-command-verbs
-supersedes: —
-superseded_by: —
-phase: v6.0.0 · governance, evals, evidence-based pruning
-type: forward-looking
----
-
-# ADR-041 — Controlled verb vocabulary for visible commands
-
-## Status
-
-**Accepted** · 2026-06-03. Authored as Phase 2 / Step 4 of
-[`road-to-6.0.0-c-governance-and-evals`](../../agents/roadmaps/road-to-6.0.0-c-governance-and-evals.md),
-the governance front of the experience-first rebuild. Sits alongside the
-per-pack command budget ([`capability-packs.md` § Budget exemption
-process](../contracts/capability-packs.md)) and the routing-metadata
-requirement (Step 4b). Builds on
-[`ADR-003`](ADR-003-command-invocation-syntax.md) (cluster / colon syntax) and
-the locked-cluster contract
-([`command-clusters.md`](../contracts/command-clusters.md)).
-
-## Context
-
-6.0.0-B made the capability **pack** the surfacing unit; 6.0.0-C installs the
-governance that keeps the surface from re-bloating. A per-pack command budget
-caps *how many* visible commands a pack carries. This ADR governs *how they are
-named*: a visible command's leading token must be a controlled verb, so the
-surface reads as a small, predictable verb vocabulary (`work`, `implement`,
-`review`, `fix`, …) rather than an open-ended noun soup.
-
-Without a controlled vocabulary, every new visible command invents its own
-naming shape and the "fewer, navigable commands" promise of the pack rebuild
-erodes one well-meaning addition at a time. The `create-*` shape is singled out
-for an outright ban: which files to create is an in-flow decision the agent
-makes, not a command surface to enumerate.
-
-> **Council convergence (anthropic/claude-sonnet-4-5 + openai/gpt-4o,
-> 3-round design debate, 2026-06-03):** both members converged on
-> forward-only enforcement (grandfather the existing surface, gate new
-> additions), a **version-controlled YAML allowlist** reviewed via PR with an
-> ADR for any new verb, **grandfathering `create-pr`** through an explicit
-> documented exception rather than a broad exemption, and a **single modular
-> lint** (one pass, configurable severity) over two/three separate lints — the
-> "vocabulary gate + structure advisor" split was rejected because a
-> CI-passes / review-fails wedge trains contributors to ignore warnings.
-
-## Decision
-
-1. **Controlled verb allowlist.** Visible commands (tier 0/1) must have a
-   leading token (the substring before the first `-`, or the cluster sub-name
-   for `cluster:sub` commands) drawn from the allowlist in
-   [`src/config/discovery/command-verbs.yml`](../../config/discovery/command-verbs.yml).
-   The allowlist seeds the curated verbs (`work`, `audit`, `plan`, `implement`,
-   `review`, `fix`, `test`, `ship`, `sync`, `explain`, `estimate`, `refine`,
-   `publish`) plus the established cluster-head / standalone tokens already in
-   use on the visible surface (so the existing 20 visible commands all pass).
-
-2. **No `create-*` commands.** `create` is a banned leading token for *new*
-   visible commands. The agent decides which files to create in-flow; the
-   command surface does not enumerate creation targets.
-
-3. **`create-pr` is grandfathered** via an explicit `grandfathered:` entry in
-   the YAML — a documented single-command exception, not a broad waiver.
-
-4. **Forward-only enforcement.** The lint
-   ([`scripts/lint_command_verbs.py`](../../src/scripts/lint_command_verbs.py))
-   checks only command files **added or promoted to visible since the `main`
-   baseline**, mirroring `lint_no_new_atomic_commands.py`. The existing surface
-   is grandfathered; no rename wave.
-
-5. **A new verb requires an ADR.** Adding a token to `approved_verbs` is a
-   governance change: it lands in its own PR with a short ADR (or an addendum
-   referencing this one) justifying the new verb. The YAML is the machine list;
-   the ADR is the human rationale.
-
-6. **Single modular lint.** One lint pass implements both the approved-verb rule
-   and the banned-prefix rule. No separate "advisory" lint that warns without
-   gating — every rule the lint carries blocks CI (configurable per-rule, but
-   default error), so there is no CI-green / review-red wedge.
-
-## Consequences
-
-- **Positive.** The visible surface stays a small, scannable verb vocabulary.
-  New commands are nudged toward reuse of an existing verb (and therefore an
-  existing cluster) before inventing a new one. The `create-*` ban removes a
-  whole class of "expose a creation target as a command" growth.
-- **Positive.** Forward-only + grandfathering means zero disruption to the
-  current surface; the gate only ever fires on a *new* visible command.
-- **Negative / accepted.** The seeded allowlist includes established cluster-head
-  nouns (`feature`, `judge`, `council`, `memory`, `roadmap`, `agents`), so the
-  vocabulary is not purely verbs on day one. This is the cost of forward-only
-  grandfathering; the teeth come from "a new token needs an ADR", not from
-  retroactively purging the established heads.
-- **Negative / accepted.** Leading-token tokenization is a heuristic
-  (`review-changes` → `review`). Compound or underscore-shaped names are out of
-  scope until a real case appears.
-
-## Alternatives considered
-
-- **Retroactive enforcement** (every existing visible command must conform now).
-  Rejected: forces a rename wave across a heavily-referenced surface for no
-  user-facing gain. Both council members rejected it.
-- **Two/three separate lints** (cluster-head structure advisor + sub-verb gate +
-  banned-pattern gate) with mixed soft/hard severity. Rejected per the council:
-  advisory-only warnings that never graduate to errors become noise and create a
-  CI-passes / review-fails wedge.
-- **Rename `create-pr`.** Rejected: breaking change across docs, READMEs, and
-  other commands for no benefit; an explicit grandfather entry is cheaper and
-  honest.
-
-## Amendment — 2026-06-04 · `git` verb (6.0.0-D Step 12, Class B1)
-
-> **Accepted** · 2026-06-04. ADR-044 §3 makes `commit` / `create-pr` move into a
-> dedicated `git` pack with `slug_prefix: git` (Class B1), so their canonical
-> invocations become `git-commit` / `git-pr-create`. The leading token `git` is
-> therefore added to `approved_verbs`. This both honours the new naming scheme
-> and lets the long-standing `create-pr` grandfather entry retire naturally: the
-> canonical name is now `git-pr-create` (verb `git`, banned `create-` prefix no
-> longer in the leading position), with `replaces: [create-pr]` keeping the old
-> invocation routable via `migrate`. The grandfather row stays until the alias
-> window closes (6.1).
-
-## References
-
-- [`src/config/discovery/command-verbs.yml`](../../config/discovery/command-verbs.yml) — the allowlist + banned prefixes + grandfathered exceptions.
-- [`scripts/lint_command_verbs.py`](../../src/scripts/lint_command_verbs.py) — the forward-only single lint.
-- [`command-clusters.md`](../contracts/command-clusters.md) — locked clusters + sub-command naming.
-- [`capability-packs.md`](../contracts/capability-packs.md) — sibling per-pack budget governance (Phase 1).
-- [`ADR-003`](ADR-003-command-invocation-syntax.md) — invocation / colon syntax.

package/docs/decisions/ADR-042-runtime-resolver-decision-gate.md

@@ -1,113 +0,0 @@
----
-adr: 042
-status: accepted
-date: 2026-06-03
-decision: runtime-resolver-decision-gate
-supersedes: —
-superseded_by: —
-phase: v6.0.0 · governance, evals, evidence-based pruning
-type: decision
----
-
-# ADR-042 — Runtime pack resolver: STOP (projection-time filtering is sufficient)
-
-## Status
-
-**Accepted** · 2026-06-03. Records the Phase 5 decision gate of
-[`road-to-6.0.0-c-governance-and-evals`](../../agents/roadmaps/road-to-6.0.0-c-governance-and-evals.md)
-(Step 9). Builds directly on
-[`ADR-040`](ADR-040-execution-model-projection-time-filtering.md)
-(projection-time filtering, not a runtime resolver).
-
-## Context
-
-6.0.0-B shipped **projection-time** (build/install-time) pack-scoped filtering.
-The final phase of 6.0.0-C is a STOP/GO gate: do we ALSO build a **runtime
-resolver** that re-resolves the active pack set mid-session, live, as the user
-switches context?
-
-The gate criterion (from the roadmap): *"Only if the answer is 'switching
-demanded' does a runtime resolver earn its place. If not, STOP — projection-time
-filtering was sufficient and a runtime resolver is over-engineering."*
-
-The evidence at decision time:
-
-- **ADR-040 already chose projection-time** as the mechanism and did not
-  foreclose runtime resolution forever — it scoped 6.0.0 to projection-time.
-  Overturning that precedent requires extraordinary, proven demand.
-- **No telemetry exists.** The measurement events (`rule.tier2_loaded`,
-  `persona.cited`, `skill.activated`) were only just added in this roadmap's
-  Phase 3; the evidence-based-pruning contract requires ≥ 30 days before any
-  usage claim is trustworthy. There is zero accumulated data showing
-  mid-session switching demand.
-- **A lightweight mid-session affordance already exists.** `/profile:activate`
-  writes an ephemeral `runtime.active_packs` overlay that *biases* the surfaced
-  set (recommendation-bias MVP, no persistence, no execution-gating). Users can
-  already bias mid-session without a resolver.
-
-## Decision
-
-**STOP. Do not build a runtime pack resolver now.** Projection-time filtering
-(ADR-040) plus the `/profile:activate` recommendation-bias overlay is sufficient
-for the surfacing problem 6.0.0 set out to solve. A runtime resolver would cross
-a new config→execution trust boundary, introduce state-sync complexity (what
-happens when projection-time config changes while runtime state is active?), and
-add a context-window tax (every pack switch = a new system prompt) — all with
-**no evidence** the problem it solves exists.
-
-> **Council convergence (anthropic/claude-sonnet-4-5 + openai/gpt-4o, 3-round
-> design debate, 2026-06-03):** both members converged on **STOP**. The burden
-> of proof rests on PROCEED and is not met without telemetry; `/profile:activate`
-> already covers mid-session biasing; building the resolver now is "speculative
-> engineering". Both flagged a sharper refinement: high `/profile:activate`
-> usage alone would justify making the overlay *persistent*, NOT a full
-> resolver — only an **execution-gating** need (skills *unavailable*, not just
-> de-prioritised) that the overlay cannot serve would justify the resolver.
-
-## Re-trigger condition (falsifiable)
-
-This decision reopens only when **all** of the following hold, measured over a
-**≥ 30-day** telemetry window:
-
-1. **Switching frequency** — `/profile:activate` invoked ≥ 2×/session in ≥ 40%
-   of sessions.
-2. **Pack diversity** — users switch between ≥ 3 distinct pack combinations
-   (not just toggling one pack on/off).
-3. **Execution-gating need** — explicit user feedback requesting *execution-level*
-   gating (skills made unavailable in a mode, not merely de-prioritised) that
-   projection-time + `/profile:activate` cannot serve.
-
-If only (1) and (2) hold without (3), the correct response is to make
-`/profile:activate` **persistent across sessions** (a config-write), NOT to
-build a resolver. The resolver earns its place only when the need is
-execution-gating, not recommendation-bias.
-
-## Consequences
-
-- **Positive.** No new trust boundary, no state-sync complexity, no
-  context-window tax. The 6.0.0 rebuild ships with the simplest mechanism that
-  solves the stated problem. ADR-040's precedent is reaffirmed, not eroded.
-- **Positive.** The re-trigger condition is concrete and data-bearing — a future
-  decision is made on telemetry, not on a guess, consistent with the
-  evidence-based-pruning posture of this whole roadmap.
-- **Negative / accepted.** If a real execution-gating need emerges, it waits for
-  the next ≥ 30-day telemetry window before it can be acted on. Accepted: the
-  cost of waiting is low (the overlay covers biasing today), and the cost of
-  building speculatively is high.
-
-## Alternatives considered
-
-- **PROCEED — build the runtime resolver now.** Rejected: no evidence of demand,
-  overturns ADR-040 without cause, adds a new trust boundary and context-window
-  cost. The council's hardest pushback throughout the 6.0.0 rebuild.
-- **Build a smaller "persistent `/profile:activate`" instead.** Deferred, not
-  rejected: it is the *correct* response IF re-trigger conditions (1)+(2) fire
-  without (3). Not warranted now (no telemetry), but it is the cheaper next step
-  if data later shows persistence demand.
-
-## References
-
-- [`ADR-040`](ADR-040-execution-model-projection-time-filtering.md) — the projection-time decision this gate reaffirms.
-- [`evidence-based-pruning.md`](../contracts/evidence-based-pruning.md) — the ≥ 30-day telemetry posture the re-trigger condition follows.
-- [`local-analytics.md`](../contracts/local-analytics.md) — the `/profile:activate` switching signal the re-trigger reads.
-- [`command-clusters.md`](../contracts/command-clusters.md) § `profile` cluster — the `/profile:activate` overlay.