AER v5: a compact contract for complete engineering

AER v5 succeeds v3.1.1 directly. I skipped v4 because its proposed enforcement and reporting runtime added process that conflicted with the product I wanted: an agent that completes the real behavior, supplies sound engineering judgment, and uses verification in proportion to the risk.

Completeness determines what must work

The recurring failures were specific. Agents repaired a visible symptom while leaving its owning abstraction broken. They implemented the mechanism I suggested even when a better design was needed. They passed a happy-path check while missing retries, state transitions, persistence, or the actual integration. They sometimes spent more effort assembling and rerunning checks than finishing the feature.

V5 makes complete behavior and a simple, coherent implementation the optimization target. An evidence-based subsystem replacement can be appropriate. So can a small edit. Diff size, extra layers, and the number of tests are not quality measures. The user owns product behavior and constraints; the agent is responsible for the technical obligations needed to deliver them.

A compact universal contract

The complete universal kernel is 45 physical lines and 5,120 bytes, including its metadata. It uses stable directive identifiers, explicit normative strength, an execution order, and a completion condition. Profiles, selected contexts, and task guidance add their own content; the kernel measurement is not a claim that every installed host instruction fits in those 45 lines.

• Repair the owning defect and update its consumers consistently, with one authoritative home for each rule.
• Preserve exact contracts, including invalid input, omitted defaults, output shape, ordering, side effects, and failure behavior.
• Trace a feature from its real entrypoint to its durable effect. A fake integration or a disconnected control does not complete it.
• Account for authorization, secrets, persistent data, migration, recovery, accessibility, and operations where they apply.
• Tie completion claims to relevant observed evidence and disclose what remains unresolved.

Verification earns its cost

Every implementation needs enough verification to establish its real behavior. That might be a build, a direct execution, a focused smoke check, or a complete user-path exercise. Permanent regression coverage is a separate investment, justified by contract stability, expected lifespan, production exposure, and the cost of failure.

Existing production regressions and repository release gates still matter. During implementation, choose the cheapest check that resolves the current uncertainty. Reuse a passing result while its evidence remains valid; repeat it when relevant behavior changes, integration occurs, or an unresolved concern warrants it. A failed check should produce a diagnosis and a relevant repair.

For selected web UI work, the interaction obligation is directly visible in the host instructions. It calls out state and draft continuity, recovery, keyboard focus after rendering, and whether the next action remains reachable. A page can look complete while losing a revised draft after a failed save or dropping keyboard focus after an edit.

Local delivery and optional diagnostics

The zero-dependency CLI continues to install project-local content for Claude Code and Codex through ownership checks. It preserves consumer-owned text and configuration. V5 installs no hooks, automatic project checks, mandatory verifier, or completion-report parser. The repository remains responsible for its own workflow and enforcement.

The aer verify command selects one optional contrast, slop, or size diagnostic. Its result is bounded by what that diagnostic actually inspected. It does not execute the project's test scripts or certify that a feature is complete.

Install and inspect

Use Node.js 24 or newer. In the Git repository you want to manage, choose the host that project uses and review the dry run before applying it:

npm install --global @aaarslan/aer@5.0.0

aer init --host codex --dry-run
aer init --host codex
aer doctor

# One explicitly selected diagnostic
aer verify contrast '#ffffff' '#000000'

Use --host claude for Claude Code, or both when the project uses both hosts. For a repository already managed by AER, upgrade the installed CLI, then preview aer update --dry-run and apply aer update. Older hand-copied rules remain unowned files; the installer refuses collisions instead of overwriting them.

What the release establishes

For a ten-minute check, use a throwaway Git repository: preview the installation, inspect the generated host instructions, run aer doctor, and invoke one selected diagnostic. Inspect the resulting diff and the diagnostic's stated scope. That can test delivery and local behavior. It cannot establish that a model will follow every instruction or produce better software across tasks.

The release notes and repository decisions record the design changes, validation, and limits of the known-task comparisons. V5 makes no general efficacy claim. Its release is a concrete revision to the engineering contract and delivery system; claims about consistent model improvement require separate evidence.