gaslighting-engine 0.1.0 → 0.2.0

package/examples/ecommerce/.codex/prompts/gaslighting.md

@@ -2,14 +2,15 @@
 
 Read the Gaslighting-engine project-control files before doing any work:
 
-1. `GASLIGHTING.md`
-2. `PRD.md`
-3. `STACK_POLICY.md`
-4. `MISSING_INFO.md`
-5. `ASSUMPTIONS.md`
-6. `DECISION_LOG.md`
+1. `.gaslighting/GASLIGHTING.md`
+2. `.gaslighting/PRD.md`
+3. `.gaslighting/STACK_POLICY.md`
+4. `.gaslighting/MISSING_INFO.md`
+5. `.gaslighting/ASSUMPTIONS.md`
+6. `.gaslighting/DECISION_LOG.md`
 7. `AGENTS.md`
-8. `MEMORY.md`
+8. `.gaslighting/MEMORY.md`
+9. `.gaslighting/PROJECT_CARE.md`
 
 Then execute the user's requested implementation.
 
@@ -23,8 +24,9 @@ Rules:
 - Do not call scaffolding completion.
 - Do not call placeholders implementation.
 - Do not over-engineer.
-- Record stable project facts in `MEMORY.md`.
-- Record product and technical decisions in `DECISION_LOG.md`.
+- Record stable project facts in `.gaslighting/MEMORY.md`.
+- Record product and technical decisions in `.gaslighting/DECISION_LOG.md`.
+- Record Git/GitHub/domain/deployment risks in `.gaslighting/PROJECT_CARE.md`.
 - If something is incomplete, declare it explicitly.
 
-Before claiming completion, perform the self-audit in `GASLIGHTING.md`.
+Before claiming completion, perform the self-audit in `.gaslighting/GASLIGHTING.md`.

package/examples/ecommerce/.codex/skills/gaslighting/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gaslighting
-description: Generate or update strict project discipline documents for Codex and AI coding agents. Use when a user asks to initialize Gaslighting, create GASLIGHTING.md/PRD.md/AGENTS.md discipline files, preserve full project scope, prevent TODO escape, prevent fake completion, or turn vague project intent into actionable control documents.
+description: Generate or update strict .gaslighting project discipline documents for Codex and AI coding agents. Use when a user asks to initialize Gaslighting, create GASLIGHTING.md/PRD.md/AGENTS.md discipline files, preserve full project scope, prevent TODO escape, prevent fake completion, track Git/GitHub/domain/deployment care risks, or turn vague project intent into actionable control documents.
 ---
 
 # Gaslighting-engine Skill
@@ -16,13 +16,14 @@ Instead:
 3. Make reasonable assumptions.
 4. Document assumptions clearly.
 5. Mark missing information clearly.
-6. Generate `GASLIGHTING.md`.
-7. Generate `PRD.md`.
-8. Generate `ASSUMPTIONS.md`.
-9. Generate `MISSING_INFO.md`.
-10. Generate `DECISION_LOG.md`.
-11. Generate `STACK_POLICY.md`.
-12. Generate or update `AGENTS.md`.
+6. Generate `.gaslighting/GASLIGHTING.md`.
+7. Generate `.gaslighting/PRD.md`.
+8. Generate `.gaslighting/ASSUMPTIONS.md`.
+9. Generate `.gaslighting/MISSING_INFO.md`.
+10. Generate `.gaslighting/DECISION_LOG.md`.
+11. Generate `.gaslighting/STACK_POLICY.md`.
+12. Generate or update root `AGENTS.md`.
+13. Generate `.gaslighting/PROJECT_CARE.md`.
 
 ## Hardcore Discipline Rule
 
@@ -87,6 +88,10 @@ Avoid over-engineering.
 
 Create real markdown files.
 
+Keep main project-control files in `.gaslighting/` and keep only the Codex pointer `AGENTS.md` in the repository root.
+
+Use `.gaslighting/PROJECT_CARE.md` to track Git/GitHub/domain/deployment/launch risks without blocking implementation.
+
 Do not only explain.
 
 Do not produce a plan without files.

package/examples/ecommerce/.gaslighting/AGENTS.md

