Lins Living Loop

Lin's Living Loop / LLL

Lin's Living Loop is a tiny file-backed living loop for serious AI-agent work. It is formerly DOP — Deep Orchestration Protocol.

Core sentence:

The filesystem is where the work lives. The chat is only the current interface. The agent is the caretaker of the next loop.

LLL is intentionally boring at the machine layer: plain files before databases, small scripts before frameworks, handoffs before long chat summaries, risk-matched validation before delivery, and upgrade paths only when the simple path stops being enough.

The current layout is deliberately shallow: mission.md and human deliverables live at the workdir root; process state, workers, logs, traceability, and error records live under internal/. New workdirs do not create output/, 00-index.md, or a standalone Next Steps file.

Use / do not use

Use LLL when:

• the user explicitly says LLL, Lin's Living Loop, DOP, 深度调研, 重型任务, 长时任务, 深度编排, 可恢复, background agent, durable worker, or similar;
• the task has multiple genuinely independent work surfaces; sequential phases inside one producer do not count as separate tracks;
• the task may outlive one turn, one request, or one stable API call;
• the conversation/tool context is already large enough that hidden assumptions may drift (long transcript, many tool outputs, context compaction risk, or the user explicitly mentions context drift / 外部文件契约);
• the result must be auditable, reproducible, resumable, or suitable for later continuation;
• correctness depends on separate review or validation.

Do not use full LLL for simple Q&A, quick searches, tiny edits, or tasks safely completed in a few tool calls. If unsure, choose the smallest honest mode that preserves the work without pretending to have more process than actually ran.

Mid-task durability escalation

Structure-mode selection is not a one-time kickoff decision. Reassess it before the next substantive durable write whenever the task grows beyond its original chat scope. A task that began as disposable chat must upgrade to at least LLL Lite when:

• it now includes a high-signal durable action such as Git commit/push, SaaS deploy/publish, DNS/domain changes, remote configuration, or AIOps write-back; and
• it also has three or more meaningful stages, an external build/propagation wait or multi-node test, or an expected retest, migration gate, or cross-session handoff.

Either condition alone is not an automatic trigger. A single isolated, low-risk write that can finish honestly in one turn without later recovery remains outside LLL.

After escalating, use the reuse/recovery rules below. If no plausible prior Worksite exists, create a new Lite Worksite from now and never fabricate historical tasks, workers, or audit. A host semantic layer may resolve a Matter/case to a Worksite, but it must not duplicate LLL state or make chat history the current-state owner.

Worksite creation and user-facing progress/result receipts are separate decisions. Follow the host interaction policy for observable actions even when no Worksite exists, and never project Worksite fields that do not exist.

Important: loading this skill is not the same as using LLL. For non-trivial skill/repo/workflow edits—especially changes touching several files, scripts, templates, docs, validation, or git commit/push—create at least an LLL Lite workdir (mission.md + compact notes/validation) rather than substituting a chat todo list for durable state.

Context-drift rule: when the chat/tool context is large, long-running, or likely to be compacted, externalize the task contract before doing more substantive work. Update mission.md, notes.md or a root deliverable, internal/recovery.json, and validation/audit files so the filesystem—not the model's current attention—is the source of truth for objective, constraints, decisions, current status, and acceptance checks.

Context-budget rule: do not create a parallel root-level context recovery system inside an LLL workdir. Keep the current restore order and next action in internal/recovery.json; put optional budget/risk state in internal/context-budget.json only when a CLI/runner consumes it. Root files should remain mission.md and human-facing deliverables/product docs, not duplicate process state.

Workflow semantic-layer rule: when a task introduces richer workflow concepts—Matter, Decision, Approval, Artifact, Asset, Presentation View, Execution Projection, typed gates, or promotion policy—treat them as semantic layers on top of the LLL workdir, not as a competing runtime state system. Root Markdown/HTML deliverables are Presentation Views. Kanban, GitHub, runners, Feishu, and similar systems are Execution Projections only when they can link back to the LLL workdir and sync/write state safely. Closeout should classify outputs as accepted deliverables, asset candidates, archived evidence, or pruned noise. Do not add a new workflow root, task root, context root, or event root beside LLL unless a real CLI/runner consumes it and the authority boundary is explicit.

Machine-state format rule:

