@keighleykodric/weeve 0.1.0

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

@@ -0,0 +1,94 @@
+# 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

@@ -0,0 +1,235 @@
+# 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_

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

@@ -0,0 +1,99 @@
+# 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

@@ -0,0 +1,207 @@
+# 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*