gaslighting-engine 0.1.0

package/examples/landing-page/ASSUMPTIONS.md

@@ -0,0 +1,146 @@
+# ASSUMPTIONS.md
+
+## Assumption: The page has one primary conversion goal
+
+Status: Active
+Confidence: High
+Impact: High
+
+### Why this assumption was made
+
+The page has one primary conversion goal.
+
+The user did not provide enough confirmed detail to treat this as fact.
+
+### What could make this wrong
+
+The user provides a different business model, vertical, stack, audience, market, or production constraint.
+
+### What changes if this assumption is wrong
+
+The PRD, page list, data model, implementation priorities, and copy may need to change.
+
+### How to replace this assumption
+
+Provide confirmed information and run `gaslighting update "new information here"`.
+
+## Assumption: Offer details are temporary and must be replaced by the owner
+
+Status: Active
+Confidence: High
+Impact: Medium
+
+### Why this assumption was made
+
+Offer details are temporary and must be replaced by the owner.
+
+The user did not provide enough confirmed detail to treat this as fact.
+
+### What could make this wrong
+
+The user provides a different business model, vertical, stack, audience, market, or production constraint.
+
+### What changes if this assumption is wrong
+
+The PRD, page list, data model, implementation priorities, and copy may need to change.
+
+### How to replace this assumption
+
+Provide confirmed information and run `gaslighting update "new information here"`.
+
+## Assumption: A lead form and repeated CTA path are required
+
+Status: Active
+Confidence: High
+Impact: Medium
+
+### Why this assumption was made
+
+A lead form and repeated CTA path are required.
+
+The user did not provide enough confirmed detail to treat this as fact.
+
+### What could make this wrong
+
+The user provides a different business model, vertical, stack, audience, market, or production constraint.
+
+### What changes if this assumption is wrong
+
+The PRD, page list, data model, implementation priorities, and copy may need to change.
+
+### How to replace this assumption
+
+Provide confirmed information and run `gaslighting update "new information here"`.
+
+## Assumption: Use the default practical web stack unless the user later specifies otherwise
+
+Status: Active
+Confidence: High
+Impact: Medium
+
+### Why this assumption was made
+
+Use the default practical web stack unless the user later specifies otherwise.
+
+The user did not provide enough confirmed detail to treat this as fact.
+
+### What could make this wrong
+
+The user provides a different business model, vertical, stack, audience, market, or production constraint.
+
+### What changes if this assumption is wrong
+
+The PRD, page list, data model, implementation priorities, and copy may need to change.
+
+### How to replace this assumption
+
+Provide confirmed information and run `gaslighting update "new information here"`.
+
+## Assumption: Build an MVP that can be implemented locally without a SaaS backend for this gen
+
+Status: Active
+Confidence: High
+Impact: Medium
+
+### Why this assumption was made
+
+Build an MVP that can be implemented locally without a SaaS backend for this generator.
+
+The user did not provide enough confirmed detail to treat this as fact.
+
+### What could make this wrong
+
+The user provides a different business model, vertical, stack, audience, market, or production constraint.
+
+### What changes if this assumption is wrong
+
+The PRD, page list, data model, implementation priorities, and copy may need to change.
+
+### How to replace this assumption
+
+Provide confirmed information and run `gaslighting update "new information here"`.
+
+## Assumption: Treat unspecified brand/content details as temporary copy that must be human-rev
+
+Status: Active
+Confidence: High
+Impact: Medium
+
+### Why this assumption was made
+
+Treat unspecified brand/content details as temporary copy that must be human-reviewed before production.
+
+The user did not provide enough confirmed detail to treat this as fact.
+
+### What could make this wrong
+
+The user provides a different business model, vertical, stack, audience, market, or production constraint.
+
+### What changes if this assumption is wrong
+
+The PRD, page list, data model, implementation priorities, and copy may need to change.
+
+### How to replace this assumption
+
+Provide confirmed information and run `gaslighting update "new information here"`.
+

package/examples/landing-page/CODEX_PROMPT.md

