godpowers 0.15.0

package/references/planning/ROADMAP-ANTIPATTERNS.md

@@ -0,0 +1,94 @@
+# ROADMAP Antipatterns
+
+> Common ways roadmaps fail. Each has a sample, why it fails, and the fix.
+
+## 1. The Date-Hopeful Roadmap
+
+**Sample**: "M-1: Auth — early Q3"
+
+**Why it fails**: "Early Q3" is not a gate, not a date, not a measurable
+state. The team treats it as soft, slippage compounds, and by mid-Q3 the
+milestone is "in progress" with no ship date.
+
+**Fix**: Replace dates with gates. "M-1 ships when integration tests pass
+on the staging environment with two beta accounts active for 7 consecutive
+days." The gate is the milestone, not the date.
+
+## 2. The Featurelist Roadmap
+
+**Sample**:
+- M-1: Auth, profile pages, settings, password reset
+- M-2: Dashboard, charts, exports, sharing
+
+**Why it fails**: Each milestone bundles unrelated features. There is no
+shippable subset; users get nothing until the whole bag arrives. Slippage
+on one item delays everything.
+
+**Fix**: Each milestone must produce a thin vertical slice that delivers
+real user value. M-1 = "user can sign up and see one chart." M-2 = "user
+can share that chart." Each milestone ships independently.
+
+## 3. The Phantom Gate
+
+**Sample**: "M-2 gate: integration tests pass."
+
+**Why it fails**: "Integration tests pass" is mechanical but vague. Which
+tests? Against what data? In what environment? Writing the gate this way
+makes it un-falsifiable.
+
+**Fix**: Specify the gate concretely. "M-2 gate: the regression suite of
+50 real CI logs identifies the right line in 95% of cases, run against
+the M-2 build on the production CI runner."
+
+## 4. The Reordering Trap
+
+**Sample**: M-1 marked "done" but the gate criterion was relaxed mid-sprint.
+
+**Why it fails**: A milestone that closed without meeting its original
+gate is technical debt disguised as progress. The team moves on; the
+unmet gate becomes invisible.
+
+**Fix**: Treat gate changes as milestone changes. If the gate must move,
+the milestone gets a new ID (M-1.1) and the old one is documented as
+"closed with relaxed gate, see ADR-XXX." The original gate is preserved
+for honesty.
+
+## 5. The Phase-as-Milestone
+
+**Sample**:
+- M-1: Planning (4 weeks)
+- M-2: Building (8 weeks)
+- M-3: Shipping (2 weeks)
+
+**Why it fails**: This is a Gantt chart, not a roadmap. Phases group
+activities, not outcomes. Tracking against phases tells you how much
+time elapsed, not what shipped.
+
+**Fix**: Milestones are user-facing outcomes. "M-1: First account synced
+end-to-end." "M-2: Dashboard reads cache, p99 under 800ms." Time
+spent is incidental.
+
+## 6. The Roadmap Without Reverse Direction
+
+**Sample**: Each milestone lists what to build but never what to remove,
+deprecate, or migrate.
+
+**Why it fails**: Software accretes; only deletes shrink it. A roadmap
+that only adds eventually becomes the source of complexity.
+
+**Fix**: At least one milestone per quarter has a "remove" item. M-N:
+"Remove the legacy v1 export path; users on v1 emails since Jan are
+migrated to v2." Roadmap = what we ship + what we sunset.
+
+## 7. The Empty Changelog
+
+**Sample**: ROADMAP.md exists; the Changelog table at the bottom is
+empty or has a single entry from project start.
+
+**Why it fails**: Roadmaps drift. Milestones get added, removed, reordered.
+No log = no honesty about why. New team members read the current roadmap
+as if it were the original plan.
+
+**Fix**: Every roadmap edit appends a changelog row with date, change,
+reason. `2026-06-15 | Moved M-3 ahead of M-2 | Beta users blocked on
+digest delivery, dashboard can wait`.

package/references/planning/STACK-ANATOMY.md

