Engineering standards

The engineering-standards/ folder — the shared rulebook every agent must load before doing any work.

The standards folder is the agent’s required reading. HARD RULE 5-bis makes loading it mandatory before planning, creating, editing, reviewing, or deploying — even when the only deliverable is a plan. Where CLAUDE.md holds the short, sharp rules, this folder holds the longer “how we build” material.

What’s in the folder

File	Role
README.md	The index, and the tier system below.
ARCHITECTURE_INVARIANTS.md	The numbered safety properties — see Architecture invariants.
AGENT_POLICY.yaml	The canonical machine-readable policy.
PROTECTED_PATHS.md	The human-readable protected paths, derived from the YAML.
AGENT_DEV_GUIDELINES.md	The “what” — what good work looks like.
AGENT_DEV_PROCESS.md	The “how” — the four-role pipeline.
AGENT_DEV_TEMPLATES.md	Reusable templates for plans and reviews.
CODEX_PROMPT.md	The prompt that binds Codex to these same rules.
PRD_TEMPLATE.md	The shape of a product requirements doc.
CURRENT_STATE.md	A timestamped snapshot of where things stand — context, not a rule.

The tier system (0–3)

The README organises the standards into tiers by how binding they are. The lower the number, the less negotiable. This is the folder’s own version of the advice-vs-enforced axis:

• Tier 0 — safety/security invariants. The invariants. These win over everything except a direct, current operator instruction.
• Tier 1 — the standards themselves. Process and guidelines an agent is expected to follow.
• Tier 2 — source code and live evidence. What the system actually does today.
• Tier 3 — wiki prose and explanation. Helpful orientation, lowest authority.

Authority order

When two sources disagree, the resolution order is fixed: current operator instruction → safety/security invariants → engineering standards → source code / live evidence → wiki prose. Prose never overrides code; code never overrides an invariant; nothing overrides a direct instruction from the operator.

The four-role development process

AGENT_DEV_PROCESS.md describes a pipeline that separates the work of building from the work of checking. The same change passes through four roles:

  Architect  ──▶  Implementer  ──▶  Reviewer  ──▶  Auditor
  (plans the     (writes the       (checks the    (verifies it
   change, the    code to the       diff against   actually holds
   brief)         plan)             the standards) after the fact)

The point of splitting these is that the agent that wrote the code is not the only thing standing between a mistake and main. The Reviewer and Auditor roles re-check against the standards and the invariants — and behind them sit the automated checkpoints that don’t rely on any role doing its job: the gate, the fitness tests, and CODEOWNERS.

Why “standards before work”

Loading the standards first is itself a rule (5-bis, tied to INV-021) because the most expensive mistakes came from agents acting on a stale mental model. The standards are deliberately the first thing read each session, so the plan an agent writes is already shaped by the constraints it will later be checked against.

See also

• Architecture invariants — Tier 0, the safety properties.
• Agent policy (YAML) — the machine-readable policy in this folder.
• Governance files — how this folder relates to CLAUDE.md.
• Morpheus drain — the autonomous coder that runs this process unattended.