@@ -0,0 +1,34 @@
+# CODEX_PROMPT.md
+
+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`
+7. `AGENTS.md`
+8. `MEMORY.md`
+
+Then implement the project MVP.
+
+Rules:
+
+- Do not shrink the scope.
+- Do not leave TODOs instead of 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.
+- Do not forget the project purpose.
+- If something is incomplete, declare it explicitly.
+
+Before claiming completion, perform the self-audit in `GASLIGHTING.md`.
+
+Proceed.

package/examples/landing-page/DECISION_LOG.md

@@ -0,0 +1,95 @@
+# DECISION_LOG.md
+
+## Decision: Initialize Gaslighting documents
+
+Date: 2026-05-23
+
+### Decision
+
+Generate strict Gaslighting-engine project-control documents for the request:
+
+> Build a landing page for a new service that captures leads.
+
+### Reason
+
+The project needs AI-agent discipline before implementation so the agent does not drift, shrink scope, leave TODOs, or fake completion.
+
+### Alternatives Considered
+
+- Start coding without discipline documents.
+- Ask the user a long list of questions before making progress.
+- Use an LLM API to generate custom documents.
+
+### Why Alternatives Were Not Chosen
+
+- Coding without control documents increases fake-completion risk.
+- Most missing information can be assumed and documented.
+- MVP must be deterministic and must not call an LLM API.
+
+### Risk
+
+The initial project type or assumptions may be wrong.
+
+### Revisit When
+
+The user provides confirmed business details, stack choices, scope changes, or production constraints.
+
+## Decision: Project type classification
+
+Date: 2026-05-23
+
+### Decision
+
+Classified project type as `landing_page` with `high` confidence.
+
+### Reason
+
+Keyword-based classification is deterministic and enough for MVP.
+
+### Alternatives Considered
+
+- Ask the user to classify the project manually.
+- Use an external LLM API.
+
+### Why Alternatives Were Not Chosen
+
+- Manual classification slows progress.
+- External LLM APIs are excluded from MVP.
+
+### Risk
+
+Low-confidence classification can create the wrong project-specific template.
+
+### Revisit When
+
+The user says the project type is different or adds a clearer project description.
+
+## Decision: Stack policy
+
+Date: 2026-05-23
+
+### Decision
+
+No stack hints were provided. Use the default practical web stack unless the user later changes it.
+
+### Reason
+
+Technology must serve the product purpose and avoid over-engineering.
+
+### Alternatives Considered
+
+- Introduce advanced infrastructure up front.
+- Leave stack completely undefined.
+
+### Why Alternatives Were Not Chosen
+
+- Advanced infrastructure is forbidden by default.
+- Undefined stack choices allow drift and inconsistent agent behavior.
+
+### Risk
+
+Production needs may require a provider change later.
+
+### Revisit When
+
+Deployment provider, database provider, storage, analytics, email, or payment requirements are confirmed.

package/examples/landing-page/GASLIGHTING.md

@@ -0,0 +1,424 @@
+# 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: `landing_page`
+
+Original request:
+
+> Build a landing page for a new service that captures leads.
+
+The purpose is:
+
+- make the offer clear within 5 seconds
+- drive CTA clicks
+- capture leads
+- support ad traffic
+- reduce bounce
+- communicate value clearly
+- load fast on mobile
+
+- Do not create a decorative page with no conversion path.
+- A landing page without CTA is a failure.
+- A page with vague messaging is a failure.
+
+## 3. Confirmed Information
+
+- The user requested: Build a landing page for a new service that captures leads.
+- Classified project type: landing_page
+- Classification confidence: high
+- No stack hints were provided. Use the default practical web stack unless the user later changes it.
+
+## 4. Assumed Information
+
+- The page has one primary conversion goal.
+- Offer details are temporary and must be replaced by the owner.
+- A lead form and repeated CTA path are required.
+- 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.
+
+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 create a decorative page with no conversion path.
+- A landing page without CTA is a failure.
+- A page with vague messaging is a failure.
+
+## 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.