@@ -0,0 +1,60 @@
+# Stack Decision Anatomy
+
+## Per-category structure
+
+For each technology category:
+
+```
+### [Category]: [Chosen Technology]
+
+**Candidates**: A, B, C
+**Scores**: A 9.2 / B 7.8 / C 6.5
+**Why this one**: [specific to ARCH NFRs]
+**Flip point**: [condition under which we reverse]
+**Lock-in cost**: Low / Medium / High
+**What switching requires**: [concrete description]
+```
+
+## Worked example
+
+### Language: TypeScript
+
+**Candidates**: TypeScript, Python, Go
+**Scores**: TS 9.2 / Python 7.8 / Go 7.1
+
+**Why TypeScript**:
+- Frontend is React (TS already in stack)
+- Team has TS experience
+- Type safety reduces post-deploy bug rate per PRD NFR (95% reduction in
+  runtime type errors vs JavaScript baseline; team's last project)
+
+**Flip point**: If we add a service that needs sub-millisecond p99 latency
+or hot-path performance (e.g., a real-time analytics engine), evaluate Go
+or Rust for that service specifically. Don't migrate the whole stack.
+
+**Lock-in cost**: Medium
+- Switching the API to Python would require rewriting the data access layer
+  and validation library. Estimated 4-6 weeks for a single engineer.
+- Lower if we keep an abstraction layer between web framework and business logic.
+
+## Pairing checks
+
+Verify chosen technologies work together:
+
+- TypeScript + Express + Prisma: yes (Prisma has first-class TS support)
+- Postgres + Prisma: yes (Prisma supports Postgres natively)
+- BullMQ + Redis: yes (BullMQ requires Redis; we have it)
+
+Flag mismatches:
+- ChosenORM doesn't support ChosenDB: blocker
+- Library X requires Node 16, but we chose Node 20: minor (verify upgrade path)
+
+## High lock-in watch list
+
+Choices marked "High" lock-in with flip points <6 months away:
+
+| Choice | Lock-in | Likely flip | Mitigation |
+|--------|---------|-------------|------------|
+| Vercel for hosting | High | If we hit Vercel's scale tier limits | Maintain Dockerfile so we can leave |
+
+If a high-lock-in choice has no mitigation, that's a have-not (S-04).

package/references/planning/STACK-ANTIPATTERNS.md

@@ -0,0 +1,95 @@
+# STACK Antipatterns
+
+> Common ways stack decisions fail. Each has a sample, why it fails, and the fix.
+
+## 1. The Resume-Driven Choice
+
+**Sample**: "Selected Rust because it's a great learning opportunity."
+
+**Why it fails**: The PRD does not require Rust's strengths (extreme
+performance, no GC). The team takes 3x longer building features than they
+would in TypeScript. The choice serves the resume, not the user.
+
+**Fix**: Map each choice to a PRD requirement. "Rust because PRD NFR
+requires processing 10MB logs in under 500ms with zero allocations in
+hot path; benchmarks show TypeScript is 4x slower at this." If the PRD
+doesn't pull, the stack doesn't push.
+
+## 2. The Lock-In Without Acknowledgment
+
+**Sample**: "Selected Vercel for hosting" with no flip point and no
+estimated migration cost.
+
+**Why it fails**: Single-vendor lock-in is sometimes the right choice,
+but it must be acknowledged. Without a documented flip point, the team
+can't tell when the choice has become a liability.
+
+**Fix**: Every high-lock-in choice has a flip point and a migration cost
+estimate. "Vercel; flip point when sync-worker exceeds 300s function
+timeout; migration to Fly.io estimated at 2 weeks (cron + KV
+re-platforming)."
+
+## 3. The Pairing Mismatch
+
+**Sample**: "Selected Next.js + AWS Lambda + DynamoDB."
+
+**Why it fails**: Next.js is built around Vercel's runtime. Lambda has
+cold-start issues for Next.js's SSR model. DynamoDB requires a different
+data access pattern than the Next.js server-component idiom assumes. The
+pairing fights itself.
+
+**Fix**: Verify pairing compatibility pairwise. Document any
+incompatibilities found. If a pair fights, either change the pair or
+explicitly accept the friction with a Mitigations section.
+
+## 4. The Buzzword Stack
+
+**Sample**: A small SaaS app stack listing Kubernetes, Kafka, Cassandra,
+Redis, Elasticsearch, and Spark.
+
+**Why it fails**: Each tool is a category leader for its problem, but
+the project doesn't have those problems yet. Operating six distributed
+systems for 200 users is a full-time job; the actual product never ships.
+
+**Fix**: Match operational complexity to current scale. A SaaS at $5k
+MRR runs on Postgres + a single Node process. Add Kafka the day you
+need event streaming you can't get from Postgres LISTEN/NOTIFY.
+
+## 5. The Untyped Selection
+
+**Sample**: "TBD on database; will decide during build."
+
+**Why it fails**: Stack decisions made under build-time pressure are
+worse than stack decisions made up front. The team picks whatever is
+fastest in the moment; that choice locks in operational debt.
+
+**Fix**: STACK.md has zero "TBD" entries before /god-build starts. If
+genuinely unresolved, the entry says "/god-spike scheduled to evaluate
+options X, Y, Z by date" and is gated as Tier 1 incomplete until the
+spike resolves.
+
+## 6. The "We'll Just Use" Trap
+
+**Sample**: Casual sentence in PRD: "We'll just use Postgres."
+
+**Why it fails**: That casual line skipped STACK entirely. No flip point,
+no rationale, no pairing check. The choice is now load-bearing for
+several other decisions and nobody owns it.
+
+**Fix**: Promote every stack decision to STACK.md. If a PRD or ARCH
+sentence implies a stack choice, that choice gets its own row in
+STACK.md with rationale and flip point, even if the decision feels
+obvious.
+
+## 7. The Migration That Wasn't
+
+**Sample**: STACK.md says "we use library X 2.x" but package.json shows 1.4.
+
+**Why it fails**: Stack drift between the document and the code is
+invisible until something breaks. The doc has aspirational truth; the
+code has actual truth. Reverse-sync (Phase 6) catches this.
+
+**Fix**: STACK.md entries get reverse-sync'd from `package.json` /
+`go.mod` / `Cargo.toml` etc. The sync runs on /god-sync and updates
+"Used in: X files; current version: 1.4" footers. Drift between stated
+and actual is flagged in REVIEW-REQUIRED.md.

