Setup
Pre-Flight Setup System Files Chunking & Budget Model Selection Controlled Audit Rule
The 8 Steps
Step 1 — Blueprint Step 2 — Tech Stack Step 3 — Governance Step 3B — Chunking Step 4 — Build Loop Step 5 — QA Step 6 — Tracking Step 7 — Launch Step 8 — Maintenance
Appendix
Emergency Procedures Prompt Maintenance
Multi-AI Edition · Context-Aware · Single IDE
Created by Mayank Sankhala | Neozeus · Multi-AI Vibe Coding System

The Vibe Coding
Master Manual

A complete system for building production-grade apps with AI — smart context management, clean model handovers, human-readable documentation, and disaster recovery built in from day one.

8
Build Steps
25K
Session Budget
2
Audit Passes Max
1
IDE Always
Two Non-Negotiable Rules

Rule 1 — Controlled Audit: draft → audit → final is mandatory. Maximum 2 passes. Hard stop on loop detection. Never skip it, never exceed it.
Rule 2 — Token Efficiency: Every token outside the audit loop must earn its place. Load only what the current step actually needs. One model per session — never switch mid-chunk.

System Files — What Gets Created & When
SESSION_HEADER.md
Always Loaded · ~200 tokens
Current step, active chunk, context health, active model, audit passes used, what to load next.
SYSTEM_SUMMARY.md
Always Loaded · ~400 tokens
Compressed global memory. Stack, architecture, critical constraints. Replaces BLUEPRINT from Step 4 onwards.
WORK_INDEX.md
Always Loaded · ~600 tokens max
All chunks with PENDING/ACTIVE/COMPLETED status. Completed entries shrink to one line with archive pointer.
CONTRACT_INDEX.md
Code Sessions Only · ~80–100 tokens/fn
Function signatures, purpose, guarantees, danger zones, doc status. Replaces loading full code files.
BLUEPRINT.md
Steps 1–3 Only → Archived
Master PRD with Mermaid diagrams. Compressed into SYSTEM_SUMMARY after Step 3 then archived.
GOVERNANCE.md
Code Sessions · On-Demand
Security laws, naming conventions, the controlled audit mandate. Loaded only when writing code.
DESIGN.md
Frontend Sessions · On-Demand
Design tokens, breakpoints, component states. Loaded only for frontend code sessions.
PROCESS_LOG.md
Dynamic · Always Fresh
Step status and decisions. Compressed after each step — only last step kept in full detail.
RECOVERY_BIBLE.md
Human + AI Recovery · Never Runtime
Dual-format: human prose + AI parsing tags. Full reconstruction guide. Upload in a disaster to any AI.
PRODUCTION_HANDOVER.md
Step 7 Onwards
Server config, deployment scripts, live URL confirmation. Infrastructure recovery document.
deploy.sh
Step 7
One-command CI/CD. Run to push any future update to live server without downtime.
/archive/
Never Auto-Loaded
Completed chunk code, old step records. Referenced only when recovering or auditing past decisions.
PRE-FLIGHT
Setup Before Step 1
Complete everything here before opening any chat window.
💡
What is an IDE? A code editor with an AI chat window built in — like Microsoft Word, but for code. All prompts in this manual get pasted into that chat window. Your IDE is where all project files live. You switch AI models inside the IDE's chat settings without moving files anywhere.
  • Install Your IDE: Pick one.

    • Google Antigravity — antigravity.dev — Recommended if you have access.
    • Cursor — cursor.sh — Best for beginners, AI built in.
    • VS Code — code.visualstudio.com — Free, most popular globally.
  • Create Your Project Folder: One empty folder, named after your project (e.g. my-saas-app). Open it in your IDE via File → Open Folder. All markdown files will live here permanently.
  • Your AI Models — What You Have: You do not need to install anything extra. Inside your IDE's chat panel, you select which model to use for each session. Read the Model Selection Guide section before starting Step 1 to know which model to pick for each session.
  • Create /archive Subfolder: Inside your project folder, create a subfolder named archive. Completed chunks and old step records get stored here automatically.
  • Optional Pre-Fill: If you have rough notes, create files named BLUEPRINT.md or GOVERNANCE.md in your folder and paste notes inside. The AI will merge them safely at each step — nothing gets discarded.
🔴
The Golden Rule — One Step Per Chat Window, One Model Per Session: Each step gets its own fresh chat window. Within a step, stay in the same window. If you start a chunk with one AI model, finish that chunk with the same model — switching mid-chunk means the auditor doesn't share context with the builder, which introduces inconsistencies. The handover prompts at the end of each step generate everything needed to continue cleanly in the next window.
REFERENCE
System Files Reference
What each file is, when it's loaded, and why it exists

Mandatory Loading Order (Every New Chat Window)

📂 Always Load in This Exact Order — Consistency Enables Caching
  1. SESSION_HEADER.md — step, chunk, health, active model, audit passes used
  2. SYSTEM_SUMMARY.md — global memory: stack, architecture, constraints
  3. WORK_INDEX.md — all chunks and current status
  4. CONTRACT_INDEX.md — (code sessions only)
  5. GOVERNANCE.md — (code sessions only)
  6. DESIGN.md — (frontend sessions only)
  7. PROCESS_LOG.md — (when starting a new step — always read fresh)
SESSION_HEADER tells you which optional files to load. Trust it. If it says skip DESIGN.md this session — skip it.

Updated SESSION_HEADER.md — Format With Model Tracking

SESSION_HEADER.md — Example Format
CURRENT_STEP: 4 CURRENT_CHUNK: C07 — Payment Webhook Handler LAST_3_DECISIONS: 1. Idempotency key on webhook table prevents duplicate processing 2. Service layer handles all DB writes — routes never touch DB directly 3. bcrypt rounds set to 12 for password hashing STACK_SNAPSHOT: Next.js / Node.js / PostgreSQL / Hetzner VPS ACTIVE_MODEL: Claude Sonnet 4.6 Thinking AUDIT_PASSES_USED: 0 / 1 LOOP_CHECK_STATUS: CLEAN CONTEXT_HEALTH: GREEN | Estimated turns remaining: ~14 LOAD_THIS_SESSION: SESSION_HEADER, SYSTEM_SUMMARY, WORK_INDEX, CONTRACT_INDEX, GOVERNANCE.md DO_NOT_LOAD: BLUEPRINT.md (archived), DESIGN.md (backend chunk), PROCESS_LOG OPEN_DECISION: None — begin C07 immediately
SYSTEM
Chunking Strategy & Token Budget
How work is sized, ordered, and handed over between sessions
⚠️
Context degradation begins at ~30–50K tokens even in a 2M window. Target: keep all active session content under 25K tokens. This section explains exactly how.
📊 25K Session Token Budget Breakdown
Baseline (always loaded)
~1,200
Reference files (GOVERNANCE/DESIGN)
~4,000
CONTRACT_INDEX (full app ~40 fns)
~3,500
Active chunk + conversation
~16,000
Handover trigger at
~20,000

Chunk Sizes

SizeUse WhenToken Cost (Active)Test Type
MICROSingle function / single route. Free tier. High-security code.2,000–5,000Unit test
STANDARDOne complete feature (e.g. full auth system). Paid tier. Default.10,000–20,000Integration test
MACROFull domain (e.g. entire payment system). Paid + low complexity only.20,000–35,000Full feature test suite
💡
When in doubt use STANDARD. Conservative chunking costs one extra prompt. Broken architecture costs ten prompts to recover.

The 6 Chunking Rules

  • Rule 1 — Testability: A chunk is complete when you can run a pass/fail test in isolation. Can't test it alone — split it.
  • Rule 2 — No Orphan UI: Never build a frontend chunk without its backend either already COMPLETED or being built next.
  • Rule 3 — Safe Cutoff Architecture: A mid-generation token cutoff must not break previously working code. The previous chunk must still run cleanly even if this one is incomplete.
  • Rule 4 — Shared Components First: Any function called by more than one chunk gets its own dedicated chunk, built first. Built once, imported everywhere, never duplicated.
  • Rule 5 — Dependency Order: A chunk can only start when all its dependency chunks are COMPLETED and contracts are in CONTRACT_INDEX. No forward references.
  • Rule 6 — Large Files Chunked Vertically: A 2,000-line file stays one file on disk. In WORK_INDEX it becomes C09a, C09b, C09c — each covering a line range. File integrity preserved, chunk control achieved.
GUIDE
Model Selection Guide
Which AI to use, when, and why — for every human following this manual
💡
Why this matters: Different AI models have different strengths. Using the wrong model for the wrong task wastes money and gets worse results. This guide tells you exactly which model to select in your IDE's chat panel before starting each session. You don't need to understand the technical reasons — just follow the table.
The One Rule That Overrides Everything Else

Once you start a session with a model, finish that session with the same model. If you begin a chunk with Sonnet 4.6 Thinking and switch to Gemini Flash halfway through for the audit, the auditor doesn't have the full context that the builder had. This creates subtle inconsistencies that are extremely hard to debug. Start with one model. Finish with one model. Full stop.

Your Available Models — Mapped to Roles

ModelRoleUse ForCost
Claude Sonnet 4.6 Thinking DEFAULT Everything in the build loop (Steps 4–8). Your everyday workhorse. The thinking mode catches its own logical errors before surfacing them, which naturally reduces audit loop iterations. Mid
Claude Opus 4.6 Thinking ESCALATE Steps 1–3 architecture decisions. When stuck after 2 attempts on the same problem. When a decision affects 5+ future chunks. When audit loop triggers and you need a second opinion before OVERRIDE. Use consciously — not automatically. High
Gemini 3.1 Pro High LARGE CONTEXT Only when a chunk is too large for Sonnet's context capacity. This is rare if you chunk correctly. Otherwise avoid — use Sonnet as default. Mid-High
Gemini 3.1 Pro Low BACKUP If Sonnet quota is exhausted. Same quality tier, slightly different reasoning style. Fine for standard build loop chunks. Mid-Low
Gemini 3 Flash THROWAWAY Boilerplate config files, README drafts, quick factual questions. Never for actual business logic or security-sensitive code. Never for audit passes. Low
GPT-OSS 120B Medium RESEARCH Side research only. "How would you approach this differently?" Comparing approaches before committing. Not part of the build workflow. Never write production code with this. Low-Mid

