godpowers 0.15.0

package/references/shipping/HARDEN-OWASP-WORKSHEETS.md

@@ -0,0 +1,89 @@
+# OWASP Top 10 Manual Walkthrough
+
+> Worksheets for each of the OWASP Top 10. Use during /god-harden.
+
+## A01: Broken Access Control
+
+For each protected endpoint:
+- [ ] What permission is required?
+- [ ] Is the permission check present and correct?
+- [ ] Test: unauthenticated user hitting endpoint -> 401
+- [ ] Test: authenticated user without permission -> 403
+- [ ] Test: authenticated user WITH permission -> 200
+
+```
+Endpoint: GET /api/users/:id
+Required: authenticated AND (user_id == :id OR role == admin)
+Implementation: src/api/users.ts:45 (permission check is line 47)
+Tested: yes (test_users_self_access, test_users_other_403, test_users_admin_other_200)
+```
+
+## A02: Cryptographic Failures
+
+- [ ] All ePHI / PII / financial data encrypted at rest? (DB-level, not just app-level)
+- [ ] All transmissions over TLS 1.2+? (verify with `nmap --script ssl-enum-ciphers`)
+- [ ] No hardcoded secrets? (run `grep -ri "sk_live\|api_key\|secret" src/`)
+- [ ] No weak algorithms? (no MD5, no SHA1 for security; AES-256 minimum for symmetric; RSA-2048 minimum for asymmetric)
+- [ ] Random number generation cryptographically secure? (crypto.randomBytes, not Math.random)
+
+## A03: Injection
+
+For each input source (user form, URL param, header, file upload, third-party webhook):
+- [ ] SQL: parameterized queries only? (no string concat)
+- [ ] XSS: output encoded? CSP headers in place?
+- [ ] Command injection: never pass user input to shell commands?
+- [ ] Template injection: safe template engines? No `eval()` of user data?
+- [ ] LDAP/XML/NoSQL injection: parameterized?
+
+```
+Input: req.body.email (signup endpoint)
+Validation: src/auth/signup.ts:23 (zod schema)
+Used in: SQL via Prisma (parameterized) - safe
+```
+
+## A04: Insecure Design
+
+- [ ] Rate limiting on auth endpoints?
+- [ ] Bulk operation safeguards (e.g., delete-all has confirmation)?
+- [ ] Race condition risks? (TOCTOU on account balance, e.g.)
+- [ ] Business logic flaws? (negative quantities, sign-up bypass, etc.)
+
+## A05: Security Misconfiguration
+
+- [ ] Default credentials removed?
+- [ ] Verbose error messages disabled in production?
+- [ ] Security headers present? (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
+- [ ] Unnecessary features disabled? (debug endpoints, sample data)
+- [ ] Cloud bucket permissions? (no public-by-default S3)
+
+## A06: Vulnerable Components
+
+- [ ] `npm audit` (or equivalent) clean for high+critical?
+- [ ] Dependencies updated within last 12 months?
+- [ ] Pinned versions or version ranges?
+
+## A07: Authentication Failures
+
+- [ ] Strong password policy?
+- [ ] MFA available for sensitive accounts?
+- [ ] Session fixation prevented? (rotate session ID on login)
+- [ ] Credential stuffing protection? (rate limit, account lockout, captcha)
+- [ ] Forgot-password flow secure? (token expiry, single-use)
+
+## A08: Data Integrity Failures
+
+- [ ] Updates signed/verified? (e.g., software updates from upstream)
+- [ ] No unsafe deserialization? (no `pickle.loads(user_input)` or equivalent)
+- [ ] Critical data has integrity checks? (HMAC, signature)
+
+## A09: Logging Failures
+
+- [ ] Security events logged? (auth, authz failures, admin actions)
+- [ ] No sensitive data in logs? (no passwords, no full tokens, no PII unless required and redacted)
+- [ ] Alerts on suspicious activity? (e.g., 100 failed logins in 5 min)
+
+## A10: SSRF
+
+- [ ] User-supplied URLs validated? (no localhost, no internal IPs)
+- [ ] Internal services not reachable from user-facing endpoints?
+- [ ] Cloud metadata endpoints blocked? (169.254.169.254 in AWS, etc.)

package/references/shipping/LAUNCH-ANTIPATTERNS.md

@@ -0,0 +1,68 @@
+# LAUNCH Antipatterns
+
+## 1. The Quiet Launch
+
+**Sample**: Code is deployed; nobody told anyone. Team waits to see if
+users notice.
+
+**Why it fails**: Users don't notice good things. They notice broken ones.
+Quiet launches give you adoption signals only when something is wrong.
+
+**Fix**: Launch with intent. At minimum: announcement to existing users,
+opening of signup for new users, and clear telemetry to verify the
+expected adoption pattern.
+
+## 2. The HARDEN-Skipped Launch
+
+**Sample**: Time pressure; HARDEN gate skipped "to ship Friday."
+
+**Why it fails**: Friday-launched, weekend-on-fire. The skipped harden
+review missed an authentication bug; production is breached over the
+weekend.
+
+**Fix**: HARDEN is a gate, not a stage. The launch agent (god-launch-
+strategist) refuses to advance if HARDEN/FINDINGS.md has open CRITICAL
+or HIGH items. Even under --yolo. CRITICAL findings are not waivable.
+
+## 3. The Launch Without Rollback
+
+**Sample**: Launch plan describes how to ship; says nothing about how to
+unship.
+
+**Why it fails**: When the new release reveals a problem, the team has
+no defined path backwards. Recovery improvises.
+
+**Fix**: Rollback is part of the launch checklist. Trigger conditions
+are explicit ("if error rate exceeds 5x baseline for 10 minutes,
+rollback"). The rollback path is tested as part of launch prep.
+
+## 4. The Launch Without Success Criteria
+
+**Sample**: Launched; no measurable definition of "the launch worked."
+
+**Why it fails**: Was the launch a success? The team can't tell.
+Subsequent decisions ("ship a similar feature?") are made on vibe.
+
+**Fix**: Each launch defines its success criteria up front, drawn from
+the PRD success metrics. "M-5 launch is successful when 50 active
+accounts within 60 days." The criteria are tracked in LAUNCH/STATE.md.
+
+## 5. The Quiet Failure
+
+**Sample**: A subset of users hits the bug; they don't report it because
+it's intermittent. The team doesn't know.
+
+**Fix**: Active error tracking from minute one. Sentry or equivalent
+reports unhandled errors with user context. Launch readiness includes
+"error tracking captures failures from real users in staging within
+30 seconds of the failure occurring."
+
+## 6. The Launched-and-Forgotten Feature
+
+**Sample**: M-3 shipped 6 weeks ago. No follow-up tracking. Nobody knows
+adoption.
+
+**Fix**: Launch creates a measurement timeline. T+7d, T+30d, T+60d
+checkpoints with the success metric tracked. Below threshold triggers a
+god-postmortem (was the feature wrong, the messaging wrong, or the
+metric wrong?).

package/references/shipping/OBSERVE-ANTIPATTERNS.md

@@ -0,0 +1,62 @@
+# OBSERVE Antipatterns
+
+## 1. The Vanity Dashboard
+
+**Sample**: Beautiful dashboards showing aggregate request counts. Nothing
+shows error budget burn or per-feature latency.
+
+**Why it fails**: When something breaks, vanity dashboards don't tell you
+what or why.
+
+**Fix**: Dashboards anchored to SLOs, not to metric availability. Every
+dashboard panel maps to a question the on-call needs to answer.
+
+## 2. The Alert That Fires Forever
+
+**Sample**: "High error rate" alert fires hourly; team has muted it.
+
+**Why it fails**: An always-firing alert is no alert. The team learns
+to ignore the channel; real fires get missed.
+
+**Fix**: Alerts have actionable thresholds and a runbook. If an alert
+fires more than weekly without action, it's tuned or removed. Alert
+fatigue is a measurable failure.
+
+## 3. The Logs Without Correlation
+
+**Sample**: Logs scattered across services with no trace ID.
+
+**Why it fails**: A user-reported bug touches 5 services. Without
+correlation, the on-call greps by timestamp and prays.
+
+**Fix**: Trace IDs propagate end-to-end. Every log line includes the
+trace ID. OpenTelemetry standard or equivalent.
+
+## 4. The Missing Error Budget
+
+**Sample**: SLO defined as "99.9% uptime." When breached, no policy.
+
+**Why it fails**: SLOs without error budget policies are theater. The
+team has no defined response when reliability slips.
+
+**Fix**: Each SLO has a written error budget policy: "When 50% of monthly
+budget is consumed, halt feature work; when 100% consumed, freeze
+non-fix deploys." Codified in OBSERVE/STATE.md.
+
+## 5. The Untested Alert
+
+**Sample**: Alerts configured; nobody has ever simulated the underlying
+condition to verify the alert actually fires.
+
+**Fix**: Each alert has a documented test (e.g., "kill one pod and
+confirm HighErrorRate fires within 5 minutes"). Run quarterly.
+
+## 6. The PII in Logs
+
+**Sample**: User logging includes email, phone, billing address.
+
+**Why it fails**: Logs are usually the least-protected data store. PII
+in logs is a privacy incident waiting to happen.
+
+**Fix**: Structured logging with explicit redaction. Schemas mark fields
+as "redacted at source." Linting catches violations.

package/references/shipping/OBSERVE-SLO-EXAMPLES.md

@@ -0,0 +1,107 @@
+# SLO Examples
+
+## SLO Definition
+
+A Service Level Objective ties to a PRD success metric.
+
+```
+PRD says: "99.9% uptime over 30 days"
+SLO is:   Availability of /api/* endpoints > 99.9% over rolling 30 days
+Indicator: 1 - (5xx responses / total responses)
+Error budget: 0.1% = 43 minutes/month
+```
+
+## SLO + Error Budget Policy
+
+The SLO without a policy is paper.
+
+```
+Error budget policy for /api/* availability:
+  - Budget remaining > 50%: continue feature work
+  - Budget remaining 25-50%: prioritize reliability work next sprint
+  - Budget remaining 5-25%: freeze non-critical features; reliability only
+  - Budget exhausted: halt deploys to /api/*; engage reliability rotation
+```
+
+The policy is what makes the SLO operational.
+
+## Symptom-based Alerting
+
+Alert on user-facing pain, not internal state.
+
+```
+GOOD: Alert when error rate on /api/* > 1% sustained for 5 minutes
+GOOD: Alert when p99 latency > 2s sustained for 10 minutes
+GOOD: Alert when checkout success rate drops 20% from rolling baseline
+
+BAD: Alert when CPU > 80%
+BAD: Alert when memory > 75%
+BAD: Alert when disk > 85%
+```
+
+CPU/memory/disk alerts are good for capacity planning, not for "wake
+someone up at 3am". Wake people for symptoms.
+
+## Runbooks
+
+Each alert has a runbook. The runbook has been DRY-RUN.
+
+```
+# Runbook: Error rate on /api/* > 1%
+
+Trigger: Error rate alert fires (sustained 5 min)
+
+Diagnostic steps:
+1. Check Datadog dashboard "API Health" - which endpoint is failing?
+2. Check recent deploys (last 30 min): is there a likely culprit?
+3. Check Stripe API status: are we depending on a degraded upstream?
+4. Check database connection pool: are we exhausted?
+
+Mitigation:
+- If recent deploy: rollback (see DEPLOY-PATTERNS.md)
+- If upstream issue: enable degraded mode (return cached data)
+- If DB connection: scale connection pool, restart bad pods
+- If unknown: page the on-call engineer
+
+Escalation: if not mitigated in 30 minutes, page CTO.
+
+Last dry-run: 2026-04-20 (in staging, simulated 5xx)
+```
+
+## Structured Logging
+
+```json
+{
+  "ts": "2026-05-09T14:23:45.123Z",
+  "level": "info",
+  "request_id": "req_abc123",
+  "user_id": "user_xyz789",
+  "endpoint": "/api/mrr",
+  "duration_ms": 145,
+  "status": 200
+}
+```
+
+NOT:
+```
+2026-05-09 14:23:45 INFO Request to /api/mrr from user xyz789 took 145ms (200 OK)
+```
+
+Structured logs are queryable. Free-text isn't.
+
+## Anti-patterns
+
+### Vanity Dashboard
+Charts with metrics that look impressive but tie to no SLO and no action.
+
+**Fix**: every chart answers a question that ties to an action. Delete the rest.
+
+### Alert without runbook
+"Production down!" -- now what?
+
+**Fix**: every alert payload includes the runbook URL.
+
+### Untested runbook
+Written once during a quiet afternoon. Never verified.
+
+**Fix**: dry-run quarterly in staging. Update based on what's actually true.

package/references/shipping/README.md

@@ -0,0 +1,18 @@
+# Shipping References
+
+Per-tier reference content for Tier 3 (Deploy, Observe, Launch, Harden).
+
+## Files
+
+- (placeholder)
+
+## Planned content
+
+- Same-artifact promotion patterns and anti-patterns
+- SLO worked examples with error budget policies
+- Symptom-vs-cause alerting catalog
+- OWASP Top 10 manual review worksheets
+- Launch copy substitution-test calibration set
+- D-7 to D+7 runbook templates
+
+See [HAVE-NOTS.md](../HAVE-NOTS.md) for the canonical failure-mode catalog.

package/routing/god-add-backlog.yaml

@@ -0,0 +1,24 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-add-backlog
+  description: Add idea to backlog (less urgent than todo)
+  tier: 0
+
+prerequisites:
+  required: []
+
+execution:
+  spawns: [built-in]
+  context: fresh
+  writes: []
+
+success-path:
+  next-recommended: /god-next
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-0 updated for /god-add-backlog
+  events: [agent.start, agent.end]

package/routing/god-add-tests.yaml

@@ -0,0 +1,27 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-add-tests
+  description: Add tests to legacy code
+  tier: 0
+
+prerequisites:
+  required:
+    - check: state:tier-2.repo.status == done
+
+execution:
+  spawns: [god-executor]
+  context: fresh
+  writes:
+    []
+
+
+success-path:
+  next-recommended: /god-refactor
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-0 updated for /god-add-tests
+  events: [agent.start, artifact.created, agent.end]

package/routing/god-add-todo.yaml

@@ -0,0 +1,24 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-add-todo
+  description: Capture a todo from current context
+  tier: 0
+
+prerequisites:
+  required: []
+
+execution:
+  spawns: [built-in]
+  context: fresh
+  writes: []
+
+success-path:
+  next-recommended: /god-next
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-0 updated for /god-add-todo
+  events: [agent.start, agent.end]

package/routing/god-agent-audit.yaml

@@ -0,0 +1,24 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-agent-audit
+  description: Validate agents/*.md against agent contract
+  tier: 0
+
+prerequisites:
+  required: []
+
+execution:
+  spawns: [built-in]
+  context: fresh
+  writes: []
+
+success-path:
+  next-recommended: varies
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-0 updated for /god-agent-audit
+  events: [agent.start, agent.end]

package/routing/god-arch.yaml

@@ -0,0 +1,46 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-arch
+  description: Design system architecture
+  tier: 1
+
+prerequisites:
+  required:
+    - check: state:tier-1.prd.status == done
+      auto-complete: /god-prd
+      human-required: true
+    - check: have-nots-pass:prd
+      auto-complete: /god-prd
+      human-required: true
+
+execution:
+  spawns: [god-architect]
+  context: fresh
+  reads:
+    - .godpowers/prd/PRD.md
+    - templates/ARCH.md
+  writes:
+    - .godpowers/arch/ARCH.md
+    - .godpowers/arch/adr/
+
+standards:
+  substitution-test: true
+  three-label-test: true
+  have-nots: [A-01, A-02, A-03, A-04, A-05, A-06, A-07, A-08, A-09, A-10, A-11, A-12]
+  gate-on-failure: pause-for-user
+
+success-path:
+  next-recommended: /god-roadmap
+  alternatives:
+    - command: /god-stack
+      when: stack-not-yet-decided
+
+failure-path:
+  on-have-nots-fail: /god-arch
+  on-pause: relay-to-user-with-options
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-1.arch.status = done
+  events: [agent.start, artifact.created, have-nots.check, agent.end]

package/routing/god-archaeology.yaml

@@ -0,0 +1,28 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-archaeology
+  description: Deep brownfield code archaeology
+  tier: 0
+
+prerequisites:
+  required: []
+
+execution:
+  spawns: [god-archaeologist]
+  context: fresh
+  writes:
+    - .godpowers/archaeology/REPORT.md
+
+success-path:
+  next-recommended: /god-reconstruct
+  alternatives:
+    - command: /god-tech-debt
+      when: archaeology-surfaced-debt-concerns
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: archaeology completed
+  events: [agent.start, artifact.created, agent.end]

package/routing/god-audit.yaml

@@ -0,0 +1,32 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-audit
+  description: Score artifacts against have-nots
+  tier: 0
+
+prerequisites:
+  required:
+    - check: file:.godpowers/PROGRESS.md
+      auto-complete: /god-init
+      human-required: true
+
+execution:
+  spawns: [god-auditor]
+  context: fresh
+  writes:
+    - .godpowers/AUDIT-REPORT.md
+
+
+success-path:
+  next-recommended: /god-status
+  alternatives:
+    - command: /god-redo
+      when: failures-found
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-0 updated for /god-audit
+  events: [agent.start, artifact.created, agent.end]

package/routing/god-budget.yaml

@@ -0,0 +1,24 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-budget
+  description: 
+  tier: 0
+
+prerequisites:
+  required: []
+
+execution:
+  spawns: [built-in]
+  context: fresh
+  writes: []
+
+success-path:
+  next-recommended: varies
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: none
+  events: [agent.start, agent.end]

package/routing/god-build-agent.yaml

@@ -0,0 +1,24 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-build-agent
+  description: Generate custom specialist agent
+  tier: 0
+
+prerequisites:
+  required: []
+
+execution:
+  spawns: [built-in]
+  context: fresh
+  writes: []
+
+success-path:
+  next-recommended: /god-next
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-0 updated for /god-build-agent
+  events: [agent.start, agent.end]

package/routing/god-build.yaml

@@ -0,0 +1,46 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-build
+  description: Build slices with TDD enforcement and two-stage review
+  tier: 2
+
+prerequisites:
+  required:
+    - check: state:tier-1.roadmap.status == done
+      auto-complete: /god-roadmap
+      human-required: true
+    - check: state:tier-2.repo.status == done
+      auto-complete: /god-roadmap
+      human-required: true
+
+execution:
+  spawns: [god-planner]
+  context: fresh
+  secondary-spawns: [god-executor, god-spec-reviewer, god-quality-reviewer]
+  writes:
+    - .godpowers/build/PLAN.md
+    - .godpowers/build/STATE.md
+    - source code
+
+standards:
+  substitution-test: true
+  three-label-test: true
+  have-nots: [B-01, B-02, B-03, B-04, B-05, B-06, B-07, B-08, B-09, B-10, B-11, B-12]
+  gate-on-failure: pause-for-user
+
+success-path:
+  next-recommended: /god-deploy
+  alternatives:
+    - command: /god-harden
+      when: parallel-with-deploy
+
+  post-success-actions:
+    - run: /god-scan
+      reason: refresh linkage map; surface drift to REVIEW-REQUIRED.md
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: tier-2 updated for /god-build
+  events: [agent.start, artifact.created, agent.end, linkage.snapshot, drift.detected, review-required.populated]

package/routing/god-cache-clear.yaml

@@ -0,0 +1,24 @@
+apiVersion: godpowers/v1
+kind: CommandRouting
+metadata:
+  command: /god-cache-clear
+  description: 
+  tier: 0
+
+prerequisites:
+  required: []
+
+execution:
+  spawns: [built-in]
+  context: fresh
+  writes: []
+
+success-path:
+  next-recommended: varies
+
+failure-path:
+  on-error: /god-doctor
+
+endoff:
+  state-update: none
+  events: [agent.start, agent.end]