@keighleykodric/weeve 0.1.0 → 0.1.2

package/examples/engineering/demo/weeve/helm/helm-intake.md

@@ -0,0 +1,16 @@
+# helm-intake — Volta
+# Source: weeve/helm/incidents.md, PagerDuty, Datadog, team observations
+
+_Feed to `/helm-intake`. Focus: deploys, monitoring, incidents, on-call._
+
+---
+
+- Rollback avg time: ~8 minutes. SLO target: 5 minutes.
+- Staging cluster availability: 97.1% over the last 30 days. Target: 99.5%.
+- 3 P1 incidents in 60 days — 2 from config drift, 1 from a dependency update.
+- No automated rollback trigger. Rollback is always manual.
+- On-call rotation includes 6 backend engineers who have never touched the Volta codebase.
+- Alert fatigue: PagerDuty fires ~40 alerts/week. Engineers estimate ~30% are noise.
+- No SLO dashboard visible to non-platform engineers. Staging health is invisible to the backend team on rotation.
+- `config-watcher` has been patched 3 times for the same class of drift issue. Root cause unresolved.
+- No deploy freeze windows — deploys happen 24/7 including Friday afternoons.

package/examples/engineering/demo/weeve/helm/incidents.md

@@ -0,0 +1,40 @@
+# Incident log — Volta
+
+_P1 and P2 incidents, last 90 days. P3s tracked in Jira._
+
+---
+
+## P1 — April 14, 2026 · 3h 22m
+
+**Title:** Config drift — env provisioning failure for 12 teams
+**Impact:** 12 engineering teams unable to provision environments
+**Root cause:** Terraform state file format changed after a version bump. `config-watcher` didn't detect the schema change.
+**Resolved by:** Alex manually patched the state file parser.
+**Postmortem:** No formal postmortem. Slack thread exists with notes.
+**Follow-up:** "Add schema validation to config-watcher" — Jira ticket filed, not prioritized.
+
+---
+
+## P1 — March 3, 2026 · 1h 34m
+
+**Title:** Deployment pipeline down
+**Impact:** All deploys blocked across 80 engineers
+**Root cause:** A Go dependency update introduced a breaking API change in the deploy orchestration layer.
+**Resolved by:** Jordan rolled back the dependency manually.
+**Postmortem:** Written. Recommendation: pin dependency versions. Implemented for this one dependency only.
+**Follow-up:** Pin `go-deploy-sdk` to v2.1.3 — done. Other unpinned dependencies not reviewed.
+
+---
+
+## P2 — February 11, 2026 · 6h (4h undetected)
+
+**Title:** Staging cluster degraded
+**Impact:** Staging at 94% availability for 6 hours. 3 teams had broken test environments.
+**Root cause:** Disk pressure on a staging node. No alert threshold set for disk usage.
+**Resolved by:** Sam noticed it in Datadog while working on something else.
+**Postmortem:** No.
+**Follow-up:** Disk usage alert added at 85% threshold.
+
+---
+
+_Note: the Feb and April incidents have the same root cause class (undetected environmental change). No systemic fix has been made._

package/examples/engineering/demo/weeve/helm/on-call-runbook.md