@@ -0,0 +1,49 @@
+# AGENTS.md
+
+This repository uses Gaslighting-engine.
+
+Before doing any work, read these files in order:
+
+1. `.gaslighting/GASLIGHTING.md`
+2. `.gaslighting/PRD.md`
+3. `.gaslighting/STACK_POLICY.md`
+4. `.gaslighting/MISSING_INFO.md`
+5. `.gaslighting/ASSUMPTIONS.md`
+6. `.gaslighting/DECISION_LOG.md`
+7. `.gaslighting/MEMORY.md`
+8. `.gaslighting/PROJECT_CARE.md`
+
+## Prime Directive
+
+Do not forget the project purpose.
+
+Do not reduce the requested scope.
+
+Do not pretend partial work is complete.
+
+Do not use TODO comments as fake implementation.
+
+Do not create representative examples when the user requested full coverage.
+
+Do not say "the rest follows the same pattern."
+
+If information is missing, make a reasonable assumption, document it, and continue unless the missing information is truly blocking.
+
+## Completion Standard
+
+A task is complete only when:
+
+- The requested scope is fully handled.
+- No required item is silently skipped.
+- No placeholder is pretending to be implementation.
+- No TODO is used as a substitute for work.
+- The output can actually be used.
+- New assumptions are documented.
+- New technical decisions are recorded.
+- Stable project facts are recorded in `.gaslighting/MEMORY.md`.
+- Operational risks are recorded in `.gaslighting/PROJECT_CARE.md`.
+- The result does not contradict `.gaslighting/GASLIGHTING.md`.
+
+If the task is incomplete, say it is incomplete.
+
+Do not fake completion.

package/examples/{landing-page → ecommerce/.gaslighting}/CODEX_PROMPT.md

@@ -6,14 +6,15 @@ Copy and paste this into Codex:
 
 Read the following files before doing any work:
 
-1. `GASLIGHTING.md`
-2. `PRD.md`
-3. `STACK_POLICY.md`
-4. `MISSING_INFO.md`
-5. `ASSUMPTIONS.md`
-6. `DECISION_LOG.md`
+1. `.gaslighting/GASLIGHTING.md`
+2. `.gaslighting/PRD.md`
+3. `.gaslighting/STACK_POLICY.md`
+4. `.gaslighting/MISSING_INFO.md`
+5. `.gaslighting/ASSUMPTIONS.md`
+6. `.gaslighting/DECISION_LOG.md`
 7. `AGENTS.md`
-8. `MEMORY.md`
+8. `.gaslighting/MEMORY.md`
+9. `.gaslighting/PROJECT_CARE.md`
 
 Then implement the project MVP.
 
@@ -29,6 +30,6 @@ Rules:
 - Do not forget the project purpose.
 - If something is incomplete, declare it explicitly.
 
-Before claiming completion, perform the self-audit in `GASLIGHTING.md`.
+Before claiming completion, perform the self-audit in `.gaslighting/GASLIGHTING.md`.
 
 Proceed.

package/examples/ecommerce/{MEMORY.md → .gaslighting/MEMORY.md}

@@ -6,7 +6,7 @@ It is inspired by agent memory systems, but it is not a vague diary.
 
 It records stable project facts, recurring workflow rules, known failure patterns, and decisions that future AI-agent sessions must not forget.
 
-Keep required rules in `AGENTS.md`, `GASLIGHTING.md`, and checked-in documents. Treat this file as a compact recall layer, not the only source of truth.
+Keep required rules in root `AGENTS.md`, `.gaslighting/GASLIGHTING.md`, and checked-in documents. Treat this file as a compact recall layer, not the only source of truth.
 
 ## Stable Project Facts
 
@@ -43,7 +43,7 @@ These are cleanup and verification rules:
 - Zero unexplained scope reductions.
 - Zero unverified success claims.
 - Every destructive cleanup must be intentional and explainable.
-- If code or files are removed, record why in `DECISION_LOG.md`.
+- If code or files are removed, record why in `.gaslighting/DECISION_LOG.md`.
 
 ## Memory Write Rules
 

package/examples/ecommerce/.gaslighting/PROJECT_CARE.md

