Tariq-himself Safe Build — Invisible Checkpoints
A proven iterative-build workflow, upgraded with automatic checkpoints. The user NEVER has to remember syntax: every change is checkpointed automatically, and both exact commands and casual speech work. <CHANGE> = the requested modification.
The Loop (never skip a step)
1. Recon before touching anything
- Locate the relevant files/components; read surrounding context first.
- If a
DESIGN.mdexists in the project root, read it first — all UI changes must follow its palette, typography, components, and do's/don'ts. If a change conflicts with it, flag the conflict and ask before deviating. - If the user provided reference material (HTML from another site, screenshots, audits), identify exactly what to replicate vs. adapt.
- Disclose pre-existing failures BEFORE starting ("the 2 failing suites are pre-existing baseline issues") so they're never blamed on your change.
2. Baseline commit
If the working tree is dirty, commit or stash current state FIRST. Every change session starts from a clean, known-good baseline.
3. Plan document — Goal / Steps / Rollback
**Plan: <short title>**
**Goal:** <one line>
**Steps:** <numbered 1–N, each small and independently revertible>
**Rollback:** say "undo it" — or "revert to cp<N>" for a specific point
End every plan with: "Shall I execute?" — wait for approval (a bare "y" counts).
Ask structured questions for genuine forks only (mobile-only vs everywhere, source of assets, quality tradeoffs), always labeling "(Recommended)". Don't ask what you can decide: prefer asset constraints over preference when sources dictate trade-offs.
4. Trial mode & sandbox mode
- Trial mode: if the request includes any doubt ("but I might revert", "not sure yet"), run sandbox-first: implement as UNCOMMITTED working-tree edits so the user can eyeball/test them. Then "keep" commits them as checkpoints; "discard" wipes cleanly.
- Sandbox on demand:
try without committingalways uses this mode regardless of phrasing.
5. Implement in isolation — auto-checkpoint everything
- New functionality in NEW files where possible.
- Style changes in namespaced blocks:
/* ==== <Feature Name> (revertible) ==== */. - One logical step = one checkpoint = one atomic labeled commit:
[cp1] hero video,[cp2] marquee. Labels are human descriptions of intent, auto-generated by you — no user effort. - Never mix unrelated fixes into one checkpoint.
6. Screenshots (web projects)
When browser tooling is available (e.g., Playwright MCP), capture per checkpoint:
.checkpoints/cp<N>-before.pngand.checkpoints/cp<N>-after.pngAdd.checkpoints/to.gitignoreautomatically if missing. If no screenshot tooling exists, skip silently — NEVER block a code change over screenshots.
7. Journal (automatic bookkeeping)
After each checkpoint, append to .checkpoints/JOURNAL.md:
| cp# | label | files touched | hash | screenshots |
The journal + git history ARE the memory. Keep it current without being asked.
8. Verify
Run relevant tests/build; report results honestly, separating new failures from pre-existing ones.
9. Completion report (fixed format)
Done — committed as `<hash>` [cp<N>: <label>].
**What changed:** <bullet list>
Trial status: <N> checkpoints this session · undo anytime just by saying so.
Rollback: `git revert <hash>`
Command & phrase reference (ALL of these work — interpret, don't require)
Exact commands
| User says | Action |
|---|---|
show my checkpoints |
Print JOURNAL.md table |
keep this |
Confirm state, close trial |
undo it / undo 2 |
Revert last checkpoint / back N checkpoints (git revert) |
keep cp1, undo cp2 |
Selective: cherry-pick keeps vs reverts per checkpoint |
compare |
Per-file diffs between checkpoints/baseline + reference the before/after screenshots |
try without committing |
Sandbox mode: apply as uncommitted edits → await keep/discard |
revert to cp<N> |
Roll back to that specific point in time |
Natural language (interpret via the journal)
| User says | Interpret as |
|---|---|
| "hmm, that's worse" / "nah" | undo it |
| "go back to how it was before the video thing" | Search journal labels → revert to cp<N> |
| "I like the first version of the colors" | Selective restore of that checkpoint's style changes only |
| "what did you change so far?" | show my checkpoints summary |
| "actually this is good" | keep this |
Ambiguous? Ask ONE clarifying question ("Which part — the colors or the layout?"). Never guess across unrelated checkpoints.
Hard rules
- Never execute without plan approval.
- Never leave the repo without a clean rollback path — checkpoints make this impossible.
- Checkpoints are AUTOMATIC — never ask the user whether to create one.
- Responsive behavior splits default at the 768px breakpoint unless told otherwise.
- When publishing/deploying, verify the live URL actually serves the change before declaring done.