@keighleykodric/weeve 0.1.0 → 0.1.2

package/examples/strategy/README.md

@@ -0,0 +1,59 @@
+# strategy preset
+
+## Who this is for
+
+The `strategy` preset is for leadership teams and strategy functions running quarterly planning, annual reviews, or major pivots. It focuses on market orientation, audience understanding, and narrative alignment — giving executives and strategy leads the structured inputs they need to make high-confidence directional decisions. This preset deliberately omits execution-layer lanes (design, engineering, revenue) to keep the focus on where to go, not how to get there.
+
+## What you get
+
+- **compass-signals.md** — ranked strategic opportunities and threats drawn from market, competitive, and internal signals
+- **compass-context.md** — current position snapshot: where you stand relative to market shifts and competitors
+- **layers-plus-map.md** — audience segmentation with motivational layers to anchor strategic choices in real user reality
+- **maven-brief.md** — market narrative and positioning brief: how the strategy translates into a story the market will believe
+- **pilot-brief.md** — strategic go/no-go recommendation with key assumptions, risks, and decision criteria
+
+## Install
+
+```bash
+npx weeve add strategy
+```
+
+Equivalent individual lanes:
+
+```bash
+npx weeve add compass layers-plus maven pilot
+```
+
+## First run sequence
+
+Run these skills in order. Steps marked **(parallel)** can be run simultaneously once their prerequisites are complete.
+
+1. **compass** — Surveys market signals, competitor moves, and internal strategic context to produce a ranked opportunity and risk map.
+2. **layers-plus** — Segments the audience into motivational layers; grounds the strategy in concrete user and buyer realities rather than abstract personas.
+3. **maven** — Translates the compass signals and layers-plus map into a market narrative and positioning brief, identifying the story the strategy needs to tell.
+4. **pilot** — Synthesizes the strategic inputs into a go/no-go recommendation with key assumptions surfaced, risks ranked, and decision criteria stated.
+
+## What you'll have at the end
+
+| File | Description |
+|---|---|
+| `weeve/compass/compass-signals.md` | Ranked strategic signals with evidence and confidence scores |
+| `weeve/compass/compass-context.md` | Market position snapshot with competitive and trend analysis |
+| `weeve/layers-plus/layers-plus-map.md` | Audience layer map grounding the strategy in real motivations |
+| `weeve/maven/maven-brief.md` | Market narrative and positioning brief for the strategic direction |
+| `weeve/pilot/pilot-brief.md` | Strategic recommendation with assumptions, risks, and decision criteria |
+
+## CODEOWNERS
+
+Copy to `.github/CODEOWNERS`:
+
+```
+weeve/compass/       @leadership
+weeve/layers-plus/   @product
+weeve/maven/         @marketing
+weeve/pilot/         @leadership
+```
+
+## Time estimate
+
+First full run: **50–80 minutes**. The compass lane is the most input-sensitive — teams with rich competitive intelligence and internal context documents will get sharper outputs. Maven runs fastest when compass and layers-plus artifacts are complete and specific. Subsequent runs during a planning cycle: 20–30 minutes for updates.

package/examples/strategy/demo/README.md

