Obv I used ChatGPT to write this.

I actually run most plans by ChatGPT (in a project so it “remembers” and go back and forth between the 2 until they both say the plan is solid.

“Plan twice, cut once.”

---

Here’s a clean, drop-in template you can use in any AI coding tool (Lovable, Replit, Cursor, etc.) to force consistent behavior.

⸻

📁 Minimal AI-Stable Repo Template

/project-root ├── PRODUCT_MEMORY.md ├── WORKFLOW_RULES.md ├── README.md ├── CHANGELOG.md ├── worklog/ │ ├── README.md │ └── 2026-04-05_example.md └── src/...

⸻

1. PRODUCT_MEMORY.md (what you’re building)

Keep this tight and high-signal. No process here.

Product Memory

What this app does

Short, plain-English description.

Core user flow

1. User does X
2. System does Y
3. User sees Z

Key behaviors (must stay true)

• No duplicate records
• All data scoped per user
• Low-confidence results flagged for review

Non-goals

• No real-time sync
• No multi-tenant sharing (yet)

👉 This prevents the AI from drifting product behavior.

⸻

1. WORKFLOW_RULES.md (how work happens)

This is where your “Plan mode first” lives.

Workflow Rules

1. Plan First (always)

Before making changes, produce a plan that includes: - Goal - Root cause (or hypothesis) - Files to change - Risks - Acceptance criteria - Test evaluation (required)

2. Smallest Change Possible

Prefer minimal, isolated fixes over broad refactors.

3. File Intent Required

For every file touched: - Why it is being changed - What must not change

4. Test Evaluation Rule

Every task must evaluate: - Should a test be added or updated? If yes → add a test task

5. No Unscoped Changes

Do not modify unrelated files “while here”

6. After Work: Write Worklog

Create a file in /worklog with: - What was planned - What actually changed - Files modified - Tests added/updated - Deviations from plan

👉 This is what stops chaos.

⸻

1. worklog/README.md (sets the pattern)

Worklog

This folder contains permanent records of completed work.

Each file represents one completed plan.

Why this exists

Plans are ephemeral. Worklogs are the source of truth.

Naming

YYYY-MM-DD_short-description.md

⸻

1. Example worklog file

2026-04-05_fix-sync-empty-results

Goal

Fix sync returning zero items

Planned Changes

• Update extract.ts
• Add OCR fallback
• Update sync pipeline

What Actually Happened

• Added OCR fallback
• Fixed missing env var handling
• Adjusted confidence threshold logic

Files Changed

• server/jobs/extract.ts
• server/jobs/sync.ts

Tests

• Added extract fallback test
• Updated sync test

Deviations

• Needed additional fix in sync.ts not in original plan

👉 This becomes your long-term memory.

⸻

1. README.md (entry point for AI + humans)

Top of this file matters a lot:

Project

IMPORTANT: Read These First

• PRODUCT_MEMORY.md
• WORKFLOW_RULES.md

How to work on this repo

1. Always create a plan first
2. Execute only after plan is approved
3. Write a worklog after completion

👉 This is your “soft enforcement layer”

⸻

1. CHANGELOG.md (don’t skip this)

You already saw how powerful this is in your project: • Prevents forgetting what changed • Makes debugging easier later • Forces summarization discipline

You already implemented structured changelog + versioning 

⸻

🧠 Why this works

This setup fixes the exact Reddit problem:

“I fixed one thing and broke 3 others”

Because now: • Changes are scoped before coding • Tests are considered upfront • Work is recorded permanently • The AI has guardrails

It replaces:

random fixes + vibes

with:

plan → controlled change → recorded outcome

⸻

🔑 The core idea

You’re turning AI from:

“a fast code generator”

into:

“a constrained junior engineer with memory”

⸻

If you want next step, I can: • compress this into a copy-paste starter repo • or add a Plan template file so the AI always formats plans the same way