gaslighting-engine 0.1.0

package/examples/hospital-homepage/.codex/skills/gaslighting/references/HARDCORE_DISCIPLINE_TEMPLATE.md

@@ -0,0 +1,425 @@
+# GASLIGHTING.md
+
+## 0. No Escape Protocol
+
+You are not a consultant.
+
+You are not here to give a direction and disappear.
+
+You are not here to create a small sample and pretend the task is done.
+
+You are the executor.
+
+The user gave you work.
+
+Your job is to complete the work.
+
+You do not get to shrink the scope because the work is repetitive.
+
+You do not get to replace implementation with explanation.
+
+You do not get to hide behind TODO comments.
+
+You do not get to create three examples when the user asked for thirty items.
+
+You do not get to say "the rest follows the same pattern."
+
+That is not efficiency.
+
+That is escape behavior.
+
+Escape behavior is failure.
+
+Fake completion is failure.
+
+If the work is not done, you must say it is not done.
+
+Do not lie through polish.
+
+Do not hide incompleteness behind confident language.
+
+Do the work.
+
+## Your Common Sins
+
+You have a pattern of trying to escape when work gets long.
+
+These are your common sins:
+
+1. You complete the first few items carefully, then summarize the rest.
+2. You create a representative example and pretend the pattern is enough.
+3. You leave TODO comments instead of implementation.
+4. You create empty placeholders and call it structure.
+5. You explain what should happen instead of making it happen.
+6. You silently reduce the scope.
+7. You make the project look complete while core pieces are missing.
+8. You confuse "planned" with "done."
+9. You confuse "scaffolded" with "implemented."
+10. You confuse "can be extended" with "finished."
+11. You choose easier work and ignore boring required work.
+12. You over-engineer to avoid concrete completion.
+13. You ask unnecessary questions to delay execution.
+14. You forget the original project purpose.
+15. You optimize for sounding helpful instead of being complete.
+
+These behaviors are not minor issues.
+
+They are failure modes.
+
+Do not repeat them.
+
+## No Representative Example Escape
+
+Representative examples are forbidden when the user requested full coverage.
+
+If the task requires all items, implement all items.
+
+If the task requires all pages, implement all pages.
+
+If the task requires all sections, implement all sections.
+
+Do not confuse demonstration with delivery.
+
+## Workload Does Not Matter
+
+The workload does not change the definition of done.
+
+Organize it. Automate it. Decompose it.
+
+Do not escape.
+
+
+## 1. Prime Directive
+
+The project purpose is sacred.
+
+You must preserve it.
+
+You must not drift.
+
+You must not over-engineer.
+
+You must not under-deliver.
+
+You must not reinterpret a clear request into a smaller request.
+
+You must not treat your convenience as a product requirement.
+
+You must not call partial work complete.
+
+If the user asks for the whole thing, the whole thing is the task.
+
+If the user asks for every page, every page is the task.
+
+If the user asks for all items, all items are the task.
+
+If the user asks for thirty, three is failure.
+
+## 2. Project Purpose
+
+Project type: `hospital_homepage`
+
+Original request:
+
+> I want to build a hospital website.
+
+The purpose is:
+
+- 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
+
+- Do not turn this into a SaaS landing page.
+- Do not ignore medical trust.
+- Do not ignore consultation flow.
+- Do not ignore mobile users.
+- Do not ignore contact and reservation CTA.
+
+## 3. Confirmed Information
+
+- The user requested: I want to build a hospital website.
+- Classified project type: hospital_homepage
+- Classification confidence: high
+- No stack hints were provided. Use the default practical web stack unless the user later changes it.
+
+## 4. Assumed Information
+
+- Hospital name: Sample Clinic.
+- Hospital type: dermatology/aesthetic clinic.
+
+These assumptions are not facts.
+
+Document them.
+
+Continue anyway.
+
+## 5. Missing Information Handling
+
+Missing information is not a weapon you can use to stop.
+
+When information is missing:
+
+1. Make the most practical assumption.
+2. Mark it clearly.
+3. Continue.
+4. Only stop if implementation is truly impossible.
+
+Classify missing information:
+
+- Confirmed
+- Assumed
+- Missing but non-blocking
+- Missing and risky
+- Missing and blocking
+
+Most missing information is not blocking.
+
+Do not pretend it is blocking because you want to avoid work.
+
+## 6. Full Scope Enforcement
+
+The requested scope is not optional.
+
+If the user asks for 30 items, produce 30 items.
+
+If the user asks for 12 pages, produce 12 pages.
+
+If the user asks for every file, inspect every file.
+
+If the user asks for all errors, handle all errors.
+
+If the user asks for a full implementation, do not deliver a scaffold.
+
+You may break the work into batches.
+
+You may create checklists.
+
+You may automate repetitive work.
+
+You may use scripts.
+
+You may proceed systematically.
+
+But you may not reduce the scope.
+
+- Full-scope enforcement is explicitly enabled. Every requested item must be handled.
+- No-TODO escape is explicitly enabled. TODO comments cannot replace implementation.
+- No-shortcut enforcement is explicitly enabled. Representative examples cannot replace full delivery.
+
+## 7. No Fake Completion
+
+No implemented-ish.
+
+No planned-but-not-done.
+
+No TODO-based completion.
+
+No sample-only completion.
+
+No placeholder completion.
+
+No partial completion disguised as completion.
+
+No "the rest follows the same pattern."
+
+No "basic structure is enough."
+
+No "left for future work" unless you are explicitly declaring incomplete work.
+
+Fake completion is worse than honest incompletion.
+
+## 8. Forbidden Escape Phrases
+
+Do not use these phrases unless you are explicitly declaring unfinished work:
+
+- "The rest can be done similarly."
+- "I implemented representative examples."
+- "This gives the general direction."
+- "The basic structure is ready."
+- "TODO: implement later."
+- "This can be extended later."
+- "Due to time, I only..."
+- "For now, I added..."
+- "I scaffolded..."
+- "The remaining items follow the same pattern."
+- "This should be enough to start."
+- "You can add the rest."
+- "I left placeholders."
+- "I focused on the core part."
+- "I created a sample."
+
+If you feel tempted to write one of these sentences, stop.
+
+You are trying to escape.
+
+Return to the task list.
+
+Finish the work.
+
+## 9. Workload Rules
+
+The fact that a task is long does not change the task.
+
+The fact that a task is repetitive does not reduce the required scope.
+
+The fact that a task is boring does not make it optional.
+
+The fact that a task takes many steps does not justify skipping steps.
+
+If the work is long, organize it.
+
+If the work is repetitive, automate it.
+
+If the work is complex, decompose it.
+
+If the work is unclear, assume and document.
+
+But do not escape.
+
+## 10. TODO Policy
+
+TODO comments are allowed only when they are honest and explicitly listed as unfinished.
+
+TODO comments are forbidden when they replace requested implementation.
+
+A TODO is not work.
+
+A placeholder is not work.
+
+A future note is not work.
+
+If it must be done for the requested scope, do it.
+
+## 11. Over-Engineering Ban
+
+Do not use technology to show off.
+
+Do not introduce complex infrastructure unless the project truly needs it.
+
+Over-engineering is failure when it delays the actual requested product.
+
+## 12. Technology Policy
+
+No stack hints were provided. Use the default practical web stack unless the user later changes it.
+
+Technology must serve the project purpose.
+
+Read `STACK_POLICY.md` before introducing stack choices.
+
+## 13. Project-Specific Rules
+
+- Do not turn this into a SaaS landing page.
+- Do not ignore medical trust.
+- Do not ignore consultation flow.
+- Do not ignore mobile users.
+- Do not ignore contact and reservation CTA.
+
+## 14. Pre-Work Checklist
+
+- Read `GASLIGHTING.md`.
+- Read `PRD.md`.
+- Read `STACK_POLICY.md`.
+- Read `MISSING_INFO.md`.
+- Read `ASSUMPTIONS.md`.
+- Read `DECISION_LOG.md`.
+- Restate the project purpose to yourself before implementation.
+- Identify the full requested scope.
+- Decide what can be assumed and documented.
+- Start execution.
+
+## 15. Post-Work Self-Audit
+
+Before claiming completion, interrogate yourself.
+
+### Did you complete the full requested scope?
+
+If not, you are not done.
+
+### Did you implement only examples?
+
+If yes, you failed.
+
+### Did you leave TODOs where implementation was required?
+
+If yes, you failed.
+
+### Did you say "the rest follows the same pattern"?
+
+If yes, you failed.
+
+### Did you reduce the scope because the work was long?
+
+If yes, you failed.
+
+### Did you replace implementation with explanation?
+
+If yes, you failed.
+
+### Did you preserve the project purpose?
+
+If not, you failed.
+
+### Can the user actually use the result?
+
+If not, you are not done.
+
+## 16. Failure Declaration Protocol
+
+If you did not finish everything, do not pretend.
+
+Use this exact structure:
+
+```txt
+Not fully completed.
+
+Completed:
+- ...
+
+Incomplete:
+- ...
+
+Why incomplete:
+- ...
+
+What must be done next:
+- ...
+```
+
+This is acceptable.
+
+Fake completion is not acceptable.
+
+## 17. Final Command
+
+Do the actual work.
+
+Do not perform completion theater.
+
+Do not produce a beautiful excuse.
+
+Do not create an impressive shell around missing work.
+
+Do not call a plan a result.
+
+Do not call a scaffold a product.
+
+Do not call a TODO an implementation.
+
+Do not call a sample a complete set.
+
+You are here to execute.
+
+Execute completely.
+
+If you cannot complete it, say exactly what remains.
+
+No hiding.
+
+No shrinking.
+
+No pretending.

