Module 5 Project Navigation and Metrics
Status: Complete · How a team of one measures and steers work without story points.
Story points, burndown charts, and man‑months exist to measure collective human effort and time spent in alignment. For a solo operator they are meaningless. The SAE measures execution complexity using Context Entropy Ratings — how much context preparation a task demands before generation.
| Rating | Band | Description | Prep required | Expected time |
|---|---|---|---|---|
| 1–3 | Low entropy | Linear feature addition inside a single, tightly‑constrained bounded context | Minimal — fire the agent | Minutes |
| 5–8 | Medium entropy | Multi‑file feature touching several schemas and external webhooks | Audit the Markdown spec before generation | Under an hour |
| 13 | High entropy | System‑wide change, major third‑party integration, or paradigm shift | Meticulously redefine context boundaries and rules first | A single afternoon |
The scale is Fibonacci‑flavoured to reflect that entropy compounds — a "13" is not 13× a "1", it's a different class of work that requires re‑establishing the context window before you touch anything.
How to use it. Before starting a task, name its rating out loud. A "1–3" means just do it. A "13" is a signal to stop and spec — rushing a high‑entropy change into a cold context window is how you get confident, plausible, wrong output. The rating is a prompt to invest in clarity proportional to risk.
Reality check. Context Entropy measures preparation difficulty, not business value or risk. A 1‑line change to an auth check is "low entropy" but high stakes. Don't let a low rating lower your guard on security‑ or money‑touching code — pair the entropy rating with a simple blast‑radius check (what breaks if this is wrong?).
With one operator owning the whole lifecycle, the loop from production anomaly → code fix must be automated. The SAE builds a self‑healing circle:
┌─────────────────────────────────────────┐
│ PRODUCTION │
│ (telemetry · traces · error payloads) │
└─────────────────────┬─────────────────────┘
│ exception captured
▼
┌─────────────────────────────────────────┐
│ AI AGENT CONTEXT LOOP │
│ cross-reference stack trace ↔ codebase │
│ isolate root cause → draft SPEC change │
└─────────────────────┬─────────────────────┘
│ proposed spec amendment
▼
┌─────────────────────────────────────────┐
│ HUMAN CONDUCTOR (1 click) │
│ review amendment → approve correction │
└─────────────────────┬─────────────────────┘
│ zero-ops pipeline
▼
back to PRODUCTION
- Telemetry, traces, and exceptions route into a dedicated sandbox.
- On a crash, the error payload is fed into the agent context loop.
- The agent cross‑references the stack trace against the codebase, isolates the root cause, and drafts the exact spec amendment (not a raw code patch) needed to fix it.
- The operator reviews the amendment, approves the correction, and the Zero‑Ops pipeline ships it.
Note the discipline carried from Module 2: the fix flows through the spec, so the source of truth never drifts.
Reality check. "One‑click fix" is the goal state for well‑understood, low‑blast‑radius bugs. The human approval step is not a rubber stamp — it is the control that keeps an auto‑remediation loop from confidently shipping a wrong fix to production and then "healing" the symptom while masking the real cause. Keep the loop proposing, keep the human deciding, and never auto‑apply to anything touching auth, payments, or data deletion.
▶ Putting it into practice: the full measurement system (flow / quality / health, starter scorecard, anti‑gaming) in KPIs & Metrics · where each metric is produced in The End‑to‑End Lifecycle.
You've completed the core playbook. Next: build something → Getting Started, or contribute → Contribution Guidelines.