The Dark Line — Automation Map

Why this document exists

The DARK LINE landing page presents the idea of a lights-out web-development factory at the level of concept: a six-station line where raw intent goes in and shippable software comes out, with humans moved "up a level" to defining intent and the checks that decide what ships. That framing is deliberately high-level and is doing its job — engaging people on ideas, not implementation.

This document begins the next step: weighing how to accomplish it against the core idea. Specifically it answers three questions:

1. Which steps of the line can be automated, and what is the nature of that automation? (Deterministic? AI? Human-anchored?)
2. What already exists — in the MachinaXX tooling and in live client projects — that fills those steps today?
3. Where are the gaps, and what is the smallest credible sequence to close them with Claude Code as the orchestrator?

What was examined

Two categories of asset were investigated: components (reusable MachinaXX tooling that is the line's machinery) and consumers (live client projects that are outputs of the line and prove the machinery works together).

Components — the MachinaXX tooling

Consumers — live projects that are outputs of the line

The method layer — universal across all of the above

Every modern project, regardless of stack, shares the same operating method, applied by hand through Claude Code:

• A Plans/ folder of phased documents following a consistent shape: Requirement → Implementation Plan → Evaluation Plan → Findings → Remediation. This is exactly the phased-implementation skill available in the environment.
• A claude-sessions/ archive of AI session transcripts (RentaStore, SNTSystems, LifeGauge all have 20–40+).
• A CLAUDE.md encoding house conventions (K&R braces, net10.0, nullable, "no inline SQL", vertical-slice pattern).
• A .claude/settings.local.json permission allowlist, and an issues/ log (RentaStore) feeding remediation.

The line has two separable layers

The projects reveal that "the line" is really two layers that can be adopted independently:

Station-by-station automation map

For each of the six stations: the nature of the automation possible, what fills it today, and the gap.

Station 01 — Specification Human layer

Nature of automation: assistive, not autonomous. The spec is the raw material and caps output quality; it stays human-owned by design. But it can be made machine-readable and AI-drafted-then-human-signed.

• Already automated: The MakerX XML model is a fully machine-readable spec for the data layer — and MakerGen proves the principle end-to-end. RentaStore and SNTSystems drive their entire data/API layer from one XML file. Rich domain specs already exist as structured prose (Documents/ — Domain Boundaries, Ubiquitous Language, Features Endpoints Specification).
• Nature today: Data-layer spec = fully codified & machine-consumed. Feature/behaviour spec = structured prose, AI-assisted but not yet a validated contract.
• Gap: No single validated spec format for features/stories/acceptance-criteria/API-contracts the way there is for the data model.
• Opportunity: Extend the MakerX "declarative input → deterministic output" pattern upward from data to endpoints and acceptance criteria. This is adoption step 1 ("codify the spec format").

Station 02 — Jigs Tooling

Nature of automation: deterministic constraint. Jigs are where house standards become tooling the agent can't drift from. This is the line's strongest station today.

• Already automated: Chassis is the primary jig — it ships the architecture as a package, so every app inherits house standards. MakerGen is a second jig — it enforces the data-access pattern ("no inline SQL", generated IXxxData interfaces) by construction. CLAUDE.md files encode conventions; phased-implementation is a process jig.
• Nature today: Split between enforced-by-construction (Chassis/MakerGen — strong) and documented-but-advisory (CLAUDE.md prose — weaker, relies on the agent complying).
• Gap: Few deterministic guardrail hooks. Conventions are not yet pre-commit/CI hooks that block on violation.
• Opportunity: Promote the highest-value CLAUDE.md rules into hooks that fail the build/commit — converting advisory jigs into enforced ones.

Station 03 — Machines Automated

Nature of automation: two kinds — deterministic and probabilistic, with different trust models.

• Already automated (deterministic): MakerGen is the deterministic machine for the data/API layer — same input, byte-identical output, no LLM in the loop. Fully lights-out and safe today.
• Already automated (probabilistic): Claude Code sessions are the machines for feature logic, UI and integrations — but currently human-launched, one session at a time.
• Gap vs the website's claim ("headless agents under orchestration… in parallel"): there is no orchestration and no headless/event-triggered execution yet. The orchestrator is the human at the keyboard.
• Opportunity: The central automation target — Claude Code becomes the primary orchestrator (see Section 06).

Station 04 — Inspection Automated — the trust mechanism

Nature of automation: deterministic verification — the whole safety system. This is what lets the lights go off, and it is the station with the biggest gap between current state and the website's promise.

• Already automated: Compile with warnings-as-errors (G1, partial), full test suites — xUnit/NSubstitute + Vitest (G2), CI gating release on v* tags. The Evaluation Plan → Findings half of every phased document is effectively a second-pass AI inspection (the advisory A1 gate), already practised. Vector adds a deploy-time health-check-and-rollback gate.

Station 05 — Exception Desk Human layer

Nature of automation: deliberately human. Escalations, judgement calls, release ownership.

• Already established: This station is working as designed — Al reviews Findings, decides remediation, and cuts the v* tag that authorises a release (PR Reviews/, issues/).
• Nature today: Healthy. The human is currently the orchestrator and the exception desk; as Station 03 gains orchestration, the human should shed the orchestrator role and keep only the desk.
• Gap: Escalations aren't yet surfaced by the system — the human goes looking for them. A mature line pushes "undecided intent" and "failed-after-N-attempts" to the desk as explicit events.

Station 06 — Ratchet Compounding

Nature of automation: process discipline, currently manual. Every escaped defect should upgrade a jig or gate so its whole class can't recur.

• Already automated (partially): The discipline exists — issues/ISSUE-001-business-logic-in-data-layer, Findings → Remediation docs, Deferred-Issues-Status.md. Crucially, Chassis and MakerGen are a structural ratchet: a fix to MakerGen propagates to every consumer on the next regenerate; a Chassis migration guide upgrades the whole fleet.
• Gap: The defect → jig/gate upgrade loop is a manual practice, not automated.
• Opportunity: Wire the loop so a logged defect spawns a remediation task that must land a new test/gate/hook before closing — making the ratchet a rule, not a habit.

Coverage at a glance

Claude Code as the orchestrator — the harness question

The working assumption — "set up Claude Code to be the primary orchestrator of the line" — is well-founded. The evidence:

• The orchestration pattern already exists as a skill (phased-implementation) and is practised by hand on every project.
• Claude Code already drives all the components: it invokes makergen generate, consumes Chassis, reads the CLAUDE.md jigs, runs the test gates, authors the Evaluation/Findings.
• Each project exposes an MCP server (RentaStore 129 tools, SNTSystems) — the apps already publish an agent-facing tool surface.

What additional harness is required — minimal, and mostly glue rather than new platform:

1. An event trigger. Today a human starts each run. The line needs spec-change / issue-filed / schedule to launch a headless Claude Code run. Vector already proves the in-house webhook→action pattern; a sibling "build trigger" is the same shape pointed at generation.
2. A run controller for parallelism. Claude Code's own agent/workflow orchestration covers this; the missing piece is a thin queue + concurrency cap + per-task isolation (worktrees) so multiple task-classes run without colliding.
3. A gate runner. A single deterministic entry point that runs G1–G6 and returns pass/fail+report, so the orchestrator has one verdict to act on.
4. An escalation channel. A defined way to push "undecided intent" or "failed after N attempts" to the human exception desk.

Gap analysis — ranked by leverage

1. Inspection depth (Station 04). Highest leverage; it is what makes lights-out safe. Add (in order): coverage as a hard gate → architecture-fitness tests → secrets/security scan hook → contract tests → mutation testing.
2. Orchestration & headless execution (Station 03). Convert the manual, sequential session pattern into event-triggered, parallel, gated runs. The biggest visible change; depends on #1 to be trustworthy.
3. Enforced jigs (Station 02). Promote the top CLAUDE.md rules from prose to blocking hooks. Cheap, compounding, feeds the ratchet.
4. Spec formalisation (Station 01). Extend the MakerX "declarative → deterministic" pattern from data to endpoints/acceptance-criteria.
5. Automated ratchet (Station 06). Make "defect must land a new gate before closing" a rule, not a habit.
6. Escalation surfacing (Station 05). Push exceptions to the desk rather than having the human discover them.

A practical sequence

The site already prescribes a seven-step adoption order; the assets above let us make it concrete and pick the smallest trustworthy loop first.

Honest caveats

Consistent with the site's "twilight, not dark" framing.

• The component stack is .NET-shaped. Chassis/MakerGen/Vector assume ASP.NET Core + SQL + IIS. LifeGauge shows a constrained legacy modernisation runs on the method alone — so "the line" must be sold and built as method-first, components-when-the-substrate-allows.
• The orchestration claim is currently aspirational. "Parallel headless agents under orchestration" is not running yet; what runs is disciplined, human-launched, sequential Claude Code. The gap is closeable with glue, but it is real today and shouldn't be over-stated to partners.
• Inspection is the long pole. Three of the seven advertised gates (mutation, architecture-fitness, security scan) don't exist yet. Until they do, "lights-out" is a promise the safety system can't fully back.
• Vector is code-complete but not production-validated. The deploy arm is ready in principle; the staging soak hasn't run.
• The human is doing two jobs. Today Al is both orchestrator and exception desk. The point of the build-out is to automate the first so only the second remains — the whole "moved up a level" thesis.