• current singleton snapshots use JSON (recovery.json, validation.json, task status.json);
• row-oriented collections and append-only history use JSONL (tasks.jsonl may be atomically rewritten; runs.jsonl, error-report.jsonl, and traceability.jsonl append);
• Markdown/HTML are for human-facing deliverables or genuinely free-form natural-language contracts/handoffs, not machine state disguised as prose;
• agents decide; lll CLI/scripts perform deterministic, atomic structured-state mutation;
• phase plus internal/tasks.jsonl/operational_queue are authoritative; legacy duplicate aliases such as current_phase and nonterminal_tasks must not survive a fresh checkpoint, and conflicting aliases block closeout;
• YAML is for human-authored declarative configuration when needed, not runtime state;
• add SQLite only after real cross-Matter query, concurrency, transaction, or latency pressure appears; JSON/JSONL remain the portable protocol boundary.

Mode selection: structure mode, loop preset, and carrier

LLL has three orthogonal decision axes:

Choose the structure mode first, add Code Loop only when the work is truly iterative, then choose the lightest reliable carrier. Code Loop is not a fourth structure mode; it is a runner-oriented preset layered on an LLL workdir. CLI/task preset fields may also carry adapter labels such as manual or deep-research; those labels do not create new product-level modes or protocol semantics.

Code Loop preset

Use Code Loop only for repeated develop/run/verify/fix work that needs command execution, verification, leases, retries, or checkpoints. It is layered on a normal LLL Worksite, not a fourth structure mode.

Compile the objective into tasks with explicit command, verify, safety boundary, repo/cwd, attempt limit, and delivery policy. Let the runner own deterministic lifecycle; the supervisor still owns judgment, synthesis, validation, and user-facing handoff. The reference CLI is optional and replaceable; host wrappers/executors must not duplicate LLL state. See references/minimal-runner.md and references/adapters.md.

Use full LLL for real worker lanes, long/background execution, large evidence, multi-node/wait/retry recovery, or delegated roles needing durable records. Use LLL Lite for durable single-track work. Sequential phases or role labels alone do not upgrade the mode. Do not manufacture worker directories when there were no real workers. Detailed examples live in references/mode-selection-and-escalation.md.

Living loop

Seed -> Split -> Work -> Trace -> Heal -> Validate -> Hand off -> Grow or Close

Default new workdir; reuse only with a clear signal

Default to a fresh LLL workdir. Do not proactively scan old LLL/DOP/PWF directories just because a similar task may have been done before.

A path to an old workdir is not by itself a reuse signal. Reuse only when there is explicit continuation/recovery intent, such as 继续, 接着, 复用, 基于这个目录继续, 恢复, repair this workdir, audit this workdir, add to this run, or an immediate same-conversation correction/addendum to the active run.

When reuse is chosen, read the compact current state first:

1. mission.md
2. lll status <workdir> --json --compact when available; it projects task counts/records plus recovery.json and validation.json without creating another stored truth
3. otherwise read internal/recovery.json, internal/validation.json, and internal/tasks.jsonl
4. relevant internal/agents/<task-id>/status.json and handoff.md
5. top-level task-specific deliverables
6. tails/slices of internal/traceability.jsonl, internal/error-report.jsonl, and logs only as needed

Classify the new request as extension, correction, workflow addendum, new evidence, validation follow-up, or mission change. Update mission.md, append JSONL audit entries, and update/rewrite the relevant root deliverable. Create a new workdir when the mission changed enough that old evidence would contaminate the new task.

For a narrow correction or analytical addendum on an existing completed workdir, scale execution to the delta instead of replaying the original topology. Reuse frozen inputs and deterministic scripts; add a validator only when the changed surface meets the final gate below. Multiple producers require genuinely independent evidence or methods—not archival symmetry.

Older layouts remain resumable with loose detection only:

• transitional: collab/ + readable/;
• legacy: root tasks.jsonl, runs.jsonl, agent-registry.md, agents/, deliverables/.

Legacy/transitional layouts remain discoverable, but LLL 0.2 full validation expects the current JSON machine-state format. On an explicit continuation, migrate the active workdir once; never dual-write old Markdown state and new JSON state. Leave unrelated archived workdirs untouched.

Minimal workdir

Default new workdir path:

~/lll-work/YYYYMMDD-HHMMSS_short-description-in-kebab-case/

Canonical current layout:

