Mission Driver: A General Reference Implementation of Loop Engineering

How a universal AI task-driven engine achieves local fault tolerance and stability guarantees through nested loops.

Part 1: Getting Started

1. The Problem: From Vibe Coding to Autonomous Operation

Current mainstream AI-assisted development is still Vibe Coding: a human prompts, the AI responds, the human corrects, and the AI responds again. This can be called the Human in the Loop model. Every output requires human confirmation and correction; human and AI work in alternation.

This model has two problems.

The first is loss of quality control. AI execution is essentially a probabilistic sampling process. Without an external control structure intervening, the AI can easily veer off course—for example, changing other code halfway through a task, forgetting to run tests after making changes, falling into an infinite loop upon failure, or losing state after a crash and having to start over. Even more dangerous is self-declared completion—claiming something is done without actually implementing it.

The second is capacity limitation. When a human is in the loop, the ultimate bottleneck remains human working time and energy. A person works 8 hours a day; even if AI assistance triples efficiency, the ceiling is only 24 person-hours. To truly unleash AI productivity, we must move toward Human on the Loop: AI runs fully autonomously 7×24, the human steps out of the loop and becomes a control factor that intervenes on demand.

This is not just a shift in operating mode, but a change in cost structure. When AI can run autonomously 7×24, working hours are no longer the constraint. A weaker model may take longer and consume more tokens to complete a job, but it is cheap enough to run at night without occupying human time. Multiple missions can process different roadmap work items in parallel. Cost accounting changes from "output per person-hour" to "intelligent output per dollar."

Mission Driver is a concrete control structure that realizes this transition.

2. What is Mission Driver (One-Minute Version)

Mission Driver is a declarative task-driven engine. You give it a goal (described via a roadmap), and it automatically enters a loop:

Check health status (initial, once) → Review plans → Execute plans → Draft new plans → (back to Review plans) → When no new plans can be drafted → Deep audit → (back to Review plans)...

The loop runs until the goal is achieved or the audit budget is exhausted. Each step is an independent AI subprocess or script function; failure of a single step does not affect the overall loop.

It is a component of Attractor-Guided Engineering (open-source repository links at the end of the article), and it is not limited to software development. By configuring custom flows, prompts, and commands, it can be naturally generalized to scenarios such as data processing and document analysis—a universal mechanism for fully autonomous AI operation.

It is suitable for complex tasks that require long-running execution, clear acceptance criteria, and multi-step iteration.

Loop Engineering is a design methodology rapidly emerging in the AI engineering field—using loop structures instead of linear prompts to let AI systems run autonomously until goals are met. It is not a proprietary feature of any particular tool, but an engineering pattern that can be designed independently of specific tools. Mission Driver is a general reference implementation of Loop Engineering.

3. How It Works: Loop Nesting and Local Fault Tolerance

If we view Vibe Coding as a single infinite loop, the core of Mission Driver is decomposing that single loop into nested multi-layer loops—Mission Driver's main loop (the five-step closed loop) is the outer layer, with embedded inner layers: the Plan Loop (the execute → check → audit → verify cycle in the EXEC_PLANS subflow) and an optional Audit Loop (the multi-dimensional audit cycle in the DEEP_AUDIT subflow). Understanding this nested structure is key to understanding why it can run stably for long periods.

Suppose there are 3 active plans, and the execution of plan-002 encounters a blockage:

EXEC_PLANS:
  ├── plan-001: EXECUTE ✓ → CHECK ✓ → BUILD ✓ → completed ✓
  ├── plan-002: EXECUTE ✗ → retried 3 times still failed → subflow failed
  │              → executing agent finds a prerequisite not met
  │              → moves the blocked item to Deferred But Adjudicated, records trigger conditions
  │              → remaining phases continue → completed (with Follow-up items)
  └── plan-003: EXECUTE ✓ → CHECK ✓ → BUILD ✓ → completed ✓

The execution blockage of plan-002 has no impact on plan-001 and plan-003. The blockage is confined within the subflow and does not propagate to sibling subflows or the parent loop. This is the local fault tolerance brought by loop nesting.

