@event4u/agent-config 9.8.0 → 9.10.0

package/docs/contracts/release-trunk-sync.md

@@ -1,105 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-12
----
-
-# ADR — Release-trunk sync: main fast-forwards on every tag
-
-> **Status:** Decided · 2026-05-14
-> **Context:** PR #43 feedback (Level-5/6 product rating) and PR #143
-> revealed `main` lagging the latest tag by N skills + rules at multiple
-> points across the 2.x cycle. External readers landing on `main`
-> consistently saw stale README counts and missing skill catalogues
-> relative to the npm/Packagist artefact.
-> **Closes:** the `road-to-productization` roadmap § P1.2 (under
-> `agents/roadmaps/`).
-
-## Decision
-
-Every tagged release (`X.Y.Z`) **fast-forwards `main` to the tag's
-commit as the final step of the release pipeline**. No exceptions. No
-grace period.
-
-The fast-forward is owned by [`scripts/release.py`](../../src/scripts/release.py)
-and runs after the GitHub Release is published. The release pipeline
-is **not green** until `main == <new-tag>` at the remote.
-
-`main` is therefore a **moving stable trunk pointer**, not a feature
-branch. External readers (README, AGENTS.md, marketplace metadata, npm
-tarball provenance) reading `main` see the artefact that was last
-published, not work-in-progress.
-
-## Protocol
-
-1. `scripts/release.py` cuts `release/X.Y.Z`, bumps version files,
-   opens a release PR against `main`, waits for CI, merges.
-2. The merge commit on `main` becomes the tag's commit; the tag is
-   pushed.
-3. `publish-npm.yml` and the marketplace flow trigger on the tag.
-4. The release pipeline asserts `git rev-parse origin/main ==
-   git rev-parse refs/tags/X.Y.Z` before exit-0.
-5. If a hotfix lands on `release/X.Y.Z` after step 1 but before step 4,
-   the FF still happens — release-branch commits are part of the
-   release, not a separate trunk.
-
-### Why fast-forward, not merge
-
-Fast-forward keeps `main` linear with the tag history. A merge-commit
-on top of the tag would put `main` at a SHA that is **not** the tag's
-SHA, re-introducing the exact divergence this contract closes.
-
-If a fast-forward is impossible (force-push to `main`, divergent
-history, abandoned release-prep), the pipeline **fails loudly**; the
-operator either resets `main` manually with an audit trail or aborts
-the release.
-
-## CI Gate (P1.3)
-
-[`scripts/check_release_trunk_sync.py`](../../src/scripts/check_release_trunk_sync.py)
-runs on every `release/X.Y.Z` branch (detected by `git rev-parse
---abbrev-ref HEAD` matching `^release/\d+\.\d+\.\d+$`).
-
-It enforces: **`main` is at most ONE tagged release behind the
-release-prep branch's target version.**
-
-- On `release/2.11.0`: `main` may be at `2.10.0` or `2.11.0`. `2.9.0`
-  or older → **hard fail**.
-- On any other branch class (feature, fix, chore, docs, the agent's
-  own `feat/road-to-productization` branch): the check is a **no-op**
-  exit-0 — feature branches never trip the gate.
-- Wired into `task ci` as `check-release-trunk-sync`. No warning-only
-  mode; the exit code is the gate.
-
-### Bootstrap mode
-
-When the repo state does not yet match the gate (transitional first
-run after this contract lands), the check reads
-`docs/contracts/release-trunk-sync.bootstrap` for an opt-out window
-keyed by current version. The bootstrap file is purged at the next
-release. Absence of the file = gate is live.
-
-## Rollback
-
-Revertible by removing `check-release-trunk-sync` from `Taskfile.yml`
-and deleting `scripts/check_release_trunk_sync.py`. No state, no
-schema, no migration. Branch-detection key (`release/X.Y.Z`) is
-already used by `scripts/release.py` so removing this contract does
-not orphan the convention.
-
-## Risks
-
-| # | Risk | Mitigation |
-|---|---|---|
-| 1 | Gate fires on feature branches mid-PR | Branch-name regex; non-`release/` branches no-op exit-0 |
-| 2 | Hotfix release leaves `main` behind | FF runs **after** hotfix commits land on the release branch |
-| 3 | Manual tag (no `scripts/release.py`) skips the FF | Out of scope of this contract — covered by `release-guard.yml` which fails on tag/version mismatch; manual tags already break the pipeline |
-| 4 | Detached HEAD or shallow checkout breaks detection | Check gracefully exits-0 with a `::warning::` line when `git rev-parse --abbrev-ref HEAD == HEAD` (detached) |
-
-## See also
-
-- [`scripts/release.py`](../../src/scripts/release.py) — release pipeline owner.
-- [`.github/workflows/release-guard.yml`](../../.github/workflows/release-guard.yml)
-  — tag/version-file integrity gate (orthogonal: this contract handles
-  trunk position, release-guard handles version-string integrity).
-- The `road-to-productization` roadmap § Phase 1 (under
-  `agents/roadmaps/`).

