---
title: jleechanorg/dark-factory Repository
slug: jleechanorg-dark-factory-repo
type: source
created: 2026-06-17
updated: 2026-06-17
status: active
tags:
  - source
  - repository
  - dark-factory
  - dot
  - cxdb
sources:
  - https://github.com/jleechanorg/dark-factory
related:
  - agentic-pipeline-runner
  - dot-pipeline
  - cxdb
  - healer
  - agent-orchestrator
confidence: high
contradictions:
  - The README describes runner code as disposable, but the repository contains substantial engine, validation, observability, and benchmark code that future implementations should study.
bead_refs:
  - dark-factory-rr4
---

# jleechanorg/dark-factory Repository

Source URL: [jleechanorg/dark-factory](https://github.com/jleechanorg/dark-factory)

Captured: 2026-06-17. Observed `main` HEAD: `5449ecc1e5115afda6dca2f8cd49da2dd61a24ae`. Provenance: public GitHub repository README and local shallow clone inspection.

## Compact Takeaways

- The repository is a Python implementation of the [[attractor-pattern]] with a DOT-based pipeline engine for multi-agent software engineering workflows.
- Its README states the durable artifacts are `.dot` process graphs and `spec.md`; generated implementation code and runner internals are treated as rebuildable.
- Factory execution is split into spec generation and pipeline execution, with plan, implement, test, adversarial review, gates, and sealed holdout stages.
- The implementation includes [[cxdb]] event logging, [[healer]] failure clustering, prompt catalogs, benchmark projects, and multiple backends including Claude, Codex, Antigravity, AO, echo, and mock LLMs.
- It explicitly encodes an operator-agent isolation rule: implementing agents should not see holdouts, evaluator internals, or holdout-related environment variables.

## Wiki Implications

- [[agentic-pipeline-runner]] should include concrete runner phases, backends, sandboxing, event logging, and evidence bundles.
- [[how-do-dark-factories-validate-without-reading-code]] should include sealed holdouts, adversarial review, and structural blindness, not just ordinary tests.
- [[specs-vs-code]] should treat specs and DOT graphs as long-lived artifacts and runner implementations as lower-trust/rebuildable machinery.

## Caveats

- This is an implementation repository and contains claims about its own state of the art; use it as implementation evidence, not as independent proof that the pattern is universally validated.
- The observed commit is a point-in-time snapshot. Re-run repository inspection before making current operational claims.