@event4u/agent-config 9.8.0 → 9.10.0

package/docs/decisions/ADR-008-installed-tools-manifest.md

@@ -1,160 +0,0 @@
----
-adr: 008
-status: proposed
-date: 2026-05-12
-decision: committed-installed-tools-manifest-separate-from-settings
-supersedes: —
-superseded_by: —
-phase: v2.x · post-global-first-install
----
-
-# ADR-008 — Installed-Tools Manifest
-
-## Status
-
-**Proposed** · 2026-05-12 · pending implementation in Phase 3 of
-[`road-to-global-first-install`](../../agents/roadmaps/road-to-global-first-install.md).
-
-Originates from user ask (Matze, 2026-05-12): "Sollten wir auf
-Projektebene festhalten, welche Agents wir initialisiert haben, damit
-bei jedem Sync das Verzeichnis aktualisiert werden kann?" Validated  <!-- md-language-check: ignore -->
-through AI Council Round 1 (claude-sonnet-4-5 + gpt-4o, $0.0298 actual,
-both converged on "yes, separate file"). Council session:
-[`agents/runtime/council/sessions/2026-05-12-project-settings-and-v1-v2/`](../../agents/runtime/council/sessions/2026-05-12-project-settings-and-v1-v2/). <!-- council-ref-allowed: ADR decision trace -->
-
-## Context
-
-After ADR-007 (global-first install), each developer's AI tooling
-lives in user-scope paths (`~/.claude/`, `~/.augment/`, …). A project
-no longer carries the AI config in its tree — except for tools with
-`workspace > global` precedence (Windsurf, Cline, Gemini-when-project-
-wins) that **must** keep a project-local bridge.
-
-**Resulting gap:** a project has no committed record of which AI
-tools it expects. A new team member cloning the repo cannot tell
-whether the codebase was built with Claude Code, Windsurf, both, or
-five others. Onboarding is "ask the team lead, hope they remember".
-
-**Two related but orthogonal problems:**
-
-1. **Bill of materials** — "Which AIs does this project use?"
-2. **Settings hierarchy** — "How do agents behave in this project?"
-
-Today, `.agent-project-settings.yml` (committed) answers #2 (personas,
-quality tools, locked keys). #1 is unanswered.
-
-### What we considered
-
-| Option | Verdict |
-|---|---|
-| **A.** Add `installed_tools` block to `.agent-project-settings.yml` | **Rejected** — mixes behaviour with bill-of-materials, creates a "god file" that every sync command must parse and partially ignore. Settings ≠ manifest. |
-| **B.** Put manifest at root: `.agent-installed-tools.lock` | Rejected — root is already crowded with 10+ AI dotfiles; adding another worsens it. |
-| **C.** Separate manifest at `agents/installed-tools.lock` | **Accepted** — co-located with project-shared agent docs; clear name; clear job. |
-| **D.** Skip — let team docs / README describe the tool set | Rejected — README drifts, no machine-readable contract, no drift detection. |
-
-Council (Sonnet): _"Settings (user prefs, locked keys, override paths)
-≠ Manifest (which tools exist). Mixing them creates a god file."_ Both
-members converged on a separate file; the location split (Sonnet
-favoured `installed-tools.lock`, GPT-4o favoured
-`.project-settings.yml`) resolved in favour of Sonnet on the
-separation-of-concerns argument.
-
-## Decision
-
-**Adopt option C.** Ship `agents/installed-tools.lock` as the
-committed, schema-versioned bill-of-materials for AI tooling.
-
-### Schema (v1)
-
-```yaml
-schema_version: 1
-agent_config_version: "2.x.y"   # version that wrote the file last
-tools:
-  - name: claude-code            # matches scripts/install.py _VALID_TOOLS
-    scope: global                # one of: global, project
-    bridge_marker: ~/.claude/PROJECT_MANAGED_BY_AGENT_CONFIG
-    installed_at: "2026-05-12"
-  - name: windsurf
-    scope: project               # workspace > global → must live in repo
-    bridge_marker: .windsurf/PROJECT_MANAGED_BY_AGENT_CONFIG
-    installed_at: "2026-05-12"
-```
-
-**Fields:**
-
-- `schema_version` — integer; bump on breaking schema changes.
-- `agent_config_version` — last package version that wrote the file.
-- `tools[]` — append-on-init order; not alphabetised (preserves
-  installation history for forensics).
-- `tools[].name` — must match `_VALID_TOOLS` in `scripts/install.py`.
-- `tools[].scope` — `global` (user-home install) or `project`
-  (workspace-wins tools that need a local bridge).
-- `tools[].bridge_marker` — path to the marker file the installer
-  drops to claim ownership. `validate` checks this file exists.
-- `tools[].installed_at` — ISO date; informational only.
-
-### Lifecycle
-
-1. `init --ai <name>` — adds an entry (idempotent). Existing entry
-   for same tool with **same scope** is a no-op. Existing entry with
-   **different scope** refuses without `--force` (loud warning:
-   "tool X is committed as scope=global; you are about to change it
-   to project").
-2. `sync` — reads the lock file, replays every listed tool's install
-   (skip if marker present, install if missing). Used by new team
-   members.
-3. `validate` — read-only drift check. Exit 1 if any listed marker
-   is missing or scope mismatches the file system. **No auto-fix.**
-4. Manual edit — discouraged. Lock file is machine-managed; humans
-   edit via CLI subcommands.
-
-### Relationship to `.agent-project-settings.yml`
-
-| File | Owner | Scope | Example keys |
-|---|---|---|---|
-| `agents/installed-tools.lock` | this ADR | bill of materials | `tools[]`, `scope`, `bridge_marker` |
-| `.agent-project-settings.yml` | layered-settings system | behaviour | `personas.default`, `quality.php.tools`, `locked_keys` |
-
-Both committed, both have a single job, never overlap.
-
-## Consequences
-
-### Positive
-
-- Onboarding: `git clone` + `npx @event4u/agent-config sync` brings
-  every team member's AI tooling to parity.
-- Drift detection: `validate` catches "team lead added Windsurf but
-  forgot to commit the lock-file update".
-- Forensics: install order preserved in `tools[]` order; `installed_at`
-  pins approximate timestamps.
-- Separation of concerns: behaviour settings stay clean; manifest
-  stays focused.
-
-### Negative
-
-- New committed file = one more thing to keep in sync with reality.
-  Mitigated by **machine-written-only** rule and `validate` CI hook.
-- Scope migration (tool moves between `global` and `project`) needs
-  documented playbook in `installed-tools-manifest.md` (Phase 3.5).
-- Single-developer projects gain little — the manifest is overhead
-  until a second developer joins. Mitigation: file is optional;
-  commands work without it (empty manifest = empty install).
-
-### Neutral
-
-- File lives under `agents/`, not at repo root — consistent with
-  Matze's preference and council Sonnet's argument that root is
-  already crowded.
-
-## Implementation Plan
-
-Tracked as Phase 3 of `road-to-global-first-install` (steps 3.1–3.5).
-Ships in a v2.x minor release **after** Phase 2 lands. Out of scope
-for this ADR.
-
-## References
-
-- [`ADR-007`](ADR-007-agent-discovery-scopes.md) — global-first install (this ADR depends on it).
-- [`agents/roadmaps/road-to-global-first-install.md`](../../agents/roadmaps/road-to-global-first-install.md) Phase 3.
-- [`agents/runtime/council/sessions/2026-05-12-project-settings-and-v1-v2/`](../../agents/runtime/council/sessions/2026-05-12-project-settings-and-v1-v2/) — full council transcripts. <!-- council-ref-allowed: ADR decision trace -->
-- [`docs/guidelines/agent-infra/layered-settings.md`](../guidelines/agent-infra/layered-settings.md) — the existing 4-layer settings precedence; this ADR adds a parallel file outside that hierarchy.

package/docs/decisions/ADR-009-event4u-namespace.md

@@ -1,188 +0,0 @@
----
-adr: 009
-status: accepted
-date: 2026-05-13
-decision: event4u-namespace-and-claude-desktop-zip-bundles
-supersedes: —
-superseded_by: —
-phase: v2.4 · namespace-and-claude-desktop
----
-
-# ADR-009 — `~/.event4u/agent-config/` namespace + Claude Desktop ZIP bundles
-
-## Status
-
-**Accepted** · 2026-05-13 · signed off by Matze after the user ask
-*"auf globaler ebene sollen unsere dateien in einem  <!-- md-language-check: ignore -->
-.event4u/agent-config Folder im user ordner landen"* combined with the
-Claude Desktop deployment gap surfaced in the same turn (the v1
-`marker-only` integration did not actually make any skill visible to
-the Customize → Skills panel). Implementation tracked in
-[`agents/roadmaps/road-to-event4u-namespace-and-claude-desktop.md`](../../agents/roadmaps/road-to-event4u-namespace-and-claude-desktop.md).
-
-## Context
-
-ADR-007 made global-first install the default and seeded the
-user-scope state at `~/.config/agent-config/` (XDG-style). Two pain
-points surfaced in production use:
-
-1. **Namespace collision risk.** `~/.config/agent-config/` is a
-   generic-sounding path. Future tools owned by event4u (or
-   third-party suites named `agent-config`) would step on the same
-   prefix. The user requested a vendor-owned umbrella:
-   `~/.event4u/agent-config/`.
-2. **Claude Desktop deployment was a stub.** `scripts/install.py`
-   wrote a `claude-desktop.md` marker file under
-   `~/.config/agent-config/claude-desktop/` and called it done. Claude
-   Desktop does **not** auto-discover skills from any filesystem path
-   — the user must upload each skill through **Settings → Customize →
-   Skills → Upload**. Research against an external reference suite
-   and the Anthropic Skills API docs confirmed there is no public
-   bulk-upload API for personal installs (the `/v1/skills` endpoint is
-   workspace + code-execution gated).
-
-Tool anchors (`~/.claude/`, `~/.augment/`, `~/.cursor/`,
-`~/.codeium/windsurf/`) are owned by the host tool and must **not** be
-moved — those paths are conventionalised by the tool itself.
-
-## Decision
-
-Two coordinated moves:
-
-### 1. Package-owned user-scope state lives under `~/.event4u/agent-config/`
-
-| Old path                                            | New path                                                |
-|-----------------------------------------------------|---------------------------------------------------------|
-| `~/.config/agent-config/agent-settings.yml`         | `~/.event4u/agent-config/agent-settings.yml`            |
-| `~/.config/agent-config/installed.lock`             | `~/.event4u/agent-config/installed.lock`                |
-| `~/.config/agent-config/installed-tools.yml`        | `~/.event4u/agent-config/installed-tools.yml`           |
-| `~/.config/agent-config/update-check.json`          | `~/.event4u/agent-config/update-check.json`             |
-| `~/.config/agent-config/ai-council/`                | `~/.event4u/agent-config/ai-council/`                   |
-
-Path resolution lives in `scripts/_lib/user_global_paths.py`:
-
-- `event4u_root()` — primary path; honours `EVENT4U_HOME` override.
-- `legacy_xdg_root()` — read-only fallback for unmigrated installs.
-- `resolve(name)` — returns the primary path; if absent and the legacy
-  copy exists, returns the legacy path. Writes always target the
-  primary path.
-
-A one-shot auto-migration shim runs on first post-upgrade
-`init`/`update`/`uninstall`:
-
-1. If `~/.event4u/agent-config/` already exists → no-op.
-2. Otherwise, copy every file from `~/.config/agent-config/` to the
-   new path, preserving mtimes.
-3. Drop a `MIGRATED.md` breadcrumb in the legacy dir pointing at the
-   new home. Legacy files stay readable; loaders fall back to them
-   until the next install overwrites the primary path.
-
-Tool anchors are **untouched**. The umbrella applies only to
-package-owned files.
-
-### 2. Claude Desktop deployment = per-skill ZIP bundles
-
-`scripts/_lib/claude_desktop_bundler.py` walks `.claude/skills/`,
-dereferences symlinks, and packs each `<skill-name>/` folder into a
-self-contained ZIP under
-`~/.event4u/agent-config/claude-desktop/bundles/<skill-name>.zip`.
-
-- Exclusions: `__pycache__/`, `.git*`, `*.pyc`, `.DS_Store`.
-- Atomic writes via `tempfile` + `os.replace`.
-- SHA-256 sidecar (`<name>.zip.sha256`) drives content-hash idempotency.
-- Repeat runs write 0 bundles when source unchanged; `--force` rebuilds.
-
-The user imports the ZIPs manually via Claude Desktop → Settings →
-Customize → Skills → Upload. The install summary surfaces the bundle
-path and count so the user can paste it into Finder / Explorer.
-
-## Consequences
-
-### Positive
-
-- **Vendor namespace is reserved.** Future event4u-owned packages can
-  drop sibling dirs under `~/.event4u/` without colliding with the
-  XDG-shape of other suites.
-- **Claude Desktop integration is real.** v2.4 produces 276 ZIPs from
-  the package's own `.claude/skills/` and the import flow is
-  click-through, no terminal.
-- **Migration is zero-action.** Existing users keep working — the
-  shim copies on first install and the legacy fallback covers any
-  loader that hasn't been re-run yet.
-- **Override-friendly.** `EVENT4U_HOME` lets CI / sandbox / multi-tenant
-  layouts redirect the root without monkey-patching.
-
-### Negative
-
-- **Manual upload step for Claude Desktop.** Until Anthropic ships a
-  public per-user Skills API, every fresh install / bundle refresh
-  requires the user to re-upload through Customize. The bundle count
-  in the install summary is the closest we can get to closing this loop.
-- **Two read paths during transition.** Loaders must consult both
-  `event4u_root()` and `legacy_xdg_root()` for the next two minor
-  versions. Once usage telemetry shows the legacy dir is consistently
-  empty, we can retire the fallback.
-- **Symlink semantics differ across platforms.** The bundler
-  `dereferences` symlinks during ZIP creation; on Windows this means
-  skills must not rely on cross-volume symlinks at pack time.
-
-### Neutral
-
-- Tool anchors (`~/.claude/`, `~/.augment/`, …) keep their owner. This
-  ADR explicitly does **not** propose moving them under
-  `~/.event4u/`.
-
-## Rollback / kill-switch
-
-If the migration corrupts user state, the rollback path is **manual but
-zero-data-loss** by design:
-
-1. **Legacy tree is never auto-deleted.** Even after the breadcrumb is
-   written, `~/.config/agent-config/` retains every file. The user can
-   reinstate it by deleting `~/.event4u/agent-config/` and re-running
-   `bash install.sh --global` — the shim will re-copy from the legacy
-   tree if the new root is absent.
-2. **Per-entry atomic write.** Each top-level entry is copied to a
-   sibling `<name>.event4u-partial-<pid>` and then `os.replace`'d into
-   place. A crash mid-copy leaves `*.event4u-partial-*` debris that the
-   next run purges before retrying — a partial subdirectory is never
-   mistaken for a completed copy.
-3. **`EVENT4U_HOME` env override.** A user who needs to point the
-   resolver at a known-good state (e.g. a restored backup) can set
-   `EVENT4U_HOME=/path/to/restored/agent-config` without editing any
-   config file.
-4. **Bundler is hash-gated.** If `claude_desktop_bundler.py` ever
-   produces a corrupt ZIP, the SHA-256 sidecar diverges from the source
-   manifest and the next run rewrites it. `--force` forces a full
-   rebuild from scratch.
-5. **Out-of-scope failure modes.** Disk exhaustion mid-copy, permission
-   bit corruption on cross-filesystem moves, and unicode-NFC normalisation
-   drift on macOS HFS+ → APFS migrations are **not** auto-recovered.
-   Users hit by those run the manual rollback in step 1.
-
-## Alternatives considered
-
-1. **Symlink `~/.event4u/agent-config/` ↔ `~/.config/agent-config/`.**
-   Rejected: doubles the surface (loaders still need both paths in
-   memory) and creates a removal hazard (`rm -rf ~/.config/agent-config`
-   wipes the new home too).
-2. **Anthropic `/v1/skills` API client for Claude Desktop.** Rejected:
-   the endpoint is workspace + code-execution gated, not viable for
-   personal installs. Captured as a follow-up if user demand surfaces.
-3. **Single mega-ZIP of all skills.** Rejected: Customize → Skills
-   imports one skill per ZIP. A combined archive would require the
-   user to extract + re-zip locally, defeating the purpose.
-4. **Hard-cut migration (delete legacy on first run).** Rejected: a
-   crash mid-copy would leave the user with neither path readable.
-   The current shim is copy-then-breadcrumb, leaving the legacy dir
-   intact for at least one more cycle.
-
-## References
-
-- [`agents/roadmaps/road-to-event4u-namespace-and-claude-desktop.md`](../../agents/roadmaps/road-to-event4u-namespace-and-claude-desktop.md)
-- [`scripts/_lib/user_global_paths.py`](../../src/scripts/_lib/user_global_paths.py)
-- [`scripts/_lib/claude_desktop_bundler.py`](../../src/scripts/_lib/claude_desktop_bundler.py)
-- [`docs/setup/per-ide/claude-desktop.md`](../setup/per-ide/claude-desktop.md)
-- [`docs/migration/v1-to-v2.md`](../migration/v1-to-v2.md) § v2 → v2.4
-- ADR-007 (predecessor — global-first install scopes)
-- ADR-008 (sibling — installed-tools manifest)

package/docs/decisions/ADR-010-profile-pack-preset-boundary.md

@@ -1,168 +0,0 @@
----
-adr: 010
-status: proposed
-date: 2026-05-16
-decision: profile-pack-preset-boundary
-supersedes: —
-superseded_by: —
-phase: v2.x · step-15 Phase 1 prerequisite
----
-
-# ADR-010 — Profile / Pack / Preset Boundary
-
-## Status
-
-**Proposed** · 2026-05-16 · pending Phase 1 of
-[`agents/roadmaps/step-15-product-refinement.md`](../../agents/roadmaps/step-15-product-refinement.md).
-Council v3 action #2 (`agents/runtime/council/responses/2026-05-16-step-15-product-refinement-v3.json`): <!-- council-ref-allowed: ADR decision-trace to originating council response -->
-**"Profile / Pack / Preset boundary is undefined; Phase 2 will duplicate
-Phase 1 abstractions"**. Promoted from Phase 2 to Phase 1 prerequisite —
-the profile loader (Phase 1 item 1) cannot ship without the boundary.
-
-## Context
-
-Step-15 introduces three new configuration concepts:
-
-- **Profile** — Phase 1 item 1: `profile.id` ∈ {`founder`, `developer`,
-  `content_creator`, `agency`, `finance`, `ops`}.
-- **Preset** — Phase 1 item 4: `preset.id` ∈ {`fast`, `balanced`,
-  `strict`} bundling 12+ governance knobs (cost caps, confidence band,
-  block-on-risk, …).
-- **Pack** — Phase 2 item 7: workflow bundles (`founder-mvp`,
-  `content-engine`, `agency-delivery`) of `(profile + preset +
-  command-set + skill-allowlist)`.
-
-A pre-existing fourth concept is in play:
-
-- **`rule_loading_tier`** — current setting in `.agent-settings.yml`, values
-  `minimal` / `balanced` / `full` / `custom`. Owns **rule-tier loading**
-  (kernel · kernel + tier-1 · kernel + tier-1 + tier-2). Contract:
-  [`docs/contracts/cost-profile-defaults.md`](../contracts/cost-profile-defaults.md).
-
-Without a written boundary, three failure modes are predictable:
-
-1. The preset loader re-implements rule-tier gating (overlap with
-   `rule_loading_tier`).
-2. Packs ship duplicate `profile` + `preset` defaults that drift from
-   the canonical source.
-3. Three teams add knobs to three places, and a user picking
-   `developer + strict + founder-mvp` discovers contradicting values
-   at runtime.
-
-## Decision
-
-Four orthogonal axes, four owners, one resolution chain.
-
-| Axis | Answers | Owns | Identity key |
-|---|---|---|---|
-| **Profile** | *Who is the user?* (audience taxonomy) | Default skill/command surface; README entry-paragraph; persona pre-selection | `profile.id` |
-| **Preset** | *How cautious is this run?* (risk + cost + autonomy budget) | The 12+ governance knobs (per-call $ ceiling, confidence band, block-on-risk, autonomy default, council escalation, …) | `preset.id` |
-| **Pack** | *What bundle of skills + commands?* (workflow recipe) | A frozen `(profile, preset, allow_skills, allow_commands)` 4-tuple; nothing more | `pack.id` |
-| **Cost Profile** | *How many rules load?* (token budget) | Rule-tier loading at session start (kernel · +tier-1 · +tier-2) | `rule_loading_tier` |
-
-### Resolution chain (read order, last writer wins)
-
-```
-pack  →  profile  →  preset  →  rule_loading_tier  →  user/env/runtime overrides
-```
-
-- A **pack** declares defaults for `profile`, `preset`, and the
-  skill / command allowlists. It cannot set `rule_loading_tier` (that
-  axis belongs to the rule-tier loader and is governed separately).
-- A **profile** declares defaults for `preset`, audience-specific
-  README pointer, persona pre-selection. It cannot set any preset
-  knob directly — only `preset.id`.
-- A **preset** owns the 12+ knobs. No other axis writes them.
-- A **rule_loading_tier** owns rule-tier loading. No other axis writes it.
-- The user's `.agent-settings.yml`, environment variables, and
-  runtime CLI flags override every axis above them.
-
-### Non-overlap rules (Iron Law)
-
-```
-A KNOB BELONGS TO EXACTLY ONE AXIS.
-DUPLICATION ACROSS AXES IS A CONTRACT VIOLATION.
-```
-
-- A pack **may not** override a preset knob; it overrides `preset.id`.
-- A profile **may not** override a preset knob; it overrides `preset.id`.
-- A preset **may not** override `rule_loading_tier`; the user does that.
-- The CI `task lint-config-schema` (added in Phase 1) hard-fails on a
-  pack/profile YAML that names any preset-owned knob.
-
-## Consequences
-
-### Positive
-
-- Phase 1 ships the profile loader against a fixed surface (`profile.id`
-  → audience + `preset.id` + persona). No 12-knob inheritance ambiguity.
-- Phase 1 item 4 (Config Presets) owns the knobs alone. The "Cost
-  Enforcement" section in [`config-presets.md`](../contracts/config-presets.md)
-  has a single home.
-- Phase 2 item 7 (Workflow Packs) is a 4-tuple, not a re-implementation
-  of profile + preset. Pack YAML stays under 30 lines.
-- `rule_loading_tier` keeps its single-axis charter; this ADR explicitly
-  refuses to fold it into the preset layer.
-
-### Negative
-
-- One more concept on the install screen (`profile` + `preset` + `pack`
-  + `rule_loading_tier` = four axes). Mitigated by: the wizard (Phase 1 item
-  2) only asks for **profile** + **stack** + **risk appetite** and
-  derives the rest. Packs are opt-in; `rule_loading_tier` keeps its
-  `balanced` default.
-- A skill-allowlist conflict between a pack and a runtime CLI flag is
-  resolved by "runtime wins". Users on a pack who shadow-disable a
-  skill will not see it again until the override is removed.
-
-### Neutral
-
-- This ADR records the boundary; it does **not** specify the seed
-  values for any axis. Profile IDs live in
-  [`docs/contracts/profile-system.md`](../contracts/profile-system.md)
-  (Phase 1 item 1). Preset knobs live in
-  [`docs/contracts/config-presets.md`](../contracts/config-presets.md)
-  (Phase 1 item 4). Pack shape lives in `docs/contracts/workflow-packs.md`
-  (Phase 2 item 7).
-
-## Addendum — runtime `active_packs` overlay is not a fifth axis (2026-06-02)
-
-The session-profile-activation work introduces an **ephemeral
-`runtime.active_packs` overlay**: a developer activates a profile for the
-current session and only the matching packs' commands/skills are the
-surfaced set. This addendum records that the overlay does **not** add a
-fifth axis and does **not** violate the no-duplication rule above.
-
-The resolution chain is
-`pack → profile → preset → rule_loading_tier → user/env/runtime overrides`.
-The `active_packs` overlay is an instance of the chain's **existing final
-link** (`… → user/env/runtime overrides`): a runtime override that
-**modulates the `pack` axis** for the duration of a session. It selects
-which already-installed packs are *surfaced*; it does not create a new
-knob, a new vocabulary, or a new ownership boundary.
-
-- **Axis ownership unchanged.** The `pack` axis still owns "which bundle".
-  The overlay narrows the *active subset* of installed packs at runtime —
-  the same way the documented "runtime wins" rule lets a CLI flag
-  shadow-disable a pack-supplied skill (see Consequences § Negative). It
-  is the read-time companion of that write-time precedent.
-- **No knob duplication.** The overlay stores only a list of pack ids
-  (`runtime.active_packs: [...]`), the closure of the activated
-  profile/pack. It never restates a `preset` knob or a `profile` default.
-- **Governance stays on its own axis.** Profile activation **does not**
-  touch `rule_loading_tier`. Rules load by tier + trigger, never by pack
-  (session-profile work Phase 0.4). Letting a profile move the tier would
-  be the very axis-collision this ADR forbids.
-- **Ephemeral + uncommitted.** The overlay lives in
-  `.agent-settings.local.yml` (gitignored, deepest-winning layer), never
-  the committed settings file — so it cannot drift into a persisted axis.
-
-Net: the overlay is a session-scoped *view* over the `pack` axis, not a
-new axis. ADR-010's orthogonality holds.
-
-## See also
-
-- [`agents/settings/contexts/session-host-capability-audit.md`](../../agents/settings/contexts/session-host-capability-audit.md) — host-capability facts that bound the overlay's lifecycle (addendum input).
-- [`docs/contracts/cost-profile-defaults.md`](../contracts/cost-profile-defaults.md) — the existing `rule_loading_tier` contract this ADR explicitly does **not** touch.
-- [`agents/roadmaps/step-15-product-refinement.md`](../../agents/roadmaps/step-15-product-refinement.md) — Phase 1 items 1, 4 and Phase 2 item 7.
-- [`agents/runtime/council/responses/2026-05-16-step-15-product-refinement-v3.json`](../../agents/runtime/council/responses/2026-05-16-step-15-product-refinement-v3.json) — Council v3 action #2 (origin). <!-- council-ref-allowed: ADR decision-trace to originating council response -->