@@ -0,0 +1,75 @@
+# PROJECT_CARE.md
+
+This file is the project-care ledger for Gaslighting-engine.
+
+It is not a blocker wall.
+
+It is the place where the agent keeps noticing operational risk, ownership gaps, Git/GitHub status, deployment readiness, domain ownership, and missing production decisions.
+
+The agent must treat this project as mission-critical. If something can put delivery, trust, data, launch, SEO, legal compliance, or operations at risk, record it here and keep pushing it forward.
+
+## Project Snapshot
+
+- Date: 2026-05-23
+- Original request: Build an ecommerce MVP with product catalog, cart, checkout, and admin orders.
+- Project type: ecommerce
+- Classification confidence: high
+- Project purpose:
+  - product discovery
+  - product detail clarity
+  - cart flow
+  - checkout flow
+  - order creation
+  - payment readiness
+  - admin product management
+  - mobile purchase experience
+
+## Git And GitHub Registry
+
+| Item | Status | Next Action |
+|---|---|---|
+| Git repository | Detected, branch `main` | Commit meaningful checkpoints. |
+| Origin remote | `https://github.com/nohsangwoo/GaslightingEngineering.git` | Keep remote ownership recorded when it changes. |
+| GitHub remote | Detected | Use GitHub as the source-of-truth remote. |
+
+## Domain And Deployment Registry
+
+| Item | Current Status | Risk | Next Action |
+|---|---|---|---|
+| Production domain | Missing | Users cannot reach production reliably. | Confirm domain owner, DNS provider, and final domain. |
+| DNS provider | Missing | Launch can be delayed by DNS access issues. | Record provider, account owner, and nameserver strategy. |
+| Deployment target | Not confirmed | Environment drift and launch confusion. | Confirm Vercel, Netlify, Cloudflare, or other target. |
+| Preview URL policy | Missing | Stakeholders cannot review safely. | Decide preview deployment workflow. |
+| Rollback path | Missing | Production incidents become slower to recover. | Define rollback command/provider workflow. |
+
+## Care Checklist
+
+- [x] Git repository: Git repository detected on branch main. Next: Keep committing discipline and implementation changes.
+- [x] GitHub remote: GitHub remote detected: https://github.com/nohsangwoo/GaslightingEngineering.git Next: Record repository decisions in DECISION_LOG.md when remote ownership changes.
+- [ ] Project package file: package.json is missing. Next: Create package.json when implementation starts, unless this is not a Node project.
+- [ ] Deployment target: No explicit deployment config detected. Next: Confirm deployment target, production domain, preview environment, and rollback path before launch.
+- [ ] Environment template: .env.example is missing. Next: Add .env.example before sharing the project so required secrets are visible without exposing real values.
+- [ ] Production domain confirmed.
+- [ ] DNS owner confirmed.
+- [ ] Deployment provider confirmed.
+- [ ] Analytics ownership confirmed.
+- [ ] Form/email delivery owner confirmed.
+- [ ] Privacy/legal review path confirmed.
+- [ ] Launch checklist created before production release.
+
+## Agent Care Rules
+
+- Do not stop implementation just because an operational detail is missing.
+- Do make a practical assumption, record it, and keep moving.
+- If Git is not initialized, ask for a GitHub URL and offer the exact commands.
+- If Git is initialized but no GitHub remote exists, ask for the remote URL and offer `git remote add origin <url>`.
+- If GitHub is connected, record the remote URL here and in `DECISION_LOG.md` when it changes.
+- If domain or deployment details are missing, keep warning until they are confirmed.
+- Treat missing domain, deployment, analytics, email, and privacy ownership as mission-critical launch risks, not as reasons to abandon the task.
+- Never turn care warnings into fake blockers.
+
+## Current Care Warnings
+
+- Project package file: package.json is missing. Action: Create package.json when implementation starts, unless this is not a Node project.
+- Deployment target: No explicit deployment config detected. Action: Confirm deployment target, production domain, preview environment, and rollback path before launch.
+- Environment template: .env.example is missing. Action: Add .env.example before sharing the project so required secrets are visible without exposing real values.

package/examples/ecommerce/AGENTS.md

@@ -2,46 +2,22 @@
 
 This repository uses Gaslighting-engine.
 
-Before doing any work, read these files in order:
-
-1. `GASLIGHTING.md`
-2. `PRD.md`
-3. `STACK_POLICY.md`
-4. `MISSING_INFO.md`
-5. `ASSUMPTIONS.md`
-6. `DECISION_LOG.md`
-7. `MEMORY.md`
-
-## Prime Directive
-
-Do not forget the project purpose.
-
-Do not reduce the requested scope.
-
-Do not pretend partial work is complete.
-
-Do not use TODO comments as fake implementation.
+The main discipline documents live under `.gaslighting/` to avoid cluttering the project root.
 