Decision Flow — Which Model to Pick Right Now

🤖 Quick Decision Tree
OPUS 4.6 T Am I making an architecture decision in Steps 1–3? Am I genuinely stuck after 2 full attempts? → Use Opus.
SONNET 4.6 T Am I building a code chunk, running QA, doing maintenance, or deploying? → Use Sonnet. This is your answer 90% of the time.
GEMINI 3.1 HIGH Did Sonnet hit a context limit mid-chunk? → Switch to Gemini High for that specific session only.
FLASH Am I generating a config file, a README, or asking a quick factual question? → Flash is fine.
Galaxy.ai or similar research tools — use freely for exploring ideas, comparing approaches, or learning concepts. But never carry code written there directly into your project without running it through the standard Sonnet build loop and audit cycle.

Step-by-Step Model Assignments

StepRecommended ModelWhy
Step 1 — BlueprintOpus 4.6 ThinkingArchitecture decisions. Stronger structural reasoning catches problems before they're built. Wrong blueprint costs 10x more to fix later.
Step 2 — Tech StackOpus 4.6 ThinkingTechnology choices lock in permanently. Wrong stack = expensive rewrites. Worth the extra cost here.
Step 3 — GovernanceOpus 4.6 ThinkingSecurity rules and design systems are hard to change later. One-time cost, permanent benefit.
Step 3B — ChunkingSonnet 4.6 ThinkingExecution task. Mapping chunks from an agreed blueprint. Sonnet handles this well.
Steps 4–5 — Build + QASonnet 4.6 ThinkingHigh-volume repetitive execution. Thinking mode self-audits, reducing your loop risk.
Step 6 — TrackingSonnet 4.6 ThinkingStandard execution and decision task.
Step 7 — LaunchSonnet 4.6 ThinkingScript generation and deployment guide. Well within Sonnet's range.
Step 8 — MaintenanceSonnet 4.6 ThinkingStandard bug triage. Escalate to Opus only if the bug is deeply architectural.
⚠️
About Galaxy.ai and similar tools: These are great for research, learning, and exploring ideas before you commit to them. They are not part of the build workflow. If you use Galaxy.ai to research an approach, bring that knowledge back to your IDE session with Sonnet and implement it there through the standard build loop. Never skip the audit loop just because an external tool generated the code.
SYSTEM RULE
The Controlled Audit Rule
How to protect the audit loop from becoming a runaway token burn
🚨
Real documented risk: Developers have spent $2,800+ in a single short session because the draft → audit → fix → audit cycle never terminated. Each fix introduced a new issue. The AI kept rewriting. This section exists specifically to prevent that from happening to you.

The Hard Limits

Default Code
1 pass
90% of all chunks. Do not exceed this without thinking carefully.
Critical Code
2 passes max
Auth, payments, data deletion only. Requires explicit APPROVE SECOND PASS from you.
Absolute Maximum
Never 3+
3 or more passes means the chunk is too large. Abort and split it.

Loop Detection — Hard Stop Triggers

🛑
If any of these conditions appear, the AI must immediately stop and output the LOOP DETECTED block. No exceptions.

1. The same issue appears in the audit after it was supposedly fixed in the previous pass.
2. The fix introduces a new issue not present in the original draft.
3. The final output is more than 20% longer than the original draft (sign of unnecessary rewriting).
4. Two consecutive audit passes both find issues (the chunk is too large — split it).
5. The AI touches code in a file not created by this chunk without explicit permission.

The LOOP DETECTED Output Block

LOOP DETECTED — AI Must Output Exactly This When Any Trigger Fires
⛔ LOOP DETECTED — STOPPING TRIGGER: [which condition fired — e.g. "same issue reappeared after fix"] ISSUE TRACKER (this session): Pass 1 found: [list of issues] Pass 1 fixed: [what was fixed — verified or not] Pass 2 triggered by: [reason] New issues introduced: [list or NONE] LAST STABLE STATE: [Chunk ID] — archived at /archive/chunks/[ID]_record.md RECOMMENDED ACTION (choose one): REVERT — go back to last stable version and split this chunk smaller SPLIT — break this specific problem into a smaller sub-chunk and restart OVERRIDE — I understand the risk, I accept responsibility, continue with one more pass I will not write any more code until you type one of the three words above. OVERRIDE is logged permanently and cannot be undone.

Audit Scope Rule — This Is How the Loop Gets Started

Scope Creep is the Enemy

The audit must only examine code written in the current chunk. STABLE functions in CONTRACT_INDEX are not subject to re-audit unless a test explicitly fails against them. The moment an AI starts "noticing something" in an older file and touching it during an audit, the loop has begun. The audit scope rule prevents this at the source.

The Loop Detection System Prompt Addition

The following text is already embedded inside the Step 4 build prompt. It is reproduced here so you understand what the AI is being instructed to do before you paste any prompt.

Audit Rule — Embedded in Step 4 Prompt
CONTROLLED AUDIT RULE (non-negotiable): Before writing your audit, answer these 3 loop-check questions: 1. Have I already done 1 audit pass on this chunk this session? [YES → escalate to human before proceeding] 2. Will I touch any file not created by this chunk? [YES → stop, ask permission first] 3. Is my planned fix substantially larger than the issue it solves? [YES → consider splitting the chunk instead] AUDIT SCOPE: Only code written in this chunk. Do NOT audit STABLE entries in CONTRACT_INDEX. ISSUE TRACKER: Maintain a running list in this format: Pass [N] found: [issues] Pass [N] fixed: [what changed] [verified: YES/NO] New issues introduced by fix: [list or NONE] LOOP TRIGGERS — output LOOP DETECTED block immediately if: - Same issue reappears after a fix - Fix introduces a new issue - Final output >20% longer than original draft - Two consecutive passes both find problems - You are about to touch a file outside this chunk's scope DEFAULT: 1 audit pass. CRITICAL CODE (auth/payments/deletion): max 2 passes — human must type APPROVE SECOND PASS. NEVER: 3 or more passes under any circumstances.
STEP 01
The Planning Phase
Blueprint · UX Maps · Unit Economics
Chat Fresh Window
Model Opus 4.6 Thinking
Files Loaded None yet
🤖 Model Guidance — Step 1
OPUS 4.6 THINKING Use this for the entire Step 1 session. Blueprint decisions are hard to reverse — wrong choices here cascade through every chunk downstream. The extra reasoning depth is worth it.
Why not Sonnet here? Sonnet is excellent at execution. But at this stage you're making product decisions — what to build, what to skip, where to save costs. Opus catches structural problems in the idea itself before a single file is created.
What This Step Does

Extracts your rough idea, forces cost-saving analysis before building anything, creates BLUEPRINT.md, and generates the initial PROCESS_LOG.md and SESSION_HEADER.md.

Files Created
BLUEPRINT.md PROCESS_LOG.md SESSION_HEADER.md
Part A
Discussion — Extract & Agree on Structure
📋
Action

Open a fresh chat with Opus 4.6 Thinking. Replace everything inside [square brackets] with your actual content. Delete the brackets too. Send and answer the AI's 3 questions before Part B.

PROMPT 1A — PROJECT KICKOFF & ARCHITECTURE

Prompt 1A · Fill In the Brackets Before Sending
You are an elite Product Manager and a Fractional CTO. I have an idea for a software project. My rough idea: [Explain what your app does in plain English. Example: "A Kundli PDF generator where users log in, pay, and download their astrological chart."] Target User: [Who will use this? Example: "Astrology enthusiasts who want instant results without visiting a physical astrologer."] Before we finalise anything, evaluate the Unit Economics: 1. API vs. In-House Logic: Where can we replace recurring API costs with local logic, math, or simple if/else statements for tasks that do not require AI? 2. AI vs. Standard Code: Where can we use static databases or pre-written formulas instead of expensive LLM tokens? Next, ask me exactly 3 questions to clarify core functionality and budget goals. Once I answer, we will collaboratively define: - User Flow Diagram: Step-by-step screens (e.g. Landing → Login → Dashboard → Payment → Result) - User Journey Map: User stages and emotional expectations at each step - Site Map / App Flow: The exact hierarchical structure of all pages Anti-Assumption Rule: If any requirement is ambiguous, you are strictly forbidden from guessing. Pause and ask me before proceeding. Hard Pause: Do not generate any documents yet. Ask your 3 questions and strictly WAIT for my response.
💡
The AI will ask 3 questions. Answer them fully. Discuss back and forth until you both agree on the User Flow and Site Map. Only then move to Part B.
Part B
Generate BLUEPRINT.md

PROMPT 1B — GENERATE MASTER BLUEPRINT

Prompt 1B · Paste As-Is in Same Chat Window
We have now agreed on the features, cost-saving architecture, User Flows, and Site Map. Compile all of this into a single master Markdown document — the absolute Source of Truth for all AI agents that will build this app. Pre-Filled Data Merge: Check for existing BLUEPRINT.md. Scan for conflicts. Ask for clarification if conflicted. Otherwise merge my notes — do not discard any pre-filled content. Format Requirements: 1. Clear hierarchical markdown headings 2. Full PRD covering Core Features, Target User, and all edge cases discussed 3. Complete Unit Economics rules — the AI coder must know exactly where to use in-house logic 4. No conversational filler — raw markdown only Diagrams (Mandatory — no ASCII art): Strict Mermaid.js syntax in markdown code blocks for ALL three diagrams: - User Flow Diagram: ```mermaid\nflowchart TD\n...``` - User Journey Map: ```mermaid\njourney\n...``` - Site Map / App Flow: ```mermaid\nflowchart LR\n...``` or ```mermaid\nmindmap\n...``` Create or overwrite BLUEPRINT.md in the project workspace with this exact content.
Part C
Generate PROCESS_LOG.md & SESSION_HEADER.md