package/docs/contracts/review-lens-schema.md

@@ -1,64 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-17
----
-
-# Review-lens routing schema
-
-Defines what a review **lens** is, the metadata it carries, and which review
-skills are **entry skills** (invoked directly / by task) vs **dispatched lenses**
-(run only under an orchestrator). This is the contract the Phase-3 consolidation
-scan validates merge candidates against — **proposal/schema only; no skill is
-merged here.**
-
-## Lens vs entry skill
-
-```
-A LENS IS DISPATCHED, NEVER A FRONT DOOR.
-AN ENTRY SKILL IS INVOKED; A LENS IS ORCHESTRATED.
-DO NOT MERGE ACROSS THE LINE.
-```
-
-- **Entry review skill** — a reviewer the user (or a task) invokes directly. It
-  produces a standalone verdict and may itself orchestrate. Examples:
-  `code-review` (also the `/review-changes` consolidator), `adversarial-review`,
-  `authz-review`, `design-review`, `privacy-review`, `receiving-code-review`,
-  `requesting-code-review`, `skill-reviewer`.
-- **Dispatched lens** — a specialized reviewer that runs **only** under an
-  orchestrator (`/review-changes` dispatches five, each on the same diff +
-  context, independently, then consolidates). Examples: `judge-bug-hunter`,
-  `judge-security-auditor`, `judge-test-coverage`, `judge-code-quality`,
-  `architecture-review-lens`.
-- **Router** — picks reviewers by path + risk, dispatches nothing itself:
-  `review-routing`.
-
-## Schema — the metadata a lens carries
-
-| Field | Meaning |
-|---|---|
-| `id` | the lens skill slug (`judge-bug-hunter`, `architecture-review-lens`, …) |
-| `scope` | the single dimension it reviews (correctness · security · test-coverage · quality · architecture) |
-| `constraints` | what it MUST flag and what it must NOT (stay in its lane — a bug lens does not opine on style) |
-| `dispatched_by` | the orchestrator that runs it (`/review-changes`; `/judge` for solo/steps) |
-| `runs` | `independently` — same diff + task context, no cross-talk between lenses |
-| `consolidated_by` | who merges the verdicts (`code-review` for `/review-changes`) |
-| `verdict_shape` | findings list with severity; no merge/ship decision (the human decides) |
-
-## The dispatch contract (what Phase 3 validates against)
-
-1. A **lens never becomes a front door** — it has no standalone command and is
-   not in a profile's `commands_hint`. Merging a lens into an entry skill (or
-   promoting it to a command) breaks the orchestrated-review model.
-2. A **lens stays single-scope** — consolidation must not fuse two lenses into
-   one multi-scope reviewer (that re-creates the monolith `/review-changes` was
-   built to decompose).
-3. An **entry skill may absorb another entry skill** only when both are
-   user-invoked and their scopes genuinely overlap — but never absorb a lens.
-4. The **consolidator** (`code-review`) is load-bearing — it is the entry skill
-   that both stands alone and merges lens verdicts; it is not a merge candidate.
-
-## See also
-
-- [`/review-changes`](../../src/domains/engineering-base/review-changes/command.md) — the five-judge dispatcher.
-- [`skill-family-map.yml`](skill-family-map.yml) — `family: review-judging` carries these skills; Phase 3 reads `candidate_*` against this contract.
-- [`governance.md`](../governance.md) — the lifecycle + Single-Source-of-Truth rules these skills age under.