@@ -0,0 +1,19 @@
+# Beacon — strategy preset demo
+
+A B2B analytics platform at a Series A inflection point. Use this demo to try the **strategy** preset (Compass, Layers+, Maven, Pilot).
+
+## Run it
+
+```bash
+weeve add strategy
+/compass-intro      # strategic positioning — where to play, how to win
+/layers-plus-intro  # product evaluation against the strategic doctrine
+/maven-intro        # marketing — messaging, positioning, brand voice
+/pilot-priorities   # synthesize
+```
+
+Outputs land in `./weeve/<lane>/`.
+
+## The project
+
+Beacon has a real strategic decision to make: double down on e-commerce (core ICP, competitive, well-understood) or lean into the SaaS customers who are appearing organically (lower churn, higher ACV, but outside the team's domain expertise). The board is split. This is exactly the kind of problem Compass is built for.

package/examples/strategy/demo/weeve/compass/compass-intake.md

@@ -0,0 +1,34 @@
+# compass-intake — Beacon
+# Source: weeve/compass/customer-segments.md, weeve/shared/competitive.md, board meeting notes
+
+_Feed to `/compass-intake`. The strategic tension is the whole point of this scenario._
+
+---
+
+## The core tension
+
+- 14 SaaS companies signed up without being targeted. Lower churn (6% vs 14%), higher ACV ($1,400 vs $900 avg).
+- The board is asking: "are we the right team to win e-commerce against Triple Whale?"
+- Founding team has e-commerce backgrounds. Nobody has built a SaaS metrics product before.
+- Triple Whale raised $25M Series B. Beacon has $6M. The funding gap is real.
+
+## Signals supporting a SaaS pivot
+
+- SaaS customers have better unit economics on every metric we measure.
+- Cohort analysis feature (built for e-commerce) is being repurposed by SaaS customers for subscription cohorts — accidental product-market fit.
+- One SaaS customer (350 employees) asked about enterprise contract + SSO. Team declined. It would have been $4,200/month.
+- Mid-market SaaS analytics gap: Baremetrics is strong at SMB, ChartMogul at enterprise. The $1M–$10M ARR tier is underserved.
+
+## Signals against a SaaS pivot
+
+- 85 paying e-commerce customers. Zero SaaS customers acquired intentionally.
+- All platform integrations (Shopify, WooCommerce, Meta Ads, Google Ads) are e-commerce-specific.
+- Amazon Marketplace integration — top customer request — is pure e-commerce.
+- Founding expertise is in e-commerce. SaaS metrics has different requirements.
+
+## Other observations
+
+- The weekly digest has a 71% open rate — highest engagement of any surface. Not mentioned in pricing or positioning.
+- Pricing page says "e-commerce analytics platform." SaaS customers self-qualify out. Some who would buy, don't.
+- No formal ICP document. "Mid-market e-commerce brands" is the working definition, not a written one.
+- Series A lead VC asked at last board meeting: "what's your plan for the SaaS signal?" No formal answer yet.

package/examples/strategy/demo/weeve/compass/customer-segments.md

@@ -0,0 +1,34 @@
+# Customer segments — Beacon
+
+_Rough segmentation. Not from a formal analysis — assembled from CRM and team knowledge._
+
+## Segment A: Core e-commerce (85 customers)
+
+- Shopify or WooCommerce stores, $500K–$10M annual revenue
+- Marketing or e-commerce manager is the main user
+- Primary use: ROAS tracking, anomaly alerts, weekly digest
+- Churn: ~14% annually
+- ACV: ~$900/month
+- Most common churn reason: "Triple Whale has better attribution"
+
+## Segment B: SaaS (14 customers, all inbound / word-of-mouth)
+
+- SaaS companies, $1M–$10M ARR
+- Finance or RevOps is the main user
+- Primary use: MRR tracking, cohort analysis (repurposed from e-commerce), anomaly detection
+- Churn: ~6% annually
+- ACV: ~$1,400/month
+- How they found us: mostly word of mouth; one from a "best Baremetrics alternatives" article
+
+## Segment C: Agency / multi-brand (4 customers)
+
+- Marketing agencies managing multiple client accounts
+- Want white-label or multi-brand dashboard view — not supported
+- Two have asked explicitly; not on the roadmap
+
+## Key unknowns
+
+- Whether SaaS churn (6%) is truly lower or just newer cohorts that haven't had time to churn
+- What SaaS buyers would look like if we marketed to them intentionally
+- Why SaaS customers find value despite e-commerce-specific terminology on the dashboard
+- Whether the 4 agency customers represent a third viable segment or are noise

package/examples/strategy/demo/weeve/layers-plus/layers-plus-intake.md

@@ -0,0 +1,15 @@
+# layers-plus-intake — Beacon
+# Source: product observation, SaaS customer feedback
+
+_Feed to `/layers-plus-intake`. Light — product design hasn't been a focus at this stage._
+
+---
+
+- The dashboard shows e-commerce KPIs (ROAS, add-to-cart rate) to SaaS customers who don't use them. No way to customize which metrics are shown.
+- SaaS customers encounter e-commerce terminology throughout the product. "Add to cart rate" on a SaaS metrics dashboard creates confusion.
+- The weekly digest email is the highest-engagement surface (71% open rate) but it's never been redesigned from the MVP version.
+- The pricing page and homepage say "e-commerce analytics" — SaaS customers who would buy are self-qualifying out without contacting us.
+
+---
+
+_No design research has been run at this stage. These observations are from customer support notes and one casual review._

package/examples/strategy/demo/weeve/maven/maven-intake.md

@@ -0,0 +1,33 @@
+# maven-intake — Beacon
+# Source: website review, email data, team conversations
+
+_Feed to `/maven-intake`._
+
+---
+
+## Positioning and messaging
+
+- Website hero: "The e-commerce analytics platform that tells you what to do next."
+- SaaS customers who found us organically say they were confused by the e-commerce framing. A few almost didn't sign up.
+- No messaging anywhere on the site for the SaaS analytics use case.
+- The weekly digest — highest-loved feature — is not mentioned on the homepage or pricing page.
+
+## Content and acquisition
+
+- No blog or content strategy. Acquisition is word-of-mouth and paid.
+- One "best Baremetrics alternatives" article ranked for a query that sent 3 SaaS customers.
+- No customer case studies. No customer stories.
+- Social: minimal presence. Occasional LinkedIn posts.
+
+## Email
+
+- Onboarding sequence: 3 emails over 7 days. Open rate ~45%.
+- The weekly digest is the main ongoing communication. 71% open rate.
+- No re-engagement sequence for at-risk or churned customers.
+- Nobody on the team knows what the onboarding sequence says after day 7 — it was set up 18 months ago.
+
+## Open questions
+
+- Whether SEO or content around "SaaS analytics" could be a real channel — one accidental ranking suggests it might
+- How to message to SaaS companies without confusing the e-commerce customer base
+- Whether the weekly digest's success is a positioning asset that should lead the story

package/examples/strategy/demo/weeve/shared/competitive.md

@@ -0,0 +1,40 @@
+# Competitive landscape — Beacon
+
+_Updated after board meeting, May 2026._
+
+## E-commerce analytics (current market)
+
+**Triple Whale**
+- Raised $25M Series B last quarter. Well-funded, growing fast.
+- Direct competitor for our core ICP.
+- Better attribution (pixel-based vs our UTM approach).
+- Better brand and more marketing presence.
+- 3 e-commerce customers churned in Q2 citing "Triple Whale has better attribution."
+
+**Supermetrics**
+- Data connector, not opinionated. Different job — customers use it to self-assemble dashboards.
+
+**Looker / Tableau**
+- Enterprise price points. Not direct competition at our stage.
+
+## SaaS metrics (adjacent — relevant if we change direction)
+
+**Baremetrics**
+- Subscription analytics, Stripe-native. Strong brand in SaaS. Would be a direct competitor if we serve SaaS intentionally.
+
+**ChartMogul**
+- More mature than Baremetrics. Enterprise SaaS focus. More expensive.
+
+**ProfitWell** (now part of Paddle)
+- Subscription analytics bundled with payments. Different motion.
+
+## The competitive problem
+
+If we stay e-commerce: we face Triple Whale with 4× our funding and better attribution.
+If we pursue SaaS: we compete with Baremetrics and ChartMogul, both entrenched in SaaS analytics.
+
+Neither path is obviously right. The board is aware of this. No decision has been made.
+
+---
+
+_Triple Whale data from public announcements. Baremetrics/ChartMogul from their websites and public reviews. No formal competitive research has been conducted._

package/examples/strategy/demo/weeve/shared/roadmap.md

@@ -0,0 +1,29 @@
+# Roadmap — Beacon
+
+_Series A priorities. Reviewed with the board quarterly._
+
+## Now (shipping Q2)
+
+- Amazon Marketplace integration — 18 customers have asked, 6 months overdue
+- SaaS metrics mode (MRR, churn, expansion revenue) — experimental, for the 14 SaaS customers
+- Alert threshold customization — anomaly detection too noisy for high-volume stores
+
+## Next (Q3)
+
+- Mobile app (read-only dashboard) — top NPS comment request
+- API access — one large customer is blocked without it
+- Cohort analysis improvements — SaaS customers are using the e-commerce cohort tool for subscription analysis; it's a workaround
+
+## Later
+
+- White-label / agency tier
+- Predictive analytics (LTV forecasting)
+- Data warehouse connectors (Snowflake, BigQuery)
+
+## Open strategic question affecting the roadmap
+
+The board asked us to scope a "SaaS mode" for Q3. The founding team hasn't decided if this is a separate product, a separate pricing tier, or just new features. This decision affects the Q3 plan significantly and hasn't been made.
+
+---
+
+_Amazon integration is late. It's the #1 explicit customer request and its absence has come up in 3 churn conversations._

package/examples/strategy/demo/weeve/shared/weeve-guardrails.md

@@ -0,0 +1,22 @@
+# weeve-guardrails.md — Beacon
+
+## Hard limits
+- No enterprise sales motion in the next 12 months — team is too small, no sales hire planned
+- Shopify and Meta Ads integrations are load-bearing — cannot deprecate without losing 60% of customers
+- $6M raised, 18-month runway at current burn — no raise anticipated in next 9 months
+
+## Strategic constraints
+- Founding team has e-commerce domain expertise; SaaS metrics is adjacent but not core knowledge
+- Board composition: 2 e-commerce founders as angels, lead VC is generalist — board is split on pivot
+- No dedicated marketing or sales hire; all growth has been product-led + word of mouth
+
+## Non-negotiables
+- Monthly pricing (no annual lock-in until product is more mature)
+- Customer data must never be used to train models or shared across tenants
+- The weekly digest must remain part of every paid plan
+
+## What the data shows
+- E-commerce customers: 71 accounts, 14% annual churn, avg contract $900/month
+- SaaS customers (unsolicited): 14 accounts, 6% annual churn, avg contract $1,400/month
+- Top feature requests from e-commerce: better attribution modeling, Amazon integration
+- Top feature requests from SaaS: MRR/ARR tracking, trial conversion funnel, subscription cohorts

package/examples/strategy/demo/weeve/shared/weeve-intake.md

@@ -0,0 +1,17 @@
+# weeve-intake.md — Beacon observations
+
+---
+
+## Captured observations
+
+- 14 SaaS companies signed up without being targeted — lower churn (6%) and higher ACV ($1,400) than the e-commerce core
+- Triple Whale raised $25M Series B last quarter; heavily marketing to the same e-commerce ICP
+- The weekly digest has a 71% open rate — highest engagement of any product surface, but it's not in the positioning
+- 3 e-commerce customers churned in Q2 citing "Triple Whale has better attribution" — a feature Beacon doesn't have
+- The founding team has e-commerce backgrounds; nobody has shipped a SaaS metrics product before
+- Board meeting last month: lead VC asked "are we the right team to win e-commerce against Triple Whale?"
+- Amazon Marketplace integration has been on the roadmap for 6 months; 18 customers have asked for it
+- Cohort analysis feature (LTV by acquisition channel) was built for e-commerce but SaaS customers are using it for subscription cohorts
+- Beacon's pricing page describes an "e-commerce analytics platform" — SaaS customers are confused about whether it's for them
+- One SaaS customer (350 employees) asked about enterprise contract and SSO — team declined, but it would be $4,200/month
+- No formal competitor analysis has been documented; team tracks competitors informally via Twitter/LinkedIn

package/examples/strategy/demo/weeve/shared/weeve-project.md

@@ -0,0 +1,25 @@
+# Beacon — project brief
+
+**What it is:** Beacon is a B2B analytics platform for mid-market e-commerce brands. It pulls data from Shopify, WooCommerce, Meta Ads, and Google Ads, and gives merchandising and marketing teams a unified view of performance without needing a data team.
+
+**Stage:** Series A ($6M raised). 85 paying customers, mostly $500–$2,000/month. ARR ~$1.1M. Growing 8% MoM.
+
+**Core product:**
+- Unified dashboard (revenue, CAC, LTV, ROAS in one view)
+- Automated anomaly detection (flags unusual drops/spikes)
+- Weekly digest emails (summary of key movements)
+- Basic cohort analysis (repeat purchase rate, churn by cohort)
+
+**The strategic tension:**
+The team has been e-commerce-focused since day one. But 14 SaaS companies have been SaaS companies — they found Beacon via word of mouth and are using it for subscription revenue tracking. Churn among SaaS customers is lower (6% vs 14% for e-commerce). The board is asking whether Beacon should pivot to serve SaaS companies more directly. The founding team is split.
+
+**Competitive landscape:**
+- Looker / Tableau: enterprise, requires a data team, overkill for mid-market
+- Supermetrics: connector-focused, not opinionated about what to look at
+- Triple Whale: e-commerce focused, strong brand, direct competitor in the core ICP
+- Baremetrics / ChartMogul: SaaS metrics, would be direct competitors if Beacon pivoted
+
+**Open questions:**
+- Stay e-commerce or broaden to SaaS metrics? Is the SaaS signal real or noise?
+- Triple Whale is well-funded and growing fast — can Beacon differentiate, or is this a feature war?
+- The weekly digest is the highest-rated feature, but it's not part of the core positioning

package/examples/strategy/demo/weeve.yaml

@@ -0,0 +1,15 @@
+# weeve.yaml — strategy preset demo project
+schema_version: "0.4"
+
+project:
+  name: Beacon
+  tag: BCN
+  docs_root: ./weeve
+
+roads:
+  - name: startup
+    path: roads/startup
+
+# Lanes in this preset: compass, layers-plus, maven, pilot
+# Demo project: Beacon — B2B analytics for e-commerce
+# Run /compass-intro to get started

package/examples/strategy/weeve.yaml

@@ -0,0 +1,14 @@
+# weeve.yaml — strategy preset
+# Generated by: weeve init strategy
+schema_version: "0.4"
+
+project:
+  name: My Project             # Replace with your project name
+  tag: MYP                     # Short ID — matches vault Projects/<tag>/ folder
+  # docs_root: ./weeve          # Uncomment to use a local path instead of vault
+
+roads:
+  - name: startup
+    path: roads/startup
+
+# Lanes in this preset: compass, layers-plus, maven, pilot

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@keighleykodric/weeve",
-  "version": "0.1.0",
-  "description": "Cross-functional alignment system — install and manage Weeve lanes",
+  "version": "0.1.2",
+  "description": "Cross-functional contract framework — install and manage Weeve lanes",
   "bin": {
     "weeve": "./bin/weeve.js"
   },
@@ -10,5 +10,16 @@
     "type": "git",
     "url": "https://github.com/keighleykodric/weeve.git"
   },