-Do not create representative examples when the user requested full coverage.
-
-Do not say "the rest follows the same pattern."
-
-If information is missing, make a reasonable assumption, document it, and continue unless the missing information is truly blocking.
-
-## Completion Standard
-
-A task is complete only when:
+Before doing any work, read these files in order:
 
-- The requested scope is fully handled.
-- No required item is silently skipped.
-- No placeholder is pretending to be implementation.
-- No TODO is used as a substitute for work.
-- The output can actually be used.
-- New assumptions are documented.
-- New technical decisions are recorded.
-- Stable project facts are recorded in `MEMORY.md`.
-- The result does not contradict `GASLIGHTING.md`.
+1. `.gaslighting/GASLIGHTING.md`
+2. `.gaslighting/PRD.md`
+3. `.gaslighting/STACK_POLICY.md`
+4. `.gaslighting/MISSING_INFO.md`
+5. `.gaslighting/ASSUMPTIONS.md`
+6. `.gaslighting/DECISION_LOG.md`
+7. `.gaslighting/MEMORY.md`
+8. `.gaslighting/PROJECT_CARE.md`
+9. `.gaslighting/AGENTS.md`
 
-If the task is incomplete, say it is incomplete.
+Do not reduce scope.
 
 Do not fake completion.
+
+If care risks are missing or unresolved, record them in `.gaslighting/PROJECT_CARE.md` and continue unless they truly block implementation.

package/examples/hospital-homepage/.codex/prompts/gaslighting.md

@@ -2,14 +2,15 @@
 
 Read the Gaslighting-engine project-control files before doing any work:
 
-1. `GASLIGHTING.md`
-2. `PRD.md`
-3. `STACK_POLICY.md`
-4. `MISSING_INFO.md`
-5. `ASSUMPTIONS.md`
-6. `DECISION_LOG.md`
+1. `.gaslighting/GASLIGHTING.md`
+2. `.gaslighting/PRD.md`
+3. `.gaslighting/STACK_POLICY.md`
+4. `.gaslighting/MISSING_INFO.md`
+5. `.gaslighting/ASSUMPTIONS.md`
+6. `.gaslighting/DECISION_LOG.md`
 7. `AGENTS.md`
-8. `MEMORY.md`
+8. `.gaslighting/MEMORY.md`
+9. `.gaslighting/PROJECT_CARE.md`
 
 Then execute the user's requested implementation.
 
@@ -23,8 +24,9 @@ Rules:
 - Do not call scaffolding completion.
 - Do not call placeholders implementation.
 - Do not over-engineer.
-- Record stable project facts in `MEMORY.md`.
-- Record product and technical decisions in `DECISION_LOG.md`.
+- Record stable project facts in `.gaslighting/MEMORY.md`.
+- Record product and technical decisions in `.gaslighting/DECISION_LOG.md`.
+- Record Git/GitHub/domain/deployment risks in `.gaslighting/PROJECT_CARE.md`.
 - If something is incomplete, declare it explicitly.
 
-Before claiming completion, perform the self-audit in `GASLIGHTING.md`.
+Before claiming completion, perform the self-audit in `.gaslighting/GASLIGHTING.md`.

package/examples/hospital-homepage/.codex/skills/gaslighting/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gaslighting
-description: Generate or update strict project discipline documents for Codex and AI coding agents. Use when a user asks to initialize Gaslighting, create GASLIGHTING.md/PRD.md/AGENTS.md discipline files, preserve full project scope, prevent TODO escape, prevent fake completion, or turn vague project intent into actionable control documents.
+description: Generate or update strict .gaslighting project discipline documents for Codex and AI coding agents. Use when a user asks to initialize Gaslighting, create GASLIGHTING.md/PRD.md/AGENTS.md discipline files, preserve full project scope, prevent TODO escape, prevent fake completion, track Git/GitHub/domain/deployment care risks, or turn vague project intent into actionable control documents.
 ---
 
 # Gaslighting-engine Skill
@@ -16,13 +16,14 @@ Instead:
 3. Make reasonable assumptions.
 4. Document assumptions clearly.
 5. Mark missing information clearly.