@@ -0,0 +1,33 @@
+# On-call runbook — Volta
+
+_Last updated: Priya, October 2025 (before she left)_
+
+## When you get paged
+
+1. Check the Datadog dashboard (link in Slack #platform-alerts — note: this link may be stale)
+2. If it's the deployment pipeline, look at the GitHub Actions logs
+3. If it's env provisioning, check the Terraform state
+4. If it's secrets, call Alex
+
+## Common issues
+
+- **Config drift:** restart the config-watcher service (`kubectl rollout restart deployment/config-watcher`)
+- **Slow builds:** check if the runner disk is full — happened once in March
+- **PagerDuty noise:** a lot of alerts are false positives, use judgment
+
+## Escalation
+
+- Alex knows most things (deployment pipeline, secrets)
+- Jordan knows Terraform and Kubernetes
+- If neither responds within 10 minutes, post in #platform-oncall
+
+---
+
+_TODO: Add runbook sections for the secrets module._
+_TODO: Add runbook for scheduler and on-call rotation issues._
+_TODO: Update the Datadog dashboard link — the one in Slack is broken._
+_TODO: Document what the backend team engineers should do when they're paged for something they don't recognize._
+
+---
+
+_Note from Jordan, Feb 2026: "This runbook is pretty out of date. Tom and Priya wrote most of it. I've been meaning to update it."_

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

@@ -0,0 +1,25 @@
+# Roadmap — Volta
+
+_There isn't a real roadmap doc. Platform team tracks work in Jira under project VLT._
+_This is a rough summary of what's known to be in progress._
+
+## In progress
+
+- CI caching — no ETA, Alex is working on it between other things
+- Secrets management migration evaluation — considering AWS Secrets Manager vs staying on Vault
+
+## Requested / backlog
+
+- Better rollback UX — current CLI flow is awkward, engineers complain about it
+- Staging environment self-service — currently requires a platform team ticket
+- On-call runbook refresh — hasn't been touched since Tom and Priya left
+
+## Not on the roadmap
+
+- UI redesign
+- Multi-cluster support
+- Any external-facing features
+
+---
+
+_Ask Alex or Jordan for current sprint status. This doc reflects what's publicly known, not what's committed._

package/examples/engineering/demo/weeve/shared/team.md

@@ -0,0 +1,33 @@
+# Team — Volta platform team
+
+_As of Q2 2026_
+
+## Current team
+
+| Name | Role | Tenure | Notes |
+|---|---|---|---|
+| Alex | Senior engineer | 3 years | Owns ~45% of codebase by commit count. Deployment pipeline and secrets module. |
+| Jordan | Senior engineer | 18 months | Infra, Terraform, Kubernetes. Part-time on a separate initiative. |
+| Sam | Mid-level engineer | 8 months | CI/CD tooling, on-call tooling. Still ramping. |
+| Casey | Mid-level engineer | 6 months | Reviewing and fixing bugs. New to the platform domain. |
+
+## Former team (relevant context)
+
+| Name | Departed | Owned |
+|---|---|---|
+| Tom | 8 months ago | Architecture lead. Designed the env provisioning system. No handoff docs written. |
+| Priya | 6 months ago | Secrets module and original on-call setup. Left the on-call runbook partially complete. |
+
+## On-call rotation
+
+Shared with the backend team (6 engineers). Backend engineers are on the rotation but have never touched the Volta codebase.
+
+## Commit ownership (approximate, from git log)
+
+- Alex: ~45%
+- Tom (departed): ~25%
+- Priya (departed): ~15%
+- Jordan: ~10%
+- Others: ~5%
+
+About 40% of the active codebase was last touched by people who are no longer on the team.

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

@@ -0,0 +1,27 @@
+# weeve-guardrails.md — Volta
+
+## Hard limits
+- Kubernetes only — no ECS, no Nomad; infra team has standardized
+- GitHub Actions only — no migration to other CI providers
+- Vault (HashiCorp) for secrets — cannot migrate without a 6-month project
+- No downtime for the deployment pipeline — it runs 200+ deploys/day
+
+## Technical constraints
+- Go backend (no migration appetite), React frontend
+- Multi-cluster: 3 clusters (dev, staging, prod); config changes must propagate to all
+- On-prem + AWS hybrid; some services cannot move to cloud-only solutions
+- PagerDuty + Datadog are the observability stack; no budget to change
+
+## Resourcing
+- 4 platform engineers — no dedicated QA, security, or SRE
+- On-call is shared with backend team who have no Volta context
+
+## Non-negotiables
+- Deployment pipeline must not go below 99.5% availability
+- No breaking changes to the environment provisioning CLI (engineers have scripts depending on it)
+- All secrets changes must be auditable (full log retained for 90 days)
+
+## Known risks (from last 3 incident retros)
+- Config drift between clusters is a recurring root cause — no automated reconciliation
+- Dependency updates applied without test validation caused a P1 in week 8
+- The secrets module's last code review was 14 months ago

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

@@ -0,0 +1,18 @@
+# weeve-intake.md — Volta observations
+
+---
+
+## Captured observations
+
+- CI average runtime is 18 minutes; p95 is 31 minutes — engineers are routinely skipping it on "small" PRs
+- The deployment pipeline module has 9% test coverage; it processes ~200 deploys/day
+- 3 P1 incidents in 60 days: 2 config drift, 1 dependency update gone wrong
+- Secrets management module hasn't been reviewed or audited in 14 months
+- No automated config reconciliation between clusters — drift is detected only after incidents
+- The `volta env create` CLI has 3 undocumented flags that engineers have learned via Slack — not in docs
+- Rollback takes ~8 minutes on average; SLO target is 5 minutes
+- Two original authors left 8 months ago; no knowledge transfer docs
+- The on-call rotation includes backend engineers who've never touched Volta's codebase
+- Go module dependencies haven't been audited for CVEs in the current quarter
+- One engineer is maintaining 70% of the codebase by commit count — single point of failure
+- Staging cluster SLO dashboard shows 97.1% availability last 30 days vs 99.5% target

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

@@ -0,0 +1,29 @@
+# Volta — project brief
+
+**What it is:** Volta is an internal developer platform at a 120-person B2B SaaS company. It wraps Kubernetes, Terraform, and GitHub Actions into a self-service portal — engineers provision environments, manage deployments, and view SLO dashboards without touching infra directly.
+
+**Stage:** In production. ~80 engineers using it daily. Maintained by a 4-person platform team. Not a product — internal tooling.
+
+**Core surfaces:**
+- Self-service environment provisioning (web UI + CLI)
+- Deployment pipeline management (GitHub Actions, wrapped)
+- SLO/SLA dashboard (pulls from Datadog + PagerDuty)
+- Secrets management (Vault integration, web UI)
+- On-call rotation management
+
+**Current state:**
+- The codebase is 3 years old; two original authors have left
+- Test coverage is ~42% overall; the deployment pipeline module is at 9%
+- CI runs take ~18 minutes on average; engineers have started skipping it on "small" changes
+- Three P1 incidents in the last 60 days — two were traced to config drift, one to a dependency update
+- Secrets management module has never had a security audit
+
+**Team:**
+- 4 platform engineers (2 senior, 2 mid)
+- No dedicated QA or security engineer
+- On-call rotation shared with the backend team (who don't maintain Volta)
+
+**Open questions:**
+- The deployment pipeline module is the most-used but least-tested area — rewrite or harden?
+- CI time is killing developer experience; caching strategy is ad hoc
+- Should secrets management be migrated to a managed service (e.g., AWS Secrets Manager)?

package/examples/engineering/demo/weeve/verify/coverage-report.md

@@ -0,0 +1,49 @@
+# Coverage report — Volta
+
+_From `go test -coverprofile`, run April 28, 2026._
+
+## Summary
+
+| Module | Coverage | Trend | Risk |
+|---|---|---|---|
+| api/ | 71% | → stable | Low |
+| provisioner/ | 58% | ↓ declining | Medium |
+| deployer/ | 9% | ↓ declining | **Critical** |
+| secrets/ | 34% | → stable | High |
+| scheduler/ | 61% | ↑ improving | Low |
+| config-watcher/ | 22% | → stable | High |
+| web/ | 41% | → stable | Medium |
+
+**Overall: ~42%**
+
+## deployer/ detail — what's tested vs not
+
+**Covered:**
+- `NewDeployer()` constructor
+- Basic deploy job creation
+- Error type definitions
+
+**Not covered:**
+- Deploy execution logic
+- Rollback logic
+- Retry behavior on failure
+- Concurrent deploy handling
+- GitHub Actions API calls (mocked in all tests — never hit a real API)
+
+## Known skipped tests
+
+```go
+// deployer/deploy_test.go:47
+t.Skip("flaky, investigate - added Jan 15 2026")
+
+// deployer/concurrent_test.go:23
+t.Skip("race condition, needs fixing")
+```
+
+## Untested scenarios (no tests exist)
+
+- Integration with live GitHub Actions
+- Behavior under high deploy frequency (>5 concurrent)
+- Rollback triggered during an active deploy
+- Secrets decryption in the deploy pipeline path
+- What happens when `config-watcher` and `deployer/` update the same environment simultaneously

package/examples/engineering/demo/weeve/verify/verify-intake.md

@@ -0,0 +1,16 @@
+# verify-intake — Volta
+# Source: weeve/verify/coverage-report.md, CI logs, team observations
+
+_Feed to `/verify-intake`._
+
+---
+
+- Overall coverage: 42%. `deployer/` module (highest traffic): 9%.
+- 2 known flaky tests skipped with `t.Skip()`. Neither has been investigated in 3+ months.
+- CI is routinely skipped by engineers on "small" changes — no enforcement mechanism exists.
+- No integration tests for `deployer/`. All tests mock the GitHub Actions API calls.
+- Load testing: never run. No performance baselines exist.
+- Staging is the only pre-prod environment. No canary or shadow deploys.
+- Release process: code merges to main and deploys automatically. No gating step.
+- No feature flags. Every change is a full rollout to all 80 engineers simultaneously.
+- QA role: doesn't exist on the platform team or anywhere in the on-call structure.

package/examples/engineering/demo/weeve.yaml

@@ -0,0 +1,15 @@
+# weeve.yaml — engineering preset demo project
+schema_version: "0.4"
+
+project:
+  name: Volta
+  tag: VLT
+  docs_root: ./weeve
+
+roads:
+  - name: startup
+    path: roads/startup
+
+# Lanes in this preset: forge, helm, verify, guard, pilot
+# Demo project: Volta — internal developer platform
+# Run /forge-intro to get started

package/examples/engineering/weeve.yaml

@@ -0,0 +1,14 @@
+# weeve.yaml — engineering preset
+# Generated by: weeve init engineering
+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: forge, helm, verify, guard, pilot

package/examples/gtm/CODEOWNERS.template

@@ -0,0 +1,8 @@
+# Weeve lane ownership
+# Copy to .github/CODEOWNERS and replace team handles with your org's teams
+# Requires GitHub branch protection with "Require review from Code Owners" enabled
+
+weeve/compass/       @leadership
+weeve/maven/         @marketing
+weeve/pitch/         @revenue
+weeve/pilot/         @leadership

package/examples/gtm/README.md

@@ -0,0 +1,59 @@
+# gtm preset
+
+## Who this is for
+
+The `gtm` (go-to-market) preset is for teams preparing a product launch, entering a new market segment, or standing up a sales motion for the first time. It connects strategic orientation directly to market narrative and revenue readiness — giving marketing, sales, and revenue leadership the structured artifacts they need to launch with confidence. Use this preset when the critical questions are about messaging, positioning, and whether the revenue motion is ready to execute, not about product or engineering quality.
+
+## What you get
+
+- **compass-signals.md** — market opportunity map: where demand is moving and what competitors are signaling
+- **compass-context.md** — current position snapshot to anchor messaging and differentiation decisions
+- **maven-brief.md** — go-to-market narrative and positioning brief with key messages and proof points
+- **pitch-deck.md** — structured pitch framework: value proposition, objection handling, and proof story for sales and investors
+- **pilot-brief.md** — launch readiness recommendation with go/no-go decision, key risks, and suggested timing
+
+## Install
+
+```bash
+npx weeve add gtm
+```
+
+Equivalent individual lanes:
+
+```bash
+npx weeve add compass maven pitch pilot
+```
+
+## First run sequence
+
+Run these skills in order. Steps marked **(parallel)** can be run simultaneously once their prerequisites are complete.
+
+1. **compass** — Maps market signals, competitor positioning, and demand shifts to identify where the launch has the highest chance of landing.
+2. **maven** — Builds the go-to-market narrative from the compass signals: positioning, differentiation, key messages, and the story the market needs to hear.
+3. **pitch** — Translates the maven narrative into a structured pitch framework with value proposition, proof points, and objection handling for sales and investor conversations.
+4. **pilot** — Evaluates launch readiness across market timing, narrative quality, and revenue motion maturity; outputs a go/no-go brief with risk ranking.
+
+## What you'll have at the end
+
+| File | Description |
+|---|---|
+| `weeve/compass/compass-signals.md` | Market opportunity map with demand signals and competitor moves |
+| `weeve/compass/compass-context.md` | Competitive position snapshot to anchor differentiation |
+| `weeve/maven/maven-brief.md` | GTM narrative, positioning brief, and key messages with proof points |
+| `weeve/pitch/pitch-deck.md` | Structured pitch framework with value proposition and objection handling |
+| `weeve/pilot/pilot-brief.md` | Launch readiness brief with go/no-go recommendation and risk ranking |
+
+## CODEOWNERS
+
+Copy to `.github/CODEOWNERS`:
+
+```
+weeve/compass/       @leadership
+weeve/maven/         @marketing
+weeve/pitch/         @revenue
+weeve/pilot/         @leadership
+```
+
+## Time estimate
+
+First full run: **40–65 minutes**. Maven is the most intensive lane and benefits significantly from having sharp compass artifacts to work from — invest time in compass inputs (competitor briefs, market research, positioning hypotheses) for the best maven output. Pitch runs quickly once maven is complete. Subsequent runs before a launch: 15–25 minutes for incremental refinement.

package/examples/gtm/demo/README.md

@@ -0,0 +1,19 @@
+# Relay — GTM preset demo
+
+An outbound sales automation SaaS with a noisy pipeline and inconsistent positioning. Use this demo to try the **GTM** preset (Compass, Maven, Pitch, Pilot).
+
+## Run it
+
+```bash
+weeve add gtm
+/compass-intro   # strategic position — where Relay plays and why
+/maven-intro     # messaging, positioning, brand voice
+/pitch-intro     # pipeline health, ICP, conversion, pricing
+/pilot-priorities
+```
+
+Outputs land in `./weeve/<lane>/`.
+
+## The project
+
+Relay has grown fast but the GTM motion is inconsistent. Two reps win at 2× the rate of the others. The website doesn't say what the team says on sales calls. 60% of churned customers never set up a sequence. The positioning against Apollo isn't landing even though Relay should win that comparison on paper. Rich material for Compass (where to play), Maven (how to say it), and Pitch (why deals are being lost).

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

@@ -0,0 +1,15 @@
+# compass-intake — Relay
+# Source: sales data, CRM, team conversations
+
+_Feed to `/compass-intake`._
+
+---
+
+- Win rate: 21% overall. Two reps at 38–41%, two at 12–14%. Gap unexplained.
+- Top loss reason: "evaluating Apollo" (38% of losses). Apollo is high-volume/low-quality — the opposite of Relay's pitch. Something is wrong with how the differentiation is being communicated.
+- Churn pattern: 60% of churned customers never set up a sequence in 14 days. This is an onboarding gap, not a product gap.
+- Referrals: 31% of new pipeline, growing organically. No formal referral program.
+- PLG debate: team is split on free trial. Some worry it attracts wrong customers who won't set up sequences — the same profile as the high-churn cohort.
+- ICP: 4 salespeople describe it differently when asked. No written ICP document.
+- SOC 2 Type II gap: 2 enterprise deals lost for this reason in 90 days. Not on the current roadmap.
+- Series A investors asking about net revenue retention. Not tracked consistently.

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

@@ -0,0 +1,35 @@
+# maven-intake — Relay
+# Source: weeve/maven/website-notes.md, sales deck review, team conversations
+
+_Feed to `/maven-intake`._
+
+---
+
+## Messaging inconsistency
+
+- Website: "The smarter outbound platform" — vague, no differentiation
+- Sales deck: "Personalize at scale" — same phrase Apollo uses
+- Top rep (Alex): "Precision over volume" — resonates, not in any asset
+- Bottom reps: "It's like Apollo but easier" — positions us as a cheaper version, not a different thing
+
+Four different answers to "what is Relay?"
+
+## Website observations
+
+- Hero doesn't mention quality, precision, or the Apollo differentiation
+- AI personalization (key differentiator) is buried — one paragraph, third section
+- Two case studies, both 14 months old, both predate AI personalization
+- Social proof: "210+ teams" — feels small; no logos on homepage
+- Pricing: 3 tiers, but reps say "we only ever sell the middle tier"
+
+## Acquisition
+
+- Main channel: outbound (ironic). Some inbound from comparison content.
+- Referrals: 31% of pipeline, growing organically, no program supporting it.
+- One "Apollo alternatives" article drives some inbound.
+- No content strategy or SEO investment.
+
+## Email / lifecycle
+
+- Onboarding sequence exists but CS doesn't follow a standard playbook.
+- No re-engagement or churn-prevention sequences.

package/examples/gtm/demo/weeve/maven/website-notes.md

@@ -0,0 +1,33 @@
+# Website notes — Relay
+
+_Quick review, April 2026. Not comprehensive._
+
+## Hero
+
+"The smarter outbound platform. Build sequences, personalize at scale, close more deals."
+
+- "Smarter" is undefined
+- "Personalize at scale" is Apollo's phrase
+- "Close more deals" is what every sales tool says
+- No mention of quality, precision, or why Relay is different from Apollo
+
+## Features section
+
+Sequence builder — well explained. AI personalization — one paragraph, third. Inbox management — not mentioned. Analytics — one line.
+
+## Social proof
+
+- 2 case studies (14 months old)
+- "210+ teams" as the social proof number
+- No customer logos
+
+## Pricing
+
+- Starter / Growth / Scale at $49 / $99 / $199
+- Reps say: "we only ever sell Growth"
+- No "most popular" indicator
+- Annual discount exists but not emphasized
+
+---
+
+_No changes made since the product launch 14 months ago._

package/examples/gtm/demo/weeve/pitch/pitch-intake.md

@@ -0,0 +1,54 @@
+# pitch-intake — Relay
+# Source: weeve/pitch/win-loss-notes.md, CRM notes, call shadowing, CS data
+
+_Feed to `/pitch-intake`. Most actionable sales signal is here._
+
+---
+
+## Win rate by rep
+
+- Alex (AE, 2 years): 41% — $180K last quarter
+- Morgan (AE, 2 years): 38% — $160K last quarter
+- Jordan (AE, 1 year): 14% — $52K last quarter
+- Taylor (AE, 8 months): 12% — $38K last quarter
+
+Gap between top and bottom reps is not explained by tenure alone. Jordan has been here a year.
+
+## What Alex does differently (from call shadowing)
+
+- Leads with AI personalization demo, not sequence builder
+- Asks "what's your current reply rate?" before showing anything — anchors on quality
+- Never uses "personalize at scale" — says "precision over volume"
+- Qualifies against Apollo early: "what's your reply rate with Apollo?"
+
+## What bottom reps do
+
+- Lead with the sequence builder — feature parity with Apollo, not a differentiator
+- Use "personalize at scale" from the sales deck (same phrase Apollo uses)
+- Demo everything instead of the top 2-3 features
+- Skip discovery questions
+
+## Loss breakdown (last 60 lost deals, from CRM)
+
+| Reason | Count |
+|---|---|
+| Evaluating Apollo | 23 |
+| Price | 12 |
+| No decision (went cold) | 9 |
+| Chose Outreach | 8 |
+| Missing feature | 5 |
+| Other | 3 |
+
+## Churn patterns (from CS data)
+
+- 60% of churned customers never set up a sequence in the first 14 days
+- No structured onboarding — every CSM runs it differently
+- Time to first sequence: median 8 days, range 1–47 days
+- Customers who set up a sequence within 3 days: 4% annual churn
+- Customers who take >14 days: 34% annual churn
+
+## Feature awareness gaps (from customer calls last month)
+
+- 3 customers: "I didn't know it could do LinkedIn steps"
+- 2 customers: "I didn't realize there was inbox management"
+- These are differentiating features customers are paying for but not using

package/examples/gtm/demo/weeve/pitch/sales-deck-notes.md

@@ -0,0 +1,28 @@
+# Sales deck notes — Relay
+
+_Quick review. Not a full audit._
+
+## Current structure (22 slides)
+
+1. Title: "The smarter outbound platform"
+2. The problem: "Outbound is broken"
+3. Solution: "Personalize at scale"
+4. Sequence builder demo
+5. AI personalization demo
+6. Analytics demo
+7. Integrations
+8–9. Two case studies (both 14 months old, pre-AI personalization)
+10–22. Pricing, security, FAQ
+
+## Issues noticed
+
+- Slide 3 uses "personalize at scale" — Apollo's phrase
+- AI personalization is slide 5 (after the sequence builder). Top reps lead with this, not the deck.
+- Both case studies predate the AI personalization feature — don't reflect current product
+- No reply rate data or industry benchmarks
+- No slide addressing the Apollo objection (38% of losses)
+- No "quality vs volume" framing anywhere in the deck
+
+---
+
+_Deck hasn't been updated in 14 months. Most slides reflect the pre-AI-personalization product._

package/examples/gtm/demo/weeve/pitch/win-loss-notes.md

@@ -0,0 +1,40 @@
+# Win/loss notes — Relay
+
+_Selected deals, last 90 days. From CRM notes + brief follow-up calls._
+
+## Wins
+
+**W-01 — 22-person SaaS sales team · $1,200/mo · Rep: Alex · Beat Apollo**
+Alex led with reply rate data. Prospect had used Apollo for 6 months with 1.2% reply rates. Alex showed Relay's benchmark (3.8% for similar sequences).
+Prospect quote: "You led with the only thing I actually care about."
+
+**W-02 — 15-person e-commerce brand · $99/mo · Rep: Morgan · No competitor**
+Inbound from a referral. Never considered Apollo. Chose Relay because "it looked easier."
+
+**W-03 — 35-person fintech · $1,200/mo · Rep: Alex · Beat Instantly**
+Instantly is email-only. Alex knew this before the call and led with LinkedIn steps.
+
+**W-04 — 8-person agency · $49/mo · Rep: Taylor · No real competitor**
+Won on price. Hasn't set up a sequence yet (day 12). At-risk of churn.
+
+## Losses
+
+**L-01 — 60-person B2B SaaS · Went to Apollo · Rep: Jordan**
+Jordan led with the sequence builder. Prospect said "Apollo does this too." No reply rate discussion. Apollo offered 6 months free.
+
+**L-02 — 12-person startup · Went to Apollo free tier · Rep: Taylor**
+Price objection, then Apollo free tier. Follow-up 3 months later: "Apollo's data isn't great but it's free."
+
+**L-03 — 45-person SaaS · No decision · Rep: Morgan**
+Champion left the company during the evaluation. Deal went cold. New contact unfamiliar with the evaluation history.
+
+**L-04 — 80-person enterprise · Went to Outreach · Rep: Alex**
+Lost despite best rep. Procurement required SOC 2 Type II. Relay doesn't have it.
+Second deal lost for this reason in 90 days.
+
+## Patterns
+
+- Every win above $500/mo included a reply rate or quality conversation early in the cycle
+- Alex and Morgan both disqualify fast if the prospect's primary need is contact data volume
+- Apollo free tier is pulling in price-sensitive prospects who probably weren't right-fit anyway
+- SOC 2 gap has surfaced twice at the enterprise tier — may be a real blocker worth scoping

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

@@ -0,0 +1,30 @@
+# Competitive notes — Relay
+
+_From sales calls and rep knowledge. Not a formal analysis._
+
+## Competitors we lose to most
+
+**Apollo.io** — top loss reason in the CRM (38% of losses)
+- Apollo is higher-volume, lower-quality. Our pitch is the opposite.
+- We lose because Apollo has a larger contact database and buyers conflate "more data" with "better outbound."
+- Apollo has a free tier that pulls in price-sensitive prospects.
+- Our counter-positioning ("quality over volume") is not on our website.
+
+**Outreach / Salesloft** — enterprise, $50K+ contracts
+- Win here when budget is the objection against enterprise tools.
+- Rarely the direct competitor unless the company is also considering enterprise.
+
+## Adjacent (not direct competition)
+
+- **Instantly / Lemlist** — email-only, founder-led teams. Different motion.
+- **Clay** — data enrichment and sequencing. Some power-user overlap.
+
+## What we don't know
+
+- Why we lose to Apollo when our quality positioning should be a clear differentiator
+- Whether prospects understand the Apollo quality difference or just see us as "Apollo but smaller"
+- Whether the SOC 2 gap (lost 2 enterprise deals) is a real pipeline blocker
+
+---
+
+_Win rate: 21% overall. Two reps win at 38–41%. Understanding the rep gap is more urgent than competitor research._