<lll-workdir>/
  mission.md                    # current task contract
  <task-specific-name>.md        # optional primary human-facing deliverable
  <another-topic>.md             # optional additional deliverable when justified
  notes.md                      # optional Lite notes / inline supervisor notes
  internal/                     # process, audit, validation, worker state
    tasks.jsonl                 # durable queue, when full LLL or runner state is needed
    runs.jsonl                  # append-only event stream
    error-report.jsonl          # append-only workflow/runtime abnormalities and repairs
    traceability.jsonl          # append-only claim/source/change/evidence map
    recovery.json               # canonical current resume snapshot
    validation.json             # canonical current validation verdict/evidence pointers
    inputs/                     # raw/reference materials introduced during the run
    logs/
      supervisor.log
      runner.log
    agents/<task-id>/           # only for real workers/background jobs/runner tasks
      task.md
      status.json
      log.txt
      handoff.md
      artifacts/

Keep internal/ shallow. Add deeper folders only when they reduce recovery cost. Raw repositories, source dumps, scraped pages, long logs, validation, recovery state, final/internal handoffs, and process files go under internal/. Human-facing deliverables go at the root beside mission.md.

Do not create these for new workdirs:

• output/
• 00-index.md
• 99-next-steps.md / Next Step.md / Next Steps.md

Human deliverables

Human-facing Markdown/HTML lives at the Worksite root with task-specific names. Merge coherent work; split only for independent themes, audiences, or reuse. Put current next steps inside the relevant deliverable and keep machine state/logs under internal/.

Use the user's requested/current interaction language as a hidden default; copied template prose must be localized before delivery. Link only the user-facing artifacts needed for the current reading or next action. Detailed language, audience, and reuse rules live in references/human-deliverables.md.

Research runs and retention

Research-specific scope correction, evidence tiers, traceability density, and retention/promotion belong in references/research-runs.md. Retention is a semantic closeout judgment, not LLL machine state; never promote automatically.

JSONL audit logs

internal/error-report.jsonl owns workflow/runtime abnormalities and repairs; internal/traceability.jsonl owns claims, sources, assumptions, changes, and validation evidence. Both are append-only, timestamped event streams—not human reports or places to restate normal user requirements.

Prefer lll audit append when available. Resume by tail/time/task/item instead of rereading full history; keep exact schemas and chronology rules in references/observability-recovery.md and CLI mechanics in references/minimal-runner.md.

Mission maintenance

mission.md is the current task contract, not a one-time kickoff note. Keep it compact and current. Its job is to prevent context drift: a future supervisor should be able to recover the real objective, constraints, decisions, and acceptance checks from files without trusting the previous chat window.

Maintain a visible fenced metadata block near the top:

created_at: <local/user-timezone timestamp with explicit offset>
updated_at: <refresh whenever mission constraints/success criteria/outputs/status/scope change>
status: <initialized|active|blocked|completed|archived>

Keep the main sections as a mutable current snapshot: Objective, Success criteria, Constraints, Inputs, Expected outputs, and Execution policy. When the user adds scope or corrects assumptions, update the relevant snapshot and add a short timestamped Mission addenda entry. Do not turn mission.md into a transcript.

After final validation and delivery, mark status: completed. If work resumes, set it back to active and append an addendum.

Worker record completeness

Create internal/agents/<task-id>/ only for real worker contexts, jobs, CLIs, humans, runner tasks, or an explicitly justified supervisor-inline audit record. A completed real task needs non-empty task.md, status.json, log.txt, handoff.md, and artifacts/; empty/fake worker trees are workflow errors to repair and record.

Hard invariants

1. Write/update mission.md, internal/recovery.json, the queue when used, and worker task.md before launching long work. If context is already large or compaction is likely, refresh the file-backed contract before continuing. In Lite, use compact mission.md plus notes.md or a root deliverable instead of a fake queue.
2. Workers write detailed work only under internal/agents/<task-id>/ unless explicitly assigned a shared root deliverable.
3. Shared state files (internal/tasks.jsonl, internal/runs.jsonl, internal/recovery.json, internal/validation.json) have one writer: the supervisor or a real runner. Use the CLI where a mutation command exists; tasks.jsonl owns task state and recovery.json stores only a compact projection. Queue locking is not a Worksite-wide writer lease; implementation details belong in references/minimal-runner.md.
4. Raw data, long logs, evidence, drafts, repositories, downloads, and debugging material go under internal/.
5. Synchronous subagents are not durable/background workers; if the parent turn is interrupted, they can be cancelled.
6. Child prompts carry the compact LLL contract: read mission/task/inputs, write only in the assigned area, keep handoffs short and claims traceable, do not edit shared state unless granted, and record blockers with fallback. Real contributors need complete worker records; read-only reviewers need an isolated or frozen surface. See references/validator-pass-patterns.md.
7. Runtime carriers are adapters, not the protocol. Persist only provenance and timestamps the runtime actually exposed; never invent session ids, independence, chronology, or precision. See references/observability-recovery.md.
8. Apply the risk-matched final gate below to the final deliverable; ordinary workers and internal stages do not create validators.
9. Structure validation is not mission validation.
10. Prefer the simplest reliable carrier and upgrade only when the simpler form is insufficient.

