godpowers 0.15.0

package/skills/god.md

@@ -0,0 +1,207 @@
+---
+name: god
+description: |
+  Front door. Take free-text intent from the user, match it to a recipe via
+  lib/recipes.matchIntent, and propose the matching command sequence. If no
+  text given, fall back to state-driven suggestion (same as /god-next Mode 3).
+
+  Triggers on: "/god", "god", "/god help", "I want to ...", "how do I ..."
+  (when not matched by a more specific command)
+---
+
+# /god (front door)
+
+The natural-language entry point. Users describe what they want; this skill
+matches the intent to a recipe and suggests the right command sequence. No
+agent is spawned here. This is a thin router on top of `lib/recipes.js`.
+
+## Why this exists
+
+Slash commands are precise but require the user to know the command name.
+Recipes are scenario-shaped ("I'm coming back after a week", "production is
+broken", "add a feature mid-arc") and match free-text intent. `/god` is the
+front door that turns intent into the right slash command.
+
+This skill complements `/god-next` rather than replacing it:
+
+| Skill | Best for |
+|-------|----------|
+| `/god <free text>` | "I don't know which command, but here's what I want" |
+| `/god-next` | "I just finished X, what's next?" or pre-flight checks |
+| `/god-status` | "Where are we? what's done?" |
+| `/god-init` | "Start a project here" |
+| `/god-mode` | "Run the whole arc autonomously" |
+
+## Process
+
+### Step 1: parse the user's intent
+
+Treat everything after `/god` as free text. If empty, treat as state-driven.
+
+```
+/god add a feature without breaking the current arc
+   text = "add a feature without breaking the current arc"
+
+/god
+   text = "" -> state-driven mode
+```
+
+### Step 2: dispatch by mode
+
+```
+text empty?
+  yes -> state-driven: call lib/recipes.suggestForState(projectRoot)
+         display top 3 recipes ranked by current lifecycle phase
+         also call lib/router.suggestNext(projectRoot) for structural next
+
+  no  -> intent-driven: call lib/recipes.matchIntent(text, projectRoot)
+         take top 1-3 matches by score
+         if highest score >= 10 (exact phrase match): propose directly
+         if highest score 5-9 (all-words match): propose with confirmation
+         if no matches: suggest /god-next (state-driven fallback)
+```
+
+### Step 3: render the suggestion
+
+For a single high-confidence match (score >= 10):
+
+```
+Best match: <recipe.metadata.name>
+What this does: <recipe.metadata.description>
+
+Sequence:
+  1. <command>   <why>
+  2. <command>   <why>
+  ...
+
+Run this sequence? (yes / show others / cancel)
+```
+
+For multiple matches (top 3):
+
+```
+Top matches for "<user text>":
+
+  1. <recipe-name>   (<score>)   <description>
+  2. <recipe-name>   (<score>)   <description>
+  3. <recipe-name>   (<score>)   <description>
+
+Pick one (1/2/3) or describe more specifically.
+```
+
+For state-driven (no text):
+
+```
+Where you are: <lifecycle-phase>
+
+Structural next: <command>   <why>
+
+Recipes that fit your current state:
+  - <recipe-name>   <description>
+  - <recipe-name>   <description>
+
+Run structural next? (yes / pick recipe / cancel)
+```
+
+### Step 4: execute or hand off
+
+If user confirms a recipe:
+  - Walk the recipe's `default-sequence.steps`
+  - For each step, suggest the slash command and let the user invoke it
+    (or invoke it directly if it has no destructive side effects)
+
+If user picks the structural next:
+  - Hand off to `/god-next --before=<command>` so prereqs are checked first
+
+## Interaction model
+
+This skill is a router, not an orchestrator. It:
+- Reads recipes (via `lib/recipes.js`)
+- Reads state (via `lib/state.js`)
+- Proposes commands
+
+It does NOT:
+- Spawn agents directly
+- Modify `state.json`, `PROGRESS.md`, or `events.jsonl`
+- Run multi-tier work (that's `god-orchestrator`'s job, accessed via `/god-mode`)
+
+The user always sees what command will run. Confirmation is required before
+any destructive sequence executes.
+
+## Examples
+
+### Example 1: high-confidence intent match
+
+```
+User: /god production is broken
+
+Match: production-broken (score: 30)
+What this does: P0 incident response with rollback-first triage
+
+Sequence:
+  1. /god-hotfix     Spawn god-debugger for fast triage
+  2. /god-deploy     Push the fix once green
+  3. /god-postmortem Schedule the incident review
+
+Run this sequence? (yes / show others / cancel)
+```
+
+### Example 2: ambiguous intent (multiple matches)
+
+```
+User: /god add a new feature
+
+Top matches for "add a new feature":
+
+  1. add-feature-mid-arc-pause       (15)   Pause /god-mode arc, run feature, resume
+  2. add-feature-small               (10)   Lightweight feature, no arc context
+  3. add-feature-next-milestone      (10)   Defer to next milestone
+
+Pick one (1/2/3) or describe more specifically.
+```
+
+### Example 3: state-driven (no text)
+
+```
+User: /god
+
+Where you are: tier-1 in progress (PRD done, ARCH pending)
+
+Structural next: /god-arch
+Why: PRD is complete; architecture is the next gate
+
+Recipes that fit your current state:
+  - whats-next                Show the next logical step with reason
+  - rerun-tier                Redo a previous tier with new inputs
+
+Run /god-arch? (yes / pick recipe / cancel)
+```
+
+### Example 4: no match
+
+```
+User: /god make me a sandwich
+
+No recipe matched. Falling back to state-driven suggestion.
+
+Where you are: tier-3 launched
+Structural next: (none, arc complete)
+
+Suggested: /god-next   show all valid next-step options
+       or: /god-status   re-derive state from disk
+```
+
+## Why a skill, not an agent
+
+The matching and dispatch logic is mechanical (lookups against
+`routing/recipes/*.yaml`) and has no need for fresh-context isolation. Running
+it as a skill keeps it fast, lets the user see the proposed commands, and
+avoids stacking another orchestrator layer above `god-orchestrator`. See
+`docs/concepts.md` (the Quarterback section) for why we don't add a second
+orchestrator.
+
+## Output
+
+No new artifacts. This skill only proposes commands and (with confirmation)
+hands off to the right slash command. State is updated by the downstream
+command, not by `/god`.

package/templates/ARCH.md

@@ -0,0 +1,99 @@
+# System Architecture
+
+> Every decision below has a flip point. Every claim is substitution-tested.
+> Every NFR from PRD has a corresponding architectural choice.
+
+## System Context (C4 Level 1)
+
+```
+                    [External User]
+                          |
+                          v
+                   ┌──────────────┐
+[External API] -> │  THE SYSTEM  │ -> [External Service]
+                   └──────────────┘
+                          |
+                          v
+                   [External DB / Service]
+```
+
+[Each arrow labeled with: data flowing, protocol, frequency.]
+
+## Container Diagram (C4 Level 2)
+
+```
+[Container 1] --[API/protocol]--> [Container 2]
+     |
+     v
+[Container 3 (DB)]
+```
+
+| Container | Single Responsibility | Technology |
+|-----------|----------------------|------------|
+| [Name] | [One sentence. Single thing it owns.] | [Language/framework] |
+
+## Architecture Decision Records
+
+### ADR-001: [Decision Title]
+- **Context**: [What forced this decision]
+- **Decision**: [What was chosen]
+- **Rationale**: [Why this over alternatives]
+- **Flip point**: [Conditions under which this decision reverses]
+- **Consequences**: [What this makes easier; what it makes harder]
+
+### ADR-002: [Decision Title]
+[Same structure]
+
+## NFR-to-Architecture Map
+
+| PRD NFR | Architectural Choice | ADR Reference |
+|---------|---------------------|---------------|
+| p99 < 100ms | [Choice that delivers this] | ADR-00X |
+| 99.9% uptime | [Choice that delivers this] | ADR-00X |
+| [Other NFR] | [Choice] | ADR-00X |
+
+Every NFR from PRD MUST appear here. If an NFR has no corresponding choice,
+flag it.
+
+## Trust Boundaries
+
+```
+[External]
+    |
+=== TRUST BOUNDARY: [Auth method, data classification] ===
+    |
+[Internal]
+```
+
+For each external integration:
+- **Boundary**: [Where it sits]
+- **Auth model**: [How identity is established]
+- **Data classification**: [What flows across; sensitive or public]
+- **Failure mode**: [What happens if the boundary is breached]
+
+## Data Model
+
+### Entities
+
+| Entity | Owner Service | Consistency Model |
+|--------|--------------|-------------------|
+| User | auth-service | Strong |
+| Order | orders-service | Strong (own DB), Eventual (read replicas) |
+
+### Relationships
+- [User] 1:N [Order]
+- [Description of relationships]
+
+---
+
+## Have-Nots Checklist
+
+Before declaring done, verify:
+- [ ] Every container has a clear single responsibility
+- [ ] No two containers share responsibility without justification
+- [ ] Every NFR from PRD has an architectural mapping
+- [ ] Every ADR has a flip point
+- [ ] "Scalable" never appears without numbers
+- [ ] Every external integration has a trust boundary
+- [ ] Every data entity has an ownership assignment
+- [ ] No sentence is unlabeled

package/templates/DEPS-AUDIT.md

@@ -0,0 +1,66 @@
+# Dependency Audit
+
+> Critical CVEs first. Patch updates batched. Minor updates one-at-a-time.
+> Major updates routed to /god-upgrade.
+
+Date: [ISO 8601]
+Stack: [Node / Python / Go / Rust / Ruby / etc.]
+
+## Summary
+
+| Category | Count |
+|----------|-------|
+| Critical CVEs | [N] |
+| Stale (>18 months) | [N] |
+| Major behind (2+ versions) | [N] |
+| Minor behind | [N] |
+| Up to date | [N] |
+
+## Critical (act now)
+
+| Package | Current | Latest | CVE | Severity | Action |
+|---------|---------|--------|-----|----------|--------|
+| [pkg] | [v] | [v] | [CVE-ID] | Critical | Update to [v] |
+
+## Stale + Major Behind
+
+These are likely abandoned. Plan replacement.
+
+| Package | Current | Latest stable | Last release | Replacement candidate |
+|---------|---------|---------------|--------------|----------------------|
+| [pkg] | [v] | [v] | [date] | [pkg] |
+
+## Updates Applied This Run
+
+### Patch updates (batched)
+
+| Package | From | To | Status |
+|---------|------|----|----|
+| [pkg] | [v] | [v] | committed |
+
+Commit: [SHA] - `chore(deps): batch patch updates`
+
+### Minor updates (per-package)
+
+| Package | From | To | Status | Commit |
+|---------|------|----|----|--------|
+| [pkg] | [v] | [v] | committed | [SHA] |
+
+## Deferred to /god-upgrade
+
+Major version bumps requiring migration plans:
+
+| Package | Current | Target | Reason for deferring | Recommended workflow |
+|---------|---------|--------|---------------------|---------------------|
+| [pkg] | [v] | [v] | Breaking changes per changelog | /god-upgrade |
+
+---
+
+## Have-Nots Checklist
+
+- [ ] Critical CVEs addressed (or deferred with rationale)
+- [ ] No bulk commit (each package update is its own commit for bisect)
+- [ ] No major version bumps in this workflow (routed to /god-upgrade)
+- [ ] Tests run between updates
+- [ ] Lockfile committed alongside dep changes
+- [ ] Changelog consulted for breaking changes

package/templates/DESIGN.md

@@ -0,0 +1,71 @@
+---
+name: [Name your design system; one-word codename or product name]
+description: [One line. Visual register and feel. Brand vs product.]
+colors:
+  # Use OKLCH for wide-gamut accuracy; fall back to hex sRGB if linter requires.
+  ink: "oklch(20% 0.01 250)"
+  paper: "oklch(98% 0.005 80)"
+  accent: "oklch(60% 0.18 250)"
+  rule: "oklch(88% 0.01 250)"
+typography:
+  display:
+    fontFamily: "[Display family, Georgia, serif]"
+    fontSize: "clamp(2rem, 5vw, 3.25rem)"
+    fontWeight: 400
+    lineHeight: 1.1
+  body:
+    fontFamily: "[Body family, system-ui, sans-serif]"
+    fontSize: "1rem"
+    fontWeight: 400
+    lineHeight: 1.55
+  label:
+    fontFamily: "[Body family, system-ui, sans-serif]"
+    fontSize: "0.75rem"
+    fontWeight: 600
+    letterSpacing: "0.08em"
+rounded:
+  sm: "4px"
+  md: "8px"
+  lg: "12px"
+spacing:
+  xs: "8px"
+  sm: "16px"
+  md: "24px"
+  lg: "32px"
+  xl: "48px"
+components:
+  card:
+    backgroundColor: "{colors.paper}"
+    rounded: "{rounded.md}"
+    padding: "24px"
+---
+
+## Overview
+
+[DECISION] [One paragraph. What register is this (brand vs product)? What
+does it feel like, grounded in named references? Who is it for?]
+
+## Colors
+
+[DECISION] [Explain palette choices. Why these colors, what they signal,
+what they avoid. Reference impeccable's anti-patterns: no purple-blue
+gradients, no pure black, no gray text on colored backgrounds.]
+
+## Typography
+
+[DECISION] [Why this type pairing. What each style is used for. Tabular
+numerals for tables.]
+
+## Layout
+
+[DECISION] [Grid model, breakpoints, default spacing rhythm.]
+
+## Components
+
+[DECISION] [Name only the canonical components. Variants (hover, active,
+disabled) are systematic, not bespoke.]
+
+## Do's and Don'ts
+
+- [DECISION] Do: [specific positive pattern]
+- [DECISION] Don't: [specific anti-pattern to avoid]

package/templates/DOCS-UPDATE-LOG.md

@@ -0,0 +1,64 @@
+# Docs Update Log
+
+> Every claim in docs must be verifiable against code. Drift between docs
+> and code is a have-not.
+
+Date: [ISO 8601]
+Owner: [user]
+
+## Inventory
+
+### Docs reviewed
+- [doc path] - [last modified] - [brief description]
+- [...]
+
+### Code surface
+- Public APIs: [count]
+- CLI commands: [count]
+- Env vars: [count]
+- Slash commands (if Godpowers project): [count]
+
+## Verified Claims
+
+For each existing doc, every claim was checked against code.
+
+| Doc | Claims checked | Passed | Drift found |
+|-----|---------------|--------|-------------|
+| README.md | [N] | [N] | [N] |
+| CONTRIBUTING.md | [N] | [N] | [N] |
+
+## Drift Found
+
+| Doc | Claim | Reality | Action |
+|-----|-------|---------|--------|
+| README.md | "npm start" | package.json has "dev" | Updated README |
+| docs/api.md | Returns Promise<User> | Returns Promise<User \| null> | Updated docs |
+
+## Updated
+
+- [Doc path]: [what changed and why]
+
+## Created
+
+- [New doc path]: [why it was needed]
+
+## Verified Examples
+
+Every code example in docs was actually run.
+
+| Doc | Example | Result |
+|-----|---------|--------|
+| README.md | Quick start command | Ran successfully |
+| docs/api.md | curl example | Returned expected response |
+
+---
+
+## Have-Nots Checklist
+
+- [ ] Every claim verified against code
+- [ ] Drift documented and corrected
+- [ ] Examples actually run
+- [ ] Substitution test passed (no generic prose)
+- [ ] Three-label test passed
+- [ ] Diagrams reflect current state (not past or future)
+- [ ] Runbooks executed before commit

package/templates/HARDEN-FINDINGS.md

@@ -0,0 +1,69 @@
+# Security Findings
+
+Date: [ISO 8601 timestamp]
+Reviewer: god-harden-auditor
+Scope: [What was reviewed: code, config, dependencies, deploy pipeline]
+
+## Summary
+
+| Severity | Count |
+|----------|-------|
+| Critical | 0 |
+| High | 0 |
+| Medium | 0 |
+| Low | 0 |
+
+**Launch gate**: PASSED / BLOCKED
+
+If any Critical: BLOCKED. Launch cannot proceed until resolved or risk explicitly accepted.
+
+## OWASP Top 10 Coverage
+
+| Category | Status | Notes |
+|----------|--------|-------|
+| A01 Broken Access Control | Reviewed | [findings ref] |
+| A02 Cryptographic Failures | Reviewed | [findings ref] |
+| A03 Injection | Reviewed | [findings ref] |
+| A04 Insecure Design | Reviewed | [findings ref] |
+| A05 Security Misconfiguration | Reviewed | [findings ref] |
+| A06 Vulnerable Components | Reviewed | [findings ref] |
+| A07 Authentication Failures | Reviewed | [findings ref] |
+| A08 Data Integrity Failures | Reviewed | [findings ref] |
+| A09 Logging Failures | Reviewed | [findings ref] |
+| A10 SSRF | Reviewed | [findings ref] |
+
+No category may be marked "N/A" without explicit justification.
+
+## Findings
+
+### [CRITICAL-001] [Short title]
+- **Category**: OWASP A01 Broken Access Control
+- **Location**: [file:line]
+- **Description**: [What the vulnerability is]
+- **Impact**: [What happens if exploited]
+- **Reproduction**: [Step-by-step]
+- **Remediation Options**:
+  - **Option A**: [Approach] -- Estimated: [time]
+  - **Option B**: [Approach] -- Estimated: [time]
+- **Status**: Open / Fixed / Accepted-Risk
+
+### [HIGH-001] [Short title]
+[Same structure]
+
+### [MEDIUM-001] [Short title]
+[Same structure]
+
+### [LOW-001] [Short title]
+[Same structure]
+
+---
+
+## Have-Nots Checklist
+
+- [ ] Manual review performed (not just scanner output)
+- [ ] Auth boundaries actively tested (not just code-read)
+- [ ] Input validation audited
+- [ ] Rate limiting verified on auth endpoints
+- [ ] All OWASP categories reviewed (no skips without justification)
+- [ ] Every finding has a severity classification
+- [ ] Every Critical finding has remediation options

package/templates/MIGRATION.md

@@ -0,0 +1,86 @@
+# Migration: [From X to Y]
+
+> Expand-contract pattern. Incremental slices. Metric-gated progression.
+> No big-bang.
+
+Date started: [ISO 8601]
+Owner: [user]
+Status: planning | expanding | migrating | contracting | complete
+
+## Motivation
+
+[Why this migration. Specific business reason, not "newer is better".]
+
+## Surface
+
+- Files affected: [count, with link to list]
+- Modules: [list]
+- Services: [list]
+- External APIs touched: [list]
+
+## Test Coverage Today
+
+- Affected surface coverage: [%]
+- Coverage gaps: [list]
+- Plan to fill gaps before migration: [yes/no, by when]
+
+## Breaking Changes (from upstream changelog)
+
+| Change | Risk | Likelihood | Mitigation |
+|--------|------|-----------|------------|
+| [breaking change] | High/Med/Low | High/Med/Low | [specific plan] |
+
+## Plan
+
+### Phase 1: Expand
+- [ ] Introduce new version alongside old
+- [ ] Add abstraction layer (branch-by-abstraction or feature flag)
+- [ ] Verify both code paths work
+- [ ] Tests cover both paths
+
+### Phase 2: Migrate (slices)
+
+| Slice | Scope | Status | Deployed | Metrics window | Result |
+|-------|-------|--------|----------|----------------|--------|
+| 1 | [scope] | pending | -- | -- | -- |
+| 2 | [scope] | pending | -- | -- | -- |
+
+Each slice:
+- Atomic commit
+- Feature-flagged rollout: 1% -> 10% -> 50% -> 100%
+- Metric monitoring window (default 24h) before next slice
+- Rollback per slice if regression
+
+### Phase 3: Contract
+- [ ] Verify 100% of usage on new path
+- [ ] Monitoring window passed (N days, default 7)
+- [ ] Remove old code path
+- [ ] Final commit: `chore(migration): remove old <thing>`
+
+## Rollback Strategy
+
+| Scenario | Action |
+|----------|--------|
+| Slice N regresses | Revert that slice's deploy, investigate |
+| Multiple slices regress | Pause migration, full audit |
+| Critical regression | Roll back all slices, restart with revised plan |
+
+## Metrics to Watch
+
+| Metric | Baseline | Threshold for rollback |
+|--------|----------|----------------------|
+| Error rate | [%] | [+0.5%] |
+| p99 latency | [ms] | [+10%] |
+| [Other] | | |
+
+---
+
+## Have-Nots Checklist
+
+- [ ] Plan is incremental (no big-bang)
+- [ ] Expand-contract pattern in use
+- [ ] Tests added before migration started
+- [ ] Each slice has independent rollback
+- [ ] Metrics gate slice progression
+- [ ] Old code removed only after 100% migrated
+- [ ] Risk assessment complete