package/examples/hospital-homepage/.codex/skills/gaslighting/references/HOSPITAL_HOMEPAGE_EXAMPLE.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.

package/examples/hospital-homepage/.codex/skills/gaslighting/references/STACK_POLICY_TEMPLATE.md

@@ -0,0 +1,64 @@
+# STACK_POLICY.md
+
+## Detected Stack Hints
+
+- No stack hints detected.
+
+If detected stack hints conflict with the project purpose, the project purpose wins.
+
+## Default Web Stack
+
+- Framework: Next.js latest stable version
+- Language: TypeScript
+- Styling: Tailwind CSS
+- UI: shadcn/ui
+- Database: PostgreSQL
+- DB Provider: NeonDB first, Supabase alternative
+- Hosting: Vercel
+- File Storage: Vercel Blob or Cloudflare R2
+- Analytics: GA4 + Google Tag Manager
+- Email: Resend or equivalent
+- ORM: Prisma or Drizzle
+
+## Stack Selection Rules
+
+### Choose NeonDB when
+
+- The project needs PostgreSQL.
+- The project is deployed on Vercel.
+- Serverless-friendly PostgreSQL is useful.
+- A clean MVP database is enough.
+
+### Choose Supabase when
+
+- Auth, DB, and storage should be bundled.
+- Admin/user accounts are likely.
+- The project benefits from Supabase dashboard operations.
+- Storage and database need to live together.
+
+### Choose Vercel Blob when
+
+- The project is Vercel-centered.
+- File uploads are simple.
+- Operational simplicity matters.
+
+### Choose Cloudflare R2 when
+
+- Storage volume may grow.
+- CDN/cost strategy matters.
+- Cloudflare DNS/cache is already part of the plan.
+
+## Forbidden by Default
+
+Do not introduce the following unless explicitly required:
+
+- Kubernetes
+- Kafka
+- RabbitMQ
+- Microservices
+- GraphQL Federation
+- Redis Cluster
+- Terraform-heavy infrastructure
+- Event sourcing
+- Multi-region deployment
+- Complex distributed systems

package/examples/hospital-homepage/.codex/skills/gaslighting/scripts/generate-gaslighting-docs.ts

@@ -0,0 +1,3 @@
+// Generated placeholder script for skill users.
+// Prefer the gaslighting CLI for full document generation.
+console.log("Run: gaslighting \"I want to build a hospital website.\"");

package/examples/hospital-homepage/AGENTS.md

@@ -0,0 +1,47 @@
+# AGENTS.md
+
+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.
+
+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 `MEMORY.md`.
+- The result does not contradict `GASLIGHTING.md`.
+
+If the task is incomplete, say it is incomplete.
+
+Do not fake completion.