During plan execution, the AI decides based on the actual situation: locally blocked items are moved to Deferred But Adjudicated with successor trigger conditions recorded, while the rest of the scope completes normally; if the entire direction of the plan is falsified, it is marked as superseded or cancelled. The status of the plan's .md file is always managed by the AI agent.

The execution state of each step is persisted to disk (checkboxes in the plan file). After a process crash and restart, the engine scans the checkbox marks on disk and resumes from the breakpoint without replaying history.

Part 2: Starting Out

4. Quick Start

The source project for Mission Driver is in the AGE Template project. Typically, we add a tools/mission-driver.sh script in our own project to proxy calls to Mission Driver, and point to the Mission Driver source directory via the MISSION_DRIVER_HOME environment variable.

Getting started flow:

1. Download the AGE template, let AI read and adapt it to your project (adjust document structure, configure commands, initialize roadmap)
2. Ensure test commands are executable (npm test / mvn test / Playwright)
3. In daily AI conversations, draft plans into the plans directory according to the plan guide, accumulating plans and logs
4. Start the mission

# Generate mission config + roadmap
./tools/mission-driver.sh draft "your goal description"

# Validate config
node $MISSION_DRIVER_HOME/src/mission-check.mjs missions/<name>.json .

# Dry-run to verify flow orchestration
./tools/mission-driver.sh run <name> --dry-run --no-monitor

# Formal run
./tools/mission-driver.sh run <name>

Monitoring:

Mission Driver has a built-in visual monitoring page.

open http://localhost:9300              # Browser dashboard
cat _tmp/<runDir>/run-state.json        # Read state
tail -f _tmp/<runDir>/<mission>.log     # Follow logs

Interruption and Recovery:

# Ctrl-C safe interrupt (engine catches signal, cleans up child processes)
# Rerunning automatically resumes
./tools/mission-driver.sh run <name>

# Resume from a specific step
./tools/mission-driver.sh run <name> --from-step EXEC_PLANS

# Fast mode (skip DEEP_AUDIT)
./tools/mission-driver.sh run <name> --fast

Postmortem:

./tools/mission-driver.sh analyze           # Analyze most recent run
./tools/mission-driver.sh analyze <runId>   # Analyze a specific run

Postmortem scans all events and logs, runs a postmortem agent, and writes a structured report to the memory directory. Subsequent missions for the same module will automatically load these lessons learned.

5. The Four-Layer Definition System

Mission Driver consists of four layers of definitions, used through configuration rather than programming.

5.1 Mission Config (missions/<name>.json)

Pure static configuration, declaring what to do, where to do it, and how to verify:

{
  "name": "medical-qa",
  "description": "Generate QA training dataset from medical papers",
  "roadmapPath": "docs/backlog/medical-qa-roadmap.md",
  "plansDir": "docs/plans/medical-qa",
  "commands": {
    "test": "python scripts/check_quality.py --min-records 500",
    "typecheck": "python -c \"import dataflow\" && echo OK"
  },
  "promptsDir": "missions/prompts/data-processing"
}

commands.test is a required field; CHECK and BUILD_VERIFY both run it. build/lint/typecheck are optional and skipped if missing. Runtime state is in _tmp/<runId>/run-state.json and is not written to mission.json.

5.2 Flow Definition

The engine core is a generic state machine DSL executor (FlowEngine, with zero project-specific logic). Flow definitions declare how steps are orchestrated, how transitions occur, and what to do on errors. The engine advances the state machine according to the flow description, not bound to any fixed steps.

A simplified flow structure:

{
  "name": "my-flow",
  "entry": "CHECK",
  "steps": {
    "CHECK": {
      "type": "agent",
      "promptPath": "prompts/health-check.md",
      "transitions": {
        "pass": { "goto": "NEXT_STEP" },
        "fail": { "done": "failed" }
      }
    },
    "NEXT_STEP": {
      "type": "subflow",
      "flow": "my-subflow",
      "forEach": "activePlans()",
      "transitions": {
        "all_complete": { "done": "completed" }
      }
    }
  }
}

