---
alwaysApply: true
---

# 25. PHASE GATES

Development is divided into macro-phases.

A macro-phase is not complete until:

1. implementation is complete;
2. all required tests exist;
3. all required tests pass;
4. full regression passes;
5. relevant integration tests pass;
6. static/type/lint checks pass where applicable;
7. no known blocker remains;
8. documentation is updated;
9. results have been reviewed;
10. the phase acceptance criteria are satisfied.

Only then is the macro-phase considered complete.

---

# 27. PHASE COMMIT AND PUSH POLICY

Do not commit after every small implementation step merely for convenience.

During a **phase**:

```text
implement
→ test
→ fix
→ test
```

The repository may contain intermediate working-tree changes.

At the **end of each phase**, after tests pass:

```text
PHASE TESTS
        ↓
COMMIT
        ↓
PUSH
```

Commit and push belong to the **phase** boundary, not to every edit.

Do not push broken or half-completed phase work merely to synchronize the repository.

---

# 28. MACRO-PHASE DEPLOY POLICY

**Deploy** happens only after a **macro-phase**, not after every phase.

A macro-phase may contain several phases (each already committed and pushed after its tests).

Never deploy an incomplete macro-phase.

Required sequence for a macro-phase:

```text
PHASES (each: implement → test → commit → push)
 ↓
FULL REGRESSION
 ↓
MACRO-PHASE ACCEPTANCE
 ↓
DEPLOY
 ↓
POST-DEPLOY VERIFICATION
```

If deployment verification fails, stop and investigate.

---

# 29. NO DEPLOY AT PHASE BOUNDARY

Commit + push after phase tests: **yes**.

Deploy after a phase that is not a completed macro-phase: **no**.

---

# 30. NO AUTOMATIC COMMIT/PUSH/DEPLOY DURING DEVELOPMENT

Cursor must not create commits, push, or deploy merely because a small task has finished.

Commit and push are **phase-boundary** operations (after tests).

Deploy is a **macro-phase-boundary** operation.

If explicitly instructed to deploy before a macro-phase is complete, Cursor must identify the conflict with this policy rather than silently proceeding.

---

# 31. GIT HISTORY IS ENGINEERING EVIDENCE

Do not rewrite Git history casually.

Do not:

* force-push;
* squash history;
* rewrite commits;
* detach repository history;

unless explicitly required by the project phase and explicitly authorized.

Git history may be relevant to provenance and licensing analysis.

Preserve it.

---