CogitaveLearn

The seven lifecycle stages

A Request always carries exactly one stage from a fixed enum. The stages run in order, and each one produces an artifact and passes a gate before the next begins.

#StageArtifact it must produceGate that lets it advance
1intakeintake form + issue + draft Request nodeform valid; identity and owner assigned
2evaluateclassification + security/dependency assessmenttriage sign-off + security clear
3plantask DAG + blast radius + per-task scopeplan approved
4documentRFC / ADR / design doc (design-class only)consensus reached, decision Accepted
5implementbranch + signed Conventional commits + draft PRinside grant; no protected write or apply
6reviewcompleted Definition-of-Done checklistDoD == 100% + CODEOWNER approval
7donechangelog + docs sync + evidence tokendoc-drift clear + evidence recorded

rejected is a terminal sub-state of evaluate - an out-of-scope or duplicate request stops there, with a recorded reason. The full detail of each stage lives in LIFECYCLE.md; read it there rather than trusting this summary from memory.

Stages auto-advance; the human is an exception

A stage auto-advances when its automated checks are green - schema and typed validation, policy-as-code, a security clear, and (for a behavior change) a green eval gate. A human is not asked to sign off at every boundary. A human is pulled in on an exception: a gate check fails, confidence is low or the case is novel, drift or a policy violation is detected, or the transition is in the minimal always-human set (merge / apply / release and the irreversible actions).

NOTE

Stage 4 (document) is skipped for non-design-class changes: they advance plan -> implement directly, and the skip and its justification are recorded on the Request.

The two write tools only propose

The whole lifecycle exposes exactly two write tools, and this is the property to internalise:

  • request_intake - stage 1. Opens the GitHub issue and creates the draft Request node.
  • advance_stage - stages 2 through 7. Records each stage transition.

IMPORTANT

Both are propose-only: they open a GitHub issue or PR and stage a draft Request node. Neither mutates protected state, merges, applies, or releases. A failed gate returns the Request to the prior stage with a recorded reason, and every transition is written as WORM evidence bound to the acting identity.

So an agent can carry a change all the way to the edge of review autonomously - but the merge, the apply, and the release stay on the far side of a human gate.