• Step types: agent (AI subprocess), script (JS function), subflow (nested subflow), group (grouped steps)
• Control flow: transitions define jumps between steps (goto/done/retry); forEach iterates over a collection launching a subflow per element; when/otherwise for conditional skipping
• Error handling: each step can configure maxRetries, onMaxRetries, onError, onUnknown; the engine also provides global infinite-loop detection (ping_pong + max_cycles + max_total_steps)

The built-in default flow (flows/mission-driver.json) is the cycle we've been discussing. Its actual structure is: CHECK runs only once at the entry, then enters the loop body REVIEW_PLANS → EXEC_PLANS → DRAFT_PLANS; when DRAFT_PLANS has no new plans to draft, it enters DEEP_AUDIT, then returns to the loop body. It is not hardcoded, just a default configuration. EXEC_PLANS and DEEP_AUDIT themselves are subflows (plan-execution.json / deep-audit-loop.json) that can be replaced independently.

This means entirely new workflows can be designed—for example, a code review workflow that doesn't need Plan orchestration can be written as a four-step flow: FETCH_PR → RUN_LINT → AI_REVIEW → POST_COMMENT. Place custom flow JSON in the missions/flows/ directory and set "flowName": "<custom>" in mission.json; the engine remains unchanged.

5.3 Plan Files

A Plan is the smallest unit of work, automatically generated by AI following a specific format. Its core is not just defining a to-do list, but defining the closure contract for how to judge completion. Its standard structure is as follows:

# 01 Purchase Order Approval Workflow Integration

> Plan Status: draft
> Last Reviewed: 2026-07-25
> Source: roadmap item "Core Business Logic M1"

## Current Baseline
- ErpPurOrder entity modeled, CRUD generated
- No approval logic yet

## Goals
- Purchase orders support submit→approve→reject/approve status transitions
- After approval, trigger inventory posting

## Non-Goals
- No multi-level approval
- No approval delegation

### Phase 1 - Approval State Machine
Status: planned

- [ ] Implement submitForApproval / approve / reject methods
- [ ] Status validation: only DRAFT can be submitted

Exit Criteria:
- [ ] After submit→approve, posted=true
- [ ] Unit tests cover all state transitions

## Closure Gates
- [ ] End-to-end: complete chain submit→approve→posting→reversal verified
- [ ] Independent sub-agent closure audit passed
- [ ] mvn test all green

Top three lines of status markers, Goals + Non-Goals (to prevent scope drift), each Phase has Status + checkboxes + Exit Criteria, and Closure Gates are plan-level final checks. Checkboxes are machine-readable persistent state; the engine resumes from breakpoints by scanning checkboxes. Before marking completed, all checkboxes must be checked.

In AGE practice, humans generally do not need to read Plans; they are created and updated entirely by AI autonomously.

5.4 Roadmap

The Roadmap is a human-readable, controllable macro plan. According to the docs/backlog/00-roadmap-authoring-guide.md specification, work items are grouped by milestones, carrying only three states: todo/ready/done; milestones themselves carry no state:

# Core Business Roadmap

> Prerequisites: All CRUD completed

## Work Item Status

### Milestone M1 — Core Business Cycle

- Purchase requisition approval→convert to order logic: `done`
- Sales quotation approval→convert to order logic: `done`
- Purchase Order BizModel (approval/receiving trigger/posting): `done`
- Sales Order BizModel (approval/shipping trigger/posting): `done`
- Three-way matching logic: `done`

### Milestone M2 — Business-Finance Integration End-to-End

- Procure-to-Pay full chain (PO→Receive→Invoice→Pay): `done`
- Order-to-Cash full chain (SO→Delivery→Invoice→Receipt): `done`
- Period-end closing full process: `todo`
- Return-to-Refund full chain: `todo`

### Milestone M3 — Extended Domain Business Logic

- HR Shift Scheduling Engine: `todo`
- Payroll Calculation: `todo`
- APS Production Scheduling: `todo`

DRAFT_PLANS launches an AI agent: reads the full roadmap + deferred items in historical plans → reads project context and planGuide → selects the next 1–3 work items → drafts plan drafts (Status: draft) → calls an independent sub-agent to review; upon approval, marks them active. When no remaining work can be drafted, it returns nothing, and the engine decides whether to enter an audit round based on this.

