@keighleykodric/weeve 0.1.0

package/.github/SECURITY.md

@@ -0,0 +1,22 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+If you discover a security vulnerability in any Weave framework repo, please report it responsibly by opening an issue on the [pilot repo](https://github.com/kjk/pilot/issues) with the label `security`.
+
+Do **not** open a public issue on the affected repo if the vulnerability could be exploited before a fix is available. In that case, email the maintainer or use a private GitHub issue on pilot.
+
+## Scope
+
+A security issue includes:
+
+- Credential or secret exposure in generated output
+- Path traversal or file-system access beyond intended scope
+- Prompt injection that bypasses guardrails
+- Unintended data leakage between commands or sessions
+
+General bugs, feature requests, and performance issues are **not** security issues.
+
+## Response
+
+Best effort. Reports will be acknowledged within **7 days**. Fixes are prioritized by severity.

package/GOVERNANCE.md

@@ -0,0 +1,173 @@
+# Governance — ownership and permissions
+
+Addresses how ownership and permissions work in Weeve across multiple people and teams — the gap between one person running all lanes solo and an org with specialists writing to specialist outputs.
+
+This is a known adoption gate. Solvable, mostly with infrastructure orgs already use, but it needs to be explicit before Weeve lands in any multi-team environment.
+
+## The problem
+
+Weeve is markdown-in-git. In a multi-person org, anyone with repo write access can edit anything. Without explicit ownership boundaries:
+
+- Non-specialists write to specialist outputs (marketer edits `compass-recommendations`, designer edits `maven-recommendations`)
+- Authority is ambiguous — consumers don't know if upstream is the right voice
+- Quality erodes as the wrong people make decisions
+- Trust in the contract files breaks down
+
+This is the natural failure mode of any document collaboration system at scale. Weeve needs a governance overlay that makes ownership visible and enforceable.
+
+## The architectural insight
+
+Weeve already has the right ownership structure built in:
+
+- Each pack 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)
+
+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.
+
+## Editor, storage, reader — three separable layers
+
+A common adoption concern: *"won't non-technical departments resist GitHub?"* Weeve's answer is that **edit, store, and read are three separable layers**, and a department only has to engage with whichever it wants:
+
+| Layer | Who | Tool |
+|---|---|---|
+| **Editor** | The specialist team | Their preferred tool — GitHub, Obsidian, Notion (with markdown export), VS Code, Cursor |
+| **Storage** | The org (versioned, audited) | Git, Dropbox, Drive, Box, or self-hosted |
+| **Reader / consumer** | Everyone | Dashboard, AI agent, Slack notification, exported PDF, the markdown file itself |
+
+A marketer never has to touch GitHub directly. They consume Maven's outputs via the dashboard, get notifications via Slack, ask the AI agent for the latest positioning, and edit (if they edit at all) in a tool they already know. GitHub is plumbing.
+
+For non-technical orgs entirely, the storage layer can be something other than git. Downstream tools read from wherever; Weeve doesn't care.
+
+## Layer 1 — Git-native ownership (OSS, works today)
+
+GitHub CODEOWNERS solves the core write-permission problem. One file at the repo root:
+
+```
+docs/compass/      @leadership-team
+docs/maven/        @marketing-team
+docs/rubric/       @design-system-team
+docs/ally/         @accessibility-team
+docs/layers-plus/  @product-team
+docs/pilot/        @leadership-team
+```
+
+Combined with branch protection rules requiring owner approval, this is a hard gate. PRs touching those paths auto-request review from the right team and cannot merge without it.
+
+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)
+
+Each pack declares its owner, consumers, and contract in a small `pack.yaml`:
+
+```yaml
+pack: compass
+owner: leadership
+consumers: [product, engineering, marketing]
+contract: 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
+- 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:
+
+- Marketing reads `compass-position` to understand the strategic frame
+- Leadership reads `ally-recommendations` to understand accessibility commitments
+- Engineering reads `maven-recommendations` to understand the launch shape
+
+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:
+
+| 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 |
+
+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:
+
+| Pack | Default owner |
+|---|---|
+| Compass | Leadership / founder |
+| Layers+ | Product / design |
+| Ally | Accessibility lead (or whoever owns a11y) |
+| Rubric | Design system / DesignOps |
+| Maven | Marketing |
+| _(Personal capture tool)_ | Personal — usually not shared |
+| Pilot | Leadership (output) + platform (config) |
+
+## Adoption shape — the `.alignment/` repo layout
+
+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
+│   ├── CODEOWNERS           <- write permissions per folder
+│   └── pack-overrides/      <- org-specific tweaks (rare)
+├── docs/
+│   ├── compass/             <- @leadership-team
+│   ├── layers-plus/         <- @product-team
+│   ├── ally/                <- @accessibility-team
+│   ├── rubric/              <- @design-system-team
+│   ├── maven/               <- @marketing-team
+│   └── pilot/               <- mixed ownership (see below)
+└── 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.
+
+**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:
+
+```
+docs/pilot/pilot-roadmap.md       @leadership-team
+docs/pilot/pilot-config.yaml      @platform-team
+```
+
+That split mirrors the role split above.
+
+## Config control — who owns what across the system
+
+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) |
+| 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 |
+
+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.
+
+## Compliance posture
+
+For teams that care about compliance (SOC2, ISO27001, GDPR/CCPA), Weeve is structurally well-positioned:
+
+- **Audit trail.** Git history is already an immutable, signed, attributed change log — built in, not a paid feature.
+- **Access control.** CODEOWNERS + branch protection + GitHub teams = real RBAC, audited by an established external service.
+- **Data residency.** Customer's repo = customer's infrastructure = whatever residency they've already configured for source code. No new residency story to defend.
+- **Encryption.** GitHub's repo-at-rest encryption applies; transit is HTTPS. Same for any git-based backend.
+- **Backup.** Git is inherently distributed; backup is built in via every clone.
+- **Vendor risk.** BYO-everything means data stays in the adopter's infrastructure. No new vendor to evaluate for data handling.
+
+Adopters who need compliance stories (SOC2, vendor risk questionnaires) get one for free from the git-native architecture.
+
+

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 pilot contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,138 @@
+# 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.
+
+Markdown-in-git. BYO everything. Each lane writes a `<lane>-recommendations.md` file in the same shape. Pilot reads them all and produces a single roadmap. The alignment property: findings from different domains compose, rather than sit in separate files nobody reads.
+
+---
+
+## How it works
+
+1. Install the lanes you need
+2. Run each lane against your product (`/<lane>-intro` to start)
+3. Each lane writes findings to `docs/<lane>/<lane>-recommendations.md`
+4. Run `/pilot-roadmap` — Pilot reads all lane outputs and synthesizes a prioritized roadmap
+5. Run `/pilot-ship` — autonomous worker picks tasks from the roadmap and ships them
+
+---
+
+## Lanes
+
+### Strategy & Product
+
+| Lane | What it does | Install |
+|---|---|---|
+| **Compass** | Strategic positioning — Wardley, JTBD, 7 Powers | `npx skills add keighleykodric/weeve-compass` |
+| **Layers+** | Product design — 7-layer evaluation from domain to surface | `npx skills add keighleykodric/weeve-layers-plus` |
+| **Felt** | UX research — personas, journeys, synthesis, feedback | `npx skills add keighleykodric/weeve-felt` |
+
+### Design & Accessibility
+
+| Lane | What it does | Install |
+|---|---|---|
+| **Ally** | Accessibility — WCAG 2.2 AA across 7 zones | `npx skills add keighleykodric/weeve-ally` |
+| **Rubric** | Design system — tokens, components, patterns, voice | `npx skills add keighleykodric/weeve-rubric` |
+
+### Engineering & Operations
+
+| Lane | What it does | Install |
+|---|---|---|
+| **Forge** | Engineering health — architecture, code health, CI/CD, debt | `npx skills add keighleykodric/weeve-forge` |
+| **Helm** | Platform ops — deploy, rollback, monitoring, SLOs, incidents | `npx skills add keighleykodric/weeve-helm` |
+| **Verify** | QA — test strategy, regression, release readiness, bugs | `npx skills add keighleykodric/weeve-verify` |
+| **Guard** | Security — threat model, secrets, auth, supply chain, compliance | `npx skills add keighleykodric/weeve-guard` |
+
+### Go-to-Market
+
+| Lane | What it does | Install |
+|---|---|---|
+| **Maven** | Marketing — positioning, brand voice, campaigns, deliverables | `npx skills add keighleykodric/weeve-maven` |
+| **Pitch** | Sales — pipeline, ICP, conversion, competitive, pricing | `npx skills add keighleykodric/weeve-pitch` |
+
+### Orchestration
+
+| Lane | What it does | Install |
+|---|---|---|
+| **Pilot** | Synthesis — reads all lane outputs, writes the roadmap, ships tasks | `npx skills add keighleykodric/weeve-pilot` |
+
+### Scaffolded (not yet built)
+
+| Lane | Purpose | Status |
+|---|---|---|
+| **Anchor** | Shared infrastructure — schema, templates, conventions | Scaffold |
+| **Charter** | Team agreements and operating contracts | Scaffold |
+| **Ledger** | Financial tracking and budget alignment | Scaffold |
+| **Roster** | People, roles, and capacity | Scaffold |
+
+---
+
+## You don't need every lane
+
+Install only the lanes that match your team. If marketing doesn't use Maven, that's fine — Maven won't appear in the Pilot roadmap, and nothing breaks.
+
+Departments without a lane can still contribute. Any team member can feed context into another lane's intake skill — paste a doc, a ticket link, or a screenshot into `/compass-intake` or `/layers-plus-intake` and it gets scoped and routed. You don't need a lane installed to provide input; you just won't get lane-specific findings back.
+
+### Role presets
+
+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
+```
+
+| Preset | Lanes included |
+|---|---|
+| **core** | Compass, Layers+, Ally, Rubric, Pilot |
+| **product** | Compass, Layers+, Ally, Rubric, Felt, Pilot |
+| **engineering** | Forge, Helm, Verify, Guard, Pilot |
+| **strategy** | Compass, Layers+, Maven, Pilot |
+| **gtm** | Compass, Maven, Pitch, Pilot |
+| **all** | Every lane |
+
+Every preset includes Pilot — it's the synthesis layer that makes the lanes compose.
+
+---
+
+## First-run order
+
+Compass → Layers+ → Ally → Rubric → Maven → Pilot
+
+See [WORKFLOW.md](WORKFLOW.md) for the full cadence, within-lane sequences, and team ceremony examples.
+
+---
+
+## The alignment property
+
+Each lane writes findings independently. Pilot reads them all and surfaces:
+- Cross-lane conflicts (strategy says X, design says Y)
+- Ship gates (Guard or Verify can block `/pilot-ship`)
+- Priority synthesis (what to do first, across all domains)
+
+The claim: running all lanes against the same product produces coherent, composable output — not just a bigger folder of tools.
+
+---
+
+## Schema
+
+All lane recommendations files follow a versioned schema: [recommendations-schema.md](docs/shared/recommendations-schema.md) (v0.3).
+
+The schema is the durable asset. Severity uses `🔴 High / 🟡 Medium / 🟢 Low`. Lane files never use Now/Next/Watch — that vocabulary belongs to Pilot's roadmap output.
+
+---
+
+## Contributing
+
+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.
+
+---
+
+## License
+
+MIT — see [LICENSE](LICENSE).