@keighleykodric/weeve 0.1.0 → 0.1.2

package/docs/shared/idea-intake-pattern.md

@@ -1,99 +0,0 @@
-# Idea intake pattern
-
-_Pilot reference document · 2026-05-23_
-
-A lightweight holding area for working concepts — brand theses, competitive framing extensions, half-formed architectural bets — that aren't ready to be roadmap items but are too important to lose in a daily note.
-
-**Problem:** Raw ideas currently land in ad-hoc notes or catch-all files where they get lost or forgotten before they're ready to route anywhere. The pack intake skills (e.g. `/compass-intake`) are too heavy for a working concept — they require enough shape to produce a scoped row with a stable ID.
-
----
-
-## The holding area
-
-Create `context/ideas/` at the repo root. One file per idea, named by date and slug:
-
-```
-context/ideas/
-  2026-05-23-brand-thesis-draft.md
-  2026-05-23-engineering-lane-opportunity.md
-  2026-05-20-referral-wedge-v2.md
-```
-
----
-
-## Idea file format
-
-Minimal frontmatter, freeform body. No required fields beyond `date` and `title`.
-
-```markdown
----
-date: YYYY-MM-DD
-title: Short idea name
-tags: [compass, maven, layers-plus]   # optional — which packs this might route to
-status: raw | maturing | ready        # default: raw
----
-
-[Freeform text. No structure required. Write what you'd tell someone in a hallway.]
-
-## Possible next step
-[Optional. One line on what would make this ready to route to a pack intake skill.]
-```
-
-**Status values:**
-
-| Status | Meaning |
-|---|---|
-| `raw` | Just captured. May be wrong or incomplete. Don't act on it yet. |
-| `maturing` | Being developed. Some validation in progress. |
-| `ready` | Has enough shape to route to a pack intake skill. |
-
----
-
-## How ideas graduate
-
-An idea is ready to route when it can answer two questions:
-
-1. **Which pack owns the primary slice?** (Compass = strategic bet, Layers+ = product surface, Ally = accessibility concern, Rubric = design system gap, Maven = marketing angle)
-2. **What's the one-sentence version?** (Enough to write an intake row)
-
-When ready, run the relevant pack intake skill:
-
-```
-/compass-intake    → strategic ideas, market bets, positioning moves
-/layers-plus-intake → product design changes, UX concerns
-/ally-intake       → accessibility gaps or requirements
-/rubric-intake     → design system needs
-/maven-intake      → marketing ideas, campaign angles
-```
-
-After routing, update the idea file's status to `ready` and note which pack received it. The idea file becomes the origin story for the eventual roadmap item.
-
----
-
-## What goes here vs. elsewhere
-
-| Content type | Where it goes |
-|---|---|
-| Fully-formed strategic intent | `/compass-intake` directly |
-| Half-formed working concept | `context/ideas/` |
-| Daily capture (tasks, decisions) | Your daily note or capture tool |
-| Research findings with a clear home | `/research` in the relevant pack |
-| Confirmed roadmap item | Pack intake → pack recommendations → pilot roadmap |
-
----
-
-## Linking ideas to roadmap items
-
-When an idea graduates and becomes a roadmap item, add a reference in the idea file:
-
-```markdown
-## Routed
-Compass intake: CI-42 (2026-05-24)
-Roadmap: P-X27 (2026-05-24)
-```
-
-This creates a traceable origin trail: idea → intake row → roadmap item → ship commit.
-
----
-
-_Maintained in pilot/docs/shared/ · Pattern for: all pilot-family projects_

package/docs/shared/lane-conventions.md

