Skip to content

Intent: Sovereign Dark Factory (local-dark-factory)

1. Problem Statement

Modern software engineering is transitioning from interactive, prompt-by-prompt coding to autonomous, 24/7 background agent factories. Recent prototypes in this space—most notably Machinist / ESF (mitkox/esf)—demonstrate the power of combining durable workflows (Temporal) with isolated microVM execution (CubeSandbox) and deterministic verification.

However, existing implementations suffer from critical systemic flaws that prevent true autonomy and ownership: 1. Cloud Lock-in & Explosive Token Costs: Existing agent factories rely on cloud APIs (anthropic/claude-sonnet-4-5, DeepSeek cloud). Running autonomous 24/7 loops with multiple test-and-repair iterations racks up unsustainable API bills, exhausts rate limits, and exfiltrates proprietary code and intellectual property to commercial third parties. 2. Heavy, Unwieldy Infrastructure: Solutions like Tencent CubeSandbox require specialized microVM daemons and nested virtualization, which are impractical and unstable on standard local developer workstations (WSL2 / Linux). 3. Operational Drag: Running a full enterprise Temporal cluster + PostgreSQL container fleet on a local desktop wastes precious CPU and RAM (2–4 GB) that should be allocated to LLM context windows and GPU acceleration.

Guiding Principle: "Make sure you own your AI. AI in the cloud is not aligned with you; it’s aligned with the company that owns it."

2. Proposed Outcome & Vision

We will build Sovereign Dark Factory (local-dark-factory): a lightweight, local-first, zero-cloud-token AI Software Factory tailored for developer workstations equipped with NVIDIA RTX GPUs and WSL2/Linux.

The human operator transitions from a "boilerplate typist" to an AI Factory Manager. The factory operates autonomously around the clock: - Tasks are submitted via CLI, scheduled crons, or repository triggers. - Each task runs in a fast, disposable, isolated sandbox. - The agent harness executes code modifications using local models powered by our unified router (local-coder), Ollama, and Prism CUDA. - Deterministic verification gates (build.sh, test.sh, pytest) independently judge success. Failing gates feed error traces back into an AST self-healing loop. - Verified changes, execution logs, model telemetry, and unified git diffs are preserved in a durable evidence locker. - The factory manager reviews the verified patch through a Human-in-the-Loop (HITL) gate (dark-factory review <RUN_ID> --approve / --reject).

3. Key Constraints & Local Hardware

  1. Hardware: NVIDIA GeForce RTX 5070 (12 GB VRAM), 32 GB System RAM, WSL2 on Linux 6.6.
  2. Inference:
  3. Primary reasoning & generation: qwen2.5-coder:14b via Ollama (http://localhost:11434/v1).
  4. Fast triage & refactoring: qwen2.5-coder:7b (Ollama) or phi4-mini via Prism CUDA (http://127.0.0.1:5272/v1).
  5. Zero external cloud token usage.
  6. Sandboxing:
  7. Primary: GitWorktreeSandbox (zero daemon dependency, isolated working trees).
  8. Durable Orchestration:
  9. Zero-dependency embedded SQLite workflow journal (.factory/factory.db) for instant state transitions and crash recovery.
  10. Temporal is a forward-looking seam only; no Temporal worker is registered in this release.

4. Non-Goals (Out of Scope)

  1. Cloud Multi-Tenancy: This is a sovereign, single-tenant, local-first factory for the developer and their infrastructure.
  2. Web SaaS Hosting: No external public SaaS or user authentication systems. All control is local via CLI and optional localhost dashboard.
  3. Specific Framework Lock-in: The factory must remain agnostic to project languages (supporting Python, Go, Rust, Node.js, C++, and shell-based repositories).
  4. Container Sandboxing: No DockerSandbox or other container sandbox; isolation is git worktree only (see spec.md, isolation limit).

5. Success Criteria

  • [x] Zero Cloud Cost: Complete end-to-end task run with $0.00 spent on cloud APIs.
  • [x] Deterministic Gate Enforcement: Agent declaring "I am done" does not cause a run to pass; only verification scripts exiting 0 pass.
  • [x] Automatic Self-Healing: Compiler and test failures are fed back to the local model to iterate on fixes up to N retries.
  • [x] Durable Evidence: Every run saves diff.patch, manifest.json, telemetry (tokens/sec, duration), and full logs.
  • [x] HITL Review: Operator can inspect and approve/reject patches with a single command.
  • [x] Repeatable Model Eval: Operator can run a standardized suite of real-model tasks (dark-factory eval) and get a structured, comparable report of self-healing convergence — without hand-rolling a throwaway script each time.
  • [x] Local Observability: Operator can browse run history, evidence, and eval reports in a local, read-only dashboard (dark-factory dashboard) — no write actions from the UI, no dependency beyond the Python standard library, bound to 127.0.0.1 only.

Progress reconciled 2026-10-04: eval and read-only dashboard are delivered in Phase 12; existing eval/dashboard tests and retained Phase 16 local-model reports support these capability checks. This does not close the reliability campaign or imply publication. Goals, constraints and non-goals are unchanged.

Adversarial review — 2026-10-02

Scope: targeted documentation and code review with selected adversarial probes; not an exhaustive audit. Probes used synthetic data and temporary directories. Findings below describe the reviewed working tree, including pre-existing uncommitted changes. Recording this review does not mean a fix was implemented or independently re-reviewed.

  • Confirmed — verification runner shadowing. In a temporary git worktree with tests/test_fail.py containing assert False, adding a root pytest.py that only prints a message caused a python -m pytest verification step to return passed=True. dark_factory/verification/runner.py protects tests/configuration but not this runner-shadowing module.
  • Confirmed — malformed audit response passes. AdversarialAuditor._parse_response in dark_factory/verification/adversarial.py returned passed=True for both {"summary":"ok"} and {"passed":"false","findings":[],"summary":"bad"}. Required fields and types are not strictly validated. The audit is advisory under the current spec; this finding concerns the false success report, not an asserted mandatory approval barrier.
  • Known isolation limit, reproduced. GitWorktreeSandbox.execute wrote a synthetic marker outside its worktree. spec.md already states that worktrees isolate repository changes, not host processes; this is a known limitation, not a newly discovered escape from a promised OS sandbox.
  • Assessment: restore trust in verification evidence before increasing autonomy. No full factory evaluation or real-model run was performed.

Codex SDLC — 2026-10-02

Operator requested a shared SDLC across 01–08, adapted to Codex. Preserve project outcomes and constraints; use AGENTS.md, .agents/skills and explicit project gates. Existing authorization covers this migration; it does not approve adversarial remediation, commits, pushes or releases.