v1.4.0 — plural instruments + capability flags

[1.4.0] — 2026-10-10

The plural-instruments release: intent work splits into specifying (spec against latent intent) and inspecting the cascade (cascade against spec), each with more than one instrument; phase discipline travels into subagent dispatches; and the full workflow reaches instruction-file-only hosts as a vendored doc instead of an always-loaded summary.

Added

• Specification and inspection instruments. The core skill names the two kinds of intent work and their instruments, offered conversationally — never configured. Specifying: drafting-then-review or elicitation, chosen by the user's grain of interaction (one concept at a time vs. one document at a time), switching mid-artifact as the grain shifts. Inspecting: the human reading output at a stop, a zero-context reader (the coach's cold-read pass, the experimental blind differential), a delegated inspector whose summarized findings the human rules on, or out-of-band review (a PR review after the change lands on a branch). Two invariants hold whatever the instruments: an inspector's findings are never applied silently, and a spec admitting two readings always goes back to the user. Delegation changes who inspects at a stop, never how many stops there are. (LID-CORE-047–051; docs/decisions/inspection-instrument-selection.md)
• Delegation discipline. Discipline does not travel by ambient context: any dispatch of phase work to a subagent embeds that phase's obligations in the dispatch prompt itself — for implementation work, the EARS IDs in scope, the tests-first gate, and the @spec requirement. Dynamic, not a checklist: new phase obligations ride dispatches automatically. (LID-CORE-052)
• Divergence probe in Phase 4. Each new or changed spec line is probed for divergent plausible readings — what a blind implementer could take it to require — and only genuine forks surface for user resolution before tests. Reader ladder: in-context generation is the floor; blind subagents given only the spec text when available; an equivalently capable cross-provider model where the platform allows. Fork resolutions land atomic — a narrowing edit or a new line, never a compound bundle. (LID-CORE-053–055)
• Misplaced-EARS guard. Prevention: EARS requirement content lives only in the owning node's {node}-specs.md; design docs cite spec IDs without defining or extending their content — now stated inline in the core skill's Phase 3. Detection: audit check 6 scans every -design.md for EARS-labeled intent the doc defines rather than references (a mechanical marker-line screen plus a judgment pass on definition versus reference); findings only, never auto-moved. (LID-CORE-056; SCALE-MAINT-031)
• Vendored workflow doc, on demand. For harnesses without a plugin system, the full workflow ships as docs/lid/workflow.md, assembled from the core skill source at release, with a generated-file header; /update-lid's version-walk re-syncs it and surfaces hand-edits rather than overwriting them. It is vendored only where such a harness works: every project's instruction file carries one workflow section, a compact core whose pointer tells a harness without the skill to read the doc and, when it is missing, to offer once to fetch it from the release matching the project's - Version:. A decline is recorded as - Workflow doc: declined in the ## LID block. /update-lid makes no offer itself: it runs on plugin hosts, and a vendored doc pins its project to the release that wrote it. Per-tool deterministic loading is documented (.aider.conf.yml read: entry; Amp @-mention). (LID-UPDATE-048–053; docs/decisions/workflow-distribution.md; evidence: docs/research/harness-instruction-idioms.md)
• review-depth experiment (lid-experimental). A declared review depth: the user states, in their own prose, the phase depth they personally review; deeper phases still run but consolidate into one review at the declared boundary. Specification forks in the user's declared judgment areas interrupt immediately; forks outside them are parked in a write-at-detection fork log and ruled on at the boundary, never resolved silently. A separate tests gate says whether the user reviews the failing tests before code (tests always come first); with it off, tests and code consolidate into one review at the end. Fail-open guardrails; promotion target is quiet absorption into core. Judgment areas start from the core list of what still reaches the human, and a flagged kind counts as a judgment area unless the user, knowing the flag, says otherwise. (EXP-DEPTH-001–013)
• Decision-capture review dimension in /lid-coach. Flags an under-captured landed decision: one a cold reader of the landed design (holding the row and the docs above it) would question or try to reverse, and whose record does not let them reconstruct what was given up. The sweep asks the liveness question first, so terse rows on settled choices are left alone, and judges from the landed state, not from how contested the call was. The first report names findings only; remedies come in follow-up turns, defaulting to an expanded Decisions row, with a decision doc named as an option when other design nodes rely on the decision's reasoning. (LID-COACH-058–062, -066, -067)
• Tenet cascade review dimension in /lid-coach. Flags a leaf mechanism that works against one of the HLD's own tenets or goals, naming the tenet, the mechanism, and the condition; the remedy (change the design, record the exception, revise the tenet) is the user's choice. A mechanism that only costs something toward a goal, or that carries out another tenet, is not a conflict. (LID-COACH-064, -065, -068, -069)
• Design for the pair, not the model (HLD tenet). LID's guidance is written for the user and model working together; judgment that depends on the model's capability goes to the pair's review rather than LID rewording itself to coax a model through it.
• What still reaches the human. The core skill names the recurring kinds of judgment the human brings (spec fork, unsettled choice, tenet or goal conflict, cross-node contradiction, rung mismatch, code drift, missed cascade, wrong attachment level, under-captured decision, hard to undo, unpinned invariant). The list is not exhaustive and every kind defaults to the human; the user lets kinds go in their own words, by the risk they perceive, for the project or one stream of work. Spec forks and hard-to-undo changes need a deliberate opt-in. (LID-CORE-061–065)
• Capability flags. references/capability-flags.md records, from blind-graded evals at reasoning effort medium, the kinds of judgment specific model configurations (model ID at a reasoning effort) reliably miss; the file opens with a lookup by model. A flagged model brings that judgment to the user; an untested configuration treats every flag as applying. First flags: tenet or goal conflict (claude-sonnet-4-5, claude-haiku-4-5, z-ai/glm-5.3-flash) and under-captured decision (claude-sonnet-4-5, claude-haiku-4-5, openai/gpt-5.6-terra), across 13 configurations. A tendency records a lean in something the user already decides (offering decision docs too readily: claude-opus-4-8, z-ai/glm-5.3-flash), mentioned once when it comes up. Nothing is said when no flag applies. (LID-CORE-058–060, -066, -075, -076; LID-COACH-063; EXP-DEPTH-011)
• Decision docs are offered, not written by default. When the user settles a choice among options the agent sketched (Phase 1, or a new Phase 2 options sketch for an LLD-level choice), the agent records nothing, records a row, or offers a doc once, and offers only when the choice will stay live: credible options traded against more than one criterion, with other design nodes about to be sized around it. No offer for a dominated choice, one a constraint settles, or one that affects a single node, however long it was debated. The doc is written only on acceptance, in the owning node's decisions/, linked from its Decisions row (the HLD's Key Design Decisions entry for a project-level choice). (LID-CORE-011, -071–074)
• Terms flow down the arrow. A term is defined at the lowest node that dominates every node using it, as decisions are; plain descriptive phrases are preferred to coined terms. (LID-CORE-067–070)
• Core scenario evals. linked-intent-dev gains a small eval suite for the moments with a checkable output: two projects where a decision doc should be offered and two where it should not. Evals may script a follow_up turn for the user's side of an exchange, and tested_with entries now name the reasoning effort and, for runs outside Claude Code, the harness.