package/references/shared/GLOSSARY.md

@@ -0,0 +1,80 @@
+# Godpowers Glossary
+
+> Canonical vocabulary. Every doc, agent prompt, error message, and command
+> must use these consistently.
+
+## Core abstractions
+
+**Tier**: a phase of the dev arc (0: Orchestration, 1: Planning, 2: Building, 3: Shipping).
+
+**Sub-step**: a bounded unit within a tier (PRD, ARCH, Roadmap, Stack, Repo, Build, Deploy, Observe, Launch, Harden).
+
+**Artifact**: a file on disk produced by a sub-step. Has a contract.
+
+**Skill**: a slash command. Thin handle that spawns agents.
+
+**Agent**: a specialist that turns sub-step inputs into the artifact. Fresh context per spawn.
+
+**Gate**: a passing upstream artifact required for a downstream sub-step.
+
+**Have-not**: a named, grep-testable failure mode. 200 in the catalog.
+
+**Mode**: a run flavor (greenfield A, gap-fill B, audit C, multi-repo D-future).
+
+**Scale**: project size (trivial, small, medium, large, enterprise). Drives which tiers and personas activate.
+
+## Quality concepts
+
+**Substitution test**: replace product name with competitor's; if sentence still reads true, it decides nothing. Rewrite.
+
+**Three-label test**: every sentence is exactly DECISION, HYPOTHESIS, or OPEN QUESTION. Anything unlabeled is theater.
+
+**Theater**: sentences that read fine but say nothing measurable, decidable, or testable.
+
+**AI-slop**: output that passes substitution test. Reads generic.
+
+**Paper artifact**: document exists but mechanism does not (e.g., "runbook" never executed, "SLO" with no error budget policy).
+
+**Phantom resume**: agent claims tier is done but artifact is missing from disk.
+
+**Ghost handoff**: tier invoked before its upstream artifact exists.
+
+**Drift**: gap between what state.json claims and what disk actually contains.
+
+## Workflow concepts
+
+**Pause**: a genuine human-in-the-loop checkpoint. Five legitimate categories (ambiguous intent, human-only flip-point, statistical tie, Critical security finding, brand voice).
+
+**YOLO**: auto-resolve all pauses except security Criticals. Logs to YOLO-DECISIONS.md.
+
+**Workstream**: an isolated parallel branch with its own state.
+
+**Vertical slice**: one user-visible behavior end-to-end. Not "set up the database".
+
+**Wave**: a set of slices that can run in parallel within a build phase.
+
+**Reflog**: append-only log of state-changing operations. Enables /god-undo.
+
+**Trash**: recoverable deletion to `.godpowers/.trash/`.
+
+## Agent concepts
+
+**Fresh context**: each spawned agent gets a new context window. Defeats context rot.
+
+**TDD enforcement**: tests written before implementation. Code-before-test triggers rewrite.
+
+**Two-stage review**: god-spec-reviewer (compliance) then god-quality-reviewer (craft). Both must pass for commit.
+
+**Atomic commit**: one slice = one commit. Never multiple slices in one commit.
+
+**Critical-finding gate**: launch is blocked if god-harden-auditor finds Critical. Even --yolo.
+
+## Extension concepts
+
+**Extension**: a skill pack from npm. Adds new agents, skills, workflows, have-nots.
+
+**Lazy activation**: extension files don't load until a slash command from that extension is invoked.
+
+**Capability handshake**: extension declares `engines.godpowers: "^X.Y.0"` and install fails on mismatch.
+
+**Skill pack**: another name for an extension. Same thing.