-  "keywords": ["weeve", "alignment", "cross-functional", "claude-code", "skills"]
+  "keywords": [
+    "weeve",
+    "alignment",
+    "cross-functional",
+    "claude-code",
+    "skills"
+  ],
+  "files": [
+    "bin/",
+    "examples/",
+    "spec/"
+  ]
 }

package/spec/contributing-template.md

@@ -0,0 +1,109 @@
+# CONTRIBUTING.md template for Weeve lanes
+
+_Canonical shared template. Replace `<lane>` with the lane name (e.g., compass, ally, forge). Remove this preamble before publishing._
+_Reference adoption: `weeve-pilot/CONTRIBUTING.md`. Each lane repo should follow this structure and note derivation in its CONTRIBUTING.md header._
+
+---
+
+# 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 weeve/<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 `weeve/<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 `weeve/<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/spec/readme-template.md

@@ -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>-signals` | 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>-signals` — produces the prioritized output
+
+## How it fits
+
+<Lane Name> writes `<lane>-signals.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>-signals.md` for roadmap synthesis
+
+## License
+
+MIT

package/{docs/shared/SHIP-GATE.md → spec/ship-gate.md}

@@ -6,7 +6,7 @@ _The cross-functional quality gate that blocks `/pilot-ship` when critical findi
 
 ## What gate-ship means
 