-6. Generate `GASLIGHTING.md`.
-7. Generate `PRD.md`.
-8. Generate `ASSUMPTIONS.md`.
-9. Generate `MISSING_INFO.md`.
-10. Generate `DECISION_LOG.md`.
-11. Generate `STACK_POLICY.md`.
-12. Generate or update `AGENTS.md`.
+6. Generate `.gaslighting/GASLIGHTING.md`.
+7. Generate `.gaslighting/PRD.md`.
+8. Generate `.gaslighting/ASSUMPTIONS.md`.
+9. Generate `.gaslighting/MISSING_INFO.md`.
+10. Generate `.gaslighting/DECISION_LOG.md`.
+11. Generate `.gaslighting/STACK_POLICY.md`.
+12. Generate or update root `AGENTS.md`.
+13. Generate `.gaslighting/PROJECT_CARE.md`.
 
 ## Hardcore Discipline Rule
 
@@ -87,6 +88,10 @@ Avoid over-engineering.
 
 Create real markdown files.
 
+Keep main project-control files in `.gaslighting/` and keep only the Codex pointer `AGENTS.md` in the repository root.
+
+Use `.gaslighting/PROJECT_CARE.md` to track Git/GitHub/domain/deployment/launch risks without blocking implementation.
+
 Do not only explain.
 
 Do not produce a plan without files.

package/examples/hospital-homepage/.gaslighting/AGENTS.md

@@ -0,0 +1,49 @@
+# AGENTS.md
+
+This repository uses Gaslighting-engine.
+
+Before doing any work, read these files in order:
+
+1. `.gaslighting/GASLIGHTING.md`
+2. `.gaslighting/PRD.md`
+3. `.gaslighting/STACK_POLICY.md`
+4. `.gaslighting/MISSING_INFO.md`
+5. `.gaslighting/ASSUMPTIONS.md`
+6. `.gaslighting/DECISION_LOG.md`
+7. `.gaslighting/MEMORY.md`
+8. `.gaslighting/PROJECT_CARE.md`
+
+## Prime Directive
+
+Do not forget the project purpose.
+
+Do not reduce the requested scope.
+
+Do not pretend partial work is complete.
+
+Do not use TODO comments as fake implementation.
+
+Do not create representative examples when the user requested full coverage.
+
+Do not say "the rest follows the same pattern."
+
+If information is missing, make a reasonable assumption, document it, and continue unless the missing information is truly blocking.
+
+## Completion Standard
+
+A task is complete only when:
+
+- The requested scope is fully handled.
+- No required item is silently skipped.
+- No placeholder is pretending to be implementation.
+- No TODO is used as a substitute for work.
+- The output can actually be used.
+- New assumptions are documented.
+- New technical decisions are recorded.
+- Stable project facts are recorded in `.gaslighting/MEMORY.md`.
+- Operational risks are recorded in `.gaslighting/PROJECT_CARE.md`.
+- The result does not contradict `.gaslighting/GASLIGHTING.md`.
+
+If the task is incomplete, say it is incomplete.
+
+Do not fake completion.

package/examples/{ecommerce → hospital-homepage/.gaslighting}/CODEX_PROMPT.md

@@ -6,14 +6,15 @@ Copy and paste this into Codex:
 
 Read the following files before doing any work:
 
-1. `GASLIGHTING.md`
-2. `PRD.md`
-3. `STACK_POLICY.md`
-4. `MISSING_INFO.md`
-5. `ASSUMPTIONS.md`
-6. `DECISION_LOG.md`
+1. `.gaslighting/GASLIGHTING.md`
+2. `.gaslighting/PRD.md`
+3. `.gaslighting/STACK_POLICY.md`
+4. `.gaslighting/MISSING_INFO.md`
+5. `.gaslighting/ASSUMPTIONS.md`
+6. `.gaslighting/DECISION_LOG.md`
 7. `AGENTS.md`
-8. `MEMORY.md`
+8. `.gaslighting/MEMORY.md`
+9. `.gaslighting/PROJECT_CARE.md`
 
 Then implement the project MVP.
 
@@ -29,6 +30,6 @@ Rules:
 - Do not forget the project purpose.
 - If something is incomplete, declare it explicitly.
 
-Before claiming completion, perform the self-audit in `GASLIGHTING.md`.
+Before claiming completion, perform the self-audit in `.gaslighting/GASLIGHTING.md`.
 
 Proceed.

package/examples/hospital-homepage/{MEMORY.md → .gaslighting/MEMORY.md}

