godpowers 0.15.0

package/references/orchestration/MODE-DETECTION.md

@@ -0,0 +1,74 @@
+# Mode Detection
+
+> How god-orchestrator decides which mode (A/B/C/D) to use.
+
+## Mode A: Greenfield (default)
+
+**Signals**:
+- No `.godpowers/` directory exists
+- Working directory is empty OR contains only `.git/` and `README.md`
+- User describes a "new project" or "from scratch"
+
+**Behavior**: run all tiers from PRD onwards.
+
+## Mode B: Gap-fill
+
+**Signals**:
+- Some `.godpowers/<tier>/<artifact>` files already exist
+- OR existing codebase signals: package.json, Dockerfile, .github/workflows
+- User describes an existing project they want to add Godpowers to
+
+**Behavior**:
+1. For each canonical artifact path: check existence on disk
+2. For each existing artifact: spawn god-auditor to verify against have-nots
+3. If passes: mark tier "imported" in PROGRESS.md, skip
+4. If fails: mark tier "in-flight", will re-run
+5. If missing: mark tier "pending"
+
+Codebase signals (for inferring partial completion):
+- `package.json` exists -> Repo tier likely done
+- `.github/workflows/` or `.gitlab-ci.yml` exists -> CI present
+- `tests/` or `*.test.*` files exist -> Build tier in progress
+- `Dockerfile` + deploy config -> Deploy tier may be done
+
+## Mode C: Audit
+
+**Signals**:
+- Triggered explicitly with `--audit` flag
+- User says "audit the project" or "score everything"
+
+**Behavior**: run god-auditor on all existing artifacts. Build nothing.
+
+## Mode D: Multi-repo (FUTURE WORK)
+
+**Signals**:
+- Working directory contains workspace config (pnpm-workspace.yaml, nx.json, lerna.json, turbo.json)
+- OR multiple sub-repos with their own `.git/`
+- User describes a system spanning multiple repos
+
+**Status**: documented but not implemented in v0.4. Falls back to Mode A or B for the current repo.
+
+## Worked example
+
+User runs `/god-mode` in a directory with:
+
+```
+existing-saas/
+  .git/
+  package.json
+  src/
+    auth.ts
+    api.ts
+  tests/
+    auth.test.ts
+```
+
+god-orchestrator detects:
+- No `.godpowers/` -> normally Mode A
+- BUT package.json + src/ + tests/ -> existing codebase -> Mode B
+
+Reports to user:
+> "Detected an existing codebase (package.json, src/, tests/ present).
+> Setting Mode B (gap-fill). I'll work backward to fill missing artifacts.
+> First: I need to understand what this codebase does. Let me start with
+> /god-explore or you can describe it briefly."

package/references/orchestration/README.md

@@ -0,0 +1,18 @@
+# Orchestration References
+
+Per-tier reference content for Tier 0 (Orchestration). Loaded on demand by
+god-orchestrator and related agents.
+
+## Files
+
+- (empty for now; content to be added in future releases)
+
+## Contribution Welcome
+
+This directory is the natural home for:
+- Mode A/B/C/D detection heuristics with worked examples
+- Scale detection rubric with calibration cases
+- Pause vs no-pause decision tree examples
+- YOLO default rationale documents
+
+If you'd like to contribute, see [CONTRIBUTING.md](../../CONTRIBUTING.md).

package/references/orchestration/SCALE-DETECTION.md

