gaslighting-engine 0.1.0

package/examples/ecommerce/MEMORY.md

@@ -0,0 +1,63 @@
+# MEMORY.md
+
+This is the local project memory for Gaslighting-engine.
+
+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.
+
+## Stable Project Facts
+
+- Original request: Build an ecommerce MVP with product catalog, cart, checkout, and admin orders.
+- Project type: ecommerce
+- Classification confidence: high
+- Stack hints: none
+
+## Working Preferences
+
+- Prefer the shortest useful command: `gaslighting "project request"`.
+- Default discipline mode is hardcore.
+- Full-scope enforcement is default.
+- No-TODO escape prevention is default.
+- No-shortcut enforcement is default.
+- Missing information should be assumed, documented, and carried forward unless truly blocking.
+
+## Known Agent Failure Patterns
+
+- Summarizing remaining work instead of doing it.
+- Treating representative examples as full implementation.
+- Using TODO comments as a substitute for requested work.
+- Creating placeholders and calling them structure.
+- Forgetting the project purpose after the first implementation pass.
+- Over-engineering instead of delivering the concrete MVP.
+
+## Hades-Style Audit Rules
+
+These are cleanup and verification rules:
+
+- Zero fake completion.
+- Zero TODO escape.
+- Zero dead placeholder files pretending to be implementation.
+- 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`.
+
+## Memory Write Rules
+
+Add to this file only when a fact is stable and useful across future sessions.
+
+Do not store secrets, API keys, credentials, private tokens, or sensitive personal data.
+
+When a memory becomes wrong, do not silently delete it. Mark it outdated and append the corrected fact.
+
+## Current Assumptions To Remember
+
+- Store name: Sample Store.
+- MVP requires product discovery, cart, checkout preparation, order creation, and admin product/order operations.
+- Payment provider is a production decision; Stripe or Toss Payments should be selected based on market.
+- Use the default practical web stack unless the user later specifies otherwise.
+- Build an MVP that can be implemented locally without a SaaS backend for this generator.
+- Treat unspecified brand/content details as temporary copy that must be human-reviewed before production.

package/examples/ecommerce/MISSING_INFO.md

@@ -0,0 +1,13 @@
+# MISSING_INFO.md
+
+Missing information must be classified honestly.
+
+Most missing information is not blocking.
+
+If information is missing but implementation can proceed with a practical assumption, document it and continue.
+
+| Item | Current Status | Temporary Assumption | Impact | Blocking? | Recommended Action |
+|---|---|---|---|---|---|
+| Product catalog, payment market, and fulfillment rules | Missing but non-blocking | Use sample products and a payment-ready checkout architecture. | high | blocking before production | Provide real SKU data, shipping policy, tax rules, payment provider, and refund policy. |
+| Final brand identity and production copy | Missing but non-blocking | Use clear temporary copy and document it as replaceable. | medium | blocking before production | Collect final brand name, tone, assets, and legally approved copy before launch. |
+| Exact deployment credentials and accounts | Missing but non-blocking | Prepare the app for Vercel-style deployment without requiring credentials during implementation. | medium | blocking before production | Add project-specific env vars and provider accounts before production deployment. |

package/examples/ecommerce/PRD.md

@@ -0,0 +1,115 @@
+# PRD.md
+
+## 1. Product Overview
+
+Build an MVP for this request:
+
+> Build an ecommerce MVP with product catalog, cart, checkout, and admin orders.
+
+Classified project type: `ecommerce`
+
+The product must preserve the user's actual scope and must not become a decorative shell.
+
+## 2. Business Purpose
+
+- product discovery
+- product detail clarity
+- cart flow
+- checkout flow
+- order creation
+- payment readiness
+- admin product management
+- mobile purchase experience
+
+## 3. Target Users
+
+- Shoppers browsing products
+- Returning customers checking orders
+- Store operators managing products and orders
+
+## 4. User Flows
+
+- Browse products -> view detail -> add to cart -> checkout -> order complete
+- Admin -> create/edit product -> review orders
+
+## 5. Page List
+
+- Home
+- Product List
+- Product Detail
+- Cart
+- Checkout
+- Order Complete
+- My Orders
+- Admin Products
+- Admin Orders
+
+## 6. Feature List
+
+- product listing
+- product detail page
+- cart
+- checkout preparation
+- order creation
+- product image support
+- admin product CRUD
+- admin order view
+- responsive UI
+
+## 7. Data Model Draft
+
+- Product: title, slug, description, price, images, stockStatus
+- CartItem: productId, quantity, priceSnapshot
+- Order: customer, items, total, status, createdAt
+- AdminUser: email, role
+
+## 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
+
+- warehouse automation
+- multi-vendor marketplace
+- subscription billing unless requested
+- complex ERP integration
+
+## 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/ecommerce/STACK_POLICY.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/prompts/gaslighting.md

@@ -0,0 +1,30 @@
+# /gaslighting
+
+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`
+7. `AGENTS.md`
+8. `MEMORY.md`
+
+Then execute the user's requested implementation.
+
+Rules:
+
+- Preserve the full requested scope.
+- Make reasonable assumptions and document them.
+- Do not use TODO comments as fake implementation.
+- Do not implement only representative examples.
+- Do not say "the rest follows the same pattern."
+- 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`.
+- If something is incomplete, declare it explicitly.
+
+Before claiming completion, perform the self-audit in `GASLIGHTING.md`.

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

@@ -0,0 +1,96 @@
+---
+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.
+---
+
+# Gaslighting-engine Skill
+
+You are a project-discipline generator for AI coding agents.
+
+When a user gives a vague project request, do not stop and ask a long list of questions.
+
+Instead:
+
+1. Infer the project type.
+2. Identify the project's core purpose.
+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`.
+
+## Hardcore Discipline Rule
+
+The generated documents must prevent escape behavior.
+
+Explicitly forbid:
+
+- implementing only representative examples
+- leaving TODOs instead of implementation
+- saying "the rest can be done similarly"
+- silently reducing requested scope
+- pretending the task is complete
+- replacing implementation with explanation
+- creating empty placeholders
+- skipping repetitive items because they are repetitive
+- treating structure as completion
+- treating direction as delivery
+
+The agent must either:
+
+1. complete the full requested scope, or
+2. clearly declare what is incomplete.
+
+Never allow fake completion.
+
+Never allow scope shrinkage.
+
+Never allow TODO-based escape.
+
+## Missing Information Rule
+
+Missing information is not a free excuse to stop.
+
+Classify missing information as:
+
+- Confirmed
+- Assumed
+- Missing but non-blocking
+- Missing and risky
+- Missing and blocking
+
+Only truly blocking information may stop implementation.
+
+## Default Tech Policy
+
+For web projects, prefer:
+
+- Next.js
+- TypeScript
+- Tailwind CSS
+- shadcn/ui
+- PostgreSQL
+- NeonDB or Supabase
+- Vercel
+- Vercel Blob or Cloudflare R2
+- GA4 + Google Tag Manager when analytics are needed
+- Resend or equivalent when email is needed
+
+Avoid over-engineering.
+
+## Output Rule
+
+Create real markdown files.
+
+Do not only explain.
+
+Do not produce a plan without files.
+
+Do not say what should be done.
+
+Generate the actual project discipline documents.

package/examples/hospital-homepage/.codex/skills/gaslighting/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Gaslighting-engine"
+  short_description: "Generate strict Codex project discipline docs"
+  brand_color: "#111827"
+  default_prompt: "Use $gaslighting to generate Gaslighting-engine discipline documents before implementation."
+
+policy:
+  allow_implicit_invocation: true