⚙️ Claude Execution Engine

A deterministic Python pipeline that turns unstructured input into validated XML FinalPrompts for Claude.

---

🧭 What This Is

CEE takes raw, unstructured input — a question, a task, a half-formed thought — and runs it through a strict, auditable pipeline that produces a validated XML prompt structured for Claude's optimal response shape.

It's a deterministic prompt engine. Same input, same configuration, same prompt out. No LLM-in-the-loop drift in the pipeline itself — Claude is what runs against the FinalPrompt, not what builds it.

Every step is bible-grounded. Every artifact is persisted to three substrates. Every operation is recorded in a tamper-evident hash-chained audit log. Every classifier decision is checkable.

---

🎯 Why This Exists

I'm a non-technical solo founder.
I'm building real software with AI-assisted development tools.
I'm documenting the process publicly under MWI.

CEE is the production-quality demonstration of what disciplined,
AI-assisted, bible-driven development looks like at scale.

Every architectural decision lives in bible/. Every task ships with a design proposal, halt-and-resolve protocol, verification, and commit message that traces back to a specific bible section.

The git history is the build log.

If you're a fellow non-technical builder, an investor evaluating AI-native tooling, or another founder thinking "could I actually build this?" — yes, you can. This repo is one example of what that path looks like.

---

🏛️ Architecture — 1-Minute Overview

CEE has three substrates, each with a defined role:

📁 Filesystem Canon ~/cee/ The source of truth. All artifacts (Skills, Agents, Runs, audit logs, promotion queue) live here as files. Atomic writes, role-enforced via persistence/filesystem_writer.py.

🧠 Obsidian Vault Mirror ~/SecondBrain/cee/ A human-readable mirror layer. Derived from filesystem canon. Edits in the vault don't propagate back. Operator authority over post-scaffold edits is absolute (bible 13 §EC3).

📚 Notion (Async) via MCP Promotion targets for Skills and Agents that get approved for the Notion knowledge layer. Goes through an async queue with stub-injectable client for testability.

Around those substrates

Layer	Path	Job
🛡️ Safety Gate	safety_gate/	Redaction patterns + injection scanners + confirmation gate before any artifact crosses a substrate boundary
🔗 Audit Log	persistence/audit.py	Hash-chained JSONL across four canonical logs (cli, roles, boot, security). Tamper-evident
⌨️ CLI	cli/	Operator-facing verbs: cee verify, cee audit-verify, cee scaffold-obsidian, cee init, cee sync-bible
📖 Bible	bible/	24 markdown chapters defining every architectural rule. The codebase implements the bible; the bible doesn't describe the codebase

---

🗺️ How to Read This Repo

⏱️ If you have 5 minutes

1. Read this file.
2. Skim bible/00_project_vision.md for the phase plan.
3. Open build_status.md and look at the Phase 3 close-out section.

🕰️ If you have 30 minutes

1. Read bible/00_project_vision.md in full.
2. Read bible/04_database_file_structure.md for the substrate layout.
3. Read bible/12_prompt_leak_security_rules.md for the safety + audit posture.
4. Read bible/20_production_build_plan.md for the module-by-module map.

🛠️ If you want to understand how it was built (the MWI angle)

• Browse the commit history. Phase 3 (T1 through T13) is 13 disciplined task cycles.
• Each commit message documents the design decisions, halts surfaced, and bible-grounded rationale.
• The build_status.md file tracks every phase, every task, and every downstream candidate (deferred work items) with resolution commit hashes.

---

📊 Status

Phase 1 — Foundations:                          ✅ shipped
Phase 2 — Boot Sequence + Bible Sync:           ✅ shipped (gate: 635d003)
Phase 3 — Persistence + Substrates + Safety:    ✅ shipped 2026-05-03 (gate: a5a4673)
Phase 4 — Pipeline Driver:                      🔜 designed
Phase 5 — Classifier:                           🔜 designed
Phase 6 — Builders:                             🔜 designed
Phase 7 — Runtime:                              🔜 designed
Phase 8 — Observability:                        🔜 designed

📈 Test Count Progression

Phase 1 close   ──────────►  baseline
Phase 2 close   ──────────►  1,134 tests
Phase 3 close   ──────────►  1,531 tests   (+397 across Phase 3's 13 tasks)

---

🧰 Stack

Component	Choice
Runtime	Python 3.11.15
Schemas	Pydantic 2.x (closed schemas, extra="forbid", frozen where appropriate)
Tests	pytest — 1,531 tests across unit + integration suites
Filesystem writes	Atomic via os.replace
Audit logs	Hash-chained JSONL (SHA-256, GENESIS_HASH anchored)
Knowledge sync	Notion MCP integration (deferred client wrapping)
Frameworks	None. No magic. Just disciplined Python.

---

🏗️ Built With

For implementation

For design conversations

The editor surface

Halt-and-resolve discipline

The bible-first / halt-and-resolve workflow is described in build_status.md and demonstrated in every Phase 3 commit.

---

🧪 The Discipline

1.  Read the bible section.
2.  Write the design proposal.
3.  Surface the halts before writing code.
4.  Resolve every halt against a bible-grounded rationale.
5.  Implement.
6.  Verify (tests, audit chain, substrate consistency).
7.  Commit with a message that traces back to the bible section.
8.  Update build_status.md.
9.  Next task.

No skipped steps. No "we'll fix it later." Every task closes clean or it doesn't close.

---

📜 License

All rights reserved.

This repository is public for build-in-public visibility, not for redistribution. If you want to use this code or pattern for your own work, get in touch.

---

📬 Contact

---

Made Without Instructions.