package/docs/contracts/roadmap-complexity-standard.md

@@ -1,138 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-12
----
-
-# Roadmap Complexity Standard
-
-> **Audience:** roadmap authors and reviewers in `agents/roadmaps/`.
-> **Linter:** `scripts/lint_roadmap_complexity.py` (run via
-> `task lint-roadmap-complexity`).
-> **Source:** Phase 5 of the `road-to-context-layer-maturity` work
-> (now archived); reviewer-flagged drift after the
-> structural-optimization roadmap proved that "heavy" is correct for
-> structural work but wrong for normal feature work.
-
-Roadmaps drift toward heavyweight whenever the previous one was
-heavyweight. This contract pins **two tiers**, names exemplars, and
-hard-fails the lint on tier mismatch.
-
-## Tiers
-
-### Lightweight (default)
-
-Almost every roadmap is lightweight. The shape:
-
-- **≤ 6 phases** total
-- **≤ 1 page per phase** (≈ 60 source lines including header + steps
-  + exit gate; the linter doesn't enforce per-phase line budgets, but
-  reviewers do)
-- **No nested council debates** inside the roadmap (no
-  `## Council Round 1`, `## Council Round 2`, `### Verdict` sections)
-- **No 178-step backlogs** — phases are delivery-shaped, not
-  task-shaped
-- **≤ 600 lines total** (frontmatter + body, blank lines counted)
-- Frontmatter declares `complexity: lightweight`
-
-**Exemplars:**
-
-- `road-to-context-layer-maturity.md` (archived) — six phases,
-  ~376 lines, no nested council; the seed roadmap that triggered this
-  standard. Self-tagged as `lightweight`.
-- `road-to-rule-hardening.md` (archived) — five phases, ~263 lines;
-  mechanized the rule layer; sibling of the seed, also lightweight.
-
-**Typical use:** feature work, follow-ups, bounded refactors,
-mechanization passes, telemetry plumbing.
-
-### Structural (rare)
-
-Triggered only when the work changes a contract layer or a budget
-invariant. The shape:
-
-- Multi-round council, locked decisions, file-ownership matrix,
-  gating contracts on phase boundaries
-- **> 600 lines** total (typical: 800 – 1500)
-- May include `## Council Round N` / `### Verdict` blocks, ADR
-  cross-links, decision matrices
-- Frontmatter declares `complexity: structural`
-
-**Exemplars:**
-
-- Archived `agents/roadmaps/_archived/road-to-structural-optimization.md`
-  (closed 2026-05-03 after 6 phases of council-driven budget work).
-  ~1.5k lines, multi-round council, file-ownership matrix.
-
-**Triggered by:** changes to a public contract surface in
-`docs/contracts/`, a budget invariant in
-[`load-context-budget-model.md`](load-context-budget-model.md), or a
-priority hierarchy in
-[`rule-priority-hierarchy.md`](rule-priority-hierarchy.md).
-**Requires:** explicit user opt-in on creation. The agent must not
-upgrade a lightweight roadmap to structural mid-flight without that
-opt-in.
-
-## Anti-game clause
-
-The trigger is **contract-layer change**, not line count alone. A
-heavy roadmap split into two lightweights to dodge the gate is a
-linter-defeat — reviewers flag it on PR review. Conversely, a
-roadmap that legitimately needs the structural shape but tries to
-hide as `lightweight` to skip council overhead is the same defeat in
-the other direction.
-
-## Frontmatter
-
-Every roadmap in `agents/roadmaps/` (including draft and archived
-ones) declares its tier:
-
-```yaml
----
-complexity: lightweight
----
-```
-
-or
-
-```yaml
----
-complexity: structural
-status: draft
----
-```
-
-Other frontmatter keys (`status:`, `owner:`, `target_release:`) are
-permitted alongside but not required by this contract.
-
-## Linter contract
-
-`scripts/lint_roadmap_complexity.py` (≤ 150 LOC, stdlib only)
-enforces the **measurable** subset of this standard:
-
-| Check | Lightweight | Structural |
-|---|---|---|
-| `complexity:` frontmatter declared | required | required |
-| Total line count | ≤ 600 | > 0 (no upper cap) |
-| `## Phase N` heading count | ≤ 6 | no cap |
-| `## Council Round N` / `### Verdict` blocks | forbidden | allowed |
-| Council session cross-links (`agents/sessions/.../council-…`) | warn | allowed |
-
-The linter runs on every roadmap file under `agents/roadmaps/` and
-exits non-zero on any violation. Hooked into `task ci` via
-`task lint-roadmap-complexity`.
-
-**Out of scope for the linter** (reviewer judgment only): step count,
-per-phase length, the contract-layer-change trigger for the
-structural tier.
-
-## Migration
-
-Phase 5.3 of `road-to-context-layer-maturity` applies the standard
-retroactively to all open roadmaps in `agents/roadmaps/`: each gets
-a `complexity:` tag based on the rules above. No content rewrites
-land in that step — only the tag.
-
-Roadmaps that exceed the lightweight cap but plausibly should be
-lightweight (e.g. they accumulated drift) are tagged `structural`
-for now and may be split or trimmed in a follow-up. The migration
-records existing reality, not aspirational reality.