@@ -0,0 +1,81 @@
+# Scale Detection
+
+> How god-orchestrator infers project scale from the user's description.
+
+## Five scales
+
+| Scale | Signals | Recommended workflow |
+|-------|---------|---------------------|
+| Trivial | Single-file change, bug fix, config tweak | /god-fast (skip planning) |
+| Small | One feature, one service, <1 week | /god-quick OR lightweight /god-mode |
+| Medium | Multiple features, 1-3 services, 1-4 weeks | /god-mode (full arc) |
+| Large | Multiple services, team coordination, 1-3 months | /god-mode + /god-sprint (sprints) |
+| Enterprise | Multiple teams, compliance, 3+ months | /god-mode + extension packs (security, etc.) |
+
+## Detection signals
+
+### Trivial signals
+- "fix typo"
+- "change config value"
+- "rename variable"
+- One file mentioned
+
+### Small signals
+- "build [single feature]"
+- "add [one thing] to my app"
+- One service mentioned
+- Time mentioned: "today", "this afternoon"
+
+### Medium signals
+- Multiple features mentioned
+- Multiple services or components mentioned
+- Time mentioned: "next few weeks", "this sprint"
+- "SaaS for X" or "MVP" or "side project"
+
+### Large signals
+- "platform"
+- Multiple teams mentioned
+- Time mentioned: "next quarter", "next 2-3 months"
+- Mentions multiple stakeholder roles (PM, designer, QA)
+
+### Enterprise signals
+- Compliance mentioned (SOC 2, HIPAA, PCI, GDPR)
+- Multiple teams mentioned
+- Multi-region mentioned
+- Time mentioned: "next year", "Q1-Q3"
+- Words like "enterprise", "B2B", "regulated industry"
+
+## What scale changes
+
+| Scale | Tiers active | Personas | Ceremonies | Hygiene |
+|-------|--------------|----------|------------|---------|
+| Trivial | Build only | god-executor | None | None |
+| Small | PRD (lightweight), Build, Deploy | PM, Dev | None | None |
+| Medium | All tiers | PM, Architect, Dev, QA | None | Weekly /god-hygiene |
+| Large | All tiers | All | /god-sprint optional | Weekly /god-hygiene |
+| Enterprise | All tiers + extension packs | All + extensions | /god-sprint required | Daily /god-hygiene |
+
+## Worked examples
+
+### "Add a typo fix to the README"
+-> Trivial -> /god-fast
+
+### "Build a side project to track my reading list"
+-> Small -> lightweight /god-mode (skip ARCH)
+
+### "Build a SaaS for solo founders to track MRR"
+-> Medium -> /god-mode
+
+### "Build a platform for our 5-person team to track customer health"
+-> Large -> /god-mode + /god-sprint
+
+### "Build a HIPAA-compliant patient portal for a hospital"
+-> Enterprise -> /god-mode + @godpowers/security-pack
+
+## When in doubt
+
+If signals are mixed, ask the user explicitly:
+> "I detect signals between Medium and Large scale. Are you a solo
+> developer or a team? How long do you plan to work on this?"
+
+The user's answer determines the scale.

package/references/planning/ARCH-ANATOMY.md

