npm - @keighleykodric/weeve - Versions diffs - 0.1.0 → 0.1.1 - Mend

@keighleykodric/weeve 0.1.0 → 0.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (13) hide show

package/GOVERNANCE.md +21 -21
package/README.md +8 -8
package/WORKFLOW.md +31 -31
package/bin/weeve.js +17 -2
package/package.json +1 -1
package/reference/contributing-template.md +108 -0
package/{docs/shared/lane-conventions.md → reference/conventions.md} +37 -7
package/{docs/shared/engineering-pack-contract.md → reference/engineering-contract.md} +14 -14
package/{docs/shared/id-prefix-reference.md → reference/id-prefixes.md} +9 -9
package/{docs/shared/idea-intake-pattern.md → reference/intake-pattern.md} +10 -10
package/reference/readme-template.md +55 -0
package/{docs/shared/recommendations-schema.md → reference/schema.md} +27 -27
/package/{docs/shared/SHIP-GATE.md → reference/ship-gate.md} +0 -0

package/GOVERNANCE.md CHANGED Viewed

@@ -19,9 +19,9 @@ This is the natural failure mode of any document collaboration system at scale.
 Weeve already has the right ownership structure built in:
-- Each pack has a domain (compass = strategy, maven = marketing, etc.)
+- Each lane has a domain (compass = strategy, maven = marketing, etc.)
 - Each contract file has a clear consumer (Pilot reads recommendations)
-- Each output has a logical author (the department that owns the pack)
+- Each output has a logical author (the department that owns the lane)
 What's missing is the *governance overlay* that exposes this structure and enforces it. The good news: 80% of the solution is infrastructure orgs already use. Nothing new needs to be invented.
@@ -56,28 +56,28 @@ Combined with branch protection rules requiring owner approval, this is a hard g
 Adoption is the only friction. Most orgs using GitHub already use CODEOWNERS for code; using it for the docs folders is the same pattern applied one level over. Weeve should ship a template CODEOWNERS file and make adoption obvious during install.
-## Layer 2 — Pack-declared ownership (small addition)
+## Layer 2 — Lane-declared ownership (small addition)
-Each pack declares its owner, consumers, and contract in a small `pack.yaml`:
+Each lane declares its owner, consumers, and output in a small `lane.yaml`:
 ```yaml
-pack: compass
+lane: compass
 owner: leadership
 consumers: [product, engineering, marketing]
-contract: compass-recommendations.md
+output: compass-recommendations.md
 ```
 This becomes:
 - A scaffolding template — installing Compass for an org auto-generates the right CODEOWNERS entry, picking up the org's team names from a one-time setup
-- A documentation artifact — anyone reading the pack repo can see who owns what
+- A documentation artifact — anyone reading the lane repo can see who owns what
 - Input to downstream tooling — populates role-based views and routing without extra configuration
 Small addition; large payoff in adoption clarity.
 ## Read vs write
-Weeve gates *writes*, not reads. Cross-functional alignment depends on cross-pack readability:
+Weeve gates *writes*, not reads. Cross-functional alignment depends on cross-lane readability:
 - Marketing reads `compass-position` to understand the strategic frame
 - Leadership reads `ally-recommendations` to understand accessibility commitments
@@ -87,19 +87,19 @@ Everyone can read everything. Only the *authors* are gated.
 ## Roles and ownership
-Each domain pack has an obvious owner (the department whose work it captures). Pilot doesn't — it's the meta-pack. "Owning Pilot" splits into three roles, which collapse to one or two people at startup scale but need to be named so they can separate cleanly as the org grows:
+Each domain lane has an obvious owner (the department whose work it captures). Pilot doesn't — it's the meta-lane. "Owning Pilot" splits into three roles, which collapse to one or two people at startup scale but need to be named so they can separate cleanly as the org grows:
 | Role | Owns | Small startup | Medium startup |
 |---|---|---|---|
 | **Pilot operator** | Runs `/pilot-roadmap` and `/pilot-ship`. Routine work. | Eng lead, platform person, or founder | Platform team |
 | **Pilot owner** | The roadmap *output* and the prioritization that produces it. Cross-functional priorities. | Founder / CEO | Leadership team |
-| **Alignment platform owner** | Weeve config — which packs are installed, scoring weights, CODEOWNERS template, integrations. | Weeve champion | Platform / ops |
+| **Alignment platform owner** | Weeve config — which lanes are installed, scoring weights, CODEOWNERS template, integrations. | Weeve champion | Platform / ops |
 At small scale (5–50 people), one person is typically all three. That's fine. Naming the roles now lets them split cleanly later without re-architecting.