package/docs/contracts/role-experience.md

@@ -1,125 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-23
----
-
-# Role-experience contract
-
-**Purpose.** Freeze the on-disk shape of a `role-experience` — the artefact that turns a non-developer persona (galabau owner, content creator, consultant, …) into a first-class entry point with three first tasks, a named prompt library, and a curated skill shortlist. Pins the interface **before** the launcher in Phase 4 reads it, so the launcher and the role authors can move independently.
-
-Last refreshed: 2026-05-24. Phase 3 of the employee-product workstream.
-
-## What a role experience is
-
-A folder at `agents/roles/<role>/` that contains:
-
-- One **identity index** (`index.md`) — one-paragraph persona, three concrete first tasks, recommended pack list, install-path hint.
-- A **prompt library** (`prompts/<name>.md`) — 5–10 named prompts, each a single markdown file with structured frontmatter and a parameterised body the launcher can fill.
-- A **skill shortlist** (`skills.yml`) — the existing skills the launcher should surface for this role, in priority order. Cites existing skills only; never duplicates them.
-
-A role experience is **not**:
-
-- A new skill — the shortlist references existing skills under `packages/<pack>/.agent-src.uncondensed/skills/`. The role experience curates; it does not implement.
-- A documentation page — `docs/getting-started-by-role.md` is the prose surface and links **to** the role experience, never duplicates it.
-- A persona file under `personas/` — personas are review voices the AI Council uses; role experiences are end-user entry points.
-
-## Folder shape
-
-```
-agents/roles/<role>/
-├── index.md            # identity + three first tasks + recommended packs
-├── skills.yml          # skill shortlist (priority-ordered)
-└── prompts/
-    ├── <name-1>.md
-    ├── <name-2>.md
-    └── …               # 5–10 prompts
-```
-
-`<role>` is a kebab-case identifier; it doubles as the launcher key and the URL slug. Reserved words: `default`, `_template`, `_archive`.
-
-## `index.md` frontmatter (required)
-
-```yaml
----
-role: <kebab-case-id>
-display_name: "Galabau owner"
-tagline: "One-sentence description visible in the launcher rail."
-recommended_packs: [core, founder-strategy]   # cites existing packs only
-install_path_hint: "MCP recommended (Claude Desktop) · CLI when …"
-recruit_session_ref: "agents/recruit-sessions/01-galabau-owner.md"  # nullable until session lands
-status: stable | beta | draft
----
-```
-
-The body of `index.md` then lists, in this order:
-
-1. **Persona paragraph** (≤ 80 words) — who this role is for, in the role's own language.
-2. **Three first tasks** — each a single sentence + the prompt name (`prompts/<name>.md`) that bootstraps it.
-3. **Recommended pack list** — referenced from frontmatter, expanded with one-line rationale per pack.
-
-## Prompt frontmatter (required)
-
-Each `prompts/<name>.md` carries:
-
-```yaml
----
-name: <kebab-case-id>            # unique within the role's prompts/ folder
-intent: "One sentence: what the user gets out of this prompt."
-inputs:
-  - name: customer_brief
-    required: true
-    shape: "free-text paragraph"
-  - name: tone
-    required: false
-    shape: "one of [neutral, warm, urgent]"
-output_shape: "Markdown — H2 sections, ≤ 600 words, structured offer."
-skill_hint: refine-prompt        # which skill the host should foreground; cites existing skill
----
-```
-
-The body is the parameterised prompt itself, with `{{input_name}}` placeholders the launcher fills before sending to the host model. Bodies stay ≤ 200 lines; prompts longer than that get split.
-
-## `skills.yml` shape
-
-```yaml
-# Priority-ordered. The launcher surfaces the first 5 in its default view; the rest go behind "more".
-skills:
-  - id: refine-prompt
-    why: "Tightens fuzzy customer briefs before any drafting."
-  - id: voice-and-tone-design
-    why: "Locks the role's voice so emails read consistent across customers."
-  - id: doc-coauthoring
-    why: "Section-by-section drafting flow for longer offers."
-```
-
-Every `id` must resolve to an existing skill under `packages/<pack>/.agent-src.uncondensed/skills/<id>/SKILL.md` — verified by the lint pass in Phase 3 Step 6.
-
-## Versioning + status
-
-- `status: draft` — scaffold only, no validation evidence yet. Launcher hides drafts in the default view.
-- `status: beta-internal` — scaffold + maintainer internal-authoring / dogfooding basis; **no external recruit session yet**. `recruit_session_ref` stays `null`. Launcher surfaces with an `internal beta` badge. This tier exists so a role can be *used* without claiming external validation it does not have. The basis is recorded in [`agents/roles/EVIDENCE_BASIS.md`](../../agents/roles/EVIDENCE_BASIS.md). It is the honest ceiling for a role that has never been in front of an external user.
-- `status: beta` — scaffold + at least one recruit session backs the first-task choice. Requires a non-null `recruit_session_ref`. Launcher surfaces with a `beta` badge.
-- `status: stable` — at least two recruit sessions concurred on the role's first tasks and the friction-inventory landed at ≤ 3 P0 items. Requires a non-null `recruit_session_ref`.
-
-Status promotion is a maintainer decision. `draft → beta-internal` is an internal-authoring promotion (no recruit session needed); `beta-internal → beta → stable` is the **external-validation** ladder and is gated on the `recruit_session_ref` trail. Demotion (stable → beta) happens when a follow-up recruit session contradicts the existing first-task choice.
-
-> **Why two beta tiers (AI-council convergence, claude-sonnet-4-5 + gpt-4o, 2026-06-08, design mode):** the recruit sessions test a boundary the self-improvement loop is blind to — *can a cold-start external user get in at all?* — so they are kept as an optional future activity, never faked and never cancelled. `beta-internal` lets downstream work proceed and the launcher surface the roles **today**, honestly labelled, while `beta`/`stable` stay reserved for real external evidence. Fabricating a `recruit_session_ref` to reach `beta` is the one move this contract forbids.
-
-## Lint pass (deferred to Phase 3 Step 6)
-
-The lint pass (`task lint-role-experiences`, wired into `task ci`) asserts:
-
-1. Every `agents/roles/<role>/index.md` has all required frontmatter keys + at least 3 first tasks.
-2. Every `prompts/<name>.md` has the four required frontmatter keys (`name`, `intent`, `inputs`, `output_shape`) plus `skill_hint`.
-3. Every `skills.yml#skills[].id` resolves to an existing skill.
-4. Every `recommended_packs[]` entry resolves to an existing pack manifest.
-5. `status` is one of `draft | beta-internal | beta | stable`.
-6. `status: beta` and `status: stable` require a **non-null** `recruit_session_ref` (external-validation gate). `draft` and `beta-internal` may keep `recruit_session_ref: null`.
-
-Lint pass code lives at `scripts/lint_role_experiences.py`, ≤ 200 LOC.
-
-## Open questions (Phase 3 optional council pass)
-
-- Per-role default model — should `index.md` carry a `default_model` frontmatter key the launcher honours, or stay at the host's global default? Default in this contract: stay at host default; per-role override is a future ADR.
-- Prompt input typing — should `inputs[].shape` be free-text or constrained to a small enum (`text`, `enum`, `file-path`, `url`)? Default: free-text; constraint enum is a future tightening.
-- Multi-language prompt bodies — German vs English by role? Default: prompt bodies follow the language policy of the package (English); the host translates at runtime per `language-and-tone`.