@@ -0,0 +1,143 @@
+# Architecture Anatomy
+
+> What a strong architecture document looks like. Every decision has a
+> flip point. Every NFR maps to a choice.
+
+## 1. System Context (C4 Level 1)
+
+A diagram showing the system + external actors and systems.
+
+**What good looks like**: every arrow labeled with data flowing and protocol.
+
+```
+[User browser] --HTTPS, OAuth flow--> [MRR Tracker]
+[Stripe webhooks] --HTTPS, signed payloads--> [MRR Tracker]
+[MRR Tracker] --SMTP, daily digest--> [Email user]
+[MRR Tracker] --HTTPS--> [Stripe API]
+```
+
+## 2. Container Diagram (C4 Level 2)
+
+Major runtime containers with single responsibilities.
+
+```
+[Browser SPA] <--HTTPS--> [API Server (Node)]
+                                   |
+                                   v
+                            [Postgres (managed)]
+                                   |
+                                   v
+                            [Worker (BullMQ)]
+                                   |
+                                   v
+                            [Stripe Sync Job]
+```
+
+| Container | Single Responsibility |
+|-----------|----------------------|
+| Browser SPA | Render dashboard, OAuth flow init |
+| API Server | Auth, query data, serve dashboard endpoints |
+| Postgres | Store user accounts, encrypted Stripe tokens, MRR snapshots |
+| Worker | Async Stripe sync, daily digests |
+| Stripe Sync Job | Pull Stripe events, compute MRR breakdown |
+
+## 3. Architecture Decision Records (ADRs)
+
+For each load-bearing decision:
+
+### ADR-001: Monolith vs Microservices
+
+**Context**: We need to ship V1 in 8 weeks with a solo founder. Scale
+expectations are 1000 concurrent users by month 3.
+
+**Decision**: Monolithic Node.js API with a single worker process.
+
+**Rationale**: At 1000 users, complexity of microservices outweighs the
+operational benefit. Solo founder can't afford the deploy/observability
+overhead of multiple services.
+
+**Flip point**: If we hit 10,000 concurrent users OR we add a second
+team that needs independent deploy cadence, split the worker into a
+separate service first.
+
+**Consequences**:
+- Easier: deploy, debug, develop locally
+- Harder: scaling specific bottlenecks (e.g., the Stripe sync) independently
+
+### ADR-002: Postgres vs MongoDB
+
+**Context**: Data is structured (users, accounts, MRR snapshots). Queries
+are mostly OLAP (time-series aggregations).
+
+**Decision**: Postgres.
+
+**Rationale**: Strong typing, mature OLAP support via materialized views,
+team familiar with SQL.
+
+**Flip point**: If we add document-shaped data (e.g., user-defined custom
+metrics with arbitrary schemas), revisit.
+
+**Consequences**:
+- Easier: migrations, complex aggregations, integrity
+- Harder: schema-less data (we'd have to use JSONB columns)
+
+## 4. NFR-to-Architecture Map
+
+Every NFR from the PRD MUST appear here.
+
+| PRD NFR | Architectural Choice | ADR Reference |
+|---------|---------------------|---------------|
+| p99 dashboard load < 2s | Materialized views for MRR breakdown; cache layer in API; SPA only fetches deltas | ADR-002, ADR-005 |
+| 99.9% uptime | Managed Postgres (auto-failover); single API server with automated restart; health check endpoint | ADR-003 |
+| 10,000 users by month 6 | Monolith handles up to ~5000; split worker first when needed | ADR-001 |
+| OAuth tokens encrypted at rest | Postgres pgcrypto extension; encryption key in secrets manager | ADR-006 |
+| No Stripe API keys stored | We use OAuth (refresh tokens only); never the API key directly | ADR-007 |
+
+If an NFR has no row here: that's a have-not failure (A-03).
+
+## 5. Trust Boundaries
+
+```
+[User Browser] (untrusted)
+    |
+    | === BOUNDARY: OAuth bearer token, validated per request ===
+    |
+[Our API Server] (trusted)
+    |
+    | === BOUNDARY: Stripe API key from secrets manager, never logged ===
+    |
+[Stripe API] (trusted external)
+```
+
+For each boundary:
+- Auth method: how identity is established
+- Data classification: what flows across (sensitive vs public)
+- Failure mode: what happens if the boundary is breached
+
+## 6. Data Model
+
+```
+User (1) -- (N) StripeAccount
+StripeAccount (1) -- (N) MRRSnapshot
+MRRSnapshot {date, mrr, new_mrr, expansion_mrr, churn_mrr, contraction_mrr}
+```
+
+| Entity | Owner Service | Consistency Model |
+|--------|---------------|-------------------|
+| User | API Server | Strong (single Postgres) |
+| StripeAccount | API Server | Strong |
+| MRRSnapshot | Worker writes, API reads | Eventually consistent (sync lag <1h) |
+
+## 7. Required Format
+
+Every claim must be labeled. Examples:
+
+> [DECISION] We use Postgres because the data is structured and queries
+> are OLAP-shaped.
+>
+> [HYPOTHESIS] BullMQ will handle our worker volume; if we exceed 1000
+> jobs/sec we'll need to evaluate alternatives. Validation plan:
+> load test before launch.
+>
+> [OPEN QUESTION] Where do we store OAuth state during the redirect?
+> Owner: architect. Due: before /god-build.

package/references/planning/ARCH-ANTIPATTERNS.md

@@ -0,0 +1,52 @@
+# Architecture Antipatterns
+
+## 1. Architecture Theater
+Diagrams without load-bearing decisions. Boxes connected by arrows that
+nobody can articulate the rationale for. Looks impressive; decides nothing.
+
+**Fix**: For every box and every arrow, write the WHY. If you can't, delete it.
+
+## 2. Cargo-Cult Cloud-Native
+Kubernetes + Kafka + microservices for a 10-user CRUD app.
+
+**Fix**: Match complexity to scale from PRD. If PRD says 1000 users by
+month 6, monolith is fine. Don't import patterns from a scale you'll
+never reach.
+
+## 3. Stackitecture
+Picking React + Postgres + Vercel and calling it architecture.
+
+**Fix**: Architecture is system shape (services, boundaries, data flow).
+Stack is tool selection. They're separate documents. Read /god-stack
+after /god-arch, not instead of it.
+
+## 4. "Scalable" Without Numbers
+> "Our system is highly scalable."
+
+**Fix**: Replace with quantification. "Handles 10K concurrent users at p99
+< 200ms in a single region. Beyond that, we add read replicas (ADR-008)."
+
+## 5. Resume-Driven Architecture
+Choosing GraphQL/Kubernetes/Rust because they're trendy or because the
+architect wants the experience, not because they fit.
+
+**Fix**: Tie every choice to a PRD requirement. If you can't, drop it.
+
+## 6. Paper-Tiger Architecture
+Looks robust on paper. Breaks under first real load.
+
+**Fix**: Every NFR gets a worst-case analysis. "Sustained 100 reqs/sec at
+p99 < 200ms" needs a load test before launch, not after.
+
+## 7. Hidden Single Points of Failure
+Diagram shows redundancy at every layer EXCEPT one (the auth service, the
+config server, the deploy bot).
+
+**Fix**: For each container, ask "what happens if this dies?" If the answer
+is "everything stops," it's a SPOF. Address it or document it.
+
+## 8. ADR Without Flip Point
+> "Decision: monolith. Rationale: simpler. Consequences: easier deploy."
+
+**Fix**: Add the flip point. "Reverse this decision when [specific
+condition]." Without it, the decision is forever and unfalsifiable.