Durable output-path preflight

Before the first durable write, download or extraction output, or durable delegated launch, apply the existing mode-selection rules and resolve the destination owner using current user request > current mission > standing policy. This path-safety gate does not conflate observable progress/result receipts with Worksite creation.

1. Classify the task as no LLL, LLL Lite, or full LLL before writing. One isolated, low-risk, reversible action with a single explicit owner may stay no LLL and does not require a Worksite.
2. Delegation alone does not upgrade the structure mode. Create or freeze a Worksite first only for durable, multi-stage, or recoverable delegation, or when another existing LLL trigger applies.
3. Only LLL Lite and full LLL require an explicit worksite_root under ~/lll-work/<timestamp>-<slug>/; human-facing Markdown belongs at that root and raw/process material belongs under internal/.
4. In every mode, reject direct children of $HOME such as $HOME/report.md or $HOME/ad-hoc-dir/ as default destinations for human deliverables, raw evidence, logs, or durable task state. Non-Worksite writes may target an explicit project/OPS owner path, a documented runtime cache, or a user-specified destination; record the exception in the mission when a Worksite exists, or in the compact progress/result receipt otherwise.
5. Before delivery, scan only direct children of $HOME for the current task slug. Verify any canonical report or evidence path against the selected owner boundary, and verify a workspace:// link only when such a link is actually delivered. Do not deliver while an accidental home-root copy remains.

Keep this a narrow deterministic supervisor preflight, not a database, registry, second state system, or duplicate mode-selection algorithm.

Execution flow

1. Clarify only if missing information would make the work unsafe or obviously wrong.
2. State important side effects briefly: file writes, network/API calls, background processes, code execution, Git changes, external services.
3. If SKILL.local.md exists next to this file, read it for local/user-specific defaults; otherwise skip it silently.
4. Create a fresh workdir by default, or resume only with a clear reuse signal.
5. If the current context is large, first externalize the contract: objective, constraints, decisions, current status, next action, and validation criteria.
6. Decompose into orthogonal tasks with explicit outputs and acceptance checks.
7. Choose structure mode: no LLL, LLL Lite, or full LLL.
8. Choose the lightest honest carrier for each task: inline supervisor, delegated worker, command/job, or runner/orchestrator.
9. Launch work; make workers write files and return short handoffs. When a runtime supports batching independent synchronous workers, launch independent tasks together instead of serializing them. Sequential child calls are only acceptable when later tasks depend on earlier outputs, or when rate limits/tool constraints require serialization; otherwise record the reason in the handoff or error log.
   • Name one canonical producer for each shared/root deliverable. Parallel workers may supply evidence or critique, but should not each rebuild the same analyzer, report, or canonical state unless independent implementation is the stated validation method.
   • Reference CLI arguments and path rules belong in references/minimal-runner.md.
10. Keep supervisor context small: read compact state and handoffs first; read raw artifacts only when needed.
11. Synthesize into one or more root deliverables.
12. Append traceability and error JSONL entries as needed.
13. Apply the risk-matched final gate under Synthesis and validation.
14. After a validator-only pass, run a supervisor closeout loop: consume the verdict, repair safe structural gaps, check the language of every human-facing root deliverable against the requested/current interaction language, update the validation task, record the canonical verdict through lll validation set, refresh mission.md and internal/recovery.json, and append trace/error JSONL entries as needed. Then run lll closeout <workdir> --json --write-report. Do not deliver while validation is pending, expected worker handoffs are missing, or a primary human-facing deliverable is in the wrong language.
15. Ensure mission.md, root deliverables, internal/traceability.jsonl, internal/error-report.jsonl, internal/validation.json, and internal/recovery.json are current before final delivery.
16. Final reply points to deliverables and gives a short conclusion.

Progress updates

For long, multi-stage, background, or multi-worker runs, give occasional compact phase updates separate from the final response: coarse progress, the current finding/phase, and the next action or blocker. Do not emit ceremony for every command or estimate from token/time use.

Carrier escalation ladder