package/docs/contracts/router-blending.md

@@ -1,71 +0,0 @@
----
-stability: beta
-keep-beta-until: 2026-08-13
----
-
-
-# Router Blending — Cross-Domain Skill Mix Contract
-
-> **Status:** beta · **Owner:** router governance · **Depends on:** [`universal-skills.md`](universal-skills.md), the user-types axis (axis seeds — schema field defined under [`skill.schema.json`](../../src/scripts/schemas/skill.schema.json) → `recommended_for_user_types`).
-
-## Purpose
-
-A founder doing technical due diligence needs both `runway-cognition` and `data-flow-mapper`. A consultant pitching ghost-written thought leadership needs both `ghostwriter` and `competitive-positioning`. Pure prefix-filtering — "load consulting/* for consultants" — silos these workflows and forces the operator to re-enable skills manually.
-
-Router blending defines the mix-ratio per user-type so the resolved skill set covers the **dominant** domain plus the **bridge** skills that real workflows demand.
-
-## The blend formula
-
-```
-loaded_skills(user_type) =
-    universal_allowlist            (always — see universal-skills.md)
-  ∪ dominant_pool(user_type)       (primary domain, ≈70%)
-  ∪ bridge_pool(user_type)         (cross-domain, ≈20%)
-  ∪ context_pool(user_type)        (content / writing / safety, ≈10%)
-```
-
-Percentages are **soft caps** measured against the post-filter skill count, not hard quotas. Drift > ±10% on any pool triggers a re-tag pass and a finding in `agents/evidence/eval-findings/`.
-
-## Per user-type blends
-
-| user_type | Dominant (~70%) | Bridge (~20%) | Context (~10%) |
-|---|---|---|---|
-| **creator** | `voice-and-tone-design`, `editorial-calendar`, `content-funnel-design`, `messaging-architecture`, `release-comms` | `customer-research`, `competitive-positioning`, `voc-extract` | `privacy-review`, `accessibility-auditor` |
-| **founder** | `runway-cognition`, `unit-economics-modeling`, `fundraising-narrative`, `scenario-modeling`, `okr-tree-modeling` | `data-flow-mapper`, `threat-modeling`, `api-design` | `voice-and-tone-design`, `release-comms` |
-| **consultant** | `discovery-interview`, `competitive-moat-analysis`, `competitive-positioning`, `stakeholder-tradeoff`, `customer-research` | `messaging-architecture`, `voice-and-tone-design`, `release-comms` | `privacy-review`, `data-handling-judgment` |
-| **gtm** | `pipeline-strategy`, `forecast-accuracy`, `deal-qualification-meddic`, `gtm-launch`, `release-comms` | `voice-and-tone-design`, `messaging-architecture`, `voc-extract` | `privacy-review`, `unit-economics-modeling` |
-| **finance** | `runway-cognition`, `unit-economics-modeling`, `scenario-modeling`, `forecasting`, `dcf-modeling` | `data-handling-judgment`, `privacy-review`, `contracts-cognition` | `voice-and-tone-design`, `stakeholder-tradeoff` |
-| **ops** | `incident-commander`, `data-handling-judgment`, `privacy-review`, `dashboard-design`, `launch-readiness` | `threat-modeling`, `secrets-management`, `api-design` | `voice-and-tone-design`, `release-comms` |
-| **developer** | language-/framework-keyed pool (laravel · nextjs-patterns · php-coder · …) | `api-design`, `authz-review`, `playwright-architect`, `threat-modeling` | `voice-and-tone-design`, `release-comms` |
-
-Each pool entry is a `recommended_for_user_types:` frontmatter tag on the skill. A skill with no tag is **universal** (see [`universal-skills.md`](universal-skills.md)).
-
-## How the loader resolves a profile
-
-1. **Read** `.agent-config.local.json` → `user_type`.
-2. **Filter** all 210 skills: keep the skill iff `user_type ∈ recommended_for_user_types` **or** `recommended_for_user_types` is absent (universal).
-3. **Stack overlay.** If `stack` is set (laravel / nextjs / python / …), also keep skills whose body cites that stack — language-keyed bridge. Implementation: pattern match on the skill `description:` frontmatter; details land with the schema-rigor contract once the schema bridge for stack-keyed bridge tagging is finalised.
-4. **Cap.** No filter is applied if the result drops below 50 skills (safety floor — under-filtering is recoverable, over-filtering hides essentials).
-5. **Surface** `loaded_skills_count` + per-pool counts in the agent debug output.
-
-## Drift detection
-
-`scripts/check_router_blend.py` (to ship with Phase 5) walks each user-type and reports:
-
-- Dominant-pool fraction (must be ≥ 0.55).
-- Bridge-pool fraction (≥ 0.15).
-- Empty-pool sentinel: any user-type with zero bridge tags fails the check.
-
-Wired into `task ci` as a non-blocking warning until the user-types axis stabilizes; promoted to blocking once `step-9` ships its three seed user-types.
-
-## Open questions (tracked for Phase 5 → Phase 6 transition)
-
-- Stack overlay precedence: framework tag vs. user-type tag — currently union, may want intersection for the `developer + laravel` combo. Empirical question, tested by corpus.
-- Cross-domain explicit opt-in: `agent-config skills enable <name>` to override the filter on demand. Not in scope for Phase 5 — opens once the filter ships.
-- Persona ↔ user-type mapping: a `consultant` user_type may default to `discovery-lead` persona, but personas are role-axis, not user-axis. Final mapping resolved with [`docs/contracts/persona-schema.md`](persona-schema.md).
-
-## Related
-
-- [`universal-skills.md`](universal-skills.md) — the always-loaded floor under the blend.
-- [`skill.schema.json`](../../src/scripts/schemas/skill.schema.json) — `recommended_for_user_types` field that carries the tags.
-- [`tests/eval/corpus-non-dev.yaml`](../../tests/eval/corpus-non-dev.yaml) — empirical validation of the blends.