M5 Praxis completion and conformance boundary

Praxis naming: This page documents Praxis, the AIWS workflow engine. Existing engine/* source paths, /engine/... routes, aiws-engine/* protocol identifiers, and existing script names remain unchanged for compatibility.

M5 closes the first executable Praxis profile: a local Node.js 24 + SQLite workflow engine that can take an immutable coding plan through human approval, governed dispatch, real implementation, validation, bounded correction, revalidation and explicit acceptance.

The important word is profile. M5 completion does not mean every future AIWS deployment target is qualified. It proves the accepted local SQLite implementation boundary from the M4 conformance plan. M6 covers broader recovery, capacity, platform and long-duration hardening.

The continuously verified workflow

Every Praxis CI run executes:

npm run engine:typecheck
npm run test:engine
npm run test:engine:m5-conformance
npm run example:engine:workflow

The demo performs real local subprocess and filesystem work:

human plan approval
        ↓
implementation
        ↓
validation fails
        ↓
bounded corrective work
        ↓
validation passes
        ↓
human acceptance
        ↓
SUCCEEDED

Success cannot be inferred from an exit code alone. Acceptance is bound to the current deliverable digest and successful validation evidence, and unresolved dispatch responsibility, open controls or stale artifacts block acceptance.

Explicit M5 conformance subset

npm run test:engine:m5-conformance runs the M5 closure subset required by the M4 harness:

• SQLite transaction/reopen and real-process termination tests
• supervised dispatch admission and atomic responsibility tests
• durable human controls and handoff recovery
• authenticated local control API tests
• composed coding workflow and interrupted-recovery tests

The full Praxis regression suite is still required in addition to this focused gate.

Recovery semantics

M5 distinguishes pre-dispatch work from material responsibility.

Before DISPATCH_AUTHORIZED, abandoned work may be recovered as scheduler work. After authorization, a missing worker reply is not proof that nothing happened. The attempt remains owned/accounted and may become UNKNOWN until reconciled.

The composed recovery test kills a real child coordinator after durable worker evidence exists, reopens the same SQLite installation under a new coordinator epoch, requires human restart approval and finishes the stage without repeating the implementation effect.

What M5 proves

For the local profile, M5 provides executable evidence for:

• atomic SQLite state, queue, dispatch and command-result commits;
• coordinator/worker epoch fencing;
• supervised approval/policy/hold/limit admission;
• committed dispatch responsibility before material execution;
• durable worker evidence and artifact digests;
• actual validation and settlement;
• bounded corrections without resetting attempts or accounting;
• durable planning/implementation/validation/correction handoffs;
• human pause, resume, cancellation decisions and agent replacement;
• explicit final acceptance tied to current successful evidence;
• restart without silent duplicate execution when prior evidence is conclusive;
• UNKNOWN preservation when prior execution is ambiguous.

What remains M6 or later

M5 does not claim:

• PostgreSQL conformance;
• cross-machine execution or recovery;
• Windows/macOS platform qualification;
• destructive power-loss or storage-device testing;
• sustained capacity/load qualification;
• retention, archival, history compaction or backup/restore qualification;
• long-duration calendar/timezone scheduling hardening;
• every remaining M4 semantic/fault scenario;
• release packaging/native SDK parity for the new engine APIs.

Those obligations remain explicit in M6–M8 rather than being hidden inside an overly broad “engine complete” statement.

See docs/M5-COMPLETION.md for the evidence matrix and spec/engine-v1/CONFORMANCE.md for the original M4 conformance contract.