-The departmental pack owners map straightforwardly:
+The departmental lane owners map straightforwardly:
-| Pack | Default owner |
+| Lane | Default owner |
 |---|---|
 | Compass | Leadership / founder |
 | Layers+ | Product / design |
@@ -116,9 +116,9 @@ Concrete shape for an org adopting Weeve:
 ```
 alignment/                   (the org's adoption repo, e.g. github.com/your-org/alignment)
 ├── .alignment/              <- meta-config; owned by platform
-│   ├── config.yaml          <- installed packs, scoring weights, integrations
+│   ├── weeve.config          <- installed lanes, scoring weights, integrations
 │   ├── CODEOWNERS           <- write permissions per folder
-│   └── pack-overrides/      <- org-specific tweaks (rare)
+│   └── lane-overrides/      <- org-specific tweaks (rare)
 ├── docs/
 │   ├── compass/             <- @leadership-team
 │   ├── layers-plus/         <- @product-team
@@ -129,15 +129,15 @@ alignment/                   (the org's adoption repo, e.g. github.com/your-org/
 └── README.md
 ```
-`.alignment/` is the meta-config layer. The platform person owns it; leadership owns the Pilot output (the roadmap); each department owns their pack's folder. CODEOWNERS enforces all of it.
+`.alignment/` is the meta-config layer. The platform person owns it; leadership owns the Pilot output (the roadmap); each department owns their lane's folder. CODEOWNERS enforces all of it.
 **Splitting `docs/pilot/` ownership:**
-The *roadmap content* is leadership's call (these are company priorities). The *operational config* is platform's call (scoring weights, drift thresholds, pack weighting). CODEOWNERS handles this file-by-file:
+The *roadmap content* is leadership's call (these are company priorities). The *operational config* is platform's call (scoring weights, drift thresholds, lane weighting). CODEOWNERS handles this file-by-file:
 ```
 docs/pilot/pilot-roadmap.md       @leadership-team
-docs/pilot/pilot-config.yaml      @platform-team
+docs/pilot/pilot-weeve.config      @platform-team
 ```
 That split mirrors the role split above.
@@ -149,11 +149,11 @@ For an adopting org, configuration spans several layers. Each has a clear owner:
 | Config layer | What it controls | Owner |
 |---|---|---|
 | `.alignment/CODEOWNERS` | Write permissions per folder | Platform |
-| `.alignment/config.yaml` | Installed packs, scoring weights, integrations | Platform |
-| `pack.yaml` (per pack) | Pack-declared ownership and consumers | Platform (informed by departments) |
-| Pack version pinning | Which version of each pack is installed | Platform (via git, like any dependency) |
+| `.alignment/weeve.config` | Installed lanes, dashboard output, scoring weights, integrations | Platform |
+| `lane.yaml` (per lane) | Lane-declared ownership and consumers | Platform (informed by departments) |
+| Lane version pinning | Which version of each lane is installed | Platform (via git, like any dependency) |
 | Integration credentials | OAuth tokens, webhook URLs | Platform; secured per org policy |
-| Pack content (per `docs/<pack>/`) | The actual recommendations and audit files | Department owner per pack |
+| Lane content (per `docs/<lane>/`) | The actual recommendations and audit files | Department owner per lane |
 The config is owned by whoever owns the repo — typically the same person who already maintains the company's GitHub org or `.github/` folder. This isn't a new role to invent; it's a small addition to an existing responsibility.

package/README.md CHANGED Viewed

@@ -1,4 +1,4 @@
-# Weeve
+# 🧵 Weeve
 Cross-functional alignment system. 14+ lanes that audit strategy, product, design, engineering, QA, security, marketing, sales, and UX — then synthesize into one prioritized roadmap.
@@ -77,12 +77,12 @@ Departments without a lane can still contribute. Any team member can feed contex
 Not sure which lanes to install? Pick a preset that matches your role:
 ```
-npx weeve add core           # Designer/strategist starting point
-npx weeve add product        # Product manager — strategy + design + research
-npx weeve add engineering    # Engineering lead — delivery + security + QA
-npx weeve add strategy       # Founder/leadership — strategy + marketing
-npx weeve add gtm            # Go-to-market — strategy + marketing + sales
-npx weeve add all            # Everything
+npx @keighleykodric/weeve add core           # Designer/strategist starting point
+npx @keighleykodric/weeve add product        # Product manager — strategy + design + research
+npx @keighleykodric/weeve add engineering    # Engineering lead — delivery + security + QA
+npx @keighleykodric/weeve add strategy       # Founder/leadership — strategy + marketing
+npx @keighleykodric/weeve add gtm            # Go-to-market — strategy + marketing + sales
+npx @keighleykodric/weeve add all            # Everything
 ```
 | Preset | Lanes included |