package/references/planning/PRD-ANATOMY.md

@@ -0,0 +1,117 @@
+# PRD Anatomy
+
+> What a strong PRD looks like, section by section, with what to write and
+> what to avoid.
+
+## 1. Problem Statement
+
+**What it does**: states the problem in user terms, not solution terms.
+
+**What good looks like**:
+> Solo SaaS founders running between $1k and $10k MRR don't know whether
+> their revenue is growing because of new customers or because they raised
+> prices. The two have opposite implications. Existing tools like ChartMogul
+> and Baremetrics report the metric but don't decompose the cause.
+
+**What bad looks like**:
+> We need a tool that tracks MRR with AI insights for modern founders.
+
+The bad version passes the substitution test (any product). The good version
+fails it (specific to one segment, one decomposition gap).
+
+## 2. Target Users
+
+**What it does**: names the user with enough context that a designer could
+sketch them.
+
+**What good looks like**:
+> Solo founders, age 25-45, technical, building B2B SaaS, $1k-$10k MRR,
+> looking at their dashboard 2-3 times daily, primarily worried about churn
+> vs growth attribution. Use Stripe for payments. Read Indie Hackers and
+> Twitter.
+
+**What bad looks like**:
+> Developers and small business owners who want better analytics.
+
+## 3. Success Metrics
+
+**What it does**: states observable, time-bound, measurable outcomes.
+
+**What good looks like**:
+| Metric | Target | Timeline | Measurement |
+|--------|--------|----------|-------------|
+| Daily active users | 50 | 30 days post-launch | Mixpanel daily active count |
+| Time to first insight | <60 seconds | Always | Page-load timer + first chart render |
+| Conversion (visit -> signup) | 3% | First 30 days | Mixpanel funnel |
+
+**What bad looks like**:
+> Users find it valuable. Strong growth. Good engagement.
+
+## 4. Functional Requirements
+
+**What it does**: lists what the product DOES, prioritized.
+
+**What good looks like**:
+
+### MUST (V1 launch blockers)
+- User can connect Stripe account and view MRR breakdown by new/expansion/churn within 30 seconds
+  - Acceptance: OAuth flow completes, dashboard renders within 30s of authorization
+
+### SHOULD (V1 if time)
+- User can compare MRR change to a previous period (week, month, quarter)
+  - Acceptance: dropdown selector + line chart updates in <500ms
+
+### COULD (post-V1)
+- User can export MRR breakdown as CSV
+- User can connect multiple Stripe accounts
+
+**What bad looks like**:
+- Add MRR tracking
+- Build analytics
+- Make it nice
+- AI insights
+
+## 5. Non-Functional Requirements
+
+| Category | Requirement |
+|----------|-------------|
+| Latency | p99 dashboard load < 2 seconds |
+| Availability | 99.9% over 30 days (43 minutes/month error budget) |
+| Scale | 1000 concurrent users by month 3, 10000 by month 6 |
+| Security | OAuth tokens encrypted at rest; no Stripe API keys ever stored |
+
+## 6. Scope and No-Gos
+
+**What it does**: explicit list of what is NOT being built. Prevents scope creep.
+
+**What good looks like**:
+- NOT building: mobile app for V1
+- NOT building: payment processing (Stripe handles it)
+- NOT building: customer support tooling
+- NOT building: white-label / multi-tenant for V1
+
+**What bad looks like**:
+- (empty section, or absent)
+
+## 7. Appetite
+
+**What it does**: time and resource constraints, before any planning.
+
+**What good looks like**:
+- Time budget: 8 weeks from PRD to production launch
+- Resource budget: solo founder, 30 hours/week
+- Technical constraints: must work with Stripe, must run on a single $20/mo server for V1
+
+## 8. Open Questions
+
+**What it does**: lists what's NOT decided yet, with owners and due dates.
+
+**What good looks like**:
+| Question | Owner | Due Date |
+|----------|-------|----------|
+| Should we support Paddle or only Stripe for V1? | Founder | Before /god-arch |
+| What's the highest-impact metric users want first? | Founder | Before /god-build |
+
+**What bad looks like**:
+- "TBD"
+- (open questions buried in prose)

