I don't prompt AI to write code.
I run a factory that AI works inside — with inspectors.

From a requirement to production — and back again

Two lanes, one closed loop. The build lane turns a requirement into a delivered, reviewed system. The run lane watches it in production, turns every failure into a tracked row, and feeds the learning back into the rules the next build runs under.

An instruction is not a guarantee. So the process lives outside the model.

A rule written in a markdown file is still just a sentence the model has to remember three hours into a run. These five mechanisms make the rule true whether the model remembers it or not. Long-form write-up →

# what a prompt looks like from the inside — a hook classified this very task and
# injected the three failure patterns most likely to recur, before I typed a line
UserPromptSubmit → §7.3 auto-watchdog · classified=NEW_PROJECT · top-3 prior issues from catalog:
  [R1] false 'done' claim            — recurred 4× in similar tasks
  [R9] wrong scope/project targeted  — recurred 2× in similar tasks
  [R3] mobile/browser compat broken  — recurred 2× in similar tasks

# and what a closed row looks like in the database itself (query run 2026-08-31)
$ sqlite3 factory.db "select resolved_by, verified_by, verification_method from issue_tracker where ref='P39-0005'"
p39-plist-fix-sonnet-subagent | claude-opus-5-orchestrator | Independent re-run, not self-reported: … pytest = 3 passed; RED/GREEN probe reverting cli.py = 2 failed, restore = 3 passed

Every project on this machine inherits the same law, the same inspectors, the same memory

Nothing here is exotic — plain text files in ~/.claude/, wired into Claude Code's own extension points. What matters is how they are used: the global file is a thin router that stays in context, detail is loaded on demand, enforcement runs in shell, and memory persists across sessions.

~/.claude/                          # applies to EVERY project on the machine
├── CLAUDE.md                       # v2.8.0 · 560 lines · thin router, versioned, changelog
│     INV-0.001 … INV-9              # 11 invariants (BLOCK on violation)
│     §0.4 … §0.15                   # 12 policies: scope, deploy, claims, issues-as-rows…
│     §7 task intake                 # keyword → task class → skills auto-route
│     ORCHESTRATOR ROLE LOCK         # orchestrate · validate · git — delegate the rest
├── dac/                            # 10 detail files, ~1,400 lines, loaded ON DEMAND
│     0_policies  1_invariants  1_5_audit_protocol  2_agent_modes
│     3_ccp  4_mcp  6_email  7_task_intake  8_orchestrator_spawn  9_external_llms
├── settings.json                   # hooks wired to 4 events (see table)
├── hooks/                          # 18 shell scripts · exit 2 = the call is blocked
├── skills/                         # 25 skills — each check is bash + exit code
└── projects/<repo>/memory/         # 103 memory files for the factory alone
      feedback 49 · project 38 · reference 8 · user 1

<repo>/CLAUDE.md                    # adds, never replaces. Points at global by VERSION;
                                    # preflight P-06 FAILS the build if the two drift.

One pane over every project, every issue, every agent

The Tower reads the same SQLite database the agents write to. Projects, the issue tracker with RCA and evidence, which CLIs are alive right now, which domains and sites are up — and a live link to Pehredaar.

What I ship stays watched after go-live

Pehredaar ("the one who keeps watch") is a daemon that polls every registered source — uptime, API health, and each application's own error webhook — persists events in SQLite WAL, fingerprints them, and alerts the moment a new pattern surfaces or a known one spikes. Its issues flow into the Tower as rows, so a production error and a build defect live in the same ledger.

Things that went wrong — and what each one became

Every rule in my global setup has a WHY block with a dated incident behind it. Nothing below was designed on a whiteboard; it was paid for. This is the clearest picture of how I actually work: a problem, its real root cause, and the mechanism that makes it structurally hard to repeat.

Domain can be learnt with AI. Knowing how to make AI's output trustworthy cannot be prompted.

not shownThe registry holds 55 projects. This page shows the two I chose to explain in full and one in progress; client platforms under NDA are deliberately absent.

How I build an agent around your knowledge or data

I don't know your data yet — that is step 1. What I do know is how to make an agent on top of it that you can trust, and that stays trustworthy after delivery.

"Doesn't all this governance make you slow?"

The opposite — it is what lets me move at sprint pace without the two things that actually eat a delivery: rework, and finding out in production. The rigor is automated and parallel, so it costs wall-clock time close to zero.

A sovereign software estate

Every system I currently run is watched, every caught failure is a row with a cause, every fix is verified by someone who did not write it, and every learning tightens the rules the next build runs under. Today that loop runs across the projects above. The direction is to close it fully — so the estate governs and repairs itself, and the human's job is judgement, not babysitting.