6. Configuration and Customization

The Mission Driver engine is completely generic. Customization can be achieved through configuration and prompt overrides, with absolutely no need to modify code. In general, you only need to add a mission-driver.sh script in your own project; it calls the Mission Driver implementation from the AGE template project via paths configured in environment variables.

Customization Layer	Mechanism	Example
Prompt Override	missions/prompts/<name>.md overrides built-in	EXECUTE prompt for data processing says "call script" instead of "modify code"
Flow Tuning	Override a same-name flow in missions/flows/mission-driver.json, add/remove/modify steps	Insert a compliance audit step after CHECK
Brand New Flow	Write missions/flows/<custom>.json, set flowName: "<custom>" in mission.json	Code review flow FETCH_PR → RUN_LINT → AI_REVIEW → POST_COMMENT, without Plan orchestration
Subflow Override	Place a same-name subflow JSON (e.g., plan-execution.json) in missions/flows/ to replace built-in subflows	Replace EXEC_PLANS subflow so each active plan calls external scripts before and after execution
Commands	commands field in mission.json	test = quality check script

Flow loading priority: project missions/flows/<flowName>.json → engine built-in tools/mission-driver/flows/<flowName>.json. Same-name file in project takes precedence. Subflows follow the same chain.

The promptsDir configuration allows different missions to point to different prompt subdirectories, enabling the same engine with different prompt sets:

{
  "promptsDir": "missions/prompts/analysis",
  "flowName": "mission-driver"
}

Engine prompt loading chain: promptsDir (task-type level) → missionsDir/prompts (project level) → built-in default. Behavior is unchanged when promptsDir is not set.

The built-in CHECK→REVIEW→EXEC→DRAFT→AUDIT applies to most software development scenarios. But for tasks like data processing and document analysis, it can be fully adapted with different flows—engine unchanged, just swap the flow file.

The above customization methods fully embody the Delta customization idea from the Reversible Computation Theory, a concrete implementation of non-intrusive customization. For a detailed introduction to Delta customization, see How to Achieve Custom Development Without Modifying Base Product Source Code

Part 3: Practice Methodology

7. Loop as Intelligence

The effectiveness of Mission Driver comes not only from the quality of individual AI calls, but primarily from iterative feedback improvement through loops. Feedback generated in each round of execution (test results, audit findings, human corrections) should be recorded and used to improve the next round.

AGE uses two parallel improvement tracks:

Prompts for doing (DRAFT/EXECUTE): When AI-generated plans or code are corrected by a human, the correction record is analyzed by a sub-agent, extracting general rules and writing them into skills. The AI automatically loads them next time.

Prompts for checking (CLOSURE_AUDIT/DEEP_AUDIT): When an audit misses an issue, supplement the audit prompt with additional checking dimensions.

AI generates first version
  → Human modifies (modification process logged)
  → Independent sub-agent compares original and modified versions
  → Extracts general rules on "why it was changed"
  → Writes into skills or coding standards
  → AI automatically loads next time

The nop-app-erp project has accumulated 19 reusable skills, all originating from this loop-based improvement.

8. AI Auto-Generation of E2E Tests

The manual writing and maintenance cost of E2E tests is very high; previously, few teams could maintain them broadly long-term. Now, AI can generate them automatically. The key is reducing difficulty: encapsulate the PageObject pattern, provide simplified operations like getFieldValue(containerLocator, fieldName), so AI does not need to repeatedly deal with complex DOM selectors for every page.

For example, in the Nop platform's AMIS pages, every field has a stable business identifier defined in view.xml via <cell id="customerName">, which is rendered as the AMIS component's name attribute. AI only needs to look up fields by business name:

# AI focuses on the intent "get customer name", not the DOM path
value = getFieldValue(page, "customerName")
# The encapsulation layer internally locates the input element of the corresponding AMIS component by name attribute

This encapsulation makes AI-generated test scripts more stable—when page layout changes, only the PageObject encapsulation layer needs updating; existing test cases do not need individual modification.