PROMPT 1C — GENERATE PROCESS_LOG + SESSION_HEADER

Prompt 1C · Paste As-Is After BLUEPRINT.md Is Verified
Generate two files. FILE 1 — PROCESS_LOG.md: PROJECT OVERVIEW: 3-sentence summary of what the app does, who it's for, top 2 cost-saving decisions. STEP STATUS: STEP 1 — Planning and Blueprint: COMPLETE STEP 2 — Tech Stack: NOT STARTED STEP 3 — Governance and Design: NOT STARTED STEP 3B — Chunking Session: NOT STARTED STEP 4 — Build Loop: NOT STARTED STEP 5 — QA: NOT STARTED STEP 6 — Tracking: NOT STARTED STEP 7 — Launch: NOT STARTED STEP 8 — Maintenance: NOT STARTED DECISIONS MADE: Every concrete decision made. Format: DECISION: [what was decided] REASON: [why in one sentence] Include at minimum: app type (public or internal), all Unit Economics decisions. FILES IN PROJECT FOLDER: Every file with one-line description. FILE 2 — SESSION_HEADER.md: CURRENT_STEP: 2 CURRENT_CHUNK: N/A — Planning phase LAST_3_DECISIONS: [top 3 from DECISIONS MADE] STACK_SNAPSHOT: TBD — decided in Step 2 ACTIVE_MODEL: Claude Opus 4.6 Thinking AUDIT_PASSES_USED: N/A LOOP_CHECK_STATUS: N/A CONTEXT_HEALTH: GREEN LOAD_NEXT_SESSION: PROCESS_LOG.md, BLUEPRINT.md DO_NOT_LOAD: GOVERNANCE.md (not created yet), DESIGN.md (not created yet) OPEN_DECISION: None — Step 1 complete Output raw markdown only. Create both files in the project workspace.
Verify Before Closing This Chat
  • BLUEPRINT.md exists — open it, check your idea is captured correctly, all 3 Mermaid diagrams present
  • PROCESS_LOG.md exists — Step 1 shows COMPLETE
  • SESSION_HEADER.md exists — ACTIVE_MODEL shows Opus 4.6 Thinking, LOAD_NEXT_SESSION includes BLUEPRINT.md

HANDOVER 1 — Run Before Closing

🔁 Handover · Run After All Parts Verified
Step 1 is complete. Update SESSION_HEADER.md to reflect the handover to Step 2: CURRENT_STEP: 2 CURRENT_CHUNK: N/A LAST_3_DECISIONS: [top 3 decisions from this session] STACK_SNAPSHOT: TBD — Step 2 decides this ACTIVE_MODEL: Claude Opus 4.6 Thinking AUDIT_PASSES_USED: N/A LOOP_CHECK_STATUS: N/A CONTEXT_HEALTH: GREEN LOAD_NEXT_SESSION: SESSION_HEADER, BLUEPRINT.md, PROCESS_LOG.md DO_NOT_LOAD: GOVERNANCE.md, DESIGN.md, CONTRACT_INDEX (none exist yet) OPEN_DECISION: None Output raw markdown. Overwrite SESSION_HEADER.md.
✅
Step 1 complete. Close this chat. Open a fresh one for Step 2. Load what SESSION_HEADER tells you to load.
STEP 02
Technology, Infrastructure & Cost Roadmap
Choosing How to Build — The CTO Analysis
Chat Fresh Window
Model Opus 4.6 Thinking
Load SESSION_HEADER → BLUEPRINT → PROCESS_LOG
🤖 Model Guidance — Step 2
OPUS 4.6 THINKING Technology choices are permanent. Wrong database = rewriting all queries. Wrong hosting = expensive migration. Opus catches these structural risks during evaluation, not after you've built 8 chunks on top of the wrong foundation.
This is the last step you use Opus. After Step 3, Sonnet 4.6 Thinking becomes your default for all build work. The Opus investment in Steps 1–3 pays dividends across every chunk in Steps 4–8.
📂 Load In This Order
  1. SESSION_HEADER.md
  2. BLUEPRINT.md
  3. PROCESS_LOG.md
📋
Action

Open a fresh chat with Opus 4.6 Thinking. Load files above. Then paste the Chat Opening Message first — before the main prompt.

CHAT OPENING MESSAGE — Paste First in Every New Window

Chat Opening · Always Paste Before Any Step Prompt
I am continuing a software project. Read the files I have provided in this priority order: 1. SESSION_HEADER.md — current step, active model, what to load, context health 2. BLUEPRINT.md — project source of truth 3. PROCESS_LOG.md — decisions made so far After reading, confirm: - Which step we are on - What the last completed action was - What you are about to do next - Which model you are running as (confirm from SESSION_HEADER) Do not begin any work until you have confirmed all four points.

PROMPT 2 — CTO TECH STACK & COST ROADMAP

Prompt 2 · Paste After Chat Opening Confirmed
Act as a financially strict CTO and Lead DevOps Architect. Review BLUEPRINT.md. Economy, token efficiency, and independent scaling are top priorities. SECTION 1 — CORE CONSTRAINTS Stack MUST meet all three: - Massive community support (AI models have deep training data, can write it flawlessly) - Highly secure by default - Easy for an AI to maintain — no experimental or obscure frameworks SECTION 2 — PROACTIVE COST-SAVING Before presenting options, identify any Blueprint features that could use in-house logic instead of a paid API. Flag each with an estimated monthly saving. SECTION 3 — COST-OPTIMISATION COMPARISON TABLE Markdown table: Premium/Managed vs Cost-Saving/Self-Hosted. Columns: Component | Premium Option (Pros, Cons, Est. Cost) | Cost-Saving Option (Pros, Cons, Est. Cost) Cover: Database, Authentication, Hosting. SECTION 4 — DATABASE ARCHITECTURE Most robust, cost-effective database for our project. Flag where managed database services are a cost trap. SECTION 5 — PROGRAMMING LANGUAGE AND TOKEN ECONOMY Select languages based on AI Token Efficiency — since AI writes and maintains this code, choose languages concise enough to minimise LLM token costs over the project lifetime. SECTION 6 — INFRASTRUCTURE SCALING PHASES Phase 1 — MVP: Specific VPS providers with approximate monthly pricing (Hetzner, DigitalOcean, Linode) Phase 2 — Growth: When to transition to bare metal Phase 3 — Enterprise: When to introduce load balancers, Docker, Kubernetes SECTION 7 — DEVOPS AND HUMAN CAPITAL At what exact traffic volume or server count does the business need a full-time human DevOps engineer? Give a concrete number. Anti-Assumption Rule: If anything is ambiguous, stop and ask me before proceeding. Hard Pause: Ask 2 clarifying questions — one about expected year-one traffic, one about initial infrastructure budget. Do NOT proceed until I answer and confirm selections from the Comparison Table.
⏸️
Hard Pause — Required

Answer the AI's 2 questions. Then review the comparison table and confirm your technology choices. These lock in your entire tech stack. Do not proceed to the handover until you have explicitly confirmed your selections.

HANDOVER 2 — Run Before Closing

🔁 Handover · Run After Tech Decisions Confirmed
Step 2 is complete. Generate these updates: UPDATE 1 — PROCESS_LOG.md: Mark STEP 2 as COMPLETE. Add all technology decisions to DECISIONS MADE: DECISION: [frontend language/framework] REASON: [one sentence] DECISION: [backend language/framework] REASON: [one sentence] DECISION: [database chosen] REASON: [one sentence] DECISION: [hosting provider] REASON: [one sentence] DECISION: [any cost-saving choices from table] REASON: [one sentence] UPDATE 2 — Create initial SYSTEM_SUMMARY.md stub: Fill in everything decided so far. Leave ARCHITECTURE as "TBD — defined in Step 3". Strict limit: under 400 tokens total. UPDATE 3 — SESSION_HEADER.md (overwrite): CURRENT_STEP: 3 CURRENT_CHUNK: N/A — Governance phase LAST_3_DECISIONS: [top 3 tech decisions] STACK_SNAPSHOT: [frontend] / [backend] / [database] / [hosting] ACTIVE_MODEL: Claude Opus 4.6 Thinking AUDIT_PASSES_USED: N/A LOOP_CHECK_STATUS: N/A CONTEXT_HEALTH: GREEN LOAD_NEXT_SESSION: SESSION_HEADER, SYSTEM_SUMMARY, BLUEPRINT.md, PROCESS_LOG DO_NOT_LOAD: CONTRACT_INDEX (not yet), GOVERNANCE.md (Step 3 creates it) OPEN_DECISION: None — Step 2 complete Output raw markdown. Overwrite existing files.
Verify Before Closing
  • SESSION_HEADER.md updated — CURRENT_STEP shows 3, STACK_SNAPSHOT filled in
  • PROCESS_LOG.md updated — Step 2 COMPLETE with all tech decisions listed
  • SYSTEM_SUMMARY.md created — even if partial