package/references/planning/PRD-ANTIPATTERNS.md

@@ -0,0 +1,138 @@
+# PRD Antipatterns
+
+> Common ways PRDs fail. Each has a sample, why it fails, and the fix.
+
+## 1. The Hollow PRD
+
+**Sample**: All sections filled, but no actual decisions. Every claim is
+[HYPOTHESIS] with no validation plan.
+
+**Why it fails**: Engineering can't build from hypotheses. Designers can't
+design for "users who want value". A hollow PRD is theater.
+
+**Fix**: For every [HYPOTHESIS], either commit it to a [DECISION] with
+rationale, or schedule a validation step (user interview, spike, market
+research) with a date.
+
+## 2. The Solution-First PRD
+
+**Sample**:
+> Problem: Users don't have an AI-powered MRR tracking dashboard.
+
+**Why it fails**: The problem statement names the solution. You haven't
+defined the user pain; you've assumed AI tracking is the answer. If the
+real problem is "I can't tell why MRR changed," AI tracking might not be
+the right shape.
+
+**Fix**: Restate the problem in user-pain terms. "Users can't tell why
+their MRR changed week-over-week." Then ask whether AI is the right shape
+or whether a clearer breakdown view would do.
+
+## 3. The Feature Laundry List
+
+**Sample**:
+- Add MRR tracking
+- Add charts
+- Add Stripe integration
+- Add user settings
+- Add notifications
+
+**Why it fails**: No prioritization. No acceptance criteria. Every item
+looks equally important. Engineering will pick whichever is easiest first.
+
+**Fix**: Tag each as MUST / SHOULD / COULD. Add acceptance criteria
+("user can do X within Y, measured by Z"). Order MUSTs by user value.
+
+## 4. The Assumption Soup
+
+**Sample**:
+> We assume users will love our AI insights and will pay $99/mo.
+
+**Why it fails**: Multiple stacked assumptions, none labeled or validated.
+What does "love" mean? Why $99? What if they don't?
+
+**Fix**:
+- "We hypothesize that solo SaaS founders [DECISION: target persona] will
+  pay $99/mo for [DECISION: specific feature], based on [evidence]. We
+  will validate by [user interviews, pricing test, or letter of intent]
+  before /god-build. [OPEN QUESTION] what's the price ceiling? Owner: founder.
+  Due: end of this week."
+
+## 5. The Moving Target
+
+**Sample**: PRD updated silently after engineering started building. No
+notification, no diff, no re-validation.
+
+**Why it fails**: Engineer builds X, comes back to find PRD now says Y.
+Trust collapses.
+
+**Fix**: All PRD changes after consumption (by ARCH, ROADMAP, or downstream)
+must be tracked. Append a changelog. Notify downstream agents. Re-run their
+have-nots checks.
+
+## 6. The Generic Target User
+
+**Sample**:
+> Target users: developers and businesses who want better analytics.
+
+**Why it fails**: "developers" is 30 million people with wildly different
+needs. "Businesses" is meaningless. Substitution test passes (any tool
+serves "developers").
+
+**Fix**: Name a specific persona with role, context, and current pain.
+"Solo SaaS founders running B2B businesses at $1k-$10k MRR using Stripe."
+
+## 7. The Vanity Metric
+
+**Sample**:
+> Success metric: 10,000 users.
+
+**Why it fails**: Users without retention is vanity. Users without revenue
+(if revenue is the goal) is vanity. The number doesn't tie to the problem.
+
+**Fix**: Tie the metric to the problem statement. If the problem is
+"founders can't tell why MRR changed," the metric is "% of users who
+correctly identify their primary growth driver after using the dashboard
+for 7 days, measured by exit survey."
+
+## 8. The Buzzword Bingo
+
+**Sample**:
+> AI-powered, cloud-native, scalable, robust, modern dashboard.
+
+**Why it fails**: Substitution test passes for any product. None of these
+words decide anything.
+
+**Fix**: Replace each buzzword with a specific claim:
+- "AI-powered" -> "uses GPT-4 to summarize the top growth driver in plain English"
+- "Scalable" -> "supports 10000 concurrent users by month 6"
+- "Modern" -> (delete; modernity isn't a feature)
+
+## 9. The Empty No-Gos
+
+**Sample**: Scope and No-Gos section is missing or empty.
+
+**Why it fails**: Without explicit no-gos, engineering will drift toward
+nice-to-haves. Scope creep is guaranteed.
+
+**Fix**: List 3-5 specific no-gos that you might be tempted to build but
+shouldn't:
+- NOT building: mobile app for V1
+- NOT building: customer support tooling
+- NOT building: multi-tenant / white-label
+- NOT building: AI-generated chart commentary (defer to V2)
+
+## 10. The Owner-less Open Question
+
+**Sample**:
+> Open questions: should we support Paddle? TBD.
+
+**Why it fails**: "TBD" without owner or due date means nobody resolves it.
+The question stays open forever or gets decided by accident during build.
+
+**Fix**:
+| Question | Owner | Due |
+|----------|-------|-----|
+| Support Paddle in V1? | Founder | Before /god-arch |
+
+If you don't know who owns it, the founder owns it.

package/references/planning/README.md

@@ -0,0 +1,16 @@
+# Planning References
+
+Per-tier reference content for Tier 1 (Planning: PRD, Architecture, Roadmap, Stack).
+
+## Files
+
+- (placeholder; antipattern catalogs and worked examples to be added)
+
+## Planned content
+
+- PRD anatomy with line-by-line annotations of a substitution-tested example
+- ARCH antipatterns: architecture theater, paper-tiger, cargo-cult cloud-native
+- Worked Stack decision examples with flip-point analysis
+- Roadmap anti-examples: Gantt theater, feature-factory output, shelf roadmaps
+
+See [HAVE-NOTS.md](../HAVE-NOTS.md) for the canonical failure-mode catalog.

package/references/planning/ROADMAP-ANATOMY.md

@@ -0,0 +1,43 @@
+# Roadmap Anatomy
+
+## Now / Next / Later (Shape Up flavor)
+
+**Now**: currently building. Committed. Has a target date but slippage is OK.
+**Next**: planned to start when Now ships. Order is set, scope is flexible.
+**Later**: intent. May change. Captures direction without commitment.
+
+## Milestone Structure
+
+Each milestone has:
+- **Goal**: what users can DO when this ships (substitution-tested)
+- **Completion gate**: observable criterion ("not feels done")
+- **Size**: S / M / L (T-shirt; no day-precision without capacity input)
+- **Depends on**: explicit upstream milestones
+- **Features**: from PRD (no speculative features)
+
+## Examples
+
+### Good
+> Milestone 1 (Now): Connect Stripe + see basic MRR
+> - Goal: User can connect Stripe in <60s and see current MRR breakdown by new/expansion/churn
+> - Gate: 5 friendly users complete onboarding without help
+> - Size: M
+> - Depends on: none
+> - Features: PRD-MUST-1, PRD-MUST-2
+
+### Bad
+> Milestone 1: Build the dashboard
+> - Goal: have a dashboard
+> - Gate: it works
+> - Size: ?
+> - Features: dashboard, charts, things
+
+## Velocity Tracking
+
+After 2 sprints, you have a baseline. Use it for Next milestones.
+
+| Sprint | Committed | Delivered | Notes |
+|--------|-----------|-----------|-------|
+| 1 | 5 slices | 4 | Auth slice underestimated |
+| 2 | 5 slices | 6 | Recovered the auth overhang |
+| Avg | 5/sprint | 5/sprint | Stable baseline |