# Lins Living Loop > Use when work becomes durable or resumable—even mid-conversation—or the user requests LLL/DOP, 深度编排/调研, background agents, or recoverable execution. Choose the smallest file-backed mode; keep human deliverables at the root and process/recovery state under internal/. - Skill: `linlin00000000/lins-living-loop` (Agent Skill, multi-file: 10 files) - Install (CLI): `npx skillmds@latest add linlin00000000/lins-living-loop` - Raw SKILL.md: https://api.skillmd.com/api/skills/linlin00000000/lins-living-loop/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: LinLin00000000 (https://skillmd.com/u/linlin00000000) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/linlin00000000/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: | axis | choices | answers | |---|---|---| | Structure mode | no LLL, LLL Lite, full LLL | How much durable workspace, state, validation, and recovery surface is needed? | | Loop preset | none, Code Loop | Is the task a repeated develop/run/verify/fix loop that needs lease/retry/checkpoint semantics? | | Carrier / adapter | inline supervisor, delegated worker, command/job, runner/orchestrator | What actually executes each unit of work in this environment? | 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](references/minimal-runner.md) and [references/adapters.md](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](references/mode-selection-and-escalation.md). ## Living loop ```text Seed -> Split -> Work -> Trace -> Heal -> Validate -> Hand off -> Grow or Close ``` | LLL step | File-backed action | |---|---| | Seed | Write/update `mission.md` | | Split | Decompose `internal/tasks.jsonl` and, for real workers, `internal/agents//task.md` | | Work | Workers write artifacts and logs under `internal/agents//` | | Trace | Append claim/source/change records to `internal/traceability.jsonl` | | Heal | Append workflow/runtime abnormalities and repairs to `internal/error-report.jsonl` | | Validate | Validator writes evidence; supervisor records the canonical verdict with `lll validation set` | | Hand off | Refresh `internal/recovery.json`; keep free-form worker handoffs task-local | | Grow or Close | Put current next steps inside the primary deliverable or relevant deliverable | ## 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 --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//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: ```text ~/lll-work/YYYYMMDD-HHMMSS_short-description-in-kebab-case/ ``` Canonical current layout: ```text / mission.md # current task contract .md # optional primary human-facing deliverable .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// # 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](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](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](references/observability-recovery.md) and CLI mechanics in [references/minimal-runner.md](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: ```text created_at: updated_at: status: ``` 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//` 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//` 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](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](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](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/-/`; 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](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 --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. | level | carrier bucket | use when | |---|---|---| | 0 | inline supervisor | planning, small edits, synthesis, quick validation | | 1 | delegated worker | bounded parallel research, critique, synthesis, validation, or specialist execution that can write durable files | | 2 | command/job | deterministic scripts, tests, crawls, builds, scheduled checks, or long bounded jobs | | 3 | runner/orchestrator | many tasks need leases, retries, checkpoints, recovery, human block/unblock, or long project coordination | 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](references/observability-recovery.md) and runtime mappings in [references/adapters.md](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//` 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](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//` 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: ```yaml 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: ```yaml 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: ```text 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.