LAD Factory is a Markdown workflow for sequential software development with native coding agents.
Use it when a specification needs planning, implementation, independent review, repair, and an Arbiter decision against the original goal. Stage instructions live in files. Current assignments and evidence stay readable on disk.
- Clone or copy this package into a directory your host session can read.
- Follow SETUP.md to discover available bindings and prepare a private installation profile and selected adapter.
- Start run setup using its actual path from the host's working directory.
- Run setup prepares
run/current/, preserves your criteria and target instructions, and pins the installation files into an immutable snapshot. - Start the Orchestrator with setup's recorded single-line prompt after resolving the selected mode's execution gates.
For a package copied into your host directory as lad-factory/, the installation prompt is:
Read lad-factory/SETUP.md and follow instructions.
Installation recommends model bindings from role needs, permitted model metadata, and your quality, cost, speed, and privacy priorities. It inspects existing metadata without model calls or benchmarks. Unknown capabilities remain explicit execution gates.
Reading the workflow authorizes neither a native Goal nor recurring work. The Orchestrator verifies the selected controls before delegating. Model, reasoning effort, and fresh context are agent settings. Every initial stage prompt only reads its pinned stage file. The assignment carries the work.
Recon for existing code -> Planner -> Manager
-> Builder -> Checker -> Updater -> next packet
-> Fixer -> Doublechecker
After two evaluated Fixer cycles: Learning, then the pending route
Unresolved review: Troubleshooter -> Consultant when needed
All packets complete -> Arbiter -> closure or scoped remediation
The Orchestrator starts one stage at a time and uses its adapter's completion wait or authorized callback yield. Interactive mode records when you must return to resume. Stages may use fresh helpers for separable work. Planner works alone.
Checker freezes expected behavior before inspecting any target implementation or Builder evidence. Doublechecker preserves that review baseline. Arbiter checks every original criterion independently of packet completion.
Stage markers express preferred outcomes, not a rigid result schema. After exact-owner completion, the Orchestrator can interpret clear prose against current evidence and checks. Missing substance, contradictory evidence, or an unknown writer still requires reconciliation or review. See transition policy.
- Routing identifies each role's required context.
- Shared contracts define worker ownership, development checks, evidence, and logs.
- Continuation policy defines Goal, heartbeat, callback, and interactive resumption, authorization, recovery, and closure.
- Transition policy covers every stage outcome and evidence-driven recovery.
- Instruction revisions preserve stable review guidance and existing user work.
- Nested model selection defines helper capability tiers and delegation. Your profile binds their models and efforts.
- Protocol fixture exercises documented transitions without running native agents.
The optional adapter source pack contains six guides. They cover Codex CLI, Codex Cloud, Claude Code, OpenCode, Pi, and Hermes Agent. Codex Cloud follows the same methodology with capabilities exposed by its current session. Its cross-harness guide describes explicit transport bindings and their limits. The Codex CLI source supplies the shipped Sol/Astra/Terra defaults. Your installed profile may choose other permitted models.
Setup merges all selected binding guides into self-contained installation/adapter.md and writes installation/profile.md.
Cross-harness installations include the full shared cross-harness contract in the same pinned adapter file.
Required native files are copied outside the source pack. You may then remove the entire optional adapter-templates/ folder.
Keep the folder to reconfigure later, or deliberately restore the needed source version. Setup never deletes it automatically.
The host must provide fresh contexts, effective model settings, exact-owner completion, and the selected continuation mechanics. Native configuration can override requested settings. Provider, permission, and tool inheritance follow the actual host.
Explicit user limits and actual host limits apply. LAD supplies no default dispatch, command, duration, or recovery quotas. Builder and Fixer may run development checks within existing permissions. Independent review follows their work.
Model IDs alone do not enable another harness. No universal bridge, scheduler, or recovery service is included. Unloaded-session resumption requires actual evidence. Run records require retention and backup. Run setup explains execution gates and interrupted-run recovery.
Stage responsibilities draw on Millrace v0.21.1. The layout is informed by Jake Van Clief's Interpretable Context Methodology. Provenance records the sources and adaptation boundaries.
Licensed under the Apache License 2.0.