Development process

Before any enforcement matters, the work itself is shaped: four roles, a size tier for every task, hard limits on code shape, and a template for every document.

The enforcement plane answers “can this action happen?” The development process answers an earlier question: “is this work being done in a way that produces reviewable, reversible changes?” It lives in engineering-standards/ as a set of documents agents are required to load before planning anything.

Four roles, in sequence

Every non-trivial task moves through four roles (AGENT_DEV_PROCESS.md). One agent can play several of them, but the steps don’t merge — each role produces its own artifact, and the next role starts from that artifact, not from the chat history:

  ARCHITECT      designs — produces the plan / ADR / RFC
      │
      ▼
  IMPLEMENTER    builds — produces the change itself
      │
      ▼
  REVIEWER       reads the change against 8 dimensions
      │           (correctness, security, performance, …)
      ▼
  AUDITOR        adversarial pass — pre-mortem ("how does
                  this fail in production?") + OWASP-style
                  security review

The separation is the same idea as the enforcement plane’s independent layers: the person (or prompt) that wrote the code is the worst-placed one to notice what’s wrong with it.

Tiers: matching ceremony to risk

Every task is sized into a tier, 0 through 3, and the tier decides how much of the process applies — a typo fix doesn’t get a threat model, and a schema migration doesn’t get to skip one. Higher tiers require more artifacts (PRD, ADR, threat model), more review, and higher test coverage: 60% for tier-1 work, 80% from tier 2 up.

Hard limits on code shape

AGENT_DEV_GUIDELINES.md sets numeric caps that exist specifically because agents drift past soft guidance: no file over 500 lines, no class over 300, no function over 50. Inputs are parsed into typed values at the boundary rather than re-validated everywhere (“parse, don’t validate”). Before handing work over, an agent walks a 14-item self-audit checklist. The forensic audit of 2026-05-28 (see decision records) measured the codebase against exactly these caps — which is the point of writing limits as numbers: they’re checkable later.

A template for every document

AGENT_DEV_TEMPLATES.md means no governance document starts from a blank page — and every document of a kind has the same sections, so readers know where to look:

ADR (architecture decision record) — MADR format: context, options considered, decision, consequences.
RFC — Google-style design doc for changes big enough to argue about.
Threat model — STRIDE walk-through for security-relevant work.
Postmortem — blameless, timeline-first, for incidents.
PR description — what changed, why, how it was verified.

Who outranks whom

AGENTS.md at the repo root binds any agent that loads the repository (Codex reads it automatically) and settles conflicts between sources of truth with an explicit ranking:

Two more files round out the folder: CODEX_PROMPT.md — five ready-to-paste prompts that put Codex into each role with the standards pre-loaded, including the identity rule that no AI attribution ever appears in commits or PRs — and CURRENT_STATE.md plus PRD_TEMPLATE.md / canary-app-template/, the living snapshot of where the system stands and the scaffolds new work starts from.