@keighleykodric/weeve 0.1.0 → 0.1.2

package/WORKFLOW.md

@@ -1,354 +0,0 @@
-# WORKFLOW.md — Cross-pack rhythm
-
-How ideas move from raw capture through to shipped code. This is the canonical doc for the cross-pack workflow. All sibling pack READMEs cite this file.
-
----
-
-## The rhythm in one sentence
-
-> Capture raw ideas in your preferred tool. Each lane's intake skill routes them. Lanes process their slice. Recommendations accumulate. Pilot synthesizes and ships.
-
----
-
-## The full flow
-
-```
-Your capture tool (notes, daily log, Obsidian, etc.)
-    ↓ raw capture
-*-intake skills (per pack)
-    ↓ scoped rows with stable IDs
-Pack main skills (primitives, zones, layers, campaigns)
-    ↓ structured findings
-<pack>-recommendations.md (the recommendations file)
-    ↓ one file per pack in docs/<pack>/
-/pilot-roadmap
-    ↓ merged, tiered, conflict-surfaced
-docs/pilot/pilot-roadmap.md
-    ↓
-/pilot-ship
-    ↓ N items per day, guardrails, PR
-shipped code
-```
-
----
-
-## Step by step
-
-### Step 1 — Raw capture
-
-Every idea, observation, or strategic thought gets captured first — in whatever tool you use. A daily note, an Obsidian vault, a plain text file. The goal is capture, not routing — get it down before it evaporates.
-
-```
-User-to-user referral program — tight community, peer vouching,
-low CAC. Maps to Compass doctrine + Layers+ Layer 4-7 + Maven channel strategy.
-```
-
-This goes in your project notes. You can also skip straight to Step 2 and capture directly via intake skills.
-
-> **Tip:** [Claudette](https://github.com/keighleykodric/claudette) is a personal CLI companion built for this workflow — `/research`, `/todo`, `/focus` commands that feed naturally into Weeve's intake skills. Not required, but designed to pair well.
-
-### Step 2 — Route to lanes via intake skills
-
-Once captured, route the idea to the lanes that own slices of it. Each lane has an intake skill that accepts raw intent — paste in whatever context you have — and writes a scoped row with a stable ID.
-
-**What to include with your intake:** The more context you provide, the better the intake skill can scope the work. Include any of:
-- The idea or observation in your own words
-- Links to relevant docs, tickets, or threads
-- File paths or folder references in your codebase
-- Screenshots, error messages, or user feedback
-- Ticket/issue IDs from your project tracker
-
-The intake skill will ask clarifying questions if it needs more.
-
-```
-/compass-intake    → CI-prefixed row → routes to compass-position / compass-move
-/layers-plus-intake → LI-prefixed row → routes to layers-plus-strategy / surface
-/ally-intake       → AI-prefixed row → routes to ally zone audit
-/rubric-intake     → RI-prefixed row → routes to rubric-components / patterns
-/maven-intake      → MI-prefixed row → routes to maven-campaign-plan / deliverable
-```
-
-One idea may produce intake rows in multiple packs if it spans strategy, product, and channel.
-
-### Step 3 — Packs process their slice
-
-Each pack's main skills process the intake rows. They write findings to their output files under `docs/<pack>/` in the consumer project.
-
-- Compass primitives + lenses → findings in `compass-*.md`
-- Layers+ layers → findings in `layers-plus-*.md`
-- Ally zones → findings in `ally-*.md`
-- Rubric zones → findings in `rubric-*.md`
-- Maven phases → findings in `maven-*.md`
-
-Each pack is autonomous — it doesn't need the others to run.
-
-### Step 4 — Recommendations: the shared output format
-
-Each pack writes a `<pack>-recommendations.md` file — the recommendations file Pilot reads. This file is the distilled, tiered, prioritized output of all the pack's work. It's the only file Pilot needs from each pack.
-
-```
-docs/compass/compass-recommendations.md
-docs/layers-plus/layers-plus-recommendations.md
-docs/ally/ally-recommendations.md
-docs/rubric/rubric-recommendations.md
-docs/maven/maven-recommendations.md
-```
-
-### Step 5 — Pilot synthesizes: /pilot-roadmap
-
-`/pilot-roadmap` reads all `<pack>-recommendations.md` files present, merges them into one prioritized backlog, surfaces cross-pack conflicts, and writes `docs/pilot/pilot-roadmap.md`.
-
-Items are tiered: Now → Next → Watch. Cross-pack conflicts are surfaced explicitly — Pilot does not silently pick a side.
-
-### Step 6 — Pilot ships: /pilot-ship
-
-`/pilot-ship` picks N items from the roadmap, executes against guardrails (constraints, design system health, accessibility health), and opens or updates a PR.
-
-One daily batch, one check-in, one PR.
-
----
-
-## The worked example — user-to-user referral
-
-A strategic idea decomposed across the full system. This is the canonical illustration of how a cross-cutting idea flows. The route-then-decompose pattern is identical for any cross-functional setting: a SaaS team routing a growth initiative across strategy and delivery, a consulting firm coordinating an engagement across strategy and operations, a nonprofit aligning programme design with communications and fundraising.
-
-### The idea
-
-Existing users send a personalized referral link to a peer who isn't on the platform. Link carries context (referrer ID, prefilled profile, voucher message). Recipient lands on a guided signup that knows who sent them. Referring user sees status updates. Reward: free month per successful referral.
-
-### Why it spans multiple packs
-
-| Pack | Its slice |
-| --- | --- |
-| Compass | Strategic bet: is referral the right growth wedge? Which doctrine supports it? |
-| Layers+ | Product surface: how does referral become a first-class product object? |
-| Maven | Channel: how do we announce the program and sustain referral messaging? |
-
-### How it flows
-
-| Step | Tool | What happens |
-| --- | --- | --- |
-| 1 | Your notes / capture tool | Raw capture: "User-to-user referral program — tight community, peer vouching, low CAC." Lands in project notes. |
-| 2 | `/compass-intake` | Strategic slice captured: "Codify referral-as-growth-wedge as doctrine; specific move = build user-to-user invite mechanic." Writes CI-prefixed row. |
-| 3 | `/compass-doctrine`, `/compass-move` | Process intake. Writes doctrine row (D-prefixed) and move row (M-prefixed). |
-| 4 | `/layers-plus-intake` | Product slice: "Build referral as first-class product surface — Layer 4 strategic bet, Layers 5-7 implementation." Writes LI-prefixed row. |
-| 5 | `/layers-plus-strategy`, `/layers-plus-conceptual-model`, `/layers-plus-interaction-flow`, `/layers-plus-surface` | Each layer processes its scoped rows. |
-| 6 | `/maven-intake` | Channel slice: "Plan referral program announcement + ongoing referral messaging." Writes MI-prefixed row. |
-| 7 | `/maven-campaign-plan`, `/maven-deliverable` | Process intake. Writes campaign plan and deliverable rows. |
-| 8 | `/compass-recommendations`, `/layers-plus-recommendations`, `/maven-recommendations` | Each pack writes its prioritized recommendations. |
-| 9 | `/pilot-roadmap` | Reads all three recommendations files. Synthesizes one backlog. Referral shows as one tracked initiative with strategy, product, and channel slices. |
-| 10 | `/pilot-ship` | Picks N items, executes, opens PR. |
-
-### Key pattern
-
-Single-pack ideas exist ("add a tooltip on the time-window picker" → Layers+ only). Most strategic ideas don't. The route-then-decompose pattern handles both:
-
-- A tooltip change is one intake row.
-- A growth wedge is six.
-
-**Heuristic:** if you're not sure where it lands, ask "what's the *highest* tier this touches?" Start there and let it cascade. The referral idea's highest tier is Compass (strategic bet about *how we grow*). Start there.
-
----
-
-## First-run order
-
-When setting up the system from scratch, run packs in this order. Each step produces inputs that make the next step richer.
-
-```
-1.  Compass    — establish strategic position and growth doctrine
-2.  Layers+    — evaluate product design against that strategy
-3.  Felt       — audit user research posture; feeds observed-behaviour and user-needs
-4.  Ally       — audit accessibility on the existing surface
-5.  Rubric     — audit design system health
-6.  Maven      — develop marketing positioning and brand voice
-7.  Pitch      — audit revenue health and GTM execution (reads Maven positioning)
-8.  Pilot      — synthesize all recommendations files
-```
-
-**Why this order:** Compass sets the strategic frame; Layers+ uses it. Felt runs after Layers+ because its research output (felt-research.md, felt-personas.md) feeds directly into layers-plus-observed-behaviour and layers-plus-user-needs confidence ratings — run Layers+ first to know what research questions are open, then run Felt to answer them. Ally and Rubric are parallel (order between them doesn't matter). Maven reads Compass and Layers+ outputs for positioning context. Pitch runs after Maven — it checks whether the positioning is landing in deals and co-owns the Marketing→Sales lead handoff. Pilot reads all. (Forge/Helm/Verify/Guard can run in parallel after Layers+; see PITCH-LANE.md for the full 11-lane sequencing.)
-
-Packs can be run in any order — this sequence is the recommended path for a first full run, not a hard dependency.
-
----
-
-## Within-pack sequences
-
-Cross-pack order is in the First-run order section above. Within each pack, skills run in a defined sequence. Steps marked _(optional)_ can be skipped on first run and added on re-runs or when the area is relevant.
-
-### Compass
-
-```
-/compass-intro          — onboarding; load once per project
-/compass-orient         — broad diagnostic; shows which primitives are missing
-/compass-position       — what you have, who your customers are, which markets
-/compass-context        — external forces, trends, competitor moves
-/compass-doctrine       — operating principles and anti-patterns
-/compass-choice         — active strategic choices and decisions
-/compass-move           — strategic moves in flight
-Lens skills (pick relevant ones):
-  /compass-wardley      — Wardley map; evolution and ecosystem position
-  /compass-jtbd         — Jobs-to-be-done; primary market and outcomes
-  /compass-7powers      — 7 Powers; defensibility check
-  /compass-market-research  — (optional) external signal probe
-/compass-recommendations — tiered move list from all lens outputs
-```
-
-### Layers+
-
-```
-/layers-plus-intro      — onboarding; load once per project
-/layers-plus-orient     — broad diagnostic across all seven layers
-/layers-plus-user-needs — formalise user needs and job stories
-/layers-plus-domain     — domain concepts, terminology, constraints
-/layers-plus-conceptual-model — product objects, relationships, key attributes
-/layers-plus-interaction-flow — task flows, decision points, failure paths
-/layers-plus-surface    — screens, UI surfaces, component inventory
-/layers-plus-observed-behaviour  — (optional) user research synthesis
-/layers-plus-strategy   — opportunity map tied to user needs
-/layers-plus-recommendations — prioritised improvement list
-```
-
-### Felt
-
-```
-/felt-intro             — onboarding; load once per project
-/felt-orient            — broad diagnostic across all seven research zones
-Zone skills (run the zone with the biggest gap first):
-  /felt-research        — generative research coverage audit
-  /felt-testing         — usability and evaluative test coverage audit
-  /felt-data            — analytics instrumentation and funnel audit
-  /felt-journey         — journey map coverage and pain point catalogue
-  /felt-personas        — segment definitions and JTBD validity audit
-  /felt-synthesis       — affinity maps, themes, HMW statements
-  /felt-feedback        — NPS, CSAT, support tickets, app reviews
-Ad hoc:
-  /felt-intake          — capture research requests and observations any time
-Output (on demand from zone data):
-  /felt-report          — stakeholder-ready research readout
-  /felt-recommendations — tiered research gap list (Pilot reads this)
-Maintenance:
-  /felt-triage          — walk open findings; close / defer / dismiss
-  /felt-check           — verify closed findings are actually resolved
-  /felt-tickets         — push findings to task management
-  /felt-dashboard       — HTML visual status dashboard
-```
-
-### Ally
-
-```
-/ally-intro             — onboarding and zone framework; load once per project
-/ally-map               — route inventory + broad pass across all 7 zones
-/ally-landscape         — bottleneck analysis; recommends which zone to address next
-Zone skills (run the zones landscape recommends first):
-  /ally-bones           — semantic structure, landmarks, relationships
-  /ally-flow            — keyboard nav, focus management, wayfinding
-  /ally-signal          — contrast, text alternatives, media
-  /ally-control         — input, touch, pointer, errors, forms
-  /ally-ease            — time limits, language, reading level
-  /ally-calm            — flashing, harmful motion, sensory overwhelm
-  /ally-reach           — AT compatibility, screen readers, name/role/value
-Output (on demand from audit data):
-  /ally-plan            — ally-recommendations.md (Pilot reads this)
-  /ally-status          — team health snapshot
-  /ally-report          — org/leadership progress view
-```
-
-### Rubric
-
-```
-/rubric-intro           — onboarding; load once per project
-/rubric-gap [topic]     — (optional) trace a gap cascade before the zone audits
-Zone audits (run in order; each builds on the last):
-  /rubric-tokens        — foundations: CSS tokens, colour, spacing
-  /rubric-components    — component inventory and conformance
-  /rubric-patterns      — layout patterns, page templates
-  /rubric-voice         — copy tone, vocabulary, Tier 1/2/3 conventions
-/rubric-audit           — full sweep across all four zones
-/rubric-recommendations — prioritised system improvements (Pilot reads this)
-```
-
-### Maven
-
-```
-/maven-intake           — route raw observations to Maven; writes stable IDs
-/maven-positioning      — ICP, problem statement, unique attribute
-/maven-brand-voice      — tone, vocabulary, voice rules
-/maven-channel-monitor  — (optional) monitor live channel signals
-/maven-campaign-plan    — campaign design for a specific motion
-Deliverables (on demand):
-  /maven-deliverable    — one-pager, case study, or other artifact
-  /maven-social         — platform-specific social posts
-  /maven-email          — email sequence
-  /maven-battlecard     — competitive battlecard
-  /maven-seo            — keyword and content gap analysis
-/maven-recommendations  — prioritised marketing improvements (Pilot reads this)
-```
-
-### Pitch
-
-```
-/pitch-intake           — route raw sales observations (deals, objections, patterns)
-/pitch-orient           — diagnostic sweep; surfaces bottleneck zone
-Zone audits (run weekly or on trigger):
-  /pitch-pipeline       — stage distribution, velocity, stall rate, coverage
-  /pitch-icp            — deal-level ICP fit and qualification discipline
-  /pitch-conversion     — stage-to-stage drop-off, deal size, time-to-close
-  /pitch-competitive    — win/loss patterns, battlecard accuracy
-  /pitch-outreach       — sequence performance, channel mix, positioning alignment
-  /pitch-proposal       — discovery quality, demo effectiveness, reference coverage
-  /pitch-pricing        — discount discipline, pricing floor, pricing power
-  /pitch-leads          — marketing → sales handoff (co-owned with Maven)
-  /pitch-forecast       — commit-to-close rate, methodology health
-  /pitch-handoff        — sales → CS handoff quality, early churn indicators
-/pitch-recommendations  — prioritised sales moves (Pilot reads this)
-```
-
----
-
-## Cadence
-
-| Pack | Typical cadence |
-| --- | --- |
-| Ally | Weekly (change detection) |
-| Rubric | Weekly (drift detection) |
-| Felt | On-demand (after each research study; quarterly hygiene sweep) |
-| Layers+ | Monthly or on-demand (deeper, slower-changing) |
-| Compass | Quarterly (strategic position) |
-| Maven | On-demand (campaign-driven) |
-| Pitch | Weekly (pipeline, conversion, forecast); on-trigger for competitive, pricing, handoff |
-| Pilot `/roadmap` | After any pack refreshes its recommendations |
-| Pilot `/ship` | Daily (autonomous batch) |
-
----
-
-## Roadmap refresh triggers
-
-`/pilot-roadmap` should be re-run when one of three trigger types fires. Running it on an arbitrary schedule produces noise; running it only when these triggers fire keeps it signal-dense.
-
-**Milestone trigger** — re-run after any of:
-- A pack completes a run and writes a new `<pack>-recommendations.md`
-- A ship batch closes (all Now items shipped → re-read to confirm and promote Next items)
-- A new pack is installed or an existing pack is significantly revised
-
-**Signal trigger** — re-run immediately when a Watch item escalates:
-- Any P-W item fires (competitor announcement, platform shift, external adopter feedback)
-- A constraint in `docs/business.md` changes (e.g., a legal or business blocker resolves)
-- A significant blocking finding is confirmed that wasn't in the current roadmap
-
-**Time-based floor** — re-run at minimum once per quarter, even if no milestone or signal trigger has fired. Quarterly runs catch slow drift: Watch items that have aged past their revisit date, Next items whose effort estimates are now stale, constraints that have silently become unblocked.
-
-**Who triggers it:** The Pilot operator (see GOVERNANCE.md § Roles). On teams, any pack owner can request a re-run by opening a PR to update their `<pack>-recommendations.md` and tagging the Pilot operator for review.
-
-**What happens after a re-run:** Compare the new `pilot-roadmap.md` diff against the prior version. If any Now items changed tier, or any new conflicts surfaced, notify pack owners before starting the next `/pilot-ship` batch.
-
----
-
-## Pack independence
-
-Every pack works standalone. The workflow above is opt-in, not required. A designer can run Layers+ alone. A strategist can run Compass alone. Cross-pack references are citations — each pack degrades gracefully when sibling outputs are absent.
-
-**The one exception:** Pilot needs at least one pack to have written a `<pack>-recommendations.md` file. With no packs writing recommendations, Pilot has nothing to synthesize. This is stated plainly in Pilot's README.
-
----
-
-*Maintained in [keighleykodric/weeve-pilot](https://github.com/keighleykodric/weeve-pilot). All sibling pack READMEs cite this file.*

package/docs/shared/engineering-pack-contract.md

@@ -1,94 +0,0 @@
-# Engineering pack — contract shape
-
-_Pilot reference document · Draft 2026-05-23_
-
-This document defines the contract shape for a future engineering pack — what `engineering-recommendations.md` would contain, how findings are tiered, and how Pilot synthesizes it alongside strategy, product, accessibility, design system, and marketing outputs.
-
-**Purpose:** Claim the dev lane by defining the schema now, before it's filled. Anyone building an engineering pack for this family has a conformant target to hit. ClaudeFast and successor tools become plug-in candidates rather than competitors.
-
----
-
-## What the engineering domain covers
-
-The engineering domain audits the operator's technical foundation — not whether the product works (that's QA) but whether the team can ship it safely, repeatedly, and at speed.
-
-| Subdomain | Questions it asks |
-|---|---|
-| CI/CD pipeline | Is every change tested before merge? Is the deploy path automated and auditable? |
-| Infrastructure | Are environments reproducible? Is there a paper trail for who changed what? |
-| Security posture | Are secrets managed correctly? Are dependencies audited? Is access scoped? |
-| Test coverage | Are the right things tested at the right level (unit / integration / e2e)? |
-| Observability | Can the team detect, diagnose, and recover from failures without tribal knowledge? |
-| Technical debt | Is debt tracked, prioritised, and scheduled — or just accumulated? |
-
-The engineering pack audits the operator's *shipping system*, not the product's feature set. Stays in its lane.
-
----
-
-## `engineering-recommendations.md` — the output recommendations file
-
-Follows the shared schema (`docs/shared/recommendations-schema.md` v0.1). Three tiers, stable IDs, evidence-traced.
-
-### Tier 1 — Foundations (fix first)
-
-Items that block safe, reliable shipping. Examples:
-
-```
-ENG-T1-1 · 🔴 High · CI/CD · No automated tests run on PR · Every merge is manual trust. Add a test-runner step to the PR pipeline before merge is allowed. · Effort: S
-ENG-T1-2 · 🔴 High · Security · Secrets in source control · Rotate affected credentials immediately; move to env var management (Vault, Doppler, or platform secrets). · Effort: XS
-ENG-T1-3 · 🟡 Medium · Observability · No structured error logging · Errors surface as user complaints, not alerts. Add structured logging to critical paths; wire to an alerting channel. · Effort: M
-```
-
-### Tier 2 — Layer-specific
-
-Targeted improvements within a subdomain once foundations are stable.
-
-```
-ENG-T2-1 · 🟡 Medium · CI/CD · Deploy pipeline has no rollback path · One bad deploy requires manual intervention. Add a rollback trigger to the pipeline. · Effort: S
-ENG-T2-2 · 🟡 Medium · Test coverage · No integration tests for critical user flows · Unit tests pass but flows break at seams. Add integration tests for checkout, auth, and payment paths. · Effort: M
-```
-
-### Tier 3 — Polish
-
-Self-contained improvements with no dependencies.
-
-```
-ENG-T3-1 · 🟢 Low · Technical debt · No debt register · Debt is invisible until it blocks a sprint. Create a lightweight `docs/engineering/debt.md` with known items, effort estimates, and revisit triggers. · Effort: XS
-```
-
----
-
-## Pilot synthesis — how it integrates
-
-Pilot reads `engineering-recommendations.md` the same way it reads any pack output: looks for the `## Tier 1`, `## Tier 2`, `## Tier 3` sections, extracts items, merges with other pack findings, and surfaces cross-pack conflicts.
-
-**Expected cross-pack citations:**
-
-| Engineering finding | Cross-pack implication |
-|---|---|
-| No CI pipeline | Ally finding fixes may not ship (no automated gate) — cite in ally-recommendations |
-| No rollback path | Rubric token changes are risky without rollback — cite in rubric-recommendations |
-| Secrets in source control | Compass strategic moves gated on security posture — cite in compass-recommendations |
-| No observability | Layers+ interaction flow findings can't be validated in prod — cite in layers-plus-recommendations |
-
-Pilot surfaces these cross-pack conflicts explicitly in `pilot-roadmap.md` rather than silently picking a side.
-
----
-
-## ID prefix
-
-Engineering pack uses `ENG-` prefix for all finding IDs. Tier label included: `ENG-T1-`, `ENG-T2-`, `ENG-T3-`.
-
-Qualified cross-pack reference format (per `docs/shared/id-prefix-reference.md`): `ENG::ENG-T1-1`.
-
----
-
-## Why now
-
-The Claude Code skills ecosystem had 15,134 repos indexed by May 2026 and is commoditising. Every adjacent tool (ClaudeFast, Copilot Workspace, Cursor) will eventually cover engineering workflows. The contract shape — what `engineering-recommendations.md` *is* — is at Genesis stage. Defining it now means future tools that want to plug into this family have a target to conform to, rather than a format to compete with.
-
-This document is the lane claim. The engineering pack itself can be built by any contributor (internal or external) once the recommendations file shape is clear.
-
----
-
-_Maintained in pilot/docs/shared/ · Referenced by: pilot-roadmap skill, compass-recommendations SR4_

package/docs/shared/id-prefix-reference.md

@@ -1,235 +0,0 @@
-# Cross-pack ID prefix reference
-
-_Version: 0.2_
-_Published: 2026-05-24_
-_Scope: All lanes — Compass, Layers+, Ally, Rubric, Maven, Forge, Helm, Verify, Guard, Charter, Anchor, Ledger, Roster, Pitch, Pilot_
-
-Finding IDs are pack-local. Each pack uses its own prefix system. This document is the single cross-pack reference so Pilot can synthesise across packs without ID collisions.
-
----
-
-## Pilot
-
-Pilot generates its own IDs when synthesising across packs.
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `P-N` | Now batch (current sprint) | `P-N1`, `P-N7` |
-| `P-X` | Next / cross-pack backlog item | `P-X5`, `P-X18` |
-| `P-B` | Backlog (pre-prioritised) | `P-B1` |
-| `P-W` | Watch signal | `P-W1`, `P-W14` |
-
----
-
-## Compass
-
-Compass uses a two-part ID system: primitive-layer prefixes for raw findings, and `SR` prefixes for synthesised strategic recommendations.
-
-**Primitive findings (within pack):**
-
-| Prefix | Layer | Example |
-|---|---|---|
-| `CI` | Context item (external forces) | `CI5` |
-| `D` | Doctrine finding | `D6` |
-| `J` | JTBD lens finding | `J1`, `J3` |
-| `M` | Move finding | `M1` |
-| `P` | 7 Powers finding | `P2`, `P3` |
-| `W` | Wardley lens finding | `W1`, `W3` |
-| `C` | Choice finding | `C1`, `C4` |
-
-**Synthesised recommendations (Pilot-readable recommendations file):**
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `SR` | Strategic recommendation (tiered) | `SR1`, `SR6` |
-
----
-
-## Layers+
-
-Layers+ uses layer-prefixed finding IDs that reflect the seven-layer model. Cross-lens suffixes are appended when findings span accessibility or design system concerns.
-
-| Prefix | Layer | Example |
-|---|---|---|
-| `OB` | Observed behaviour | `OB1`, `OB2` |
-| `D` | The domain | `D1` |
-| `UN` | User needs | `UN1` |
-| `ST` | Strategy | `ST1`, `ST2` |
-| `CM` | Conceptual model | `CM2`, `CM-A1`, `CM-DS1` |
-| `IF` | Interaction flow | `IF1`, `IF-A1`, `IF-DS1` |
-| `SU` | Surface | `SU4`, `SU-AP1`, `SU-AR1` |
-
-Cross-lens suffix convention:
-- `-A` — accessibility sub-finding (routes to Ally)
-- `-DS` — design system sub-finding (routes to Rubric)
-- `-AP` — accessibility, primary concern
-- `-AR` — accessibility, reach/AT concern
-
-**Synthesised recommendations (Pilot-readable recommendations file):**
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `T1-` | Tier 1 recommendation | `T1-1`, `T1-4` |
-| `T2-` | Tier 2 recommendation | `T2-1`, `T2-7` |
-| `T3-` | Tier 3 recommendation | `T3-1`, `T3-4` |
-
----
-
-## Ally
-
-Ally uses zone-prefixed finding IDs. Zone abbreviations match the seven Ally zones.
-
-| Prefix | Zone | Example |
-|---|---|---|
-| `Bones-` | Semantic structure | `Bones-M1` |
-| `Flow-` | Keyboard nav / focus | `Flow-M1` |
-| `Signal-` | Contrast / text alternatives | `Signal-M1`, `Signal-M2` |
-| `Control-` | Input / form handling | `Control-M1` |
-| `Ease-` | Cognitive ease / readability | `Ease-H1`, `Ease-M1` |
-| `Calm-` | Motion / sensory | `Calm-L1` |
-| `Reach-` | AT compatibility | `Reach-M1`, `Reach-L1` |
-
-Severity suffix: `-H` (High), `-M` (Medium), `-L` (Low), followed by a sequence number.
-
-Dashboard-specific findings use `Dashboard-Manual-N`.
-
-**Synthesised recommendations (Pilot-readable recommendations file):**
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `T1-` | Tier 1 recommendation | `T1-1`, `T1-3` |
-| `T2-` | Tier 2 recommendation | `T2-1`, `T2-7` |
-| `T3-` | Tier 3 recommendation | `T3-1`, `T3-2` |
-
----
-
-## Rubric
-
-Rubric uses a gap cascade ID system for tickets and cross-references zone-prefixed IDs for findings.
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `G[N]-T[N]` | Gap cascade ticket (Gap number – Ticket number) | `G1-T1`, `G1-T7` |
-
-Zone findings within Rubric audits use the same zone abbreviations as Ally (Foundations, Components, Patterns, Voice, Quality gate, Governance, Adoption, Multi-brand) but without standardised short-codes in the current version.
-
-**Synthesised recommendations (Pilot-readable recommendations file):**
-
-Rubric currently maps its findings to `rubric-recommendations.md` without a formal Tier ID system. Findings are referenced by gap cascade ID (`G1-T1` etc.) or descriptive label. A formal tier structure is a pending addition.
-
----
-
-## Maven
-
-Maven uses `MR` (Maven Recommendation) prefixes for its synthesised output.
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `MR` | Maven recommendation | `MR1`, `MR4` |
-
----
-
-## Forge
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `FR` | Forge recommendation | `FR1`, `FR4` |
-
-Intake IDs are lane-internal (`I<n>`) and not propagated to Pilot.
-
----
-
-## Helm
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `HR` | Helm recommendation | `HR1`, `HR3` |
-
----
-
-## Verify
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `VR` | Verify recommendation | `VR1`, `VR2` |
-
----
-
-## Guard
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `GR` | Guard recommendation | `GR1`, `GR5` |
-
----
-
-## Charter
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `CR` | Charter recommendation | `CR1`, `CR2` |
-
----
-
-## Anchor
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `AR` | Anchor recommendation | `AR1`, `AR3` |
-
----
-
-## Ledger
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `LR` | Ledger recommendation | `LR1`, `LR2` |
-
----
-
-## Roster
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `RO` | Roster recommendation | `RO1`, `RO2` |
-
----
-
-## Pitch
-
-| Prefix | Meaning | Example |
-|---|---|---|
-| `PR` | Pitch recommendation | `PR1`, `PR3` |
-
----
-
-## Raw capture (pre-intake)
-
-The raw capture step (your notes, daily log, or personal CLI tool) does not generate finding IDs — captured items are routed to the appropriate lane's intake skill, which assigns lane-local IDs.
-
----
-
-## Collision risk at Pilot synthesis
-
-**Known collision risks:**
-
-| Pack A | Pack B | Colliding prefix | Notes |
-|---|---|---|---|
-| Compass `D` | Layers+ `D` | `D` | Both use `D` for doctrine/domain findings |
-| Compass `M` | Pilot `P-N` | Low risk | Different contexts |
-| Ally T1/T2/T3 | Layers+ T1/T2/T3 | `T1-`, `T2-`, `T3-` | Same tier numbering, different packs — always qualify with pack name when cross-referencing |
-
-**Convention:** When Pilot synthesises across packs, prefix all cited finding IDs with the pack abbreviation:
-
-```
-compass:SR3      → Compass strategic recommendation 3
-layers:T2-7      → Layers+ tier 2, item 7
-ally:Ease-H1     → Ally Ease zone, High severity, finding 1
-rubric:G1-T5     → Rubric gap cascade 1, ticket 5
-maven:MR3        → Maven recommendation 3
-```
-
----
-
-_Closes: Layers+ CM-DS2 🟡 (no cross-pack ID reference)_
-_Generated: 2026-05-23 · pilot-ship batch_