-A finding in any lane's recommendations file can carry a `gate-ship: true` field. When `/pilot-ship` runs, it scans the ship gate sections of Guard and Verify recommendations files. If any finding is marked `gate-ship: true` and its state is not `closed` or `accepted-risk`, the ship is blocked.
+A finding in any lane's signals file can carry a `gate-ship: true` field. When `/pilot-ship` runs, it scans the ship gate sections of Guard and Verify signals files. If any finding is marked `gate-ship: true` and its state is not `closed` or `accepted-risk`, the ship is blocked.
 
 **The gate is a hard stop, not an advisory.** `/pilot-ship` will not execute tasks in the affected area until the finding is resolved or an explicit operator override is recorded.
 
@@ -61,7 +61,7 @@ An operator can override a gate-ship block. The override must include:
 2. **Scope** — what area the override covers
 3. **Owner** — who made the decision
 
-The override is appended to the **Ship override history** table in the relevant recommendations file so the pattern becomes visible across runs. If the same finding is overridden repeatedly, the finding's severity or scope is wrong — surface it as a 🔴 item to fix the finding, not the override.
+The override is appended to the **Ship override history** table in the relevant signals file so the pattern becomes visible across runs. If the same finding is overridden repeatedly, the finding's severity or scope is wrong — surface it as a 🔴 item to fix the finding, not the override.
 
 ```markdown
 ## Ship override history
@@ -78,7 +78,7 @@ The override is appended to the **Ship override history** table in the relevant
 Blocking findings do not auto-close on ship. When a gate-ship finding is resolved:
 
 1. The lane's `-check` skill verifies the fix (`/guard-check`, `/verify-check`)
-2. The finding state is updated to `closed` in the recommendations file
+2. The finding state is updated to `closed` in the signals file
 3. The gate-ship field remains `true` but the state change lifts the block
 4. `/pilot-ship` reads the updated state on its next run and proceeds
 
@@ -86,14 +86,14 @@ Blocking findings do not auto-close on ship. When a gate-ship finding is resolve
 
 ## How to add gate-ship to a finding
 
-In a lane's recommendations skill spec, tag the finding:
+In a lane's signals skill spec, tag the finding:
 
 ```markdown
 **gate-ship:** true
 **State:** open
 ```
 
-The finding must also appear in a dedicated `## Ship gate` section at the top of the recommendations file so `/pilot-ship` can scan it without parsing the full document.
+The finding must also appear in a dedicated `## Ship gate` section at the top of the signals file so `/pilot-ship` can scan it without parsing the full document.
 
 ---
 
@@ -105,9 +105,9 @@ Changes to the gate-ship protocol (which lanes can trigger it, what severity lev
 2. Reflected in `lane-conventions.md` under the severity mapping section
 3. Communicated to all lane maintainers
 
-Adding gate-ship authority to a new lane requires a recorded decision in `docs/decisions.md` — it changes the power dynamics of Weeve.
+Adding gate-ship authority to a new lane requires a recorded decision in `weeve/decisions.md` — it changes the power dynamics of Weeve.
 
 ---
 
-_Source: `lane-conventions.md` severity mapping, Guard and Verify recommendations skill specs, `/pilot-ship` skill spec_
+_Source: `lane-conventions.md` severity mapping, Guard and Verify signals skill specs, `/pilot-ship` skill spec_
 _Generated by [pilot](https://github.com/keighleykodric/weeve-pilot) · 2026-05-25_