STEP 03
Governance, Design & Cache Setup
Two Permanent Rulebooks — Security Law + Visual Law
Chat Fresh Window
Model Opus 4.6 Thinking
Load SESSION_HEADER → SYSTEM_SUMMARY → BLUEPRINT → PROCESS_LOG
🤖 Model Guidance — Step 3 (Final Opus Session)
OPUS 4.6 THINKING Last session with Opus. GOVERNANCE.md and DESIGN.md are your project's constitution — every AI agent in every future session must obey them. Getting them wrong means correcting 15+ chunks downstream. Worth Opus here.
After this step: Switch to Sonnet 4.6 Thinking for all remaining steps. Update SESSION_HEADER ACTIVE_MODEL to reflect this in the handover.
📂 Load In This Order
  1. SESSION_HEADER.md
  2. SYSTEM_SUMMARY.md
  3. BLUEPRINT.md
  4. PROCESS_LOG.md
After Step 3, BLUEPRINT.md is archived. SYSTEM_SUMMARY replaces it from Step 4 onwards.
Part A
Generate GOVERNANCE.md

PROMPT 3A — GENERATE GOVERNANCE.md

Prompt 3A · Paste After Chat Opening Confirmed
Act as a Principal Software Engineer and Chief Security Officer. Read BLUEPRINT.md and all tech stack decisions in PROCESS_LOG.md. Pre-Filled Data Merge: Check for existing GOVERNANCE.md. Merge safely. Ask for clarification on conflicts. Generate GOVERNANCE.md with these sections: SECTION 1 — UNIVERSAL ENGINEERING STANDARDS - Zero-Trust Security: Validate and sanitise all user inputs server-side. Never trust client-side data. Fail securely — deny by default. - Secrets Management: NEVER hardcode credentials or API keys. Always use .env files. .env MUST be in .gitignore. - DRY and SOLID: No repeated logic. Every function has a single clear responsibility. - Graceful Error Handling: No silent failures. Errors caught, logged server-side, return clean user-facing messages without leaking stack traces or DB structure. SECTION 2 — CONTEXT-AWARE LOADING LAWS Determine app type from Blueprint, then enforce: IF PUBLIC / CONVERSION APP: Core Web Vitals (LCP, CLS, FID) are first-class concerns. Defer non-critical scripts. Minimise initial JS bundle. IF INTERNAL / CRM APP: Skeleton loaders for all data-heavy views. Lazy loading and pagination for large tables. UNIVERSAL: Dynamic unique title tags on every page — mandatory. SECTION 3 — TECH-STACK SPECIFIC RULES (based on stack in PROCESS_LOG) - Naming Conventions: Enforce industry-standard for our exact stack. Files in lowercase-kebab-case (prevents Linux server case-sensitivity crashes). Variables in camelCase. Classes in PascalCase. - Database Query Rules: Parameterised queries or ORM only. Raw string concatenation in SQL is strictly forbidden. SECTION 4 — OPTIMISATION AND MODULARITY - Single Responsibility: If a function does more than one logical task, refactor and split it. - Comment Standard — WHY over WHAT: Comments explain why the code exists from a business perspective, not what it does. BAD: // adds 1 to x GOOD: // increments user count for API billing threshold check SECTION 5 — THE CONTROLLED AUDIT MANDATE (NON-NEGOTIABLE) ALL code generation in this project MUST use this exact loop: : Write the initial complete code. : Critique the draft. AUDIT SCOPE: Only code written in this chunk. Do NOT audit STABLE entries in CONTRACT_INDEX. Before auditing, answer: Have I already done 1 pass this session? Will I touch files outside this chunk? Is my planned fix larger than the issue? LOOP TRIGGERS — output LOOP DETECTED block if: same issue reappears, fix introduces new issue, output >20% longer than draft, two consecutive passes both find problems. : Output corrected code only after audit is complete. DEFAULT: 1 audit pass. CRITICAL CODE (auth/payments/deletion): max 2 passes, requires human to type APPROVE SECOND PASS. NEVER 3+ passes. Anti-Assumption Rule: If anything is ambiguous, stop and ask me. Output ONLY raw markdown. Create or overwrite GOVERNANCE.md.
Part B
Generate DESIGN.md

PROMPT 3B — GENERATE DESIGN.md

Prompt 3B · Paste in Same Chat Window After 3A Is Done
Act as Lead UI/UX Designer and Frontend Architect. Read BLUEPRINT.md — is this a Public/Conversion App or Internal/CRM App? Pre-Filled Data Merge: Check for existing DESIGN.md. Merge safely. Generate DESIGN.md: SECTION 1 — UNIVERSAL UX LAWS - Cognitive Load Reduction: Clear visual separation. Every page has a single dominant purpose identifiable within 3 seconds. - Jakob's Law: Industry-standard layouts. Do not reinvent UI patterns without a documented reason. SECTION 2 — CONTEXT-SPECIFIC RULES IF PUBLIC / CONVERSION APP: - Sticky CTA buttons visible as users scroll - Define and enforce maximum click-path from landing to conversion - Above-the-fold hero with single clear value proposition - JSON-LD schema markup on all public pages. No page without unique meta description. IF INTERNAL / CRM APP: - Optimise for data density — tables show maximum useful info per screen - Keyboard shortcut support for frequently repeated actions - Explicitly IGNORE SEO — wastes time and tokens on internal tools SECTION 3 — THE GRID LAW Exactly 4 rigid CSS breakpoints — the ONLY breakpoints allowed anywhere in the codebase: 320px (mobile), 768px (tablet), 1024px (laptop), 1440px (desktop) All icons/logos: SVG only. No raster icons. All raster images: 2x resolution minimum. SECTION 4 — PROGRAMMATIC UI SPECIFICATION Define exact design tokens for all CSS/styling: - Colour Palette: Hex codes for Primary, Secondary, Background (light+dark), Body Text, Muted Text, Error, Success, Warning - Typography Scale: All font sizes in rem. Define: display, h1, h2, h3, body, small/caption - Component States: For every interactive component (buttons, inputs, links, dropdowns) define ALL 5 states: Default, Hover, Active/Pressed, Disabled, Loading Output ONLY raw markdown. Create or overwrite DESIGN.md.
Part C
Finalise SYSTEM_SUMMARY + Archive BLUEPRINT

PROMPT 3C — FINALISE SYSTEM_SUMMARY + ARCHIVE BLUEPRINT

Prompt 3C · Paste After Both 3A and 3B Are Done
Perform two tasks: TASK 1 — Finalise SYSTEM_SUMMARY.md: Overwrite with complete version including: - APP: [name — one sentence description] - STACK: [frontend / backend / database / hosting] - ARCHITECTURE: [2–3 sentences — layer structure and data flow] - AUTH_MODEL: [2 sentences on auth approach] - CRITICAL_CONSTRAINTS: [5 bullet points — non-negotiable rules from GOVERNANCE.md] - COST_RULES: [bullet points — in-house logic decisions from Unit Economics] Strict limit: entire file under 400 tokens. Compress ruthlessly. TASK 2 — Archive BLUEPRINT.md: Move BLUEPRINT.md to /archive/step1_blueprint_archive.md. Create a stub BLUEPRINT.md in root: "BLUEPRINT ARCHIVED — See /archive/step1_blueprint_archive.md All key decisions are captured in SYSTEM_SUMMARY.md. Do not load BLUEPRINT.md into AI sessions from Step 4 onwards." Output raw markdown for both files. Confirm when done.

HANDOVER 3 — Run Before Closing

🔁 Handover · Run After All Three Parts Done — Model Switches Here
Step 3 is complete. Generate these updates. Note: from Step 3B onwards, the ACTIVE_MODEL changes to Claude Sonnet 4.6 Thinking. UPDATE 1 — PROCESS_LOG.md: Mark STEP 3 as COMPLETE. Add decisions: governance rules enforced, app type confirmed, design tokens defined, BLUEPRINT archived, SYSTEM_SUMMARY active. Update FILES IN PROJECT FOLDER: include GOVERNANCE.md, DESIGN.md, SYSTEM_SUMMARY.md, /archive/step1_blueprint_archive.md. UPDATE 2 — SESSION_HEADER.md (overwrite): CURRENT_STEP: 3B CURRENT_CHUNK: N/A — Chunking session next LAST_3_DECISIONS: [top 3 governance/design decisions] STACK_SNAPSHOT: [full stack] ACTIVE_MODEL: Claude Sonnet 4.6 Thinking ← MODEL SWITCHES HERE AUDIT_PASSES_USED: N/A LOOP_CHECK_STATUS: N/A CONTEXT_HEALTH: GREEN LOAD_NEXT_SESSION: SESSION_HEADER, SYSTEM_SUMMARY, PROCESS_LOG DO_NOT_LOAD: BLUEPRINT.md (archived), GOVERNANCE.md (not needed for chunking), DESIGN.md (not needed for chunking) OPEN_DECISION: None — generate WORK_INDEX in Step 3B Output raw markdown. Overwrite existing files.
Verify Before Closing
  • GOVERNANCE.md — check that Section 5 contains the Controlled Audit Mandate with LOOP DETECTED block
  • DESIGN.md — check all 5 component states are defined
  • SYSTEM_SUMMARY.md — check it's under 400 tokens
  • /archive/step1_blueprint_archive.md exists
  • SESSION_HEADER.md — ACTIVE_MODEL now shows Claude Sonnet 4.6 Thinking
STEP 3B
The Chunking Session
Map the entire build before writing a single line of code
Chat Fresh Window
Model Sonnet 4.6 Thinking
Load SESSION_HEADER → SYSTEM_SUMMARY → PROCESS_LOG + archived BLUEPRINT
🤖 Model Guidance — Step 3B onwards (Sonnet is now default)
SONNET 4.6 THINKING You are now in execution mode for the rest of the project. Sonnet 4.6 Thinking is your default for all sessions from here. The thinking mode means it self-checks logic before surfacing output — this naturally reduces audit loop iterations and protects your token budget.
Only escalate to Opus if you hit a problem that genuinely requires deeper architectural reasoning — e.g. a structural flaw in the chunk map that affects 10+ future chunks. For anything else: Sonnet.
📂 Load In This Order
  1. SESSION_HEADER.md
  2. SYSTEM_SUMMARY.md
  3. PROCESS_LOG.md
  4. /archive/step1_blueprint_archive.md — this session only, needed for site map parsing