nop-app-erp went from 0 to 260+ specs; frequent human corrections were needed in the early phase, but later it was largely auto-generated or auto-modified.

Part 4: Case Study

9. nop-app-erp: 154 Modules in 22 Days

nop-app-erp provides a publicly auditable case: how multi-layer loop nesting drove AI from an empty skeleton to produce a production-grade ERP. In this project, directories like logs/audits/plans record the execution process and reasons for all key decisions, making it fully analyzable by AI to answer any questions about the project's evolution.
This is an inevitable result of AGE's explicit requirement that the project itself is the single source of truth: no information remains stranded in human brains, chat windows, or temporary conversations; the project's documentation and source code contain the latest project status and its complete evolutionary trajectory.

Scale Metrics (Independently Audited)

Dimension	Value
Development Period	22 days
Business Domains	18 + 1
Maven Modules	154
Own Entities	352 + 110 reference stubs
Java Tests	~2890 (0 failures)
Playwright E2E	260+ specs (0 regressions)
Plan Files	187 (all double-audited)

A Real Cycle (07-10)

08:00 CHECK     — mvn all green
08:05 REVIEW    — 4 drafts → independent review → all active
09:30 EXEC      — 4 plans executed, all green
16:00 DRAFT     — all roadmap work items done
16:05 DEEP_AUDIT — auto-triggered deep audit

One cycle took about 8 hours. The entire roadmap across 22 days was completed through dozens of cycles.

Pre-Coding Defect Interception

On 07-10, a batch of plans had independent draft review intercept 4 P0 defects: code value conflicts, BUDGET contaminating actual financials, an erroneous architectural premise in GlBalance, and dimensional ambiguity. All were intercepted before coding. Without the Plan Loop, these defects would only surface during implementation or even runtime.

Knowledge Transfer Curve

Human intervention was classified into three types: Type A (explicitly specifying platform mechanisms, concentrated early on), Type B (indicating engineering principle directions), Type C (only asking AI to self-check and compare, mainly later on).

The two curves crossed around 06-29 ~ 07-01; thereafter, AI autonomy became the primary working mode.

"Late-stage human intervention dropped to zero not because AI learned to write code, but because the attractor had been defined (the formal definition of attractors is in §12). With the right direction, AI can advance automatically."

Human attention should be spent on defining attractors, not on supervising execution. Mission Driver handles the latter. Over the entire 22 days, there were only 28 human interventions, concentrated in the early project phase. Later, as the attractor stabilized, human intervention dropped to zero, and AI advanced fully autonomously.

Part 5: In-Depth Analysis

10. Loop Engineering Principles

Traditional pipelines assume each step is deterministic, but the nature of AI execution is probabilistic—the same prompt in different sessions can produce different results.

Advantages of loop nesting: failure is expected (loops natively support retry and skip), quality is iterative (audit findings lead to improvement), recovery is natural (checkpoints are checkboxes on disk), isolation is structural (subflow boundaries = fault tolerance boundaries).

The three basic principles of Loop Engineering are: trajectory recoverability (persisted to disk, crash recovery via disk scan), local fault tolerance (subtask failure does not propagate to the parent loop), and independent verification (completion is audited by an independent sub-agent, not self-verified by the executor).

Stability Guarantees

Defense Line	Mechanism	Role
Disk Persistence	All state written to disk	Crash → restart → disk scan → breakpoint recovery
Subflow Isolation	Each plan in its own subflow	Local errors do not spread
Retry Budget	Max 3 fresh sessions per step	Avoid repeated failures in the same context
Infinite-Loop Detection	ping_pong + max_cycles + max_total_steps	Prevent infinite loops
Watchdog	60-minute sub-agent timeout	Prevent hangs
Independent Audit	CLOSURE_AUDIT uses different sub-agent	Prevent executor self-deception

Recovery Mechanism

Recovery is not replay (it does not re-execute historical steps) but disk scan (scanning disk marks). On startup, the engine scans .md files in plansDir, finds plans with Status: active, reads checkboxes ([x] skipped, [ ] resumed). The steps history in run-state.json is only for audit viewing and does not drive recovery.

