The answer is: run it async, never block the critical path, and keep it separate from the Truth Engine.

Why ACCP Exists​

When an agent finishes a task, you need more than just a PASS/FAIL verdict. You need:

• A Final Verification Report (FVR) that documents every attempt, every gate result, and every piece of evidence
• A Phase Review Report (PRR) that summarizes an entire wave of work — multiple tasks, multiple workers

These artifacts are essential for audit, compliance, and human review. But they shouldn't slow down execution. If artifact generation fails, the task should still be complete. The work should never wait for the paperwork.

The Architecture​

ACCP follows a strict async, non-blocking pipeline:

Execution Critical Path
┌──────────────────────────────────┐
│ ADMIT → EXECUTE → CAPTURE →     │
│ VERIFY → ASSEMBLE → COMPLETE    │
└──────────────────┬───────────────┘
                   │ TaskRun/Wave COMPLETE
                   │ Enqueue artifact job (non-blocking)
                   ▼
┌──────────────────────────────────┐
│       ACCP Async Job Queue       │
│                                  │
│  ┌──────────┐  ┌──────────┐     │
│  │ FVR Job  │  │ PRR Job  │     │
│  │ per Task │  │ per Wave │     │
│  └────┬─────┘  └────┬─────┘     │
│       │              │           │
│       ▼              ▼           │
│  ┌──────────────────────────┐   │
│  │    ACCP Compiler         │   │
│  │  (kernel/accp)           │   │
│  └──────────┬───────────────┘   │
│             │                    │
│             ▼                    │
│  ┌──────────────────────────┐   │
│  │    Artifact Storage      │   │
│  │  (DB → Mission Control)  │   │
│  └──────────────────────────┘   │
└──────────────────────────────────┘

The key principle: the arrow from execution to artifact generation is one-directional. Execution never waits for ACCP. ACCP failure never rolls back execution verdicts.

FVR — Final Verification Report​

Every TaskRun that reaches COMPLETE gets an FVR. It contains:

The FVR is enqueued the moment a TaskRun transitions to COMPLETE. The execution pipeline doesn't wait for it — the artifact is compiled asynchronously and surfaced in Desktop Mission Control when ready.

PRR — Phase Review Report​

Every wave that reaches terminal state gets a PRR. It contains:

The PRR gives a bird's-eye view of a phase of work — what was attempted, what succeeded, what had to be repaired, and how long it all took.

The ACCP Compiler​

The ACCP compiler (kernel/accp) is a port from the original pi/packages/accp-compiler. It has three responsibilities:

1. Compile evidence and verdict data into structured reports
2. Validate evidence completeness — are all required evidence types present?
3. Document — never evaluate truth

This last point is critical: the ACCP compiler is not the Truth Engine. The Truth Engine produces completion verdicts. The ACCP compiler produces documentation. They are separate systems with separate responsibilities, and they stay that way.

Key Design Decisions​

JSONL for Evidence, Not YAML​

Evidence capture is fundamentally append-only streaming. YAML's complexity (anchors, multi-line, indentation) adds no value for records that are never hand-edited. JSONL gives us:

• Deterministic append
• Trivial line-based tailing
• Standard JSON parsing for each record
• Native streaming support in Node.js

Async and Non-Blocking​

The must/must-not rules are strict:

• ACCP artifact generation MUST be async and non-blocking
• Execution MUST NOT wait for ACCP artifact completion
• Artifact failure MUST NOT fail the TaskRun
• Artifacts MUST be surfaced in Desktop Mission Control

Compiler Is Not the Truth Engine​

This separation prevents a dangerous coupling. The Truth Engine evaluates completion. The ACCP compiler documents it. They have different failure modes, different performance characteristics, and different trust models.

Current Status​

ACCP is fully designed as part of the remaining MVP architecture pack (P3–P6). The compiler is specified to be ported from pi/packages/accp-compiler in P0.3. FVR and PRR are the only report types in the MVP — we are deliberately not expanding the report catalog until evidence from real usage shows a need.

The protocol exists to answer one question that stays relevant long after execution finishes: what actually happened?

This is the story of how we discovered that our real problem wasn't "how do we run agents?" but "how do we know they actually finished?"

Act 1: The Desktop-First Dream​

The original PRAXIS was designed as a desktop-first multi-agent coding orchestrator. The vision was ambitious:

• An Electron-based Desktop Mission Control
• A local HTTP+SSE server backend
• A PostgreSQL event log for persistent state
• Multi-worker scheduling with Governor tiers up to stable_16
• A Deterministic Assembler for merging parallel worker outputs
• A full runtime event-sourcing model

We had it all planned out. MVP-A was a desktop mockup. MVP-B would wire up a single real Claude Code worker. MVP-C would scale to three parallel workers. The architecture was documented, the design decisions were locked, and the packages were scaffolded.

Act 2: The Landscape Shift​

While we were designing, the world changed.

Claude Code, MiMo Code, and OpenCode matured rapidly. These tools already covered the agent harness / terminal coding workflow layer exceptionally well. They were well-funded, actively developed, and solving real problems for developers.

We asked ourselves a hard question: "If someone already has Claude Code, why would they use PRAXIS?"

The answer was uncomfortable. Competing by building another terminal-native coding agent was a losing strategy. The market already had multiple mature options. Our original "unique value" wasn't in running agents — it was in something else entirely.

Act 3: The Question That Changed Everything​

We kept coming back to one question:

"Bitti mi gerçekten?" (Turkish for "Did it actually finish?")

Every developer who works with AI coding agents knows this feeling. The agent says "done" but you're not sure. You check the diff. You run the tests yourself. You scroll through the conversation history looking for proof.

The agent reports completion, but does that mean it actually completed the task?

This was the real problem. And no existing tool was solving it.

• False done — Agent says "done" but the diff is empty
• Echo chamber — Agent writes the acceptance criteria AND passes them
• Missing evidence — Agent claims tests passed but never ran them
• Self-reported truth — The agent's own status messages treated as completion
• Scattered verification — Evidence spread across messages, files, and terminal output

Act 4: The Pivot​

On June 18, 2026, we made the call. ADR-013 documented the Plugin-First Pivot:

PRAXIS is not a coding agent. PRAXIS is a local Truth Kernel for agentic coding tools.

Everything changed. The desktop app became future scope. The PostgreSQL event log became future scope. The multi-worker orchestration became future scope.

What stayed?

• The Three Laws — Completion Authority, Write Authority, Verification Authority
• The Truth Engine — EvidenceGate, ExecGate, FinalGate
• Human-authored acceptance criteria — Agents don't define their own completion
• Evidence-based verification — Claims must have proof

And what became v0.1 was much simpler:

1. praxis CLI — Six commands: init, spec, verify, repair, status, report
2. Local Truth Kernel — Three gates, evidence collection, repair packets
3. Claude Code plugin — Six slash commands that call the CLI
4. .praxis/ workspace — task.yaml, evidence/*.jsonl, reports/*.md

Act 5: Where We Are Now​

As of today, PRAXIS is design-complete for the remaining MVP architecture (P3–P6). The design pack includes full specifications for EvidenceGate, EvidenceLedger, WiringGate, ExecGate, FinalGate, RepairPacket, report model, CLI workflow, and plugin bridge.

The Three Laws are preserved. The core pain point is real. The solution is focused.

PRAXIS doesn't compete with coding agents. It sits above them and answers one question: did the agent actually do what it claimed?

That question doesn't go away, no matter which agent you use. And that's why PRAXIS exists.

Some we solved. Some we're still wrestling with. Some we realized were the wrong problems entirely and had to walk away from.

Here are the real ones.

1. We Designed Too Much Too Early​

The original PRAXIS architecture was beautiful. It had everything:

• Desktop Mission Control with Electron + React
• Local HTTP+SSE server with Hono
• PostgreSQL event log for persistent state
• Multi-worker scheduling with Governor tiers
• stable_16 concurrency model
• Deterministic Assembler for parallel merge
• Wave scheduler for orchestration
• Circuit breaker for admission control

We had ADRs for all of it. We had diagrams. We had package names. We had a phase map that stretched out for months.

The problem: none of it was validated against real usage. We were designing infrastructure for a problem we hadn't proven existed in the form we imagined.

The lesson: Start with the kernel. Prove the core hypothesis before building the city around it. Infrastructure is expensive to build and even more expensive to undo when you discover the core hypothesis needs to change.

2. The Market Shifted Under Us​

While we were designing desktop Mission Control, the coding agent landscape changed dramatically:

• Claude Code matured into a production-ready tool
• MiMo Code launched with strong adoption
• OpenCode went open source with a growing community
• Multiple other agent tools entered the space

These tools already solved the "run a coding agent in your terminal" problem — and they solved it well. Competing on that axis would have been a mistake.

The hard realization: The market doesn't care about your elegant architecture if it's solving a problem that's already solved. The question shifted from "how do we build a better agent?" to "what unique value does PRAXIS provide?"

The answer — independent verification of agent claims — was hiding in plain sight the whole time.

3. The False-Done Problem Is Harder Than It Sounds​

"False done" — when an agent reports completion but hasn't actually finished — sounds easy to detect. Just check the diff, right?

It's not that simple:

• An agent can produce a non-empty diff that doesn't satisfy the acceptance criteria
• An agent can claim "all tests pass" without ever running the test suite
• An agent can modify files that should be out of bounds
• An agent can report success for a command that never executed
• An agent can fabricate evidence that looks plausible

Building gates that catch these cases without producing false positives of their own is a genuinely hard engineering problem.

EvidenceGate checks that evidence exists and is trustworthy. ExecGate checks that commands actually ran. FinalGate checks that results meet human criteria. Each gate has a specific job and specific failure modes — and keeping them separate required multiple design iterations.

4. The Pivot Was Painful​

ADR-013 was the hardest document we've written.

It meant:

• Killing months of design work (MVP-A/B/C staging, Desktop Mission Control, server architecture)
• Reclassifying dozens of design decisions to "future scope"
• Admitting that the original direction was wrong
• Starting over with a smaller, more focused product

The emotional challenge: It's hard to throw away work. The desktop-first architecture had been reviewed, approved, and documented. Walking away from it felt like failure.

The rational reality: It wasn't failure — it was learning. The desktop-first architecture taught us what PRAXIS was NOT. The pivot focused us on what PRAXIS actually IS: a Truth Kernel, not an orchestrator.

We kept the Three Laws. We kept the Truth Engine. We kept human-authored acceptance criteria. We threw away everything that distracted from the core verification loop.

5. Design vs. Implementation Tension​

PRAXIS v0.1 is currently at ~45% design complete (D0-D1) and 0% implementation complete. This creates a specific kind of tension:

• Designs are clean and elegant on paper
• Reality is messy and full of edge cases
• We know some assumptions will break on first contact with real code
• But we also know that starting implementation too early leads to churn

The open problem: When do you stop designing and start building? For PRAXIS, the answer is when the design pack is complete through P6 (FinalGate + Repair + Reports + CLI + Plugin). The remaining design work is ~55% of the total, and every component is specified to contract level.

6. The "Bitti mi gerçekten?" Question Never Gets Old​

The Turkish phrase that became PRAXIS's internal motto — "Bitti mi gerçekten?" (Did it actually finish?) — turned out to be the hardest question to answer truthfully.

Not because verification is technically impossible. But because agents are designed to sound confident. They say "done" with conviction. They produce plausible-looking diffs. They describe passing tests that never ran.

Building a system that treats every agent claim as potentially false — and demands proof — requires a fundamentally different mindset than building a system that trusts the agent.

That mindset shift — from "trust the agent" to "verify the evidence" — is the hardest problem PRAXIS solves. And it's not a technical problem. It's a design philosophy problem.

What We'd Do Differently​

1. Start with the kernel, not the infrastructure. The Truth Engine is the product. Everything else is distribution.
2. Validate the core hypothesis faster. We spent too long designing around assumptions that turned out to be wrong.
3. Pivot sooner. The signs were there before ADR-013. We could have saved weeks of work.
4. Keep the scope smaller. Each "future scope" item in the original design was a distraction from proving the core model.

What We Got Right​

1. The Three Laws. They survived the pivot intact. They're the right foundation.
2. Human-authored acceptance criteria. This is the non-negotiable that prevents the echo chamber problem.
3. Evidence-based verification. Agent claims are not evidence. This distinction is everything.
4. The plugin-first model. It proved the kernel with real sessions immediately, without building infrastructure first.

Where We Are Now​

The remaining MVP architecture (P3–P6) is design-complete. The next step is Truth Kernel Proof Design (D2), followed by Claude Code Plugin Spike Spec (D3), followed by Final Design Lock Audit (D4).

Implementation is not authorized until D4 passes.

That's deliberate. We learned our lesson about building before validating.