package/references/shared/ORCHESTRATORS.md

@@ -0,0 +1,76 @@
+# Composing with Other AI Coding Workflow Systems
+
+> Godpowers is one of several skill-based AI dev tools. Here's how it
+> composes with others, what's safe to combine, and how to resolve
+> conflicts.
+
+Godpowers does not assume it's the only AI workflow system installed.
+Many users layer multiple tools (planning frameworks, discipline harnesses,
+codebase mappers, story trackers). The rules below let them coexist.
+
+## Coexistence principles
+
+1. **One state directory per project.** Godpowers owns `.godpowers/`.
+   Other systems own their own directories (e.g. `.planning/`,
+   `.<vendor>/`). Don't point two systems at the same directory.
+
+2. **Skills can coexist in `~/.claude/skills/`** (or the equivalent for
+   other AI tools). The AI tool routes by description match. Multiple
+   `/god-*` skills and any other namespace coexist fine.
+
+3. **Don't mix recovery commands across systems.** `/god-undo` reverts
+   Godpowers state only. If another tool also writes to `.godpowers/`,
+   recovery drifts. Keep recovery scopes disjoint.
+
+4. **Hooks are per-tool but share the directory.** SessionStart hooks
+   from multiple systems live in `~/.claude/hooks/` and run sequentially.
+   Order is not guaranteed; do not rely on cross-tool hook ordering.
+
+5. **Resolve conflicts by state-directory ownership.** If Godpowers
+   says X and another tool says Y about the same artifact, follow
+   whichever system owns the directory the artifact lives in.
+
+## When two systems overlap
+
+| Overlap kind | Strategy |
+|---|---|
+| Both write to the same artifact | Pick one as authoritative. Disable the other's writer for that artifact. |
+| Both define a planning workflow | Pick one for planning. Mixing creates duplicate state and divergent truth. |
+| One reasons (TDD, review), the other plans (PRD/ARCH) | Stack them. They're orthogonal. |
+| Both ship slash commands with similar names | Disambiguate by prefix. `/god-*` is reserved for Godpowers. |
+
+## Migration into Godpowers
+
+If you arrive at Godpowers carrying artifacts from another system,
+`/god-init` Mode B (gap-fill) reads what exists and maps it forward:
+
+- Existing PRD-like documents -> `.godpowers/prd/PRD.md` (after
+  substitution-test rewrite if needed)
+- Existing ADRs -> `.godpowers/arch/adr/`
+- Existing roadmap / milestones -> `.godpowers/roadmap/ROADMAP.md`
+- Existing story / ticket files -> `.godpowers/stories/STORY-*.md`
+  (via `/god-story`)
+
+Mode B does not delete the source files. It produces Godpowers
+artifacts alongside them. Once parity is reached, you can retire the
+older system at your own pace.
+
+## Migration out of Godpowers
+
+Every Godpowers artifact is a plain Markdown file with optional
+frontmatter. There's no proprietary binary state. To leave:
+
+1. Copy `.godpowers/prd/`, `arch/`, `roadmap/`, `stack/` somewhere.
+2. Strip the fenced "Implementation Linkage" footers if the target
+   system doesn't understand them (they're recoverable from code
+   annotations).
+3. Delete `.godpowers/`.
+
+## What Godpowers does not try to be
+
+Godpowers is opinionated about: artifact discipline, bidirectional
+linkage, the four-tier arc, the single-orchestrator rule, headless
+runtime verification, and the substitution / three-label / have-nots
+gates. It is intentionally not opinionated about: team ceremonies,
+sprint cadence, ticket trackers, knowledge graphs, prompt engineering
+methodology. If you need those, run them alongside.

package/references/shared/README.md