@@ -1,207 +0,0 @@
-# Lane conventions
-
-Cross-cutting decisions that apply to every lane. Captured here so we don't re-litigate them per lane.
-
----
-
-## Lane → team mapping
-
-Lanes are framework concepts. Teams are org concepts. CODEOWNERS entries use the team name (function-named), not the lane name.
-
-| Lane | Owner team | CODEOWNERS entry |
-|---|---|---|
-| Compass | strategy | `@strategy-team` |
-| Layers+ | product | `@product-team` |
-| Forge | engineering | `@engineering-team` |
-| Helm | platform | `@platform-team` |
-| Verify | qa | `@qa-team` |
-| Guard | security | `@security-team` |
-| Ally | accessibility | `@accessibility-team` |
-| Rubric | design-system | `@design-system-team` |
-| Maven | marketing | `@marketing-team` |
-| Pitch | sales | `@sales-team` |
-| Charter | legal | `@legal-team` |
-| Anchor | support | `@support-team` |
-| Ledger | finance | `@finance-team` |
-| Roster | people | `@people-team` |
-| Felt | ux | `@ux-team` |
-| Pilot | leadership | `@leadership-team` |
-
-Rationale: the lane is Weeve's word for the work; the team is the org's word for the people. Org charts shift more often than framework concepts, and the CODEOWNERS file lives in the org's reality.
-
-At small/solo scale teams collapse — e.g., `@engineering-team` covers Forge, Helm, Verify, and Guard. The mapping table stays the same; what changes is which humans are in each team.
-
----
-
-## Skill suffix convention
-
-Each lane has a `-check` skill that verifies closed findings are actually resolved. The suffix is `-check`, not `-verify` — `-verify` is reserved as the lane name.
-
-Lane | Follow-up skill
---- | ---
-Forge | `/forge-check`
-Helm | `/helm-check`
-Verify | `/verify-check`
-Guard | `/guard-check`
-Ally | `/ally-check`
-Rubric | `/rubric-check`
-Maven | `/maven-check`
-Compass | `/compass-check`
-Layers+ | `/layers-plus-check`
-Felt | `/felt-check`
-
-Yes, `/verify-check` reads slightly recursive. That's the cost of having a lane named Verify and is preferable to inventing a different word per lane (`-followup`, `-confirm`, etc.) and losing tab-completion symmetry.
-
-Other standard skill suffixes across all lanes: `-intake`, `-orient`, `-recommendations`, `-dashboard`, `-tickets`, `-triage`, plus one primitive per zone.
-
----
-
-## Triage states
-
-All lanes share a base set of triage states for findings:
-
-- `open` — default; awaiting triage
-- `closed` — fix implemented; `/<lane>-check` will verify
-- `deferred` — acknowledged, scheduled for later
-- `dismissed` — not going to act on this; reason recorded
-
-Guard adds one more:
-
-- `accepted-risk` — explicit risk acceptance with an owner and a review date; lives in `guard-accepted-risks.md` rather than recommendations
-
-Verify and Helm may add this state too if adopters ask for explicit "accepted defect" or "accepted operational debt" tracking. For now, `dismissed` covers it.
-
----
-
-## Severity → ship-guardrail mapping
-
-When `/pilot-ship` runs, it consults release-relevant lanes (Guard, Verify, and any others that opt in) to decide whether to block or proceed.
-
-Default mapping — canonical reference is Guard's severity model in `GUARD-LANE.md`:
-
-| Finding severity | `/pilot-ship` behaviour |
-|---|---|
-| 🔴 Critical | **block** — must be triaged before ship in the affected area; operator override only with recorded reason |
-| 🔴 High | Now item in recommendations; escalated but doesn't gate ship |
-| 🟡 Medium | Next item; tracked with deadline; doesn't gate ship |
-| 🟢 Low | Watch tier; not surfaced at ship time |
-
-Only Critical gates ship by default. High findings are surfaced in the ship preview but ship proceeds — they belong on the next-release punch list, not as a stop-everything signal. This keeps the gate meaningful: if every High blocked, the gate stops being credible.
-
-Each lane defines what "critical/high/medium/low" means in its domain. Guard is the prototype because its severity model is the most carefully defined; Verify is the other lane that can gate ship (release-readiness blockers).
-
----
-
-## Sensitive file read-access
-
-Most framework files follow "everyone in the org can read everything; gate writes via CODEOWNERS." A few may contain information that warrants tighter read posture:
-
-- **Guard** — `guard-threat-model.md`, `guard-infra.md`: attack surface and exposure detail an attacker could use
-- **Compass** (potentially) — unreleased strategic positioning, M&A considerations, sensitive bets
-- **Layers+** (potentially) — unreleased product specifications, embargoed launch material
-
-For OSS deployments the repo's existing access model governs — keep the alignment repo private, or move sensitive lane files to a separate private repo with cross-references from the main one. This needs a documented pattern before org rollout.
-
-For SaaS deployments, per-file read access is a deferred feature in `GOVERNANCE.md`.
-
-Lanes producing sensitive output should call out the relevant files explicitly in their own draft (Guard already does this in its CODEOWNERS section). When in doubt, default to "treat as sensitive" — easier to relax later than to retract.
-
----
-
-## Intake row schema
-
-Every lane's `/<lane>-intake` skill creates rows with the same metadata so Pilot can trace any finding back to its origin without lane-specific parsing.
-
-```yaml
-id: I<N>                        # e.g., I1, I42 — lane is implied by the file it lives in
-source: <freeform string>       # e.g., "pen-test 2026-Q2", "post-mortem #34", "reviewer comment"
-reporter: <handle or email>
-date: <ISO 8601>
-evidence:                       # optional; links to artifacts
-  - type: <log|ticket|doc|url>
-    ref: <path or url>
-body: <finding text>
-```
-
-Intake IDs use `I<N>` — a simple monotonic integer within the lane. The lane name is already implied by the file (`forge-intake.md`, `guard-intake.md`, etc.) so a lane prefix in the ID is redundant. Do not use `FORGE-0142`-style IDs — they are verbose and create false symmetry with the recommendations prefix system (`FR`, `HR`, etc.), which is Pilot-readable. Intake IDs are lane-internal only and are never propagated to Pilot.
-
-Intake rows are pre-triage. They move into a zone file when a primitive skill processes them.
-
----
-
-## Tier vocabulary — pack vs Pilot
-
-There are two tier vocabularies in Weeve. They mean the same thing but live at different layers.
-
-| Context | Vocabulary | Used by |
-|---|---|---|
-| Pack recommendations files | 🔴 High / 🟡 Medium / 🟢 Low | All lanes except Compass |
-| Compass recommendations file | T1 — Act now / T2 — Plan for / T3 — Watch | Compass only |
-| Pilot merged roadmap | **Now / Next / Watch** | Pilot only — `/pilot-roadmap` output |
-
-**Rule:** Pack skills write 🔴/🟡/🟢 (or T1/T2/T3 for Compass). Pilot reads them and maps to Now/Next/Watch in the roadmap. Never use Now/Next/Watch in a lane's own recommendations file — that vocabulary belongs to the synthesis layer.
-
-Pilot's tier mapping: 🔴 High → Now, 🟡 Medium → Next, 🟢 Low → Watch. Compass T1 → Now, T2 → Next, T3 → Watch.
-
----
-
-## The four delivery lanes
-
-Forge, Helm, Verify, and Guard form a delivery group. They run together after Layers+ establishes the product model, and feed Pilot together. Within the group:
-
-- **Sequential:** Forge → Helm → Verify (each informs the next)
-- **Parallel:** Guard runs alongside, since its inputs don't depend on the others
-
-The group is referred to as "the four delivery lanes" — not as "the delivery triad plus security" or "engineering and its dependents." Security is a peer lane in the group, though it plays a distinct role: Guard is the only lane that can hard-block `/pilot-ship` by default (Verify can also gate release-readiness).
-
----
-
-## Future lanes
-
-### Planned
-
-- **People Ops** — owns team health, hiring posture, on-call sustainability, organisational capacity against roadmap. Brushes against Helm (on-call load) and Verify (triage discipline) today; planned as its own lane.
-
-### Not planned (watch for adopter pressure)
-
-- **Data / Analytics** — would own instrumentation coverage, event schema health, metric definitions, experiment infrastructure. Currently no home; Forge would absorb badly (it's not code health), Layers+ won't (it's not product model). Could become a lane or a zone in Layers+ if an adopter raises it.
-- **FinOps** — infrastructure cost is currently one zone in Helm. Could become its own lane for cost-primary adopters. Not planned; revisit if adopter pressure shows.
-- **AI / ML** — model behaviour, eval posture, prompt-injection surface, training data posture sit awkwardly across Forge / Verify / Guard. Guard's `guard-appsec` zone covers the security surface; the rest would need a dedicated lane. Not planned until Weeve has AI-product adopters at scale.
-
-### Out of scope
-
-- **HR / People management** — Pilot is a code-and-system framework, not an org framework. People Ops covers the work-systems side; broader HR is not a framework concern.
-
----
-
-## Missing prerequisite files — canonical failure path
-
-Skills read files produced by other skills. When a prerequisite file is missing, Weeve enforces one canonical behaviour: **warn and proceed**.
-
-### Pattern
-
-```
-⚠ [filename] not found — proceeding without [what it provides]. Run /[skill] to generate it.
-```
-
-Example:
-
-```
-⚠ guard-recommendations.md not found — proceeding without security findings. Run /guard-recommendations to generate it.
-```
-
-### Rules
-
-1. **Never silently skip.** If a skill expects an input file and the file is missing, the skill must emit the warning line above so the operator knows what's absent and how to produce it.
-2. **Never hard-stop on a missing optional input.** A missing recommendations file, dashboard, or intake file is not a reason to abort. The skill produces the best output it can with the inputs it has and tells the operator what's missing.
-3. **Exception: `/pilot-ship` gate-ship check.** Gate-ship is the one place a hard stop is justified. If a gate-relevant lane file (e.g., `guard-recommendations.md`, `verify-recommendations.md`) contains unresolved Critical findings — or is missing entirely when the lane is registered — `/pilot-ship` may block the release. This is by design: the gate exists to prevent shipping without safety confirmation.
-
-### Rationale
-
-- **Silent skip** hides problems. The operator sees a clean output and assumes everything was considered. This is the worst failure mode because it erodes trust invisibly.
-- **Hard stop** on optional inputs makes Weeve brittle. A solo operator running only two lanes shouldn't be blocked because a third lane's file doesn't exist yet. Weeve should degrade gracefully.
-- **Warn and proceed** gives the operator agency: they see what's missing, they know the command to fix it, and they decide whether to act now or continue.
-
----
-
-*Draft · docs/shared/lane-conventions.md · 2026-05-25*

package/docs/shared/recommendations-schema.md

@@ -1,363 +0,0 @@
----
-schema: recommendations
-version: v0.3
-date: 2026-05-24
-status: active
----
-
-# Recommendations schema — v0.3
-
-*Authoritative versioned spec for the recommendations file format that all packs produce and Pilot reads.*
-
-This document is the authoritative spec. Every pack's recommendations skill writes a file that conforms to this shape. `/pilot-roadmap` reads those files and trusts them — it does not re-evaluate upstream sources. If a pack's output diverges from this spec, Pilot's merge step degrades silently.
-
----
-
-## 1. File naming convention
-
-```
-docs/<pack>/<pack>-recommendations.md
-```
-
-| Pack | File path |
-|---|---|
-| Compass | `docs/compass/compass-recommendations.md` |
-| Layers+ | `docs/layers-plus/layers-plus-recommendations.md` |
-| Ally | `docs/ally/ally-recommendations.md` |
-| Rubric | `docs/rubric/rubric-recommendations.md` |
-| Maven | `docs/maven/maven-recommendations.md` |
-| Forge | `docs/forge/forge-recommendations.md` |
-| Helm | `docs/helm/helm-recommendations.md` |
-| Verify | `docs/verify/verify-recommendations.md` |
-| Guard | `docs/guard/guard-recommendations.md` |
-| Charter | `docs/charter/charter-recommendations.md` |
-| Anchor | `docs/anchor/anchor-recommendations.md` |
-| Ledger | `docs/ledger/ledger-recommendations.md` |
-| Roster | `docs/roster/roster-recommendations.md` |
-| Pitch | `docs/pitch/pitch-recommendations.md` |
-
-The filename is stable across re-runs. The skill overwrites in place; the roadmap always reads the latest snapshot.
-
----
-
-## 2. Required sections
-
-Every recommendations file must contain these sections, in this order:
-
-1. **Summary block** — open findings counts by severity, current bottleneck, 1–2 sentence strategy statement
-2. **Tier 1** — act now (🔴 High findings or Compass T1 moves)
-3. **Tier 2** — plan for (🟡 Medium or Compass T2)
-4. **Tier 3** — watch (🟢 Low or Compass T3)
-5. **What's working — don't disrupt** — strengths the recommendations preserve
-6. **Manual checks required** — findings that need live testing or operator judgement
-7. **Out of scope / accepted exceptions** — deferred items with rationale and revisit trigger
-
-Optional sections (present in some packs, allowed in all):
-
-- **Cross-pillar citations** — where this pack's findings link to other packs
-- **Validation gaps** (Maven) — assumptions under 🔴 / 🟡 items not yet tested
-- **Evidence trace** (Compass) — source row IDs, confidence ratings, external signal count
-
----
-
-## 3. Finding ID format
-
-Finding IDs must be stable across re-runs. If a finding is re-run and the underlying issue is unchanged, its ID does not change.
-
-### Format
-
-```
-<PACK-PREFIX><N>
-```
-
-Where `N` is a monotonically increasing integer within the pack's namespace. IDs are never reused for a different finding.
-
-### Registered pack prefixes
-
-| Pack | Prefix | Example |
-|---|---|---|
-| Compass / Strategy | `SR` | SR1, SR2 |
-| Layers+ / Tiers | `T1-`, `T2-`, `T3-` | T1-1, T2-3 |
-| Ally | `T1-`, `T2-`, `T3-` | T1-1, T2-2 |
-| Rubric | `RR` | RR1, RR2 |
-| Maven | `MR` | MR1, MR2 |
-| Forge | `FR` | FR1, FR2 |
-| Helm | `HR` | HR1, HR2 |
-| Verify | `VR` | VR1, VR2 |
-| Guard | `GR` | GR1, GR2 |
-| Charter | `CR` | CR1, CR2 |
-| Anchor | `AR` | AR1, AR2 |
-| Ledger | `LR` | LR1, LR2 |
-| Roster | `RO` | RO1, RO2 |
-| Pitch | `PR` | PR1, PR2 |
-| Felt | `FL` | FL1, FL2 |
-
-**Note on Layers+ and Ally sharing the `T1-`/`T2-`/`T3-` prefix:** both packs use tier-relative IDs rather than a pack-scoped prefix. When Pilot reads both files, it disambiguates by source file. Verbose mode tags items with their pillar: `[layers-plus:T1-1]` vs `[ally:T1-1]`. This is a known namespace collision — a future schema version may assign distinct prefixes to one or both packs.
-
-**Registering a new pack prefix:** add a row to the table above and increment the schema version.
-
----
-
-## 4. Canonical finding shape
-
-This is the most important section. Every finding — whether written as a heading block (Compass/Maven style) or a table row (Layers+/Ally/Rubric style) — must carry these five fields.
-
-```
-id · severity · location · what's wrong · what to do
-```
-
-### Field definitions
-
-| Field | Required | Description |
-|---|---|---|
-| **id** | Yes | Stable pack-prefixed ID (see §3). Never changes between re-runs for the same finding. |
-| **severity** | Yes | 🔴 High / 🟡 Medium / 🟢 Low — consistent scale across all packs (see §5). |
-| **location** | Yes | File path, skill name, zone, route, or surface. Must be specific — not "everywhere" or "the codebase". |
-| **what's wrong** | Yes | One sentence describing the gap, drift, or risk. Describes the current state, not the desired state. |
-| **what to do** | Yes | One concrete action sentence. Describes the fix or move, not the problem. |
-| **evidence trace** | Optional | Source row IDs, confidence ratings, external signal count. Required for Compass lens skills. Recommended for any finding claiming Validated confidence. |
-| **gate-ship** | Optional | `true` / `false` (default: `false`). Set to `true` on findings that must be resolved before `/pilot-ship` proceeds. Only Guard and Verify set this by default; any lane may set it. `/pilot-ship` parses this field across all packs — do not use alternative names (`block`, `block-ship`, etc.). |
-
-### Heading-block format (Compass / Maven)
-
-```markdown
-### SR1 · Short title
-
-**Move:** What to do — one concrete sentence
-**Why now:** What erodes or compounds if this is deferred
-**Effort signal:** Low / Medium / High
-**Closes findings:** [finding IDs this move resolves]
-**Evidence:** [source row IDs, confidence, weight — e.g. "P2 (Hypothesis, Central) · 0 external signals"]
-```
-
-The `**Move:**` field satisfies **what to do**. The heading title + `**Move:**` context satisfies **what's wrong** (implied from the finding being surfaced at all; "Why now:" makes the gap explicit).
-
-### Table-row format (Layers+ / Ally / Rubric)
-
-```markdown
-| ID | Severity | Location | Finding | What to do | Effort |
-|---|---|---|---|---|---|
-| T1-1 | 🔴 High | [zone / file / path] | [one sentence — what's wrong] | [one sentence — what to fix] | M |
-```
-
-The columns map directly to the canonical shape. "Effort" is an extension field — allowed in all packs, not required by the schema.
-
----
-
-## 5. Tier definitions
-
-| Tier | Name | Meaning | Compass label | Ally / Layers+ / Rubric / Maven label |
-|---|---|---|---|---|
-| T1 | Act now | Validated evidence of active erosion or a blocked user group. Deferring costs more. T1 findings must have at least one Validated input — Hypothesis-only evidence drops to T2. | T1 — Act now | 🔴 High |
-| T2 | Plan for | Gap or misalignment that will compound. Not urgent today. Schedule deliberately. | T2 — Plan for | 🟡 Medium |
-| T3 | Watch | Could escalate if an external signal changes. Review quarterly or on trigger. | T3 — Watch | 🟢 Low |
-
-The severity emoji (🔴 🟡 🟢) and the Compass tier labels are equivalent views of the same scale. Pilot maps them in both directions when building the merged roadmap.
-
----
-
-## 6. Confidence / evidence notation
-
-Use these terms consistently in evidence traces and frontmatter:
-
-| Term | Meaning |
-|---|---|
-| **Validated** | Confirmed by observed output, user data, or external signal. Anchors T1 eligibility. |
-| **Working** | Hypothesis that has been partially tested or is grounded in consistent observed behaviour. T2 default. |
-| **Hypothesis** | Assumed but not yet tested. Cannot anchor a T1 finding without at least one Validated or Working co-source. |
-
-**Frontmatter usage (Maven pattern, optional for other packs):**
-
-```yaml
-foundation: validated | hypothesis | missing
-note: "Built without validated positioning. Treat as working hypothesis."
-```
-
-**Finding row usage:**
-
-Confidence is expressed in the evidence trace field: `"P2 (Hypothesis, Central) · 0 external signals"`. If a finding has no evidence trace, Pilot assumes Working confidence.
-
----
-
-## 7. What Pilot reads — how `/pilot-roadmap` consumes this file
-
-`/pilot-roadmap` reads each pack's recommendations file as the authoritative source. It does not re-evaluate the upstream sources. The recommendations file is the unit of trust.
-
-**Extraction:** Pilot extracts per finding: ID, severity/tier, title, brief description, evidence trace, status (open / in-flight / closed / blocked). The canonical finding shape (§4) makes this extraction deterministic.
-
-**Tier mapping:**
-
-| Pack output | Roadmap tier |
-|---|---|
-| Compass T1 (Act now) | **Now** |
-| 🔴 High from any other pack | **Now** |
-| Compass T2 (Plan for) | **Next** |
-| 🟡 Medium from any other pack | **Next** |
-| Compass T3 (Watch) | **Watch** |
-| 🟢 Low from any other pack | **Watch** |
-| Closed or Retired | Dropped |
-
-**Validated-input gate:** if an item would land in **Now** but its evidence trace is Hypothesis-only or Assumed-only, Pilot demotes it to **Next** and adds a note. This gate is inherited from `/compass-recommendations` and applies across all pillars.
-
-**De-duplication:** if two packs surface findings that trace to the same source row or gap, Pilot collapses them into one roadmap item and notes that multiple pillars surfaced it. It does not write two items that rest on the same signal.
-
-**Conflict detection:** if two packs recommend opposing actions on the same surface, Pilot surfaces the conflict in the **Conflicts surfaced** section and does not silently pick a side.
-
-**Malformed file:** if a recommendations file is structurally unreadable (Pilot cannot extract IDs, tiers, or evidence), Pilot stops and surfaces the parse error. It does not write a degraded roadmap.
-
----
-
-## 8. Current conformance
-
-Assessment against the canonical finding shape (§4): id · severity · location · what's wrong · what to do.
-
-### Compass (`/compass-recommendations`)
-
-**Status: Conformant with extensions.**
-
-Compass uses heading-block format. All five canonical fields are present:
-- ID: `SR<N>` prefix, stable.
-- Severity: implied by tier (T1 = High, T2 = Medium, T3 = Watch).
-- Location: "Closes findings: [lens finding IDs]" satisfies location indirectly. Location is lens-level, not file-path-level (expected for a strategy layer).
-- What's wrong: `**Why now:**` field.
-- What to do: `**Move:**` field.
-- Evidence trace: present and required (T1 moves must cite at least one Validated source).
-
-**Divergence:** Tier 3 uses a table format (signal to watch / trigger to escalate) rather than the heading-block format used for T1/T2. This is intentional and acceptable — T3 items are signals, not moves.
-
----
-
-### Layers+ (`/layers-plus-roadmap`)
-
-**Status: Partially conformant — missing "what's wrong" (Finding) column.**
-
-Layers+ uses table-row format. The tier tables have: ID, Item (description), Layer(s), Effort, Findings closed.
-
-- ID: `T1-<N>` / `T2-<N>` / `T3-<N>` — conformant.
-- Severity: implied by tier placement — conformant.
-- Location: "Layer(s)" column satisfies location at the layer level — partially conformant (layer name, not file path or zone name).
-- What's wrong: **absent as a distinct column.** The "Item" column contains a fix description (what to do), not a gap description (what's wrong). The two-sided shape (gap + fix) is collapsed into one cell.
-- What to do: present in "Item" column.
-
-**Gap:** add a "Finding" column (what's wrong, one sentence) alongside the "Item" column (what to do). Without it, Pilot cannot extract the gap description for the **Why now** briefing in the roadmap.
-
----
-
-### Ally (`/ally-plan`)
-
-**Status: Conformant with extensions.**
-
-Ally uses table-row format with: ID, Fix, WCAG, Zones, Routes, Effort, Findings closed.
-
-- ID: `T1-<N>` / `T2-<N>` / `T3-<N>` — conformant.
-- Severity: implied by tier — conformant.
-- Location: "Zones" + "Routes" columns provide richer location than the schema requires — conformant and exceeds minimum.
-- What's wrong: the "Findings closed" column links back to zone finding IDs, which carry the gap description in their source files. The recommendations file itself does not restate what's wrong in a dedicated column.
-- What to do: "Fix" column — conformant.
-- Extra: WCAG criterion column — an Ally-specific extension, not in schema but not conflicting.
-
-**Minor gap:** the "Finding" (what's wrong) is not restated inline in the recommendations table — it's in the source zone files. Pilot must follow the finding ID back to the zone file to get the gap sentence. Adding a brief "Finding" column to the tier tables (same as Layers+ gap above) would make the recommendations file self-contained.
-
----
-
-### Rubric (`/rubric-status` → `rubric-recommendations.md`)
-
-**Status: Conformant (heading-block format, Compass-style).**
-
-Rubric uses heading-block format for T1/T2 and a table for T3. All five canonical fields are present:
-- ID: `RR<N>` — conformant.
-- Severity: implied by tier.
-- Location: "Closes findings:" field cites source finding IDs with file names — conformant.
-- What's wrong: "Why now:" field — conformant.
-- What to do: "Move:" field — conformant.
-- Evidence: present.
-
-**Note:** Rubric does not have a dedicated `/rubric-recommendations` skill — the recommendations file is produced by `/rubric-status`. The output conforms; the skill name diverges from the pattern. This is acceptable at v0.1 but should be noted for future skill naming conventions.
-
----
-
-### Maven (`/maven-recommendations`)
-
-**Status: Conformant with extensions.**
-
-Maven uses heading-block format for 🔴 / 🟡 and a table for 🟢. All five canonical fields are present:
-- ID: `MR<N>` — conformant.
-- Severity: `🔴 High / 🟡 Medium / 🟢 Low` explicit in section headers — conformant.
-- Location: "Closes gap in:" field cites source files and sections — conformant.
-- What's wrong: "Why now:" field — conformant.
-- What to do: "Move:" field — conformant.
-- Evidence: "Evidence:" field — present and required for 🔴 items.
-
-**No gaps against canonical shape.**
-
----
-
-### Forge (`/forge-recommendations`)
-
-**Status: Diverges — see [four-lane-reconciliation.md](../observations/four-lane-reconciliation.md).**
-
-Registered prefix: `FR`. Divergences to resolve: missing "What's working", "Manual checks required", "Out of scope" sections (D2); tier vocabulary uses Now/Next/Watch instead of 🔴/🟡/🟢 (D3); `block-ship` annotation not yet normalised to `gate-ship` (D7); evidence trace absent (D4).
-
----
-
-### Helm (`/helm-recommendations`)
-
-**Status: Diverges — see [four-lane-reconciliation.md](../observations/four-lane-reconciliation.md).**
-
-Registered prefix: `HR`. Same divergences as Forge (D2, D3, D4, D7).
-
----
-
-### Verify (`/verify-recommendations`)
-
-**Status: Diverges — see [four-lane-reconciliation.md](../observations/four-lane-reconciliation.md).**
-
-Registered prefix: `VR`. Same divergences as Forge (D2, D3, D4, D7). Verify is also a ship-gate lane — `gate-ship: true` applies to release-blocking findings.
-
----
-
-### Guard (`/guard-recommendations`)
-
-**Status: Diverges — see [four-lane-reconciliation.md](../observations/four-lane-reconciliation.md).**
-
-Registered prefix: `GR`. Same divergences as Forge (D2, D3, D4, D7). Guard is also a ship-gate lane — `gate-ship: true` applies to Critical findings. Guard adds an `accepted-risk` triage state not yet in the base schema; this is a Guard-specific extension.
-
----
-
-### Charter, Anchor, Ledger, Roster, Pitch
-
-**Status: Scaffold only — recommendations skills not yet written.**
-
-Registered prefixes: `CR` (Charter), `AR` (Anchor), `LR` (Ledger), `RO` (Roster), `PR` (Pitch). Conformance assessment pending skill development.
-
----
-
-### Summary table
-
-| Pack | ID | Severity | Location | What's wrong | What to do | Evidence trace | Status |
-|---|---|---|---|---|---|---|---|
-| Compass | Conformant | Conformant | Conformant (lens-level) | Conformant | Conformant | Required | **Conformant** |
-| Layers+ | Conformant | Conformant | Partial (layer name only) | **Absent** | Conformant | Not present | **Diverges — missing Finding column** |
-| Ally | Conformant | Conformant | Conformant | Indirect (via finding ID) | Conformant | Not present | **Minor gap — Finding not inline** |
-| Rubric | Conformant | Conformant | Conformant | Conformant | Conformant | Present | **Conformant** |
-| Maven | Conformant | Conformant | Conformant | Conformant | Conformant | Required | **Conformant** |
-| Forge | Pending | Pending | Pending | Pending | Pending | Absent | **Diverges — see reconciliation doc** |
-| Helm | Pending | Pending | Pending | Pending | Pending | Absent | **Diverges — see reconciliation doc** |
-| Verify | Pending | Pending | Pending | Pending | Pending | Absent | **Diverges — see reconciliation doc** |
-| Guard | Pending | Pending | Pending | Pending | Pending | Absent | **Diverges — see reconciliation doc** |
-| Charter / Anchor / Ledger / Roster / Pitch | — | — | — | — | — | — | **Scaffold only** |
-
----
-
-## 9. Schema changelog
-
-| Version | Date | Change |
-|---|---|---|
-| v0.1 | 2026-05-22 | Initial publication — making the implicit schema explicit. No changes to pack skill specs in this version; conformance gaps noted above are addressed as follow-on work. |
-| v0.2 | 2026-05-24 | Register prefixes for 9 new lanes (FR/HR/VR/GR/CR/AR/LR/RO/PR). Add `gate-ship` field to canonical finding shape §4. Add §1 file paths and §8 conformance entries for all new lanes. Reconciliation divergences (D1–D7) documented in four-lane-reconciliation.md; skill-level fixes tracked separately. |
-| v0.3 | 2026-05-24 | Register `FL` prefix for Felt (UX research lane). |
-
----
-
-_Maintained in `pilot` repo · `docs/shared/recommendations-schema.md`_
-_Next review: when any pack skill spec is updated to change its finding table shape, or when a new pack is added._