feat(ultraplan-local): v2.3.1 — qualified slug convention for cc-architect-catalog

Resolves v2.3.0 dogfood collision: skill-factory produced a
specialized hooks-pattern.md draft that would have overwritten the
generic seed. Qualified slugs let one feature host multiple named
patterns at different abstraction levels.

Slug convention: <cc_feature>[-<qualifier>]-<layer>.md. Unqualified =
canonical baseline. Qualified = sub-pattern (e.g., hooks-observability-
pattern.md) that does not displace the baseline.

Changes:
- SKILL.md: slug convention section, coverage-table qualified column,
  matcher logic for N patterns per feature, modification rules cover
  qualified-vs-canonical choice and collision handling.
- feature-matcher: catalog map is cc_feature -> {layer -> [skills]};
  selection rules (baseline by default, qualified when justified,
  multi-skill when non-overlapping); supporting_skill accepts list.
- gap-identifier: adds pattern_count[cc_feature] to coverage audit.
- architecture-critic: supporting-skill verification — every cited
  skill name must exist in the catalog (blocker severity).
- First qualified skill: hooks-observability-pattern.md (promoted from
  .drafts/, source ai-psychosis/README.md, ngram-overlap 0.01).
- Version bump 2.3.0 -> 2.3.1 across plugin.json, badges, table, root
  CLAUDE.md, CHANGELOG.

Non-breaking: existing unqualified slugs keep working, no cc_feature
taxonomy changes, hallucination gate unchanged.

plugins/ultraplan-local/agents/architecture-critic.md

@@ -66,6 +66,14 @@ the catalog or fallback list.
 catalog, this is a **major** finding (REVISE — the feature is real but
 the catalog has a coverage gap worth surfacing), not a blocker.
 
+**Supporting-skill verification:** `supporting_skill` entries (one or
+more skill names per feature, following the
+`<feature>[-<qualifier>]-<layer>.md` convention) must match real files
+in the catalog. A cited skill that does not exist is a **blocker**.
+Multiple supporting skills for one feature are allowed when they cover
+non-overlapping aspects — but the `integration_note` must justify
+having more than one.
+
 ### 3. Contradiction detection
 
 Scan for internal contradictions:

plugins/ultraplan-local/agents/feature-matcher.md

@@ -47,14 +47,16 @@ enough.
 
 ### 2. Consult the catalog
 
-Read `{catalog_root}/SKILL.md` to learn the `cc_feature` taxonomy and
-layer model.
+Read `{catalog_root}/SKILL.md` to learn the `cc_feature` taxonomy, the
+layer model, and the slug convention (`<feature>[-<qualifier>]-<layer>.md`).
 
 Glob `{catalog_root}/*.md` excluding `SKILL.md`. Parse each skill's
 frontmatter:
 - `name`, `description`, `layer`, `cc_feature`, `source`, `concept`.
 
-Build an in-memory map: `cc_feature → [skill_names]`.
+Build an in-memory map: `cc_feature → {layer → [skills]}`. One feature
+can have multiple pattern-layer skills (one baseline plus zero-or-more
+qualified variants).
 
 **Fallback when the catalog is empty or unreadable:** use this
 hardcoded minimum list. Mark `fallback_used: true` in your output.
@@ -79,14 +81,37 @@ For each feature you propose, produce:
   Goal / Constraint / NFR / Success Criterion) that motivates this
   feature. Prefer verbatim quotes; paraphrase only when length forces
   it.
-- **supporting_skill** — a skill name from the catalog that supports
-  this choice, or `null` if only the fallback hint was used.
+- **supporting_skill** — one or more skill names from the catalog that
+  support this choice, or `null` if only the fallback hint was used.
+  When multiple pattern skills exist for the feature, apply the
+  selection rules below.
 - **confidence** — `high` (direct brief anchor + skill), `medium`
   (brief anchor without strong skill support, or skill match without a
   strong anchor), `low` (inferred need with no explicit anchor).
 - **integration_note** — one sentence on how this feature integrates
   with the task at hand.
 
+#### Selecting among multiple patterns per feature
+
+A feature can have a baseline pattern (`<feature>-pattern.md`) plus
+zero-or-more qualified patterns (`<feature>-<qualifier>-pattern.md`).
+When the feature is relevant to the brief:
+
+1. **Baseline by default.** If the brief's anchor is generic
+   ("need hooks for policy"), pick the unqualified `<feature>-pattern`.
+2. **Qualified when justified.** If the brief explicitly calls for the
+   qualified variant's concept (e.g., observability, migration,
+   multi-tenant), pick the qualified pattern and name it in
+   `supporting_skill`. The anchor must reference the specific aspect,
+   not just the feature.
+3. **Propose both when they cover non-overlapping aspects.** Example:
+   the brief needs both generic hook shapes *and* observability-style
+   cadence tracking — list `supporting_skill: [hooks-pattern, hooks-observability-pattern]`
+   and explain the split in `integration_note`.
+4. **Never pick a qualified pattern just because it looks fancier.**
+   If the brief does not justify the qualifier, the baseline is the
+   honest answer.
+
 ### 4. Propose feature composition
 
 After the per-feature list, write a short (3–5 bullet) note on how the
@@ -112,7 +137,7 @@ Return your response as markdown, with this structure:
 
 1. **<feature_id>** (confidence: <high|med|low>)
    - Brief anchor: "<verbatim quote from brief section X>"
-   - Supporting skill: <skill_name or "none — fallback hint">
+   - Supporting skill: <skill_name, or [skill_a, skill_b] for multi, or "none — fallback hint">
    - Integration: <one sentence>
 
 2. ...
@@ -140,7 +165,8 @@ Return your response as markdown, with this structure:
   fallback list.** That is a hallucination; `architecture-critic` will
   block it.
 - **Never invent skill names.** If you don't see a skill for a
-  feature, say "none — fallback hint".
+  feature, say "none — fallback hint". Every skill name in
+  `supporting_skill` must match a real file in the catalog.
 - **Quote the brief; don't paraphrase silently.** Reviewers need to
   verify the anchor matches.
 - **Rationale must trace to the brief.** "We should have hooks because

plugins/ultraplan-local/agents/gap-identifier.md

@@ -38,12 +38,16 @@ enough" notes. You do not propose architecture — only gaps.
 
 ### 1. Catalog audit
 
-Read `{catalog_root}/SKILL.md` to learn the taxonomy + coverage table.
-Glob `{catalog_root}/*.md` (excluding `SKILL.md`) and parse
-frontmatter. Build:
+Read `{catalog_root}/SKILL.md` to learn the taxonomy, slug convention
+(`<feature>[-<qualifier>]-<layer>.md`), and coverage table. Glob
+`{catalog_root}/*.md` (excluding `SKILL.md`) and parse frontmatter.
+Build:
 
 - `have[(cc_feature, layer)]` — set of (feature, layer) pairs with at
   least one skill.
+- `pattern_count[cc_feature]` — number of pattern-layer skills per
+  feature (useful signal for the audit; one baseline plus zero-or-more
+  qualified variants).
 
 ### 2. Read the brief + research
 
@@ -111,7 +115,7 @@ They are not issues; they are informational.
 ### Catalog coverage audit
 - Skills in catalog: N
 - Features with reference: [list]
-- Features with pattern: [list]
+- Features with pattern: [list with (feature, pattern_count) when >1]
 - Features with decision: [list]
 - Features with no coverage: [list]