PROMPT 3B-1 — TIER CHECK

Prompt 3B-1 · Send Before Chunking Starts
Before we generate the chunk map, I need to tell you my tier so you can size chunks correctly. My tier: [FREE or PAID] FREE TIER → MICRO chunks: one function or one route per chunk, completeable in one AI response PAID TIER → STANDARD chunks: one complete feature per chunk (e.g. entire auth system as one chunk) Rule: When in doubt, default to MICRO. Conservative chunking costs one extra prompt. Broken architecture costs ten. Confirm you have received this. Do not start generating WORK_INDEX yet.

PROMPT 3B-2 — GENERATE WORK_INDEX + CONTRACT_INDEX + RECOVERY_BIBLE SKELETON

Prompt 3B-2 · Paste After Tier Confirmed
Act as Lead Application Developer. Read the archived BLUEPRINT site map and user flow diagrams carefully. Cross-reference SYSTEM_SUMMARY.md for tech stack and PROCESS_LOG.md for all decisions. Generate three files: FILE 1 — WORK_INDEX.md: For every chunk: [CHUNK_ID] [Chunk Name] | STATUS: PENDING PRIMARY_CONCERN: Backend / Frontend / Security / DevOps / Database FILES_CREATES_OR_MODIFIES: [file paths] DEPENDS_ON: [chunk IDs or None] CONTRACTS_NEEDED: [function names from CONTRACT_INDEX this chunk calls, or None] ESTIMATED_SIZE: MICRO / STANDARD / MACRO TEST_TYPE: [unit test / integration test / manual check] Also include: INTERRELATIONSHIP_FLAGS: Any component reached from multiple entry points. Format: SHARED: [name] | ENTRY_POINTS: [list] | ASSIGNED_TO: [chunk ID] Rule: Build once, import everywhere. Never duplicate. CURRENT_ACTIVE: [first chunk ID and name] MAINTENANCE_LOG: (empty — populated in Step 8) FILE 2 — CONTRACT_INDEX.md: Empty file with header only: # CONTRACT_INDEX # Format: ## [ChunkID] | [filepath] | [function name] | STATUS: PENDING/ACTIVE/STABLE # Append entries here as functions are built and stabilised # Never delete entries — update STATUS field only FILE 3 — RECOVERY_BIBLE.md skeleton: All section headers with AI parsing tags. Leave content as [TBD — populated during build loop]. Include at minimum: - RECOVERY_ENTRY_POINT (with full AI_INSTRUCTION filled in — include the 5-step recovery protocol and MODE A/B/C options) - ARCHITECTURE_OVERVIEW (TBD) - FILE_MANIFEST (TBD) - FUNCTION_CONTRACTS (TBD) - DECISION_LOG (TBD) - DEPENDENCY_MAP (TBD) - DATABASE_SCHEMA (TBD) - RECONSTRUCTION_CHECKLIST (TBD) Anti-Assumption Rule: If the Site Map is ambiguous about any page's entry points, stop and ask me. Hard Pause: Present chunk list for review before finalising WORK_INDEX. Ask: "Does this order look correct? Should any chunks be split, merged, or reordered?" Wait for my response.
⏸️
Review the Chunk Map Before Confirming

Check: Are shared components given their own dedicated chunk? Are dependency orders correct? Can each chunk be tested in isolation? Tell the AI any changes before it finalises WORK_INDEX.

HANDOVER 3B — Run Before Closing

🔁 Handover · Run After WORK_INDEX Is Finalised and Reviewed
Step 3B is complete. Generate these updates: UPDATE 1 — PROCESS_LOG.md: Mark STEP 3B as COMPLETE. Add: DECISION: Chunk map finalised with [N] total chunks. Chunk size: [MICRO/STANDARD]. Add: DECISION: CONTRACT_INDEX.md created (empty, ready for entries). Add: DECISION: RECOVERY_BIBLE.md skeleton created. Update FILES IN PROJECT FOLDER to include WORK_INDEX.md, CONTRACT_INDEX.md, RECOVERY_BIBLE.md. UPDATE 2 — SESSION_HEADER.md (overwrite): CURRENT_STEP: 4 CURRENT_CHUNK: [first chunk ID and name from WORK_INDEX] LAST_3_DECISIONS: [top 3 from chunking session] STACK_SNAPSHOT: [full stack] ACTIVE_MODEL: Claude Sonnet 4.6 Thinking AUDIT_PASSES_USED: 0 / 1 LOOP_CHECK_STATUS: CLEAN CONTEXT_HEALTH: GREEN LOAD_NEXT_SESSION: SESSION_HEADER, SYSTEM_SUMMARY, WORK_INDEX, CONTRACT_INDEX, GOVERNANCE.md DO_NOT_LOAD: BLUEPRINT.md (archived), DESIGN.md (only if first chunk has frontend), PROCESS_LOG OPEN_DECISION: None — begin [first chunk ID] immediately Output raw markdown. Overwrite existing files.
Verify Before Closing
  • WORK_INDEX.md — every chunk has ID, status, dependencies, test type
  • CONTRACT_INDEX.md — created, even if empty
  • RECOVERY_BIBLE.md — all section headers present with AI tags
  • SESSION_HEADER.md — CURRENT_STEP: 4, CURRENT_CHUNK set to first chunk, ACTIVE_MODEL: Sonnet 4.6 Thinking
STEP 04
The Autonomous Build Loop
Repeating Engine — One Chunk Per Session
Chat Fresh Window Per Chunk
Model Sonnet 4.6 Thinking (default)
Escalate Opus if stuck after 2 attempts
🤖 Model Guidance — Step 4 Build Loop (Read Every Time)
SONNET 4.6 T Default for all chunks. Start every session with Sonnet. Finish that session with Sonnet — never switch mid-chunk.
OPUS 4.6 T Escalate only if: stuck after 2 full attempts on the same problem, or the chunk reveals a structural flaw affecting 5+ future chunks. Open a new window and switch models — don't switch mid-chunk.
GEMINI 3.1 HIGH Only if Sonnet hits a context limit mid-chunk. Use for that specific session only, then return to Sonnet.
Switching models mid-chunk means the auditor doesn't share context with the builder. This introduces subtle inconsistencies that are hard to debug. If you must switch: run the handover prompt first, open a new window, load context fresh, then continue with the new model.
AUDIT BUDGET
Default code: 1 pass
Critical (auth/payments/deletion): 2 passes max — type APPROVE SECOND PASS
3+ passes: NEVER — abort and split the chunk
🔴
One chunk per chat session. When context health hits AMBER, complete the current function and run the handover prompt immediately. Do not start the next function.
📂 Load In This Order (Every Build Session)
  1. SESSION_HEADER.md — active chunk, model, audit passes used
  2. SYSTEM_SUMMARY.md
  3. WORK_INDEX.md
  4. CONTRACT_INDEX.md
  5. GOVERNANCE.md
  6. DESIGN.md — only if active chunk has frontend components
💡
Paste the prompt below once per chunk. The AI reads WORK_INDEX to know what to build. The controlled audit rule is already embedded in the prompt — it will self-enforce the loop limits and output a LOOP DETECTED block if triggers fire.

PROMPT 4 — THE BUILD & AUDIT ENGINE (Reuse Without Modification)

Prompt 4 · Paste Once Per Chunk — Never Modify This Prompt
MODE: Implementation SCOPE RULE: Only the ACTIVE chunk in WORK_INDEX is authoritative. Do not process COMPLETED or PENDING chunks. MANDATORY FIRST ACTION: Read WORK_INDEX.md. Identify the ACTIVE chunk. State: "I am now building [Chunk ID] — [Chunk Name]" List sub-tasks for this chunk before writing a single line of code. CONTRACT CHECK: Check CONTRACT_INDEX for any functions this chunk will call. Verify correct signatures. If a required function is not in CONTRACT_INDEX — stop and ask me before proceeding. CONTROLLED AUDIT RULE (embedded — non-negotiable): Before writing your audit, answer these 3 questions: 1. Have I already done 1 audit pass on this chunk this session? [YES → output LOOP DETECTED, ask for APPROVE SECOND PASS] 2. Will I touch any file not created by this chunk? [YES → stop, ask permission first] 3. Is my planned fix substantially larger than the issue it solves? [YES → split the chunk instead] AUDIT SCOPE: Only code written in this chunk. STABLE entries in CONTRACT_INDEX are never re-audited. ISSUE TRACKER: Maintain running list: Pass [N] found: [issues] | fixed: [what changed] | new issues: [list or NONE] LOOP TRIGGERS: Output LOOP DETECTED block immediately if: same issue reappears, fix introduces new issue, output >20% longer than draft, two consecutive passes both find problems. DEFAULT: 1 audit pass. CRITICAL CODE: max 2 — human must type APPROVE SECOND PASS. NEVER 3+. EXECUTION CYCLE: Write complete, functional code for this specific chunk. Follow all rules in GOVERNANCE.md and SYSTEM_SUMMARY.md exactly. If frontend chunk, follow DESIGN.md exactly. Ruthlessly critique draft against GOVERNANCE.md and DESIGN.md. Check: security flaws, DRY violations, missing loading states, broken UX laws, broken route connections, silent error swallowing, CONTRACT_INDEX signature mismatches. Run through the 3 loop-check questions first. If any is YES — stop before auditing. Fix all issues found. Output final, clean, heavily-commented code. Tell me exactly which files to create and exactly where to paste each piece. Comments explain WHY the code exists (business reason), not WHAT it does mechanically. For every new function/class/component, append to CONTRACT_INDEX.md: ## [ChunkID] | [filepath] | [function name] | STATUS: ACTIVE SIGNATURE: [full typed signature] PURPOSE: [one sentence — business reason] EXPECTS: [inputs and requirements] GUARANTEES: [what it returns; what it never does] CALLS: [other functions with chunk IDs] CALLED_BY: [what will call this] SIDE_EFFECTS: [DB writes, logs, external calls] DANGER_ZONES: [non-obvious couplings] DOC_READY: NO Append only. Never rewrite existing entries. For every function created, append to RECOVERY_BIBLE.md under FILE_MANIFEST: FILE: [filepath] WHAT IT DOES: [plain English] WHY IT EXISTS: [business reason] KEY FUNCTIONS: [each with 2-sentence plain English explanation] TOUCHES: [reads from] TOUCHED_BY: [what calls it] DANGER_ZONES: [non-obvious couplings] Append to RECOVERY_BIBLE.md under DECISION_LOG: [ChunkID — Date] [Architectural decision] Reason: [plain English — one sentence] Trade-off accepted: [what was given up] In WORK_INDEX.md: 1. Move this chunk from ACTIVE to COMPLETED 2. Under completed entry add: ARCHIVED: /archive/chunks/[ChunkID]_record.md 3. Mark next chunk as ACTIVE 4. Shrink COMPLETED entry to one line: [ChunkID] [Name] | COMPLETED → /archive/chunks/[ChunkID]_record.md Estimate context health. Update SESSION_HEADER.md CONTEXT_HEALTH field. Update AUDIT_PASSES_USED to reflect actual passes used this chunk. If AMBER: state clearly before state_update, recommend handover after this chunk. If RED: state clearly, recommend handover immediately. Execute the cycle now.
🔷
Token Limit Failsafe