@@ -129,7 +129,7 @@ The schema is the durable asset. Severity uses `🔴 High / 🟡 Medium / 🟢 L
 Each lane is its own repo. To contribute to a lane, open an issue or PR on that lane's repo.
-To build a community lane, see [GOVERNANCE.md](GOVERNANCE.md) for the pack.yaml spec, CODEOWNERS model, and the ship interface contract.
+To build a community lane, see [GOVERNANCE.md](GOVERNANCE.md) for the lane.yaml spec, CODEOWNERS model, and the ship interface contract.
 ---

package/WORKFLOW.md CHANGED Viewed

@@ -1,6 +1,6 @@
-# WORKFLOW.md — Cross-pack rhythm
+# WORKFLOW.md — Cross-lane 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.
+How ideas move from raw capture through to shipped code. This is the canonical doc for the cross-lane workflow. All sibling lane READMEs cite this file.
 ---
@@ -15,12 +15,12 @@ How ideas move from raw capture through to shipped code. This is the canonical d
 ```
 Your capture tool (notes, daily log, Obsidian, etc.)
     ↓ raw capture
-*-intake skills (per pack)
+*-intake skills (per lane)
     ↓ scoped rows with stable IDs
-Pack main skills (primitives, zones, layers, campaigns)
+Lane main skills (primitives, zones, layers, campaigns)
     ↓ structured findings
-<pack>-recommendations.md (the recommendations file)
-    ↓ one file per pack in docs/<pack>/
+<lane>-recommendations.md (the recommendations file)
+    ↓ one file per lane in docs/<lane>/
 /pilot-roadmap
     ↓ merged, tiered, conflict-surfaced
 docs/pilot/pilot-roadmap.md
@@ -68,11 +68,11 @@ The intake skill will ask clarifying questions if it needs more.
 /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.
+One idea may produce intake rows in multiple lanes if it spans strategy, product, and channel.
-### Step 3 — Packs process their slice
+### Step 3 — Lanes 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.
+Each lane's main skills process the intake rows. They write findings to their output files under `docs/<lane>/` in the consumer project.
 - Compass primitives + lenses → findings in `compass-*.md`
 - Layers+ layers → findings in `layers-plus-*.md`
@@ -80,11 +80,11 @@ Each pack's main skills process the intake rows. They write findings to their ou
 - Rubric zones → findings in `rubric-*.md`
 - Maven phases → findings in `maven-*.md`
-Each pack is autonomous — it doesn't need the others to run.
+Each lane 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.
+Each lane writes a `<lane>-recommendations.md` file — the recommendations file Pilot reads. This file is the distilled, tiered, prioritized output of all the lane's work. It's the only file Pilot needs from each lane.
 ```
 docs/compass/compass-recommendations.md
@@ -96,9 +96,9 @@ 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`.
+`/pilot-roadmap` reads all `<lane>-recommendations.md` files present, merges them into one prioritized backlog, surfaces cross-lane 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.
+Items are tiered: Now → Next → Watch. Cross-lane conflicts are surfaced explicitly — Pilot does not silently pick a side.
 ### Step 6 — Pilot ships: /pilot-ship
@@ -116,9 +116,9 @@ A strategic idea decomposed across the full system. This is the canonical illust
 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
+### Why it spans multiple lanes
-| Pack | Its slice |
+| Lane | 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? |
@@ -135,13 +135,13 @@ Existing users send a personalized referral link to a peer who isn't on the plat
 | 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. |
