Operations Phase

What is the Operations phase?

The Operations phase runs after the human approves the review of an epic. It closes the delivery cycle with three responsibilities:

Deploy preparation — what must happen before and after shipping
Observability definition — how to know the epic is healthy in production
Context sync — updating global memory for future epics

`/epic-close <N>`

/epic-close

The 🚀 Ops agent asks for the epic number, then reads:

doc-specs/<N>-epic/spec-epic-N.md
doc-specs/<N>-epic/PRD.md
doc-specs/<N>-epic/decisions-log.md
doc-specs/CONTEXT.md

It generates doc-specs/<N>-epic/ops-epic-N.md with:

Section	Contents
Deploy preparation	Required env vars, infra dependencies, migration sequence, feature flags, rollback plan
Breaking changes	Any changes that affect other services or future epics
Observability	Critical logs to monitor, health metrics, alerts to configure
Production validation	How to confirm this epic works correctly in production
Technical debt	Debt generated by this epic that must be addressed in future epics
Anomaly patterns	What distinguishes normal from abnormal behavior for the features delivered
Feedback for future epics	Risks, learnings, and suggested adjustments to `epics.md`

✅ HITL: Review ops-epic-N.md before deploying.

Is the deploy sequence safe?
Are all breaking changes documented?
Are anomaly patterns precise enough for on-call monitoring?

Production gate

After reviewing ops-epic-N.md, the production gate is manual — no prompt or agent involved:

Merge the epic branch (feat/E<NN>-<slug>) to main
Execute the deploy
Validate in production using the criteria defined in ops-epic-N.md
Only after production validation can the next epic begin

`/context-sync <N>`

/context-sync

After the production gate passes, the 🏗️ Architect agent reads ops-epic-N.md and decisions-log.md and updates doc-specs/CONTEXT.md with:

Summary of the completed epic
All ADRs (architectural decision records) from decisions-log.md
Technical debt registered by the Ops agent
Risks and learnings that affect future epics

CONTEXT.md is the project's long-term memory. Every agent reads it before acting on any epic. Keeping it accurate is what ensures each epic builds on a shared, validated understanding of what was built before.

Incident triage (ongoing)

At any point after an epic ships, if an incident is observed in production:

/ops-triage

The 🚀 Ops agent:

Asks for the symptom observed and the potentially affected epic
Reads ops-epic-N.md and maps the symptom to documented anomaly patterns
Proposes graduated actions: contain → mitigate → fix → prevent
Records the triage in doc-specs/<N>-epic/incident-log.md
If the incident reveals a gap in the playbook or requires a permanent fix, flags it as technical debt in epics.md

The Ops agent does not execute actions in production — it proposes, documents, and closes the learning loop.

The loop for the next epic

/context-sync <N> completes
       ↓
  CONTEXT.md updated
       ↓
  /epic-init <N+1>
       ↓
  Spec phase → Epic phase → Operations phase
       ↓
  Repeat until epics.md is complete

Each time the loop repeats, the Architect agent reads the updated CONTEXT.md, ensuring every subsequent epic is informed by the full history of decisions, debt, and learnings from all previous epics.