Keep the product-level carrier model small. Specific runtimes can map these buckets to their own tools.

Do not default to databases, daemons, boards, distributed workflow engines, or project-management systems. They are optional adapters inside the runner/orchestrator bucket, not core LLL concepts.

Carrier failure and fallback

Treat model/API carriers as replaceable and sometimes scarce. Keep child scope bounded, use deterministic tools for mechanical work, inspect durable outputs before relaunching, and keep at most one active carrier per logical role. After repeated failure from the same runtime cause, record it and switch carrier instead of repeating an identical large retry. A carrier failure is not evidence that the researched source or result does not exist. Detailed recovery rules live in references/observability-recovery.md and runtime mappings in references/adapters.md.

Synthesis and validation

Use a synthesis worker when there are multiple substantive outputs, conflicts, or a final synthesis/decision. Synthesis reads mission, task state, worker handoffs, and selected artifacts; it writes root deliverables and JSONL audit entries.

Routine low-risk Lite work may close with deterministic mission checks and focused readback. Use one independent validator for an important canonical deliverable, a real risk gate, or an explicit review requirement. This is a frozen final-deliverable gate, not a per-worker or per-stage quota.

Start the final validator only after the canonical producer has frozen the validation surface. Record the target deliverable paths and, when practical, content hashes or a generation/version marker in the validator task or producer handoff. If the producer changes a target afterward, that verdict is stale: repair the target, update the frozen marker, and rerun the one validator rather than layering a second validator on a moving artifact.

For security-sensitive public release, enumerate concrete risk axes, run deterministic scans where possible, and use one independent validator over the frozen surface. Add another perspective only for a named material axis that validator cannot cover; never use a fixed quota.

Delegated validators are real LLL workers even when they are synchronous subagents. Create internal/agents/<validation-task-id>/ records for them (task, status, handoff/log or summary, and any artifacts) or explicitly record why a lighter inline validation was chosen. Do not let internal/ imply “single-agent work” when subagents materially contributed to safety or correctness.

Validate two layers:

1. Structure validation: required files exist, JSONL parses, task ids/statuses/dependencies are valid, task output paths stay under the worker directory, per-task files exist for real tasks, no obsolete new-layout output/ surface exists, and validation/handoff files exist before final delivery.
2. Mission validation: outputs satisfy success criteria, root deliverables exist when needed, human-facing prose uses the chosen language, important claims trace to evidence, assumptions are labeled, failed/blocked tasks were handled, code/tests/builds ran or failures are documented, and the result is useful without raw intermediate context.

For a continued correction/addendum, validate the changed/active surface plus the current canonical recovery/validation snapshots. Do not normalize or backfill unrelated historical worker records solely to make a newer CLI accept an older run. If a full-workdir structure check reports a legacy-only gap that does not compromise the current delta, record it as a compatibility caveat; repair history only when it is needed for current auditability or recovery.

Verdicts:

• PASS: deliverables satisfy the mission criteria.
• PASS_WITH_NOTES: deliverables are useful and satisfy the mission well enough to deliver, but caveats are visible and non-blocking.
• FAIL: mission criteria are not met or blocking checks failed.

lll validation set merges with the existing object. For a genuinely new scope, clear stale scope-specific fields before writing the new verdict; see references/minimal-runner.md for the exact command pattern.

If FAIL, create follow-up tasks or record an explicit blocker; do not deliver a FAIL as done.

Self-iteration and error reports

Treat every editable skill as living procedural memory. LLL should improve from its own failures.

During LLL, internal/error-report.jsonl records internal workflow/runtime abnormalities and repairs, not user goals. Record failed assumptions, worker failures, adapter/quoting/tool issues, path-safety issues, validation failures, queue/status drift, stale/missing skill guidance, weak triggers, and better verification methods.

After the basic task is complete and validation has produced a usable verdict, run a lightweight workflow retrospective before final delivery. Inspect the current run's workflow reports — especially internal/validation.json, internal/error-report.jsonl, internal/traceability.jsonl, worker handoffs/logs when relevant, and the root deliverable shape — and ask what the run teaches about the workflow itself. Look for repeatable improvements: clearer triggers, better decomposition, stronger validation, safer fallback paths, smaller context surfaces, better evidence capture, missing templates/scripts, or unnecessary ceremony that should be removed.

Close the loop with one explicit self-maintenance decision: patch an existing skill when the improvement is procedural and reusable; create a new skill only after user confirmation; update durable memory only for stable user/environment preferences; or record in the validation report / handoff why no self-maintenance action is needed. Keep this retrospective small: it should strengthen future LLL runs without turning every task into a meta-project.