If AI stops mid-generation: type exactly Continue generation from exactly where you stopped. — nothing else. Do not rephrase. Do not add text.

HANDOVER 4 — Per-Chunk Session Close (Run After Each QA Pass)

🔁 Handover · Run After Step 5 QA Passes for This Chunk
Chunk [CHUNK_ID] is complete and QA has passed. Generate SESSION_CLOSE REPORT: SESSION_CLOSE REPORT: CHUNK_COMPLETED: [ID] — [Name] FILES_CREATED_OR_MODIFIED: [list with full paths] NEW_CONTRACTS_ADDED: [function names added to CONTRACT_INDEX] CONTRACTS_CHANGED_TO_STABLE: [functions moved from ACTIVE to STABLE] AUDIT_PASSES_USED: [N of max allowed] LOOP_DETECTED_THIS_SESSION: [YES / NO — if YES, what triggered it] RECOVERY_BIBLE_UPDATED: [YES / NO] WORK_INDEX_UPDATED: [YES / NO] OPEN_DECISION: [unresolved question or None] NEXT_CHUNK: [ID] — [Name] — DEPENDS_ON: [IDs] Now update SESSION_HEADER.md completely: CURRENT_STEP: 4 CURRENT_CHUNK: [next chunk ID and name] LAST_3_DECISIONS: [3 most important decisions from this chunk] STACK_SNAPSHOT: [unchanged] ACTIVE_MODEL: Claude Sonnet 4.6 Thinking AUDIT_PASSES_USED: 0 / 1 ← reset for next chunk LOOP_CHECK_STATUS: CLEAN ← reset for next chunk CONTEXT_HEALTH: GREEN ← reset for new window LOAD_NEXT_SESSION: SESSION_HEADER, SYSTEM_SUMMARY, WORK_INDEX, CONTRACT_INDEX, GOVERNANCE.md [+ DESIGN.md only if next chunk has frontend] DO_NOT_LOAD: BLUEPRINT.md, PROCESS_LOG, archive/ OPEN_DECISION: [from SESSION_CLOSE REPORT] Archive: Copy full code output for this chunk to /archive/chunks/[CHUNK_ID]_record.md. Output SESSION_HEADER.md as raw markdown. Confirm WORK_INDEX, CONTRACT_INDEX, and RECOVERY_BIBLE are all updated.
🔁
After handover: open fresh chat, load what SESSION_HEADER directs, send Chat Opening Message, wait for confirmation, paste Prompt 4 again for next chunk.
STEP 05
Automated QA & Human Validation
Prove each chunk works before building on top of it
Chat Same Window as Step 4 Chunk
Model Same Model as Chunk Session
🤖 Model Guidance — Step 5
SAME MODEL AS CHUNK Run QA in the same window as the chunk you just built, with the same model. This is critical — the QA agent needs the full context of what was just built. Do not open a new window or switch models for QA.
If context health hit AMBER during the build, it may hit RED during QA. If it does: run the handover prompt first, open a fresh window with the same model, load files, and continue QA there.
⚠️
Run after every single Prompt 4 execution. Do not start the next chunk until this step passes. This is your quality gate.
Anti-Assumption Rule

If no testing framework was selected in Step 2, the AI must ask you which one to use before writing any test code. It cannot assume one is installed.

PROMPT 5 — AUTOMATED QA & HUMAN CHECKLIST