11. Plan Loop and Verification System

Each plan's execution has its own internal control loop—the Plan Loop.

Core principle: generation and verification must be separated. Both draft review and closure audit are executed by independent sub-agents in fresh sessions; the auditor does not inherit the executor's context, starting from a fresh repository read.

Verification System: Script Checking + AI Auto-Improvement

Audit verification of whether a plan is complete is not simply mechanical checking or pure AI auditing, but a paired collaboration of both. Scripts automatically detect issues; when issues are found, AI automatically diagnoses and fixes them, then re-runs detection.

EXECUTE (agent: AI executes plan)
  ↓
CLOSURE_SCRIPT_CHECK (script: checks checkboxes + evidence)
  ├── pass → BUILD_VERIFY
  └── fail → CLOSURE_AUDIT (independent sub-agent review)
               ├── fixable → back to EXECUTE
               └── not fixable → blocked items moved to Deferred/Follow-up
                              rest of plan continues → completed
BUILD_VERIFY (agent: AI runs test/build/lint)
  ├── failure → AI auto-diagnosis → fix → re-run
  └── pass → plan completed ✓

Checkpoint	Detection Method	Upon Finding Issue
CHECK	Confirm buildable, test-passing baseline	AI auto-repair (max 3 fresh sessions)
CLOSURE_SCRIPT_CHECK	script checks checkboxes + evidence	Enter CLOSURE_AUDIT → back to EXECUTE; unfixable items moved to Deferred/Follow-up
BUILD_VERIFY	AI runs test/build/lint	AI diagnosis → fix → re-run
DEEP_AUDIT	Multi-dimensional audit + adversarial review	Generate remediation plan

The machine acts as referee, AI acts as improver.

12. AGE Theory: Attractors and Dynamical Systems

Mission Driver is the core implementation of AGE (Attractor-Guided Engineering) theory at the tool layer:

State Space = all possible states of the repository/project
Attractor   = docs documentation system (standardized docs like design/architecture)
              Defines "what stable structure the system should converge to in the long term"
Trajectory  = plans + logs + audits recording "how we got to the current state"
Control     = health checks + execution verification + independent audits correcting deviations

Note that the roadmap is not the attractor. The Roadmap is a human-controllable macro plan, a task-oriented projection of the attractor; the true attractor is the documentation system in docs.

Formation of Attractors

Attractors are not clear from the start. They undergo a process from vague to clear:

One-sentence requirement → Grill Me clarification → Attractor prototype (docs draft + roadmap)
  → Roadmap early stage: research competitors, refine attractor
  → Roadmap mid stage: execute items, audit convergence
  → Periodic insertion: audit/refactor/rethink, correct attractor
  → Convergence complete

The entire roadmap is executed fully autonomously, while humans influence it through two channels: before execution (Grill Me clarification + roadmap setting) and during execution (asynchronously injecting plans into the plans directory).

Asynchronous Human-AI Interaction

Mission Driver does not require real-time human interaction during execution. However, humans can asynchronously inject new tasks via the plans directory at any time:

User (or another AI agent) generates a new plan → places it in plans/ directory
  → Next round of REVIEW_PLANS automatically picks it up
  → draft status: independent review → promoted to active
  → active status: directly enters the execution queue

The plans directory can be viewed as a shared queue on the filesystem; multiple contributors can write to it independently: human developers, Code Review agents, remediation plans generated by DEEP_AUDIT all enter the same queue. There is no need to forcibly interrupt the currently executing mission to insert extra work.

13. Comparison with Codex Goal

Here we can compare Mission Driver with the Codex tool's goal mode. Through source code analysis of Codex, we can see that Codex has fairly sophisticated mechanisms (SQLite state database, goal 6-state state machine, pause/resume, token budget), but it differs significantly from Mission Driver in the following dimensions.