Project and source-of-truth hygiene

When LLL is used to create, publish, or maintain a reusable skill, GitHub repo, package, or long-lived project, keep work records and project source code separate:

• ~/lll-work/ is for LLL run/work records only.
• Do not put a long-lived Git repo directly under ~/lll-work/ unless the user explicitly asks.
• Default reusable projects/repos to ~/projects/<repo-slug>/ or a user-specified project directory.
• If a local installed skill should track a canonical repo, prefer a symlink from the installed skill path to the canonical repo over copying the repo into multiple skill directories.

Optional local skill memory

LLL's public skill stays portable. User-specific and environment-specific preferences may live in a local-only SKILL.local.md next to SKILL.md. If it exists, read it near the start of nontrivial LLL work. Treat it as defaults and context, not as the run's source of truth. When a local preference materially affects the current run, copy the relevant decision into mission.md, a root deliverable, internal/recovery.json, or internal/traceability.jsonl.

Final response

Match the user's language. Give the verdict, primary user-facing deliverable(s), and at most a few real caveats or next actions. Do not paste long reports or surface internal/ files by default; they are recovery/audit state, not the user's reading surface.

Resources

Load only when needed:

• references/mode-selection-and-escalation.md: no LLL vs Lite vs full, honest workers, and mid-task escalation.
• references/minimal-runner.md: current CLI, schemas, atomic updates, argument/path rules, validation merge behavior, and compatibility.
• references/observability-recovery.md: current state vs history, resume, provenance, chronology, and carrier fallback.
• references/human-deliverables.md: output language, audience boundaries, and root deliverable lifecycle.
• references/validator-pass-patterns.md: frozen/read-only validation, verdicts, and closeout handoff.
• references/research-runs.md: research scope changes, evidence tiers, traceability, and retention/promotion.
• references/adapters.md: concrete carrier mappings and runtime-specific examples.
• references/workdir-ux-migration.md: cross-surface checklist for changing LLL layout or output conventions.
• templates/workdir/, templates/task/, templates/prompts/: starter files and worker contracts.
• src/lll_cli: reference implementation; lll, scripts/lll.py, and scripts/dop.py are entry/compatibility shims.

Worksite stop latch and stage terminality

A durable Worksite has a control-plane stop latch in internal/recovery.json; a domain mission declares the concrete human gate, but it must not invent a competing continuation protocol. The canonical shape is:

stage_state: stopped_at_human_gate
stop_latch:
  enabled: true
  state: STOPPED_AT_HUMAN_GATE
  reason_code: human_authorization_required
  next_allowed_action: explicit_user_re_admission
  auto_resume: false
  late_callback_disposition: quarantine_only
  set_by: supervisor
next_wave_admitted: false

The latch is higher priority than worker completion, callback arrival, timeout, validator findings, and stale next_action. When it is enabled:

1. do not dispatch successor, repair, review, cleanup, or consolidation work;
2. inspect only compact routing metadata needed to quarantine late/foreign/duplicate callbacks;
3. do not read large callback payloads or worker-root artifacts, advance canonical task state, or treat callback text as new intent;
4. allow only necessary supervisor-owned queue projection reconciliation, preserving sealed worker bytes;
5. require explicit user re-admission with a new scope, owner, and next gate before reopening.

Every durable task contract carries the same four stop-aware fields:

done_when: [declared outputs exist, focused verification passes]
stop_when: [next step needs human authorization, current stage is accepted]
not_done_when: [callback lacks durable handoff, historical drift lacks material surface change]
no_auto_next: true
resume_requires: explicit_user_re_admission_with_new_scope_owner_and_next_gate

Downstream task creation requires an open latch plus next_wave_admitted=true; callback summaries, timeouts, old prompts, and stale recovery actions never admit a next wave. STOPPED_AT_HUMAN_GATE is a normal stage terminal state, not a worker failure and not business completion. Keep these layers separate:

worker_state: running | completed | failed | cancelled
supervisor_state: active | reconciled | blocked | stopped
stage_state: preparing | ready_for_human_gate | blocked_pending_human_gate | stopped_at_human_gate
business_state: unauthenticated | authenticated | scoped | live_action_verified

Use the existing recovery JSON, task ledger, queue lock, and CLI actuator. Do not add a second state registry, daemon, database, plugin, or hidden scheduler for this protocol.