@@ -6,7 +6,7 @@ It is inspired by agent memory systems, but it is not a vague diary.
 
 It records stable project facts, recurring workflow rules, known failure patterns, and decisions that future AI-agent sessions must not forget.
 
-Keep required rules in `AGENTS.md`, `GASLIGHTING.md`, and checked-in documents. Treat this file as a compact recall layer, not the only source of truth.
+Keep required rules in root `AGENTS.md`, `.gaslighting/GASLIGHTING.md`, and checked-in documents. Treat this file as a compact recall layer, not the only source of truth.
 
 ## Stable Project Facts
 
@@ -43,7 +43,7 @@ These are cleanup and verification rules:
 - Zero unexplained scope reductions.
 - Zero unverified success claims.
 - Every destructive cleanup must be intentional and explainable.
-- If code or files are removed, record why in `DECISION_LOG.md`.
+- If code or files are removed, record why in `.gaslighting/DECISION_LOG.md`.
 
 ## Memory Write Rules
 

package/examples/hospital-homepage/.gaslighting/PRD.md

@@ -0,0 +1,119 @@
+# PRD.md
+
+## 1. Product Overview
+
+Build an MVP for this request:
+
+> I want to build a hospital website.
+
+Classified project type: `hospital_homepage`
+
+The product must preserve the user's actual scope and must not become a decorative shell.
+
+## 2. Business Purpose
+
+- increase trust
+- generate consultation inquiries
+- support reservation conversion
+- make departments and treatments understandable
+- make doctors and hospital credibility visible
+- help mobile visitors contact the hospital quickly
+- support local SEO
+- make location and contact information obvious
+
+## 3. Target Users
+
+- Potential patients searching on mobile
+- Patients comparing hospitals
+- Users looking for treatment information
+- Users who want to call, reserve, or ask questions
+- Hospital staff receiving inquiries
+
+## 4. User Flows
+
+- Search/mobile visitor -> home -> treatment/doctor trust -> contact or reservation CTA
+- Visitor -> location/contact -> call or submit inquiry
+
+## 5. Page List
+
+- Home
+- Hospital Introduction
+- Departments / Treatments
+- Doctor Profiles
+- Consultation / Contact
+- Location
+- Privacy Policy
+
+## 6. Feature List
+
+- responsive layout
+- mobile-first UI
+- contact CTA
+- inquiry form
+- treatment sections
+- doctor introduction
+- location section
+- privacy policy
+- SEO metadata
+- analytics-ready structure
+
+## 7. Data Model Draft
+
+- Inquiry: name, phone, category, message, privacyConsent, status, createdAt
+- Treatment: title, summary, body, image, order
+- Doctor: name, specialty, bio, credentials, image
+- Location: address, phone, hours, mapUrl
+
+## 8. MVP Scope
+
+- Implement all pages, flows, and features listed above.
+- Include responsive behavior.
+- Include useful empty, loading, success, and error states where applicable.
+- Include SEO metadata where public pages exist.
+- Include analytics-ready structure where conversion matters.
+- Document every assumption that affects implementation.
+
+## 9. Out of Scope
+
+- full admin dashboard
+- payment
+- complex reservation calendar
+- EMR integration
+- user login
+- multilingual content
+- automated medical diagnosis
+
+## 10. Non-Functional Requirements
+
+- Mobile-first where users are likely to arrive from search or ads.
+- Accessible semantic HTML.
+- Fast initial load for public pages.
+- Safe form validation and clear error messages.
+- Maintainable TypeScript structure.
+- No unnecessary distributed systems.
+
+## 11. Tech Stack
+
+No stack hints were provided. Use the default practical web stack unless the user later changes it.
+
+See `STACK_POLICY.md` for defaults and forbidden-by-default technology.
+
+## 12. Risks
+
+- Vague source requirements can cause wrong vertical assumptions.
+- Placeholder copy can look real if not reviewed.
+- Missing production credentials can block deployment.
+- AI agents may reduce scope unless `GASLIGHTING.md` is enforced.
+
+## 13. Missing Information
+
+See `MISSING_INFO.md`.
+
+## 14. Success Criteria
+
+- The project purpose is visible in the implemented product.
+- The core pages and features are implemented, not merely described.
+- No required scope is replaced by representative examples.
+- No TODO is used as a substitute for implementation.
+- Assumptions and decisions remain documented.
+- The output can actually be used for the MVP purpose.