<!-- G-0: Business Model Canvas + Pricing Worksheet (blank template) — Ch.2 -->
# [Service Name] Business Model Canvas (6 boxes)
① Problem      — Who is struggling, in what situation, and why?
② Alternatives — What are they using right now? Where does it fall short?
③ Solution     — Your service's core function in one sentence
④ Differentiator — What existing alternatives structurally cannot do
⑤ Revenue model — One-time / subscription / other + the key paid-tier trigger
⑥ Cost structure — What you spend per user per month (calculated in Ch.3.4)

# Pricing Tier Worksheet
1. What's the minimum needed to experience the core value?  → put it in Free
2. What's the first moment a user thinks "I want more"?     → Free / Pro split point
3. What does one Pro user cost you per month?               → your price floor
4. What price range do existing alternatives charge?        → the price gravity field
5. How will you accommodate heavy users?                    → higher tier or BYOK


<!-- G-1: Architecture Reference (blank template) -->
# [Service Name] Architecture Reference
Last updated: YYYY-MM-DD | This document is the reference point for all technical decisions.

## 1. Service in one sentence
[Who] does [what] and gets [what result]

## 2. Component map (draw it as a restaurant)
- Dining room (frontend): [technology] — deployed on: [platform]
- Kitchen (backend): [technology] — deployed on: [platform]
- Chef (AI): [model family] — called from: [where]
- Refrigerator (DB): [technology]
- Entrance (auth): [service name]
- Dishwasher (worker): [present / absent — if present, technology name]
- Payments: [service name]

## 3. Data flow (one core scenario)
User [action] → [dining room] → [kitchen] → [chef / refrigerator] → user receives [result]

## 4. Module contracts (interfaces)
| Sender | Receiver | What is exchanged (format) |
|---|---|---|
| (sender module) | (receiver module) | (data exchanged) |

## 5. Structural decisions log (add an entry each time something changes)
| Date | Decision | Reason |
|---|---|---|
| (date) | (decision) | (reason) |


<!-- G-2: Progress Tracking Checklist (blank template) -->
# [Service Name] Progress Tracker
Current Stage: [1/2/3] | Last session: YYYY-MM-DD

## This Stage task list
- [ ] Task name — one-line definition of done
- [ ] ...

## Today's session (update at start and end — 2 min each)
- What was done in the last session:
- What to do today (one thing only):
- Stuck points / carry over to next session:

## Freeze list (do not modify — Ch.6.3)
- [file / module] (passed Stage N, YYYY-MM-DD)


<!-- G-3: Build Prompt (blank template) -->
# Build Instructions: [Task Name]
Date: YYYY-MM-DD

## Goal (one sentence)

## Context (read before starting)
- Architecture Reference [path / attachment]
- Relevant spec: [module name]
- Check the latest decisions file before proceeding (Ch.5.5)

## To do
1.
2.

## Do NOT do (prohibited actions — always fill this in)
- Do NOT modify any file on the Freeze list. If you believe a change is necessary,
  stop and report to me instead.
- Do NOT build features outside the scope of this stage ([e.g., auth, payments]).

## Done criteria (answerable as PASS / FAIL)
- [ ]


<!-- G-3.5: Spec Document (blank template) — The exact document that brought down V2 -->
# Spec: [Module Name]
Last updated: YYYY-MM-DD | This document governs all work that exchanges data with this module.

## Role in one sentence
This module takes [what], does [what], and outputs [what].

## Input
| Field | Format | Example | If missing? |
|---|---|---|---|
| (field) | (format) | (example) | (reject / use default / allow empty) |

## Processing (conceptual level — non-engineer language)
1.
2.

## Output
| Field | Format | Example |
|---|---|---|
| (field) | (format) | (example) |

## Behavior on failure (silent failure is not allowed — Ch.12)
- On failure: [return error / retry N times / send alert]
- How will I know it failed: [log / alert channel]

## Modules that have a contract with this one
- [module name] — what is exchanged:


<!-- G-4: Stage Gate Verification (blank template) -->
# Gate Verification: Stage [N] → [N+1]
Verification date: YYYY-MM-DD | Rule: every item must be PASS. "Almost PASS" is FAIL.

## Gate 1 (Core → SaaS) baseline items
- [ ] Core processing: 5 consecutive successes with varied inputs
- [ ] Output quality: would I pay for this?
- [ ] I know the cost per processing run as a number (→ enter in Appendix D ③)
- [ ] Module inputs / outputs match the spec document exactly
- [ ] Freeze list for the next Stage written

## Gate 2 (SaaS → Monetization) baseline items
- [ ] Someone else can sign up and complete the core feature with no guidance
- [ ] User data isolation confirmed (User A's data not visible to User B)
- [ ] Full flow working in the deployment environment
- [ ] What the user sees when an error occurs has been checked
- [ ] API Freeze declared

## Project-specific items (add your own)
- [ ]

## Verdict: PASS / FAIL → list FAIL items and actions:


<!-- G-5: Cross-Verification Checklist (PASS/FAIL format — Ch.5.6) -->
# Cross-Verification: [feature / screen / design under review]
Verification date: YYYY-MM-DD

## Role 1 — Backend developer perspective
Question: Is this structure stable? Where does it break first when users grow?
- Issues found:
- Action: [applied / deferred + reason]

## Role 2 — UI/UX designer perspective
Question: Where will a first-time user get confused?
- Issues found:
- Action:

## Role 3 — Security reviewer perspective (Ch.14)
Question: Doubt everything, verify everything. Especially permissions, inputs, defaults.
- Issues found:
- Action:

## Role 4 — Cost manager perspective
Question: Where are API calls excessive? Where is money leaking?
- Issues found:
- Action:

## Functional verification (focus on failure paths — generate with AI)
- [ ] Happy path: ___ (PASS/FAIL)
- [ ] Failure path: ___ (PASS/FAIL)
- [ ] Failure path: ___ (PASS/FAIL)

## Overall verdict + next review date (3:1 rule — Ch.16):


<!-- G-5: Cross-Verification Checklist (PASS/FAIL format — Ch.5.6) -->
# Incident Postmortem: [one-line title]
Occurred: YYYY-MM-DD HH:MM – HH:MM (total: N minutes / hours)

- What happened (from the user's perspective):
- Why it happened (root cause):
- How we found out: [alert / found ourselves / user report] ← if user report, fix the monitoring gap first
- How we recovered: [rollback / restart / config fix]
- Prevention (at least one of): [add alert / add checklist item / automate]
- One line to add to the development rules doc (lesson from Ch.14):