+| 8 | `/compass-recommendations`, `/layers-plus-recommendations`, `/maven-recommendations` | Each lane 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:
+Single-lane 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.
@@ -152,7 +152,7 @@ Single-pack ideas exist ("add a tooltip on the time-window picker" → Layers+ o
 ## 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.
+When setting up the system from scratch, run lanes in this order. Each step produces inputs that make the next step richer.
 ```
 1.  Compass    — establish strategic position and growth doctrine
@@ -167,13 +167,13 @@ When setting up the system from scratch, run packs in this order. Each step prod
 **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.
+Lanes can be run in any order — this sequence is the recommended path for a first full run, not a hard dependency.
 ---
-## Within-pack sequences
+## Within-lane 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.
+Cross-lane order is in the First-run order section above. Within each lane, 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
@@ -307,7 +307,7 @@ Zone audits (run weekly or on trigger):
 ## Cadence
-| Pack | Typical cadence |
+| Lane | Typical cadence |
 | --- | --- |
 | Ally | Weekly (change detection) |
 | Rubric | Weekly (drift detection) |
@@ -316,7 +316,7 @@ Zone audits (run weekly or on trigger):
 | 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 `/roadmap` | After any lane refreshes its recommendations |
 | Pilot `/ship` | Daily (autonomous batch) |
 ---
@@ -326,9 +326,9 @@ Zone audits (run weekly or on trigger):
 `/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 lane completes a run and writes a new `<lane>-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
+- A new lane is installed or an existing lane 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)
@@ -337,18 +337,18 @@ Zone audits (run weekly or on trigger):
 **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.
+**Who triggers it:** The Pilot operator (see GOVERNANCE.md § Roles). On teams, any lane owner can request a re-run by opening a PR to update their `<lane>-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.
+**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 lane owners before starting the next `/pilot-ship` batch.
 ---
-## Pack independence
+## Lane 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.
+Every lane works standalone. The workflow above is opt-in, not required. A designer can run Layers+ alone. A strategist can run Compass alone. Cross-lane references are citations — each lane 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.
+**The one exception:** Pilot needs at least one lane to have written a `<lane>-recommendations.md` file. With no lanes 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.*
+*Maintained in [keighleykodric/weeve-pilot](https://github.com/keighleykodric/weeve-pilot). All sibling lane READMEs cite this file.*

package/bin/weeve.js CHANGED Viewed

@@ -62,7 +62,15 @@ function installLanes(lanes) {
     console.log(`  + ${lane} — ${LANES[lane]}`);
     run(`npx skills add ${repo}`);
   }
-  console.log(`\nDone. Run /pilot-intro to get started.\n`);
+  // Show the right first step based on what was installed
+  const FIRST_STEP_ORDER = ["compass", "layers-plus", "felt", "ally", "rubric", "forge", "helm", "verify", "guard", "maven", "pitch", "pilot"];
+  const firstLane = FIRST_STEP_ORDER.find((l) => lanes.includes(l));
+  if (firstLane && firstLane !== "pilot") {
+    console.log(`\nDone. Run /${firstLane}-intro to get started.`);
+    console.log(`Then work through your lanes. Run /pilot-intro last — it reads all lane outputs.\n`);
+  } else {
+    console.log(`\nDone. Run /pilot-intro to get started.\n`);
+  }
 }
 switch (cmd) {
@@ -112,7 +120,14 @@ switch (cmd) {
   case "--help":
   case "-h": {
     console.log(`
-weeve — Cross-functional alignment system
+ ██╗    ██╗███████╗███████╗██╗   ██╗███████╗
+ ██║    ██║██╔════╝██╔════╝██║   ██║██╔════╝
+ ██║ █╗ ██║█████╗  █████╗  ██║   ██║█████╗
+ ██║███╗██║██╔══╝  ██╔══╝  ╚██╗ ██╔╝██╔══╝
+ ╚███╔███╔╝███████╗███████╗ ╚████╔╝ ███████╗
+  ╚══╝╚══╝ ╚══════╝╚══════╝  ╚═══╝  ╚══════╝
+ Cross-functional alignment system
 Commands:
   weeve add <lane> [lane2...]   Install one or more lanes

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@keighleykodric/weeve",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Cross-functional alignment system — install and manage Weeve lanes",
   "bin": {
     "weeve": "./bin/weeve.js"

package/reference/contributing-template.md ADDED Viewed

@@ -0,0 +1,108 @@
+# CONTRIBUTING.md template for Weeve lanes
+_Replace `<lane>` with the lane name (e.g., compass, ally, forge). Remove this preamble before publishing._
+---
+# Contributing
+## Adding a step
+Each step is a single `SKILL.md` file in its own directory under `skills/`.
+**Directory naming:** `NN-<lane>-<name>/` where `NN` is a two-digit prefix for human ordering. The prefix doesn't affect how the installer sorts — it uses the `name` frontmatter field — but it keeps the directory listing readable.
+**Required frontmatter:**
+```yaml
+---
+name: <lane>-<name>
+description: One sentence. What does this step do and what does it write?
+---
+```
+No quotes around the description value. The `name` field becomes the slash command.
+## Step structure
+Every step should follow this pattern:
+```markdown
+---
+name: <lane>-<name>
+description: ...
+---
+# /<lane>-<name>
+*Brief framing — what question does this step answer?*
+**Read only, write audit only.** [What it reads. What it writes.]
+---
+## State detection
+[Check docs/<lane>/ for existing files and handle clean/partial/old-format states.]
+---
+## What to audit
+[Specific things to look for, organised by sub-topic.]
+---
+## Rating
+[Strong / Partial / Weak / Manual check required — with definitions.]
+---
+## Write `<lane>-<name>.md`
+[Exact output template in a fenced code block.]
+---
+## After auditing
+[Confirm the file was written. Brief summary. Recommended next step.]
+```
+## The audit-only rule
+Steps read source files. They never edit, refactor, or fix anything in the repo being audited. If a step finds a problem, it records it in the output file — it does not fix it. Fixes are the operator's decision.
+## Output files
+Each step writes exactly one file: its designated `<lane>-<name>.md` in `docs/<lane>/`. No other files. No improvised outputs. No splitting results across multiple locations.
+If a step needs data from another step, it reads that step's output file — it does not re-run the audit.
+## Testing a step
+1. Make changes in `skills/<NN>-<name>/SKILL.md` (the repo — not the installed copy)
+2. Copy to the installed location: `cp -r skills/<NN>-<name> ~/.claude/skills/<name>`
+3. Run the step in a test project that has (or doesn't have) a `docs/<lane>/` folder
+4. Check the output file matches the template exactly
+## Error messages
+Every error has three parts, one line each:
+1. **What happened** — the observed state, factual.
+2. **Why it matters** — why this state requires a response from the operator.
+3. **What to do next** — concrete recovery action.
+Error tone is reassuring, not blaming. Treat the situation as "earlier in the flow than expected", not "operator did the wrong thing".
+## Repo structure
+```
+skills/           <- step source files (edit these)
+README.md         <- user-facing install and usage
+CONTRIBUTING.md   <- this file
+LICENSE           <- MIT
+lane.yaml         <- lane metadata (owner, consumers, output)
+```

package/{docs/shared/lane-conventions.md → reference/conventions.md} RENAMED Viewed

@@ -1,6 +1,6 @@
 # Lane conventions
-Cross-cutting decisions that apply to every lane. Captured here so we don't re-litigate them per lane.
+Cross-cutting decisions that apply to every lane. Captured here to avoid re-litigating them per lane.
 ---
@@ -100,9 +100,9 @@ Most framework files follow "everyone in the org can read everything; gate write
 - **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 open-source 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. A documented pattern should be established before broad rollout.
-For SaaS deployments, per-file read access is a deferred feature in `GOVERNANCE.md`.
+Per-file read access is outside the current scope.
 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.
@@ -129,17 +129,17 @@ Intake rows are pre-triage. They move into a zone file when a primitive skill pr
 ---
-## Tier vocabulary — pack vs Pilot
+## Tier vocabulary — lanevs 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 |
+| Lane 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.
+**Rule:** Lane 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.
@@ -204,4 +204,34 @@ Example:
 ---
-*Draft · docs/shared/lane-conventions.md · 2026-05-25*
+## Constraints
+Constraints define what lanes and `/pilot-ship` must not do. They live at two levels:
+### Project-level — `weeve-constraints.md`
+The single source of truth for project-wide guardrails. Lives at the project root. Pilot reads this before every ship batch. All lanes read it during orient and recommendations.
+Sections:
+- **Active constraints** — current hard limits (resources, legal, strategic)
+- **Deferred items** — work explicitly held with a revisit trigger
+- **What autonomous workers must not do** — explicit prohibitions for ship
+### Lane-level — `docs/<lane>/<lane>-constraints.md` (optional)
+When a lane has specific constraints beyond the project level — time budgets, resource limits, dependencies on other lanes, or temporarily blocked zones — it adds its own constraints file. Lane-level constraints extend the project-level file; they don't replace it.
+### Resolution order
+1. Ship reads `weeve-constraints.md` first (project-level)
+2. Ship reads `docs/<lane>/<lane>-constraints.md` if it exists (lane-level)
+3. Lane-level constraints can tighten but never loosen project-level constraints
+### Who writes them
+- **Project-level:** Pilot operator (extracted from roadmap Constrained section, strategic decisions, or operator input)
+- **Lane-level:** Lane owner or ship (when a lane-specific blocker is identified during a run)
+---
+*reference/conventions.md · 2026-05-25*

package/{docs/shared/engineering-pack-contract.md → reference/engineering-contract.md} RENAMED Viewed

@@ -1,10 +1,10 @@
-# Engineering pack — contract shape
+# Engineering lane — 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.
+This document defines the contract shape for a future engineering lane — 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.
+**Purpose:** Define the schema before filling it. Anyone building an engineering lane has a conformant target to hit. External tools become plug-in candidates rather than competitors.
 ---
@@ -21,7 +21,7 @@ The engineering domain audits the operator's technical foundation — not whethe
 | 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.
+The engineering lane audits the *shipping system*, not the product's feature set. It stays in its lane.
 ---
@@ -60,35 +60,35 @@ ENG-T3-1 · 🟢 Low · Technical debt · No debt register · Debt is invisible
 ## 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.
+Pilot reads `engineering-recommendations.md` the same way it reads any lane output: looks for the `## Tier 1`, `## Tier 2`, `## Tier 3` sections, extracts items, merges with other lane findings, and surfaces cross-lane conflicts.
-**Expected cross-pack citations:**
+**Expected cross-lane citations:**
-| Engineering finding | Cross-pack implication |
+| Engineering finding | Cross-lane 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.
+Pilot surfaces these cross-lane 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-`.
+Engineering lane 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`.
+Qualified cross-lane reference format (per `docs/shared/id-prefix-reference.md`): `ENG::ENG-T1-1`.
 ---
-## Why now
+## Why define the contract early
-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.
+The contract shape — what `engineering-recommendations.md` *is* — is at Genesis stage. Defining it now means future tools that integrate with the framework 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.
+The engineering lane itself can be built by any contributor once the recommendations file shape is clear.
 ---
-_Maintained in pilot/docs/shared/ · Referenced by: pilot-roadmap skill, compass-recommendations SR4_
+_Maintained in docs/shared/ · Referenced by: pilot-roadmap skill, compass-recommendations SR4_

package/{docs/shared/id-prefix-reference.md → reference/id-prefixes.md} RENAMED Viewed

@@ -4,18 +4,18 @@ _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.
+Finding IDs are lane-local. Each lane uses its own prefix system. This document is the single cross-lane reference so Pilot can synthesise across lanes without ID collisions.
 ---
 ## Pilot
-Pilot generates its own IDs when synthesising across packs.
+Pilot generates its own IDs when synthesising across lanes.
 | 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-X` | Next / cross-lane backlog item | `P-X5`, `P-X18` |
 | `P-B` | Backlog (pre-prioritised) | `P-B1` |
 | `P-W` | Watch signal | `P-W1`, `P-W14` |
@@ -25,7 +25,7 @@ Pilot generates its own IDs when synthesising across packs.
 Compass uses a two-part ID system: primitive-layer prefixes for raw findings, and `SR` prefixes for synthesised strategic recommendations.
-**Primitive findings (within pack):**
+**Primitive findings (within lane):**
 | Prefix | Layer | Example |
 |---|---|---|
@@ -205,7 +205,7 @@ Intake IDs are lane-internal (`I<n>`) and not propagated to Pilot.
 ## 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.
+The raw capture step (notes, daily log, or CLI tool) does not generate finding IDs — captured items are routed to the appropriate lane's intake skill, which assigns lane-local IDs.
 ---
@@ -213,13 +213,13 @@ The raw capture step (your notes, daily log, or personal CLI tool) does not gene
 **Known collision risks:**
-| Pack A | Pack B | Colliding prefix | Notes |
+| Lane A | Lane 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 |
+| Ally T1/T2/T3 | Layers+ T1/T2/T3 | `T1-`, `T2-`, `T3-` | Same tier numbering, different lanes — always qualify with lane name when cross-referencing |
-**Convention:** When Pilot synthesises across packs, prefix all cited finding IDs with the pack abbreviation:
+**Convention:** When Pilot synthesises across lanes, prefix all cited finding IDs with the lane abbreviation:
 ```
 compass:SR3      → Compass strategic recommendation 3
@@ -231,5 +231,5 @@ maven:MR3        → Maven recommendation 3
 ---
-_Closes: Layers+ CM-DS2 🟡 (no cross-pack ID reference)_
+_Closes: Layers+ CM-DS2 🟡 (no cross-lane ID reference)_
 _Generated: 2026-05-23 · pilot-ship batch_

package/{docs/shared/idea-intake-pattern.md → reference/intake-pattern.md} RENAMED Viewed

@@ -4,7 +4,7 @@ _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.
+**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 lane 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.
 ---
@@ -29,14 +29,14 @@ Minimal frontmatter, freeform body. No required fields beyond `date` and `title`
 ---
 date: YYYY-MM-DD
 title: Short idea name
-tags: [compass, maven, layers-plus]   # optional — which packs this might route to
+tags: [compass, maven, layers-plus]   # optional — which lanes 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.]
+[Optional. One line on what would make this ready to route to a lane intake skill.]
 ```
 **Status values:**
@@ -45,7 +45,7 @@ status: raw | maturing | ready        # default: raw
 |---|---|
 | `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. |
+| `ready` | Has enough shape to route to a lane intake skill. |
 ---
@@ -53,10 +53,10 @@ status: raw | maturing | ready        # default: raw
 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)
+1. **Which lane 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:
+When ready, run the relevant lane intake skill:
 ```
 /compass-intake    → strategic ideas, market bets, positioning moves
@@ -66,7 +66,7 @@ When ready, run the relevant pack intake skill:
 /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.
+After routing, update the idea file's status to `ready` and note which lane received it. The idea file becomes the origin story for the eventual roadmap item.
 ---
@@ -77,8 +77,8 @@ After routing, update the idea file's status to `ready` and note which pack rece
 | 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 |
+| Research findings with a clear home | `/research` in the relevant lane |
+| Confirmed roadmap item | Lane intake → lane recommendations → pilot roadmap |
 ---
@@ -96,4 +96,4 @@ This creates a traceable origin trail: idea → intake row → roadmap item →
 ---
-_Maintained in pilot/docs/shared/ · Pattern for: all pilot-family projects_
+_Maintained in docs/shared/ · Pattern for: all Weeve-framework projects_

package/reference/readme-template.md ADDED Viewed

@@ -0,0 +1,55 @@
+# README template for Weeve lanes
+_Use this template when creating or standardizing a lane README. Replace all `<placeholders>` with lane-specific content. Remove this preamble before publishing._
+---
+# <Lane Name>
+<One sentence: what this lane does and why it exists.>
+## Install
+```
+npx skills add keighleykodric/weeve-<lane>
+```
+## What it does
+<2-3 sentences expanding on the one-liner. What does the lane audit/produce? What's the outcome for the operator?>
+## Skills
+| Skill | What it does |
+|---|---|
+| `/<lane>-intro` | First-run onboarding — scope, context, routes to intake |
+| `/<lane>-intake` | Capture raw requests and route to the right zone |
+| `/<lane>-orient` | Diagnostic sweep — identifies the bottleneck zone |
+| ... | ... |
+| `/<lane>-recommendations` | Prioritized findings — the file Pilot reads |
+| `/<lane>-dashboard` | Visual HTML summary of findings |
+| `/<lane>-tickets` | Generate tickets from findings |
+| `/<lane>-triage` | Walk findings — mark closed, deferred, dismissed |
+| `/<lane>-check` | Verify closed findings are actually fixed |
+## Where to start
+1. Run `/<lane>-intro` — captures scope and context
+2. Run `/<lane>-orient` — identifies where to focus
+3. Run zone skills as directed
+4. Run `/<lane>-recommendations` — produces the prioritized output
+## How it fits
+<Lane Name> writes `<lane>-recommendations.md`. Pilot reads it alongside all other lane outputs and synthesizes a single roadmap. See [WORKFLOW.md](https://github.com/keighleykodric/weeve/blob/main/WORKFLOW.md) for the full cross-lane rhythm.
+### Sibling lanes
+<List lanes this one cites or is cited by — not dependencies, just cross-references.>
+- **[Compass](https://github.com/keighleykodric/weeve-compass)** — <one line on the relationship>
+- **[Pilot](https://github.com/keighleykodric/weeve-pilot)** — reads `<lane>-recommendations.md` for roadmap synthesis
+## License
+MIT

package/{docs/shared/recommendations-schema.md → reference/schema.md} RENAMED Viewed

@@ -7,19 +7,19 @@ status: active
 # Recommendations schema — v0.3
-*Authoritative versioned spec for the recommendations file format that all packs produce and Pilot reads.*
+*Authoritative versioned spec for the recommendations file format that all lanes 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.
+This document is the authoritative spec. Every lane'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 lane's output diverges from this spec, Pilot's merge step degrades silently.
 ---
 ## 1. File naming convention
 ```
-docs/<pack>/<pack>-recommendations.md
+docs/<lane>/<lane>-recommendations.md
 ```
-| Pack | File path |
+| Lane | File path |
 |---|---|
 | Compass | `docs/compass/compass-recommendations.md` |
 | Layers+ | `docs/layers-plus/layers-plus-recommendations.md` |
@@ -52,9 +52,9 @@ Every recommendations file must contain these sections, in this order:
 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):
+Optional sections (present in some lanes, allowed in all):
-- **Cross-pillar citations** — where this pack's findings link to other packs
+- **Cross-pillar citations** — where this lane's findings link to other lanes
 - **Validation gaps** (Maven) — assumptions under 🔴 / 🟡 items not yet tested
 - **Evidence trace** (Compass) — source row IDs, confidence ratings, external signal count
@@ -67,14 +67,14 @@ Finding IDs must be stable across re-runs. If a finding is re-run and the underl
 ### Format
 ```
-<PACK-PREFIX><N>
+<LANE-PREFIX><N>
 ```
-Where `N` is a monotonically increasing integer within the pack's namespace. IDs are never reused for a different finding.
+Where `N` is a monotonically increasing integer within the lane's namespace. IDs are never reused for a different finding.
-### Registered pack prefixes
+### Registered lane prefixes
-| Pack | Prefix | Example |
+| Lane | Prefix | Example |
 |---|---|---|
 | Compass / Strategy | `SR` | SR1, SR2 |
 | Layers+ / Tiers | `T1-`, `T2-`, `T3-` | T1-1, T2-3 |
@@ -92,9 +92,9 @@ Where `N` is a monotonically increasing integer within the pack's namespace. IDs
 | 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.
+**Note on Layers+ and Ally sharing the `T1-`/`T2-`/`T3-` prefix:** both lanes use tier-relative IDs rather than a lane-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 lanes.
-**Registering a new pack prefix:** add a row to the table above and increment the schema version.
+**Registering a new laneprefix:** add a row to the table above and increment the schema version.
 ---
@@ -110,13 +110,13 @@ id · severity · location · what's wrong · what to do
 | 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). |
+| **id** | Yes | Stable lane-prefixed ID (see §3). Never changes between re-runs for the same finding. |
+| **severity** | Yes | 🔴 High / 🟡 Medium / 🟢 Low — consistent scale across all lanes (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.). |
+| **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 lanes — do not use alternative names (`block`, `block-ship`, etc.). |
 ### Heading-block format (Compass / Maven)
@@ -140,7 +140,7 @@ The `**Move:**` field satisfies **what to do**. The heading title + `**Move:**`
 | 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.
+The columns map directly to the canonical shape. "Effort" is an extension field — allowed in all lanes, not required by the schema.
 ---
@@ -166,7 +166,7 @@ Use these terms consistently in evidence traces and frontmatter:
 | **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):**
+**Frontmatter usage (Maven pattern, optional for other lanes):**
 ```yaml
 foundation: validated | hypothesis | missing
@@ -181,27 +181,27 @@ Confidence is expressed in the evidence trace field: `"P2 (Hypothesis, Central)
 ## 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.
+`/pilot-roadmap` reads each lane'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 |
+| Lane output | Roadmap tier |
 |---|---|
 | Compass T1 (Act now) | **Now** |
-| 🔴 High from any other pack | **Now** |
+| 🔴 High from any other lane| **Now** |
 | Compass T2 (Plan for) | **Next** |
-| 🟡 Medium from any other pack | **Next** |
+| 🟡 Medium from any other lane| **Next** |
 | Compass T3 (Watch) | **Watch** |
-| 🟢 Low from any other pack | **Watch** |
+| 🟢 Low from any other lane| **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.
+**De-duplication:** if two lanes 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.
+**Conflict detection:** if two lanes 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.
@@ -334,7 +334,7 @@ Registered prefixes: `CR` (Charter), `AR` (Anchor), `LR` (Ledger), `RO` (Roster)
 ### Summary table
-| Pack | ID | Severity | Location | What's wrong | What to do | Evidence trace | Status |
+| Lane | 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** |
@@ -353,11 +353,11 @@ Registered prefixes: `CR` (Charter), `AR` (Anchor), `LR` (Ledger), `RO` (Roster)
 | 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.1 | 2026-05-22 | Initial publication — making the implicit schema explicit. No changes to laneskill 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._
+_Next review: when any laneskill spec is updated to change its finding table shape, or when a new laneis added._

/package/{docs/shared/SHIP-GATE.md → reference/ship-gate.md} RENAMED Viewed

File without changes