| name | drift-protection |
| description | Use during PM mode BUILD or whenever the user asks "is this still on-strategy". Auto-fires every 5 completed features. Audits the last 5 against IDENTITY.md (WHO/JOB/NEVER), Architecture Constraints, contracts (if applicable), and rework patterns. Returns CONTINUE / DISCUSS / PIVOT / CONTRACT_HALT and flags STABILIZE if quality is degrading. |
Drift Protection
Drift checks are the single most-distinctive primitive in PM mode. They're the reason the framework can run forever without slowly building the wrong product.
Cadence
- Auto: every 5 completed features during
/forge:build. The orchestrator dispatches the drift-detector agent automatically.
- Manual:
/forge:drift any time — after a refactor, before a release, after an identity update.
The 6 checks (per feature, last 5 done)
| # | Check | What's being audited |
|---|
| 1 | Serves WHO? | Does this improve life for the IDENTITY.md persona? |
| 2 | Serves JOB? | Does this make the JOB easier or remove a step? |
| 3 | Violates NEVER? | Does any aspect of this do something the NEVER list forbids? |
| 4 | Respects Architecture Constraints? | Right module, existing patterns, no unnecessary cross-module coupling? |
| 5 | Respects contracts? | (if contract_mode != "none") API shape preserved, schema additive, events versioned? |
| 6 | Is this rework? | Did it modify recently-shipped code? Pattern across multiple features? |
Each check is a verdict: YES / NO / DRIFT.
Verdict ladder
| Verdict | Meaning |
|---|
| CLEAR | All 6 checks YES across all 5 features |
| DRIFT | One feature violates WHO/JOB/NEVER/architecture |
| CONTRACT_VIOLATION | Breaks a published contract without an approved migration path |
| ARCHITECTURE_DEGRADATION | Adds complexity to hot paths or crosses module boundaries unnecessarily |
| REWORK_PATTERN | 2+ rework flags across last 5 features |
Recommendation matrix
| Recommendation | Trigger |
|---|
| CONTINUE | All clear, no stabilization indicators |
| DISCUSS | One DRIFT, surface to user, no halt |
| PIVOT | Pattern of DRIFT — identity may need to evolve |
| CONTRACT_HALT | CONTRACT_VIOLATION — halt the release until resolved |
| STABILIZE | Stabilization indicators firing — next SHAPE should be a stabilization release |
Stabilization indicators
Separate from drift verdicts. Flag STABILIZE if any:
- Avg
quality_score of last 5 features < 6.0
- 2+ REWORK flags in last 5 features
- Avg
build_resets > 2.0
- 2+ ARCHITECTURE_DEGRADATION findings in last 5 features
What CONTRACT_HALT means
Hardest blocker in the framework. Stronger than DRIFT. The release stops. No new features ship until either:
- The breaking change is rolled back, OR
- The breaking change is explicitly approved with a migration path documented in
contracts.md.
This is why contract_mode: "full" is opt-in — it's expensive but it's also why you can ship 50 releases without breaking your customers.
What PIVOT means
The drift report is telling you: your IDENTITY.md doesn't match the product you're actually building. Two valid responses:
- Update IDENTITY.md — your understanding of WHO/JOB/NEVER has evolved (good — this is identity-as-signal). Append an Evolution Log entry with the trigger evidence.
- Roll back the drifting features — your IDENTITY.md is correct; you accidentally built off-strategy. Kill the drift in the next SHAPE.
Don't do both. Don't do neither.
How drift reports get persisted
Every report appends to progress.md under "Recent Drift Reports":
### YYYY-MM-DD — {recommendation}
- Per-feature audit table
- Stabilization indicators
- Findings
- Rationale
Past reports are read on every future drift check. The framework learns from its own audit history.
Common drift patterns
These are the patterns that show up repeatedly across products. Watch for them:
- Feature creep into adjacent personas. WHO is "SOC analyst" but the last 3 features serve "CISO directly." Either evolve WHO to dual-persona, or kill the CISO features.
- NEVER violations on the way to a sale. A buyer asks for X, X violates NEVER, you ship X anyway. The drift report catches it. The right move is to lose the deal or evolve the NEVER deliberately.
- Architecture-creep through "small" features. Each one looks fine in isolation; together they've created a 4-module entanglement that isn't in
architecture.md. The drift detector flags ARCHITECTURE_DEGRADATION.
- Slow rework drift. No single feature is rework, but you've modified the executor 3 times in 5 features. REWORK_PATTERN fires. Something upstream is unclear — usually a missing contract or a feature spec that didn't survive contact with reality.
Why every-5-features
Per-feature drift checks are noise — too sensitive, lots of false positives. Per-release drift checks are too coarse — drift gets baked in by the time you check. Every 5 is the empirically-right cadence: enough features to see a pattern, few enough to catch drift before it ships.