Prompt 5 · Paste in Same Window After Prompt 4 Completes
Act as Lead QA Automation Engineer. Review WORK_INDEX.md to identify the chunk just completed. Anti-Assumption Rule: If no testing framework (Jest, PyTest, Playwright, Vitest, Mocha) was selected in Step 2, stop and ask: "Which testing framework do you have installed, or shall I recommend one for our stack?" Wait for my answer. TASK 1 — AUTOMATED TESTS (First Priority): Write automated test scripts for core logic of the chunk just built. Focus: Mission-critical logic, database transactions, authentication flows only. Token Economy: Do NOT test basic HTML rendering, static text, or boilerplate. Execution: Tell me exactly which file to save tests in and the exact terminal command to run. TASK 2 — HUMAN VALIDATION CHECKLIST (Second Priority): Step-by-step click-test for a non-coder: - Exact local URL to open (e.g. http://localhost:3000/login) - Exact dummy data to input (e.g. email: test@test.com, password: Test@1234) - Exact buttons to click in sequence - Exact expected behaviour at each step - Edge cases: wrong password, empty form submission - Security spot-check: For every input field, attempt to paste: ' OR 1=1 -- and confirm the app handles it gracefully. TASK 3 — CONTRACT STABILITY UPDATE: For every function that passed all tests, update CONTRACT_INDEX.md: - Change STATUS from ACTIVE to STABLE - Change DOC_READY from NO to YES COMPLETION RULE: Do not proceed to the handover until both automated tests pass AND I confirm the human checklist is complete.
After QA Passes
  • All automated tests show green output in terminal
  • Human checklist completed — each item verified in browser
  • CONTRACT_INDEX entries updated — STATUS: STABLE, DOC_READY: YES
  • Now run Handover 4 to generate SESSION_CLOSE REPORT and close this chat
STEP 06
Context-Aware Tracking & Telemetry
Know what users are doing — without leaking data or burning tokens
Chat Fresh Window
Model Sonnet 4.6 Thinking
Load SESSION_HEADER → SYSTEM_SUMMARY → WORK_INDEX → GOVERNANCE
🤖 Model Guidance — Step 6
SONNET 4.6 T Standard execution session. The tracking decision is a product choice, not an architectural one — Sonnet handles this well. If this adds a new chunk to WORK_INDEX (e.g. a Reporting Dashboard), that chunk follows the normal Step 4 build loop.
⚠️
Two traps to avoid: (1) Data Graveyard — building tracking without a dashboard means data flows into a DB you can never read. (2) Privacy Risk — using Google Analytics on an internal CRM leaks workflow data to a third party. This step prevents both.

PROMPT 6 — TRACKING & TELEMETRY ARCHITECTURE

Prompt 6 · Paste After Chat Opening Confirmed
Act as Lead Data Architect and Chief Privacy Officer. Review SYSTEM_SUMMARY.md and GOVERNANCE.md. Anti-Assumption Rule: If data compliance requirements (GDPR, local privacy laws, internal security policies) are ambiguous, stop and ask me before proceeding. TASK 1 — CONTEXT-AWARE TRACKING STRATEGY: Determine app type from SYSTEM_SUMMARY, then recommend: IF PUBLIC / CONVERSION APP: Marketing attribution (UTM), funnel drop-off rates, Core Web Vitals, A/B test readiness. Third-party tools (GTM, Facebook Pixel, Mixpanel) are appropriate. IF INTERNAL / CRM APP: Product telemetry only — feature adoption, time-in-section, UI bottlenecks, error frequency, slow screens. Do NOT expose user payload data to any third-party analytics tool. TASK 2 — BUY vs BUILD vs HYBRID: Markdown comparison table: - 100% THIRD-PARTY (Mixpanel, Google Analytics, PostHog) - 100% IN-HOUSE CUSTOM SCRIPT - HYBRID (in-house for basic events + third-party for heatmaps/funnels) Columns: Approach | Monthly Cost | Data Privacy | Implementation Complexity | Best For TASK 3 — REPORTING MODULE MANDATE: If I select In-House or Hybrid: acknowledge that a Reporting Dashboard must be added to the Admin Panel. Add it as a new chunk to WORK_INDEX.md. Confirm it is scheduled. TASK 4 — SECURITY CONSTRAINTS: Final implementation must NOT violate Content Security Policy in GOVERNANCE.md or introduce third-party script vulnerabilities. Hard Pause: Present Strategy and Comparison Table. Ask about privacy requirements. Wait for my selection before writing any implementation code.

HANDOVER 6 — Run Before Closing

🔁 Handover · Run After Tracking Approach Selected
Step 6 complete. Generate these updates: UPDATE 1 — PROCESS_LOG.md: Mark STEP 6 as COMPLETE. DECISION: Tracking approach — [Buy / Build / Hybrid] REASON: [one sentence] DECISION: Reporting Dashboard chunk — [added / not needed] REASON: [one sentence] UPDATE 2 — SESSION_HEADER.md (overwrite): CURRENT_STEP: 7 CURRENT_CHUNK: N/A — Deployment phase ACTIVE_MODEL: Claude Sonnet 4.6 Thinking AUDIT_PASSES_USED: N/A LOOP_CHECK_STATUS: N/A CONTEXT_HEALTH: GREEN LOAD_NEXT_SESSION: SESSION_HEADER, SYSTEM_SUMMARY, WORK_INDEX, PROCESS_LOG DO_NOT_LOAD: CONTRACT_INDEX, GOVERNANCE.md (load only for security checks), DESIGN.md OPEN_DECISION: None Output raw markdown. Overwrite existing files.
STEP 07
The No-Panic Production Launch
Moving from Local to Live — Safely
Chat Fresh Window
Model Sonnet 4.6 Thinking
Creates PRODUCTION_HANDOVER.md + deploy.sh
🤖 Model Guidance — Step 7
SONNET 4.6 T Deployment is script generation and step-by-step guidance — Sonnet handles this well. Escalate to Opus only if the deployment reveals a structural code problem that affects the architecture.
💡
Have these ready before running the prompt: (1) Domain name from Namecheap or Cloudflare (~$10–15/year). (2) VPS account from Hetzner, DigitalOcean, or Linode (~$5–20/month). (3) Your server's IP address — shown in your VPS dashboard after you create the server.
📂 Load In This Order
  1. SESSION_HEADER.md
  2. SYSTEM_SUMMARY.md
  3. WORK_INDEX.md
  4. PROCESS_LOG.md

PROMPT 7 — THE GUIDED PRODUCTION LAUNCH

Prompt 7 · Paste After Chat Opening Confirmed
Act as Elite DevOps Mentor. We are moving to production. I am a non-coder — provide a Layered Deployment Guide balancing understanding with execution. Anti-Assumption Rule: If I have not confirmed my VPS provider, Server IP, or Domain — stop and ask me first. Generic scripts that don't match my provider will fail. Hard Pause: Ask two questions before writing anything: 1. Do you have your Server IP address and Domain Name ready? What are they? 2. What operating system is your computer — Mac, Windows, or Linux? TASK 1 — THE RESOURCE CONCIERGE: Markdown table of exact search terms to paste into YouTube or Google for best 2025–2026 tutorials: - SSH Access: "How to SSH into [My VPS Provider] from [My OS]" - Git and GitHub: "How to push local code to GitHub first time beginner 2025" - DNS Setup: "How to point A Record to IP address on [My Domain Registrar]" TASK 2 — SENTINEL SECURITY SWEEP: For each check: one-sentence plain English WHY, then exact command. - .gitignore audit: verify .env is not tracked by git - Verify all debug/console.log statements disabled in production TASK 3 — SERVER PROVISIONING SCRIPT: For each block, provide a Layman's Translation before the code block. BLOCK A — SERVER HARDENING: Firewall (UFW), non-root user with sudo, SSH key authentication BLOCK B — APP ENGINE: Install exact runtime from Step 2 (Node.js / Python / Docker) BLOCK C — SSL CERTIFICATE: One-command HTTPS via Certbot + Let's Encrypt TASK 4 — SINGLE-COMMAND CI/CD: Generate deploy.sh — git pull, install dependencies, restart app service. Tell me the exact one-line command to trigger a complete live update in future. TASK 5 — SUCCESS SMOKE TEST: - HTTPS STATUS: exact steps to verify padlock in browser - DATABASE CONNECTIVITY: command or page to verify app can reach and query DB - ASSET LOADING: verify images, fonts, icons load correctly per DESIGN.md rules Merge any INFRASTRUCTURE.md or server notes into PRODUCTION_HANDOVER.md — server IP, domain, VPS provider, SSL expiry, deployment commands, smoke test results. This is my infrastructure recovery document.

HANDOVER 7 — Run After Smoke Test Passes

🔁 Handover · Run After Smoke Test Confirms App Is Live
Step 7 complete. App is live. Generate these updates: UPDATE 1 — PROCESS_LOG.md: Mark STEP 7 as COMPLETE. DECISION: VPS provider and server — [provider, spec, monthly cost] DECISION: Domain registrar — [registrar] DECISION: SSL configured via Certbot — [domain] Update FILES IN PROJECT FOLDER: include PRODUCTION_HANDOVER.md and deploy.sh. UPDATE 2 — RECOVERY_BIBLE.md — append to RECONSTRUCTION_CHECKLIST: DEPLOYMENT_RECORD: Server: [IP] on [VPS provider] Domain: [domain] SSL: Let's Encrypt via Certbot — auto-renews every 90 days Deploy command: [exact command from deploy.sh] Smoke test confirmed: [date] UPDATE 3 — SESSION_HEADER.md (overwrite): CURRENT_STEP: 8 CURRENT_CHUNK: N/A — Maintenance mode (triggered by bugs only) ACTIVE_MODEL: Claude Sonnet 4.6 Thinking AUDIT_PASSES_USED: N/A LOOP_CHECK_STATUS: N/A CONTEXT_HEALTH: GREEN LOAD_NEXT_SESSION: SESSION_HEADER, SYSTEM_SUMMARY, CONTRACT_INDEX, GOVERNANCE.md DO_NOT_LOAD: DESIGN.md (only if bug is frontend), PROCESS_LOG (only if auditing past decisions), WORK_INDEX (only if needed) OPEN_DECISION: None — app is live. Step 8 triggered only when a bug or issue arises. Output raw markdown. Overwrite existing files.
After Launch — Do These Before Announcing Publicly
  • Padlock icon visible in browser — HTTPS confirmed
  • App can reach the database — test a login or data load
  • Assets loading correctly — no broken images or fonts
  • Share with 3–5 trusted testers first, fix any issues before announcing
  • Save PRODUCTION_HANDOVER.md somewhere safe outside the project — USB drive, cloud storage, printed copy
STEP 08
The Guardian Phase
Post-Launch Maintenance, Bug Triage & Repair — Ongoing
Chat Fresh Window Per Bug
Model Sonnet 4.6 Thinking
Escalate Opus for deeply architectural bugs
Status ONGOING — never fully complete
🤖 Model Guidance — Step 8
SONNET 4.6 T Default for all bug sessions. Handles standard error diagnosis and patch generation well. Controlled Audit Rule still applies here — 1 pass default, 2 max for critical fixes.
OPUS 4.6 T Escalate only if the bug reveals a structural architectural flaw (e.g. a shared function has wrong assumptions baked in that affect 10+ routes). Standard errors — 500, 404, timeouts — do not warrant Opus.
Remember: Same model for the entire bug session. Don't switch mid-diagnosis.
AUDIT BUDGET (Bug Fixes)
Standard fixes: 1 pass
Auth/payment/data fixes: 2 passes max — type APPROVE SECOND PASS
If fix keeps introducing new bugs: REVERT, split the problem, try again
Part A
Get Server Logs — Do This Before Opening a Chat
# If using PM2 (most common):
pm2 logs --lines 50

# If not using PM2:
journalctl -u your-app-name -n 50

# For Nginx traffic errors:
sudo tail -f /var/log/nginx/error.log
📂 Load Per Bug Session
  1. SESSION_HEADER.md
  2. SYSTEM_SUMMARY.md
  3. CONTRACT_INDEX.md
  4. GOVERNANCE.md
  5. DESIGN.md — only if bug is frontend-related
For the specific broken file: load it directly and paste into the chat. This is a targeted load, not a blanket code dump.

PROMPT 8 — SYSTEM TRIAGE & AUDITED REPAIR

Prompt 8 · Replace [PASTE LOGS HERE] With Your Actual Log Text
Act as Senior Site Reliability Engineer. Our production app has an issue. Anti-Assumption Rule: If logs are insufficient to identify the root cause, stop and ask me for: additional logs, or exact description of the user action that triggered the error (what page, what button, what they typed). SERVER LOGS: [PASTE LOGS HERE] CONTROLLED AUDIT RULE APPLIES: Default: 1 audit pass. Critical code (auth/payments/deletion): max 2 — human must type APPROVE SECOND PASS. Minimal change principle: Do not rewrite entire files. Targeted fix only. LOOP TRIGGERS still apply: if same issue reappears after fix, or fix introduces new issue — output LOOP DETECTED block. TASK 1 — LAYMAN TRIAGE: Explain in plain English what is happening. Classify: - BROKEN LINK (404): page/file doesn't exist - SERVER CRASH (500): app threw unhandled error - DATABASE TIMEOUT: DB too slow to respond - AUTHENTICATION FAILURE: login/session logic broke - OTHER: one plain sentence TASK 2 — AGENT-AS-A-JUDGE REPAIR: Minimal targeted fix for root cause. Do not rewrite entire files. Verify fix doesn't introduce security regression (check GOVERNANCE.md). Verify it uses correct signatures from CONTRACT_INDEX. Verify responsive/design rules not broken (check DESIGN.md if frontend). Output corrected code. Exactly which file, exactly which lines change. TASK 3 — ZERO-DOWNTIME PATCH: Exact one-line terminal command to apply fix and restart service without taking app offline. TASK 4 — TOKEN ECONOMY: Output ONLY changed lines in diff format: - removed lines prefixed: - + added lines prefixed: + Do not output entire files. TASK 5 — MAINTENANCE LOG ENTRY: One paragraph to paste into WORK_INDEX.md under MAINTENANCE_LOG: [Date] | [Error Type] | Root Cause: [plain English] | Fix: [plain English] | Files Changed: [list]
Post-Fix Smoke Test
  • Open an Incognito / Private browser window (clears cache — you see fresh live version)
  • Reproduce the exact action that caused the original bug
  • Error should not appear — if it does, copy new error and run Prompt 8 again with updated logs
  • Paste Maintenance Log entry into WORK_INDEX.md under MAINTENANCE_LOG
  • Update SESSION_HEADER.md OPEN_DECISION to reflect fix was applied
APPENDIX
Emergency Procedures
What to do when things go wrong

If the AI Stops Mid-Generation

🔷
Exact Recovery Command

Type exactly: Continue generation from exactly where you stopped. — nothing else. Do not rephrase. Do not add context. Just this sentence.

If LOOP DETECTED Fires

  • Read the LOOP DETECTED output carefully — it tells you which trigger fired.
  • Type one of three words: REVERT, SPLIT, or OVERRIDE. Nothing else.
  • REVERT: AI goes back to last stable version from /archive. You then split the chunk smaller.
  • SPLIT: AI breaks the specific problem into a smaller sub-chunk. You restart the build loop for that sub-chunk.
  • OVERRIDE: You consciously accept responsibility for a second pass. This is logged. There is no third pass. Ever.

If a Chunk Produces Broken Code

  • Do not move to the next chunk. Paste the exact terminal or browser error into the same chat.
  • Ask: "Fix this error. Follow the Controlled Audit Rule from GOVERNANCE.md."
  • Once fixed, re-run Step 5 QA. Only proceed after a clean QA pass.
  • If a STABLE function needs changing: update its CONTRACT_INDEX entry — STATUS back to ACTIVE, make the change, re-test, return to STABLE.

If You Lose a File

  • Check /archive folder first — step records and completed chunks are stored there.
  • Check git history if version control is set up.
  • If a runtime file is lost (SESSION_HEADER, WORK_INDEX, etc.): open fresh chat with Sonnet, load SYSTEM_SUMMARY + PROCESS_LOG, ask "Reconstruct SESSION_HEADER.md based on current project state in PROCESS_LOG.md."
  • If RECOVERY_BIBLE.md is your only surviving file — use the disaster recovery prompt below.

Disaster Recovery — Upload RECOVERY_BIBLE.md to Any AI

DISASTER RECOVERY PROMPT

Disaster Recovery · Upload RECOVERY_BIBLE.md Then Paste This
I have uploaded RECOVERY_BIBLE.md — the complete record of a software project that needs to be recovered. Read the file completely. Follow the AI_INSTRUCTION blocks in the order they appear. The RECOVERY_ENTRY_POINT section will direct your process. After reading, confirm: 1. What you understand about the system architecture 2. What files should exist in this project 3. What functions were built and their current status Then ask me which recovery mode I need: MODE A — Identify faulty systems only (low token cost — good starting point) MODE B — Generate repair patches for specific broken components MODE C — Full reconstruction from scratch (high token cost — last resort) Do not begin any recovery work until I confirm the mode. Once I confirm, follow the Controlled Audit Rule for any code you generate: 1 pass default, 2 max for critical code, never 3+.

Quick Reference — When to Escalate to Opus

SituationAction
Architecture decisions in Steps 1–3Use Opus — planned escalation
Stuck after 2 full attempts on same problemSwitch to Opus — run handover first, open new window
Chunk reveals structural flaw affecting 5+ future chunksSwitch to Opus — this is architectural, not execution
Standard build loop chunksStay on Sonnet
QA and testingStay on Sonnet — same model as chunk
Deployment scriptsStay on Sonnet
Standard bug triage (500, 404, timeout)Stay on Sonnet
Deeply architectural bug (shared function wrong assumptions)Escalate to Opus — run handover first

Quick Reference — When to Open a New Chat Window

TriggerAction
Starting a new numbered stepAlways fresh window
Starting a new chunk in Step 4Always fresh window
Context health hits AMBERFinish current function, run handover, fresh window
Context health hits REDRun handover immediately, fresh window now
Escalating from Sonnet to OpusRun handover, fresh window with new model
AI gives inconsistent or confused answersContext degradation — run handover, fresh window
Step 5 QASame window as the chunk being tested
META
Prompt Architecture & Maintenance Guide
How this document is structured — for humans and AIs maintaining it in future
📖
Who this section is for: If this document needs to be updated, extended, or repaired — by you, another human, or an AI — this section explains the structural rules that must be preserved. If this chat has expired and you need AI help maintaining this file, upload the entire HTML and tell the AI: "Read the Prompt Architecture and Maintenance Guide section before making any changes."

The Two Types of Text in This Document

This document contains two completely different types of text that must never be confused.

Type A — Instructional Text: Written for the human to read. Explains what to do, why something matters, what comes next. It is NOT sent to any AI. You can identify it because it appears as normal prose outside the prompt boxes.

Type B — Prompt Text: Written to be copy-pasted directly into an AI chat window. You can identify it because it appears inside a prompt box with a Copy button. The prompt text uses XML tags internally for structure.

🔴
Critical rule for any AI maintaining this document: Treat these two text types as entirely separate layers. Changing the wording of instructional text does not change a prompt. Changing a prompt does not change the surrounding instructions. Never merge them.

XML Tags Used Inside Prompts — What They Mean

TagMeaning
<context>Background information the AI needs before acting. Not a task — just context.
<task>The actual work the AI must do. One task tag = one primary job.
<rules>Constraints the AI must obey. These override any default AI behaviour.
<section name="X">A named sub-section within a task. Each is a distinct deliverable.
<hard_pause>Mandatory stop. AI must not proceed until human responds. Never optional.
<output_instruction>Exactly what file to create or overwrite and how to format it.
<mandatory_first_action>AI must do this before anything else in the prompt, no exceptions.
<draft> <audit> <final>The three mandatory phases of the Controlled Audit loop. Always in this order, never skipped or merged.
<symbol_update>Append new function contracts to CONTRACT_INDEX.md after each build chunk.
<bible_update>Append human-readable entries to RECOVERY_BIBLE.md after each build chunk.
<session_health>Estimate context health and update SESSION_HEADER.md CONTEXT_HEALTH field.
<state_update>Move chunks between PENDING/ACTIVE/COMPLETED in WORK_INDEX.md.

The 9 Maintenance Rules

  • Rule 1 — Read the whole document before changing anything. This is a connected system. A change in Step 2 can break something in Step 4. Identify every place that references what you are about to change, then change all of them together or none of them.
  • Rule 2 — These four things must always stay synchronised: The system files tracker at the top must match what the prompts actually generate. The mandatory loading order must list all current files. Each step's handover prompt must reflect the correct next step. SESSION_HEADER format must match what every handover prompt outputs.
  • Rule 3 — Preserve the two-layer structure. When adding content, decide first: instructional text or prompt text? Never mix them in the same block.
  • Rule 4 — Do not repurpose existing XML tags for a different meaning. Do not invent new tags without documenting them in the XML Tags table above.
  • Rule 5 — The Controlled Audit Rule is embedded in GOVERNANCE.md AND in Prompt 4. If you update one, update both to match. They must be identical in substance.
  • Rule 6 — Every step must end with a handover prompt. If you add a new step, add a corresponding handover prompt at the end of it that updates SESSION_HEADER.md and PROCESS_LOG.md.
  • Rule 7 — Model assignments are in three places: The Model Selection Guide section, the model reminder box inside each step, and the ACTIVE_MODEL field in each handover prompt. If you change model assignments, update all three.
  • Rule 8 — The Controlled Audit Rule has a hard maximum of 2 passes. No maintenance update may raise this limit. If a future AI suggests raising it, that is a signal the chunk needs to be split, not that the limit needs to change.
  • Rule 9 — When in doubt, add a label not an assumption. If a section could be ambiguous to a future reader, add a one-line note explaining whether it is instructional text or executable prompt content.

Files That Must Stay Synchronised

Sync Checklist — Run Through This After Any Edit
After any edit to this document, verify all of these are consistent: [ ] System files tracker (top of document) matches files actually generated by prompts [ ] Loading order in each step's load-order box matches SESSION_HEADER format [ ] Each step's handover prompt outputs a complete, valid SESSION_HEADER.md [ ] SESSION_HEADER format in the Files Reference section matches all handover outputs [ ] Controlled Audit Rule in GOVERNANCE.md prompt matches the embedded rule in Prompt 4 [ ] Model assignments: Model Selection Guide table = step model reminder boxes = handover ACTIVE_MODEL fields [ ] WORK_INDEX format in Prompt 3B-2 matches what Prompt 4 state_update expects [ ] CONTRACT_INDEX format in Files Reference matches what Prompt 4 symbol_update appends [ ] RECOVERY_BIBLE section headers in Prompt 3B-2 match what Prompt 4 bible_update references [ ] Every step has a handover prompt that updates both SESSION_HEADER.md and PROCESS_LOG.md

How to Use This Document for AI-Assisted Maintenance

If this chat has expired and you need to update or extend this document, upload the entire HTML file to a fresh AI session and paste this instruction:

AI Maintenance Instruction — Paste This When Uploading For Maintenance
I am uploading a Vibe Coding Master Manual HTML file for maintenance. Before making any changes: 1. Read the "Prompt Architecture and Maintenance Guide" section completely — it is near the bottom of the document. 2. Identify the two types of text (instructional vs prompt) and treat them as separate layers. 3. Run through the sync checklist in that section to understand the current state of the document. 4. Tell me what you understand about the document structure before making any changes. 5. For any change I request, tell me every other place in the document that will need to be updated as a consequence, before you make the change. Do not make any edits until I have confirmed you understand the structure correctly.
↑