Changed

• Tenets are one-line leans. Embedded operational procedure routes to workflow guidance; the HLD's own tenets were trimmed accordingly (Docs carry current intent, Verticalize intent), the bundled placement/cascade tenet split in two, and elicitation now applies three tests in order — platitude, spec-shaped, form. (LID-CORE-041; template note)
• Stop and iterate at every phase → Every phase is inspected. The tenet keeps the lean — alignment is verified, never assumed, by the human or an inspector they authorize; the per-phase stop remains the core mechanism, stated in the specs and skill where mechanism belongs. The HLD § Approach gains the specification/inspection distinction the tenet turns on.
• Node-shape guidance names its two forces. Split out what is independent (a concern spanning components with its own design decisions becomes its own node, referenced from dependent nodes' design docs); consolidate what is bounded (categories of one component's intent are within-leaf facets, not child nodes). (LID-CORE-040, -042–044; compound specs -011/-015 split atomic into -045/-046/-042–044)
• map-codebase sweep handoff relocated from .lid/map-codebase/ to the reserved docs/arrows/_map-codebase/ subtree — transient, audit-excluded, removed at terminal verification. .lid/ no longer exists anywhere in LID.
• Skill size and line limits. Each SKILL.md body stays under 50 KB with no line over 2,000 characters, so every harness loads the whole skill (opencode's skill tool and file reader cut beyond these). lid-coach moved situational material into references/ (follow-up turns, conversational guidance, sampling); its principles stay in the skill.
• HLD positioning (folded from No-Version-Update): linkage's payoff named as two-fold — navigation and attestation — with a Glossary Attestation entry; marketing arrow gained the attestation story, a copy-effectiveness pass, and the Teams section (MKT-SITE-055–064), then a heading-register copy pass: claim-bearing headings on the site's skim path, the hero asking "How do you know your agent built what you meant?", and a Copy register in the marketing LLD (MKT-SITE-001/002/055/060/061 amended; 067–071 added). Site content only.

Migration (v1.3 → v1.4)

• Directives refresh (mechanical). Run /update-lid; reconcile-conventions updates the instruction file's workflow section — the per-phase stop procedure line becomes the inspection invariant ("each phase's output is inspected — by the user or an inspector they name — before the next begins; ambiguous spec readings go back to the user"). The workflow bullets become the single current shape: the pointer with the on-demand workflow-doc offer, the workflow in one line, and the bug-fix line. Stop mechanics live in the skill and workflow doc, where procedure belongs.
• Workflow doc (informational). Nothing to choose at upgrade. The refreshed workflow section offers the doc on demand to any harness without the LID skill; projects worked only on plugin hosts stay unvendored and keep following the plugin's releases. If you already vendored docs/lid/workflow.md, the walk re-syncs it.
• Tenet form sweep (judgment). One-time retroactive application of the form rule: review each ## Tenets entry for embedded operational procedure (how to apply it, steps to run); keep the one-line lean, route the elaboration into workflow guidance. Genuine lean-only tenets need no change.
• Misplaced-EARS sweep (judgment). One-time retroactive application of the new placement rule: scan your -design.md files for EARS requirement content defined in place — the audit's new check 6 finds exactly these — and extract each to the owning {node}-specs.md, leaving a reference behind. New /arrow-maintenance runs flag them as findings from now on.
• Expect new finding classes (informational). The arrow-maintenance audit gained check 6 (misplaced EARS) and /lid-coach gained review dimensions 18 (decision capture) and 19 (tenet cascade); first runs after upgrading may surface findings in previously-quiet projects. All three are findings-only — nothing is auto-repaired.
• Judgment reaches you by default (informational). Expect the agent to bring the listed kinds of judgment to you at phase stops. To let some go, say so in your own words, for the project or for one stream of work; a standing preference can be written as prose in your instruction file.
• Capability flags (informational). If your model is flagged in references/capability-flags.md, expect it to ask you to check that kind of judgment yourself.
• Old .lid/ working files (judgment, rare). A .lid/map-codebase/ directory exists only where a capacity-constrained mapping run was interrupted. If that sweep is still wanted, move it to docs/arrows/_map-codebase/, where new runs look for it; otherwise delete it.

Plugin versions

linked-intent-dev 1.4.0 · arrow-maintenance 1.3.0 · lid-experimental 0.3.0