@@ -0,0 +1,14 @@
+# Shared References
+
+Cross-tier reference content used by multiple agents.
+
+## Files
+
+- [HAVE-NOTS.md](../HAVE-NOTS.md) (canonical failure-mode catalog, 115 entries)
+
+## Planned content
+
+- ORCHESTRATORS.md: composition patterns with other AI coding workflow systems
+- RESEARCH.md: dated research notes informing agent design decisions
+- GLOSSARY.md: standardized vocabulary across tiers (substitution test,
+  three-label test, flip point, have-not, paper artifact, theater, AI-slop)

package/references/shipping/DEPLOY-ANTIPATTERNS.md

@@ -0,0 +1,64 @@
+# DEPLOY Antipatterns
+
+## 1. The Manual Deploy
+
+**Sample**: "Deploy steps: 1. SSH to server. 2. Git pull. 3. npm restart."
+
+**Why it fails**: Manual steps run by a human are unreproducible, undocumented in
+runtime state, and accumulate divergence from what's checked in.
+
+**Fix**: Every deploy is a CI workflow triggered by a tag or merge to main.
+The workflow is the deploy spec; the runbook describes the workflow, not
+the steps to run by hand.
+
+## 2. The Untested Rollback
+
+**Sample**: Deploy doc lists "rollback: redeploy previous tag." Nobody has
+ever tested rollback in production.
+
+**Why it fails**: When you need rollback, it's because something is broken.
+That's not the moment to discover the rollback path also broken.
+
+**Fix**: Rollback is exercised at least quarterly (game-day), and the
+exercise generates an entry in DEPLOY/STATE.md with the date and outcome.
+
+## 3. The Secret in the Repo
+
+**Sample**: `.env.production` checked in with API keys.
+
+**Why it fails**: Once committed, it lives in git history forever. Rotation
+is required; reputation damage is not undone.
+
+**Fix**: Secrets in the platform's secret manager (Vercel env, AWS Secrets
+Manager, etc.). `.gitignore` enforces; pre-commit hook scans. Detected
+violations BLOCK commit.
+
+## 4. The Big-Bang Deploy
+
+**Sample**: 2-week change merged and deployed all at once.
+
+**Why it fails**: Bisecting a regression across 100 commits is hours of
+work. Blast radius is the entire change.
+
+**Fix**: Continuous deploy on merge. Each commit deploys. Feature flags
+gate user exposure. Rollback rolls back one commit.
+
+## 5. The Silent Deploy
+
+**Sample**: No notification, no log, no audit when production deploys.
+
+**Why it fails**: When something breaks at 3 AM, you don't know if the
+2:55 AM deploy caused it because there's no record.
+
+**Fix**: Every deploy emits an event (Slack, audit log, observability
+trace). DEPLOY/STATE.md records the deploy SHA, time, and operator
+(human or CI).
+
+## 6. The Environment Drift
+
+**Sample**: Staging works, production fails. Investigation reveals
+staging has Node 20 and production runs Node 18.
+
+**Fix**: Identical infrastructure-as-code for staging and production.
+Differ only in scale, not in versions. Drift between environments is a
+SEV-2 incident in itself.

package/references/shipping/DEPLOY-PATTERNS.md