Dimension	Codex Goal	Mission Driver
State Persistence	SQLite + rollout JSONL. But runtime metric state is only in-memory Mutex, lost on crash; rollout may not be materialized	Checkbox disk persistence + run-state.json, all state on disk
Independent Verification	Continuation prompt requests self-review, but update_goal(complete) only writes DB without checking objective state	Combination of script checking and AI checking; CLOSURE_AUDIT mandatory by independent sub-agent
Task Granularity	Max 1 goal per thread (single objective + token budget)	Multi-plan coexistence management: plans/ can have multiple active plans simultaneously; engine executes sequentially
Async Interaction	Can pause/resume same thread, but cannot asynchronously inject new tasks	Anytime drop a plan into plans/, automatically picked up next round
Failure Isolation	Single goal failure contaminates context window	Subflow isolation: failure of one plan does not affect others
Termination Guarantee	Token budget + blocked detection (model self-reports requires 3 rounds; after self-report, deferred table prevents continued execution)	Multi-layer defenses (retry budget, infinite-loop detection, watchdog, etc.), all externally enforced
Information Visibility	SQLite + JSONL require tools to parse; runtime state is memory-invisible	All state is files, readable by both humans and AI

Part 6: Vision

14. Goal-Driven Vision and Economic Paradigm

The evolution direction of Mission Driver is a goal-driven AI system—the user states the goal, the system automatically clarifies, plans, executes, and verifies.

User: "Analyze the differences between nop-stream and Flink, improve nop-stream until it becomes a mature distributed stream processing framework"
  → Grill Me (requirement clarification) → clarified spec
  → Auto-Detect (task type → promptsDir)
  → Generate (roadmap + mission.json)
  → Run (automatic loop execution until complete)

Of these, Generate (draft command) and Run (run command) already have an implementation foundation. Grill Me (enhanced deep-interview skill) and Wrapper (entry layer) need to be built.

Shift in Economic Paradigm

§1 already pointed out that in the Human in the Loop model, the efficiency bottleneck is that the human must be inside the loop. The core change of Human on the Loop is not excluding humans, but moving the human's position from an execution node inside the loop to a control factor outside the loop. The frequency and timing of intervention are determined by the clarity of the attractor, not the AI's work rhythm.

The most profound impact of this structural change is the inversion of model selection strategy:

• In Human in the Loop mode, every output blocks on human confirmation. The human cannot wait, so the fastest, strongest model must be used, even if it's expensive. Response latency is the primary constraint; model cost is secondary.
• In fully autonomous operation mode, no one is waiting. A weaker model may be slower, consume more tokens, and require more iteration rounds to complete work, but it has a low unit cost, can run at night, and multiple missions can process different roadmap work items in parallel. Response latency changes from a constraint to a schedulable variable.

Cost accounting thus shifts from "output per person-hour" to "intelligent output per dollar"—the former optimizes the efficiency of a single human-computer interaction, the latter optimizes the cumulative output per unit of computing power. These two optimization objectives lead to completely different engineering choices: the former pursues single-conversation quality, the latter pursues the stability of the loop structure and the rigor of auditing.

15. Summary

The value of Mission Driver lies in three aspects:

First, it replaces linear pipelines with persistent, locally retryable loop nesting. AI steps are probabilistic, requiring retries, iteration, and local fault tolerance. Subflow isolation ensures the failure of one plan does not affect others.

Second, it achieves customization through configuration, not programming. The engine is a generic Flow DSL executor; the built-in five-step cycle is just the default flow—you can fine-tune steps, replace subflows, or design entirely new workflows. The differences between task types are captured in three layers: flow + prompt + commands.

Third, it puts all state on disk. Checkbox persistence + disk scan recovery means no data loss after a process crash.

It is not limited to code development. Any complex task requiring multi-step iteration, quality auditing, and fault-tolerant recovery can be driven by it. This is exactly the realization of Loop Engineering as an engineering practice.

Further Reading

• Mission Driver source code: https://github.com/entropy-cloud/attractor-guided-engineering-template/tools

• Plan authoring guide: https://github.com/entropy-cloud/attractor-guided-engineering-template/plans/00-plan-authoring-and-execution-guide.md

• In-depth analysis of AGE theory: Attractor Before Harness: Methodology for Large-Scale AI Development

• nop-app-erp full case materials: https://github.com/entropy-cloud/nop-app-erp