@@ -0,0 +1,110 @@
+# Deploy Patterns
+
+## Same-Artifact Promotion
+
+Build the artifact ONCE. Promote the SAME artifact through environments.
+
+```
+build (CI) -> dev artifact -> dev env
+                           -> staging env (same artifact)
+                           -> prod env (same artifact)
+```
+
+**Why**: prevents "works in staging, broken in prod" caused by build drift.
+
+**How**:
+- Tag the artifact (Docker image, binary, bundle) with a version
+- Use the tag throughout promotion
+- NEVER rebuild per environment
+- Configuration is the only thing that differs across environments
+
+## Environment Parity
+
+Configuration shape is the same across environments. Values differ.
+
+```
+# All environments use:
+DATABASE_URL=...
+STRIPE_API_KEY=...
+LOG_LEVEL=...
+
+# Values differ:
+DATABASE_URL=postgres://dev-host vs postgres://prod-host
+LOG_LEVEL=debug vs info
+```
+
+**Anti-pattern**: dev has feature flags that prod doesn't have. Or prod has
+secrets that dev mocks. Drift accumulates and bites you.
+
+## Expand-Contract for Schema Changes
+
+Multi-step deploy for breaking schema changes:
+
+1. **Expand**: deploy code that supports BOTH old and new schema. Old schema
+   still active.
+2. **Migrate data**: backfill new schema from old. Both still work.
+3. **Switch**: deploy code that reads/writes new schema only.
+4. **Contract**: drop old schema in a separate deploy.
+
+Each step is independently deployable and rollback-able.
+
+## Real Health Checks
+
+Application-level. NOT just TCP port.
+
+```js
+// Good
+GET /health -> {
+  status: "ok" | "degraded" | "down",
+  database: "connected",
+  stripe_api: "reachable",
+  worker_lag_seconds: 12,
+  version: "1.2.3"
+}
+
+// Bad
+GET /health -> 200 OK (just because the process is running)
+```
+
+## Tested Rollback
+
+Document the rollback. THEN run it in staging. Then commit the runbook.
+
+A rollback that's never been executed is a paper rollback.
+
+```
+Rollback procedure for v1.2.3:
+1. Tag v1.2.2 in deploy system: kubectl rollout undo deployment/api
+2. Verify health endpoint returns version: 1.2.2
+3. Verify no DB schema rollback needed (this release was code-only)
+4. Estimated time: 90 seconds
+5. Last tested: 2026-04-15 (in staging)
+```
+
+## Smoke Test Post-Deploy
+
+Automated. Runs against the live environment. Fails the deploy if it fails.
+
+```bash
+# After deploy:
+curl -sf https://api.example.com/health || rollback
+curl -sf https://api.example.com/api/v1/version | grep "1.2.3" || rollback
+# Critical user path:
+curl -sf https://api.example.com/api/v1/auth/test || rollback
+```
+
+## Anti-patterns
+
+### Manual deploy steps
+Production deploy requires a human running commands. Each step is a
+chance to mess up.
+
+**Fix**: automate end-to-end. Even the "click approve" step should be a
+script that opens the right URL.
+
+### Paper canary
+Canary deploy "label" exists, but no traffic split. Just calling something
+canary doesn't make it one.
+
+**Fix**: actually split traffic at the load balancer. 1% -> 10% -> 50% ->
+100%. Verify metrics at each step.

package/references/shipping/HARDEN-ANTIPATTERNS.md

@@ -0,0 +1,66 @@
+# HARDEN Antipatterns
+
+## 1. The Compliance-Only Audit
+
+**Sample**: Auditor runs OWASP top-10 checklist; checks all boxes; ships.
+
+**Why it fails**: OWASP top-10 is a floor, not a ceiling. A compliant
+system can still leak through application-specific vulnerabilities the
+checklist doesn't cover.
+
+**Fix**: Adversarial review with named threat models. Auditor asks
+"what would an attacker who has X try?" and traces the attack path
+through actual code, not through a checklist.
+
+## 2. The Findings Without Owner
+
+**Sample**: HARDEN/FINDINGS.md lists 12 findings. None have owners or
+deadlines.
+
+**Why it fails**: Findings without owners are graveyards. Three months
+later they're still open and no one remembers why.
+
+**Fix**: Every finding gets an owner, severity, and a deadline. CRITICAL
+findings block launch. HIGH findings have a deadline within the next
+sprint. Open findings auto-surface in /god-status until closed.
+
+## 3. The Untested Remediation
+
+**Sample**: Finding closed because "we added validation." No test
+demonstrates the validation works against the original attack.
+
+**Why it fails**: Remediation that wasn't tested may not actually fix
+the issue. Regression is invisible.
+
+**Fix**: Each remediation lands with a regression test that fails
+without the fix and passes with it. Closed findings link to the test.
+
+## 4. The Auth Boundary Confusion
+
+**Sample**: The system has authentication (who you are) but the team
+treats it as authorization (what you can do).
+
+**Why it fails**: Logged-in users can take actions they should not be
+allowed to. Authorization is a separate layer.
+
+**Fix**: Document auth boundaries explicitly: identity (who), session
+(active), permissions (what). Each layer has its own tests.
+
+## 5. The Trusted Input
+
+**Sample**: Backend trusts data from frontend because "we control both."
+
+**Why it fails**: Anyone can call the backend directly. Frontend
+validation prevents accidents, not attacks.
+
+**Fix**: Every input is untrusted. Validation runs on the boundary
+between layers, not just at the UI.
+
+## 6. The Outdated Threat Model
+
+**Sample**: Threat model written at /god-init has not been updated even
+though the system added a payment integration and a public API.
+
+**Fix**: Threat model is a living document. /god-feature, /god-deploy,
+and any change touching trust boundaries triggers a HARDEN review of
+the affected boundary.