technique_capsules.min.json

{
  "capsule_version": 1,
  "source_of_truth": "frontmatter-summary+markdown-technique-capsules-v1",
  "techniques": [
    {
      "id": "AOA-T-0001",
      "name": "plan-diff-apply-verify-report",
      "summary": "Safe workflow for agent-driven changes using explicit planning, scoped diffs, explicit validation, and concise reporting.",
      "one_line_intent": "Reduce unsafe, opaque, or non-reviewable agent changes by requiring a visible workflow before and...",
      "use_when_short": "Use when agent-assisted code changes or infrastructure or configuration edits.",
      "do_not_use_short": "Avoid when trivial wording fixes with no meaningful operational consequence or urgent manual intervention where immediate human action matters more...",
      "core_contract_short": "Core contract: changes must stay reviewable by another human or agent; validation must be named explicitly, not implied.",
      "main_risk_short": "Main risk: VERIFY is named, the report looks complete, and review passes even though the validation was symbolic or never...",
      "validation_short": "Validate by checking a concrete plan exists before apply; the diff stays inside the declared scope; at least one explicit validation method...",
      "technique_path": "techniques/execution/agent-workflows-core/plan-diff-apply-verify-report/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0002",
      "name": "source-of-truth-layout",
      "summary": "Repository document role separation pattern that keeps status, plans, history, decisions, and run instructions in distinct canonical homes.",
      "one_line_intent": "Reduce documentation drift by giving each recurring kind of project information one canonical document...",
      "use_when_short": "Use when multi-document repositories that mix planning, execution, history, and operations or solo+AI or human+agent projects where many edits happen...",
      "do_not_use_short": "Avoid when very small repositories where one short README is enough or projects that already use an external system as...",
      "core_contract_short": "Core contract: each recurring information class has one canonical home; each meaningful change routes to exactly one primary document first.",
      "main_risk_short": "Main risk: the role map drifts after repo evolution, so real updates no longer route to one canonical home.",
      "validation_short": "Validate by checking each major document has an explicit role; a sample change can be routed to one primary document without ambiguity...",
      "technique_path": "techniques/instruction/docs-boundary/source-of-truth-layout/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0003",
      "name": "contract-first-smoke-summary",
      "summary": "Runnable smoke pattern where each smoke path emits a machine-readable summary that becomes the primary validation contract.",
      "one_line_intent": "Make smoke checks reviewable, automatable, and reusable by treating the machine-readable summary as the...",
      "use_when_short": "Use when repositories with runnable smoke scripts or operational probes or CI pipelines that need stable pass or fail signals.",
      "do_not_use_short": "Avoid when one-off manual checks with no need for repeatability or cases where a full test suite already provides the...",
      "core_contract_short": "Core contract: each smoke path produces one machine-readable summary; the summary contains an explicit success or error status.",
      "main_risk_short": "Main risk: summaries collapse to a bare error signal without enough observed context to diagnose what failed.",
      "validation_short": "Validate by checking the summary file is always written on success and is written on failure whenever possible; the summary is valid...",
      "technique_path": "techniques/proof/evaluation-chain/contract-first-smoke-summary/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0004",
      "name": "intent-plan-dry-run-contract-chain",
      "summary": "Safe workflow that normalizes intent into a traceable plan, validates it with dry-run, and enforces contract checks before any real execution path exists.",
      "one_line_intent": "Turn high-level intent into a traceable, reviewable, dry-run-only chain that emits explicit artifacts and...",
      "use_when_short": "Use when automation systems that start from intent-like inputs or agent workflows that need a reviewable planning layer before execution.",
      "do_not_use_short": "Avoid when simple scripts that do not need an intent abstraction or systems that already execute real actions directly without...",
      "core_contract_short": "Core contract: the adapter does not perform real input events or equivalent side effects; the planning step emits a plan...",
      "main_risk_short": "Main risk: dry-run artifacts look complete but do not reflect real execution constraints, creating false confidence.",
      "validation_short": "Validate by checking the intent payload is accepted or rejected by explicit normalization rules; the normalized plan is written as an artifact...",
      "technique_path": "techniques/execution/intent-chain/intent-plan-dry-run-contract-chain/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0005",
      "name": "new-intent-rollout-checklist",
      "summary": "Checklist for safely adding a new intent type to an intent-plan-dry-run chain without contract drift.",
      "one_line_intent": "Extend an existing intent -> plan -> dry-run -> contract-check pipeline with one new...",
      "use_when_short": "Use when an automation chain already exists and the rollout is extending that shared chain, not redesigning it or one...",
      "do_not_use_short": "Avoid when there is no stable intent-chain contract yet or the rollout path performs real side effects before dry-run validation.",
      "core_contract_short": "Core contract: one canonical fixture exists for each new intent rollout; the rollout path stays dry-run only.",
      "main_risk_short": "Main risk: fixture drift makes the rollout look green while real inputs have already diverged.",
      "validation_short": "Validate by checking the canonical fixture exists and matches the new intent contract; the smoke path runs the new intent through the...",
      "technique_path": "techniques/execution/intent-chain/new-intent-rollout-checklist/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0006",
      "name": "latest-alias-plus-history-copy",
      "summary": "Dual-write summary pattern that keeps a stable latest alias, preserves nested history, and prevents double-count accumulation.",
      "one_line_intent": "Keep machine-readable summaries easy to discover for consumers while also preserving a trustworthy run-by-run...",
      "use_when_short": "Use when summary-producing checks need one stable consumer-facing path or history collectors or trend scanners need per-run rows.",
      "do_not_use_short": "Avoid when summaries are purely ephemeral and no latest or history contract is needed or consumers already address immutable per-run...",
      "core_contract_short": "Core contract: the latest alias path is stable and consumer-facing; the history copy lives under run_dir.",
      "main_risk_short": "Main risk: the latest alias looks healthy while nested history parity or reader precedence is already drifting, so accumulation trust...",
      "validation_short": "Validate by checking the latest alias exists at the stable expected path; the history copy exists under run_dir; the history copy differs...",
      "technique_path": "techniques/proof/published-summary/latest-alias-plus-history-copy/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0007",
      "name": "signal-first-gate-promotion",
      "summary": "Staged pattern for promoting an observed validation signal into strict enforcement without losing diagnostics or widening the fail surface too early.",
      "one_line_intent": "Turn an observed validation signal into the default staged path toward a hard gate...",
      "use_when_short": "Use when a machine-readable check already exists and can emit stable summaries or the team wants to observe regressions before...",
      "do_not_use_short": "Avoid when the check is too immature to produce stable summary output or the project needs immediate hard blocking and...",
      "core_contract_short": "Core contract: the same underlying summary contract is used in both signal_only and strict modes; signal_only returns success for valid...",
      "main_risk_short": "Main risk: promotion happens from a shallow or noisy history window, so strict mode is enabled before the signal is...",
      "validation_short": "Validate by checking the observational mode always publishes machine-readable output; the same summary contract is still readable after strict mode is introduced...",
      "technique_path": "techniques/proof/evaluation-chain/signal-first-gate-promotion/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0008",
      "name": "published-summary-remediation-snapshot",
      "summary": "Read-only aggregation pattern that turns latest published summaries into a bounded remediation snapshot without replaying history or changing runtime behavior.",
      "one_line_intent": "Create one reviewable remediation snapshot from already-published latest summaries, so operators, dashboards, and agents...",
      "use_when_short": "Use when nightly or scheduled checks already publish stable machine-readable latest summaries or several stable published summaries feed more than...",
      "do_not_use_short": "Avoid when source checks do not publish stable latest summaries yet or the source set is still small enough that...",
      "core_contract_short": "Core contract: the helper reads latest published summaries only; the helper does not replay history or recompute trend state.",
      "main_risk_short": "Main risk: remediation output starts reading like an integrity verdict or rendering instruction, so operators infer more than the backlog...",
      "validation_short": "Validate by checking only latest published summary aliases are read; no history replay or trend recomputation is required; the bucket set is...",
      "technique_path": "techniques/proof/published-summary/published-summary-remediation-snapshot/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0009",
      "name": "lightweight-status-snapshot",
      "summary": "Keep top-level status documents short and link-driven, while routing detailed execution state and history to their canonical homes.",
      "one_line_intent": "Keep repository entrypoint status easy to scan by turning top-level status docs into short...",
      "use_when_short": "Use when the repository already has a source-of-truth layout for plans, runbooks, decisions, and history or README needs to stay...",
      "do_not_use_short": "Avoid when the repository is small enough that one short README is already sufficient or there is no canonical home...",
      "core_contract_short": "Core contract: README stays a short human-facing entrypoint; MANIFEST, when present, stays a short machine or mixed snapshot.",
      "main_risk_short": "Main risk: the snapshot becomes so thin that it no longer gives enough orientation to send readers to the right...",
      "validation_short": "Validate by checking README remains short and human-facing; MANIFEST, when used, remains a compact snapshot rather than a long log; detailed run...",
      "technique_path": "techniques/instruction/docs-boundary/lightweight-status-snapshot/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0010",
      "name": "telemetry-integrity-snapshot",
      "summary": "Read-only integrity verdict that checks telemetry and summary-layout invariants across latest published summaries without widening the hard fail surface.",
      "one_line_intent": "Provide one machine-readable diagnostic verdict over published summary invariants, so operators can quickly tell...",
      "use_when_short": "Use when several latest published summaries already exist for one operational decision path or several published summaries or downstream rollups...",
      "do_not_use_short": "Avoid when source summaries are not stable enough to serve as inputs yet or the project needs direct enforcement instead...",
      "core_contract_short": "Core contract: the helper reads latest published summaries only; the helper is read-only with respect to upstream summaries and runtime...",
      "main_risk_short": "Main risk: optional consistency noise starts crowding out required-source health, so the snapshot stops pointing attention at the bounded contract...",
      "validation_short": "Validate by checking required source presence and schema health are checked explicitly; telemetry counters or mismatch counters are surfaced in the snapshot...",
      "technique_path": "techniques/proof/published-summary/telemetry-integrity-snapshot/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0011",
      "name": "required-vs-optional-source-rendering",
      "summary": "Distinguish strict required sources from tolerant optional sources so operator-facing summary surfaces remain useful without hiding true hard failures.",
      "one_line_intent": "Keep summary-driven surfaces resilient by enforcing strict behavior for required sources while letting optional...",
      "use_when_short": "Use when a UI, dashboard, CLI report, or smoke check reads multiple published summary artifacts or some sources are mandatory...",
      "do_not_use_short": "Avoid when every source is equally required for the surface to be meaningful or the surface is only for manual...",
      "core_contract_short": "Core contract: required and optional source sets are explicit; required-source failure can trigger smoke or strict contract failure.",
      "main_risk_short": "Main risk: an actually critical source is misclassified as optional and stays there long enough to distort operator interpretation.",
      "validation_short": "Validate by checking required missing sources and optional missing sources are reported separately; missing required sources fail the strict smoke or contract...",
      "technique_path": "techniques/proof/published-summary/required-vs-optional-source-rendering/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0012",
      "name": "deterministic-context-composition",
      "summary": "Compose agent context from smaller fragments into a stable generated artifact with deterministic ordering and source traceability.",
      "one_line_intent": "Keep agent context scalable by composing it from smaller source fragments into a stable...",
      "use_when_short": "Use when repositories where one hand-written AGENTS.md no longer scales or projects that want fragment-first authoring with one generated context...",
      "do_not_use_short": "Avoid when very small repositories where one short hand-maintained context file is enough or systems that depend on runtime code...",
      "core_contract_short": "Core contract: source fragments remain the canonical editable inputs; the output artifact is generated and should not become the hand-edited...",
      "main_risk_short": "Main risk: ordering and priority rules become implicit, so the generated artifact changes in ways contributors cannot predict from the...",
      "validation_short": "Validate by checking the generated artifact can be recreated from source fragments without manual merge steps; higher-priority fragments surface earlier and stable...",
      "technique_path": "techniques/instruction/instruction-surface/deterministic-context-composition/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0013",
      "name": "single-source-rule-distribution",
      "summary": "Keep one canonical rule source and distribute it to multiple agent-facing instruction surfaces without turning each target into a hand-maintained source of truth.",
      "one_line_intent": "Reduce drift and duplicated maintenance by keeping one canonical rule source and propagating it...",
      "use_when_short": "Use when repositories that support multiple coding agents or agent-facing instruction formats or projects that already feel the cost of...",
      "do_not_use_short": "Avoid when repositories that only need one instruction surface or projects that are unwilling to treat target files as managed...",
      "core_contract_short": "Core contract: one canonical rule source owns the shared instruction content; target instruction files are managed or derived outputs, not...",
      "main_risk_short": "Main risk: target instruction surfaces drift away from the canonical rule source because local edits or wrapper changes are applied...",
      "validation_short": "Validate by checking one canonical rule source is named explicitly; at least two target instruction surfaces receive the same shared rule core...",
      "technique_path": "techniques/instruction/instruction-surface/single-source-rule-distribution/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0014",
      "name": "tdd-slice",
      "summary": "Implement a bounded behavior slice through test-first discipline, minimal implementation, and explicit refactor limits.",
      "one_line_intent": "Reduce ambiguity and regression risk by expressing one bounded behavior slice as tests before...",
      "use_when_short": "Use when small or medium feature slices with clearly describable behavior or logic changes that benefit from explicit behavioral framing.",
      "do_not_use_short": "Avoid when exploratory work where the behavior is still too vague to test meaningfully or large structural rewrites where test-first...",
      "core_contract_short": "Core contract: tests should express behavior rather than incidental implementation detail; the implementation should stay bounded to the declared slice.",
      "main_risk_short": "Main risk: tests mirror the implementation instead of constraining it.",
      "validation_short": "Validate by checking tests were added or updated before implementation when the task was suitable for TDD; the implementation stayed inside the...",
      "technique_path": "techniques/execution/agent-workflows-core/tdd-slice/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0015",
      "name": "contract-test-design",
      "summary": "Make a boundary explicit by defining expected inputs, outputs, and verification around the contract rather than around hidden internals.",
      "one_line_intent": "Reduce breakage at boundaries by expressing the expected interface behavior explicitly and verifying it...",
      "use_when_short": "Use when service or module boundaries with downstream consumers or smoke paths that should emit stable summaries or structured output.",
      "do_not_use_short": "Avoid when purely local logic with no meaningful boundary or situations where the real problem is that the boundary itself...",
      "core_contract_short": "Core contract: the contract should be visible and reviewable by another human or agent; validation should target the boundary surface...",
      "main_risk_short": "Main risk: the contract is too vague or fixture-shaped to constrain the actual consumer-visible boundary.",
      "validation_short": "Validate by checking the boundary and consumers were named explicitly; tests or checks target observable contract behavior; at least one check exercises...",
      "technique_path": "techniques/proof/skill-support/contract-test-design/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0016",
      "name": "bounded-context-map",
      "summary": "Reduce semantic drift by naming bounded contexts, separating responsibilities, and making handoff interfaces visible for docs and scoping work.",
      "one_line_intent": "Reduce semantic confusion and misplaced changes by naming bounded contexts, clarifying their responsibilities, and...",
      "use_when_short": "Use when repositories with several domains, services, or subsystems that can blur together or situations where naming is overloaded or...",
      "do_not_use_short": "Avoid when tiny repositories with no meaningful subsystem ambiguity or changes that are fully local and already clearly bounded.",
      "core_contract_short": "Core contract: context boundaries should reduce semantic confusion rather than create taxonomy for its own sake; neighboring contexts should be...",
      "main_risk_short": "Main risk: too many contexts are invented for a small problem.",
      "validation_short": "Validate by checking the main ambiguity or vocabulary drift was reduced; contexts or subsystems were named with clearer responsibility boundaries; handoff or...",
      "technique_path": "techniques/proof/skill-support/bounded-context-map/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0017",
      "name": "property-invariants",
      "summary": "Express stable system or domain truths as invariant-oriented tests or checks so broad behavior is constrained beyond a small handpicked example set.",
      "one_line_intent": "Reduce weak example-only validation by expressing stable system or domain truths as invariant-oriented checks...",
      "use_when_short": "Use when rules that should hold across a wide input or state space or situations where example-based tests feel too...",
      "do_not_use_short": "Avoid when presentation-only behavior where concrete examples are clearer or situations where no meaningful invariant is yet understood.",
      "core_contract_short": "Core contract: each property should express a meaningful invariant; the technique should broaden coverage beyond a tiny fixed example set.",
      "main_risk_short": "Main risk: the chosen invariant is too weak or too generic to constrain real behavior.",
      "validation_short": "Validate by checking the property expresses a meaningful invariant rather than a vague expectation; the resulting check broadens coverage beyond a small...",
      "technique_path": "techniques/proof/skill-support/property-invariants/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0018",
      "name": "markdown-technique-section-lift",
      "summary": "Lift stable technique markdown sections into derived section-level units while keeping the bundle markdown authoritative.",
      "one_line_intent": "Lift stable TECHNIQUE.md section boundaries into a derived section-level surface so retrieval and review...",
      "use_when_short": "Use when repositories with stable technique or pattern documents that already use recurring top-level headings or generated knowledge or retrieval...",
      "do_not_use_short": "Avoid when repos where section headings are still unstable or heavily experimental or systems that want section-level authorship to move...",
      "core_contract_short": "Core contract: the markdown bundle remains the authoritative source of section meaning; lifted sections stay bounded to an explicit stable...",
      "main_risk_short": "Main risk: unstable or project-shaped headings are lifted too early, so the derived surface changes shape faster than consumers can...",
      "validation_short": "Validate by checking lifted sections come from one authoritative TECHNIQUE.md bundle; the derived output preserves the expected section order; the selected headings...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/markdown-technique-section-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0019",
      "name": "frontmatter-metadata-spine",
      "summary": "Treat bounded frontmatter and derived catalog outputs as a metadata spine for bundle routing without replacing markdown meaning or growing schema past current needs.",
      "one_line_intent": "Use shallow frontmatter and derived catalog outputs as a stable metadata spine for bundle...",
      "use_when_short": "Use when markdown-first repositories that need a small machine-readable layer for lookup or routing or corpora where domain, kind, status...",
      "do_not_use_short": "Avoid when systems that want full section meaning, rationale, or caution language to live in metadata or repos where frontmatter...",
      "core_contract_short": "Core contract: frontmatter stays shallow and bounded; the catalog remains fully derived from authoritative markdown-frontmatter.",
      "main_risk_short": "Main risk: frontmatter widens until it starts carrying section meaning or policy semantics that belong in markdown.",
      "validation_short": "Validate by checking bundle identity and routing fields are visible in frontmatter; derived catalog entries match source frontmatter; the catalog helps answer...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/frontmatter-metadata-spine/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0020",
      "name": "evidence-note-provenance-lift",
      "summary": "Use typed evidence note kinds and note paths as bounded provenance handles in derived manifests without flattening them into a note graph.",
      "one_line_intent": "Lift typed evidence notes into a bounded provenance surface so readers and tooling can...",
      "use_when_short": "Use when repositories where technique bundles already point to typed supporting notes or provenance questions such as origin proof, second-context...",
      "do_not_use_short": "Avoid when systems that have no stable note kinds or no explicit note paths or cases where the real need...",
      "core_contract_short": "Core contract: note paths and note kinds remain explicit; note meaning stays in authored markdown.",
      "main_risk_short": "Main risk: note kinds drift until the manifest can no longer tell which provenance kind a note is meant to...",
      "validation_short": "Validate by checking bundles point to supporting notes through explicit evidence.kind and evidence.path; note kinds remain understandable and bounded; the derived provenance...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/evidence-note-provenance-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0021",
      "name": "bounded-relation-lift-for-kag",
      "summary": "Lift small typed direct relations into bounded edge hints for derived consumers without turning them into graph semantics.",
      "one_line_intent": "Use a small typed set of direct bundle relations as bounded edge hints for...",
      "use_when_short": "Use when corpora that already have explicit direct relations between bundles or navigation or retrieval surfaces that need one-step adjacency...",
      "do_not_use_short": "Avoid when systems that need relation rationale, weighted edges, or multi-hop traversal policy right now or repositories where direct relations...",
      "core_contract_short": "Core contract: relations stay direct and typed; edge meaning is bounded to one-step adjacency hints.",
      "main_risk_short": "Main risk: relations multiply until the signal-to-noise ratio drops and adjacency hints stop helping.",
      "validation_short": "Validate by checking each relation points to a real direct target; current consumers use the edges for one-step navigation rather than inference...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/bounded-relation-lift-for-kag/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0022",
      "name": "risk-and-negative-effect-lift",
      "summary": "Lift richer `Risks` language into bounded caution-oriented lookup and reuse without turning caution into metadata, scoring, or generated policy.",
      "one_line_intent": "Lift richer Risks language into bounded caution-oriented lookup and reuse so reviewers and later...",
      "use_when_short": "Use when repositories where TECHNIQUE.md already uses the fixed five-part Risks shape or review or reuse flows that need to...",
      "do_not_use_short": "Avoid when systems that need a threat model, incident taxonomy, or policy-scoring framework rather than bounded technique caution or repos...",
      "core_contract_short": "Core contract: TECHNIQUE.md Risks remains the primary caution source; the five shadow-language distinctions stay explicit and bounded.",
      "main_risk_short": "Main risk: reviewers can mistake the presence of five caution subsections for proof that the technique's shadow is already fully...",
      "validation_short": "Validate by checking the source bundle keeps Failure modes, Negative effects, Misuse patterns, Detection signals, and Mitigations inside ## Risks; caution lookup...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/risk-and-negative-effect-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0023",
      "name": "stateless-single-shot-agent",
      "summary": "Keep shell-side agent work mostly stateless and bounded to one confirmed step per invocation so runs stay composable, reviewable, and low-memory by default.",
      "one_line_intent": "Keep quick shell-side agent work bounded to one mostly independent invocation so the fast...",
      "use_when_short": "Use when ad hoc shell assistance where one answer or one bounded tool-using step is enough or workflows that value...",
      "do_not_use_short": "Avoid when multi-step repository changes that need planning, diff review, verification, and reporting across several actions or tasks that depend...",
      "core_contract_short": "Core contract: each invocation stays mostly independent and reproducible by default; transient context is an input to one run, not...",
      "main_risk_short": "Main risk: a supposedly single-shot invocation quietly expands into a multi-step loop with hidden state.",
      "validation_short": "Validate by checking one invocation handles one explicit question or one explicit action request; read-only question flows do not silently gain tool...",
      "technique_path": "techniques/execution/agent-workflows-core/stateless-single-shot-agent/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0024",
      "name": "upstream-mirroring-with-provenance",
      "summary": "Mirror upstream-owned content into a curated local collection through an explicit source manifest and preserved provenance so the local copy stays reviewable without pretending to be the canonical source.",
      "one_line_intent": "Reuse externally maintained content in a local curated collection without losing origin ownership, attribution...",
      "use_when_short": "Use when repositories that curate externally maintained content but do not want each mirrored copy to become a new undocumented...",
      "do_not_use_short": "Avoid when repositories that need one local canonical source to fan out to several managed targets inside the same project...",
      "core_contract_short": "Core contract: the upstream source remains the canonical origin of the mirrored content; the local copy stays subordinate to explicit...",
      "main_risk_short": "Main risk: mirrored content drifts because local edits accumulate without a clear resync path back to upstream.",
      "validation_short": "Validate by checking each mirrored item is named in one explicit source manifest; the local mirror carries adjacent provenance or attribution metadata...",
      "technique_path": "techniques/instruction/instruction-surface/upstream-mirroring-with-provenance/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0025",
      "name": "capability-spec-versioning",
      "summary": "Keep agent-facing capability contracts in a versioned, reviewable spec so capability changes stay explicit and reusable without turning the spec into routing or registry policy.",
      "one_line_intent": "Keep capability behavior reviewable by naming it in one versioned spec instead of letting...",
      "use_when_short": "Use when agent-facing systems that expose named capabilities and need contract changes to be explicit or repositories where capability inputs...",
      "do_not_use_short": "Avoid when workflows whose main problem is plan orchestration, task scheduling, or multi-agent execution order or systems where the real...",
      "core_contract_short": "Core contract: one capability spec stays the authoritative contract for the named capability; version changes are explicit and reviewable rather...",
      "main_risk_short": "Main risk: a version number changes without any real contract review, so the spec stops signaling meaningful change.",
      "validation_short": "Validate by checking one capability has one explicit versioned spec; the spec names inputs, outputs, and invariants clearly enough to review without...",
      "technique_path": "techniques/instruction/capability-registry/capability-spec-versioning/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0026",
      "name": "session-capture-as-repo-artifact",
      "summary": "Capture AI coding sessions as versioned repo artifacts so project history stays searchable, reviewable, and reusable without turning session logs into memory or instruction policy.",
      "one_line_intent": "Preserve AI coding sessions as explicit project-scoped history artifacts so useful reasoning, decisions, and...",
      "use_when_short": "Use when repositories that want local-first session history to remain searchable and shareable as project artifacts or workflows that need...",
      "do_not_use_short": "Avoid when systems whose main reusable object is long-term memory retrieval, recall ranking, or memory-object storage or workflows that want...",
      "core_contract_short": "Core contract: session history stays project-scoped and artifact-based; local persistence remains available without requiring cloud sync.",
      "main_risk_short": "Main risk: session artifacts quietly become the de facto instruction source because no stronger authored source stays visible.",
      "validation_short": "Validate by checking session history is saved as project-scoped artifacts; the local artifact path remains useful even without cloud sync; a reviewer...",
      "technique_path": "techniques/history/history-artifacts/session-capture-as-repo-artifact/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0027",
      "name": "cross-agent-skill-propagation",
      "summary": "Keep one canonical skill or rule source and propagate it to multiple agent-facing targets without turning each target into a hand-maintained source of truth.",
      "one_line_intent": "Keep one canonical skill or rule source and propagate it to multiple agent-facing targets...",
      "use_when_short": "Use when repositories that need one shared skill or rule core to reach several agent-facing targets or projects where managed...",
      "do_not_use_short": "Avoid when repositories that only need one instruction surface or projects where each target must carry materially different meaning.",
      "core_contract_short": "Core contract: one canonical skill or rule source owns the shared meaning; target files are managed or derived outputs, not...",
      "main_risk_short": "Main risk: target surfaces drift because local edits are applied without flowing back through the canonical source.",
      "validation_short": "Validate by checking one canonical skill or rule source is named explicitly; at least two agent-facing targets receive the same shared core...",
      "technique_path": "techniques/instruction/instruction-surface/cross-agent-skill-propagation/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0028",
      "name": "confirmation-gated-mutating-action",
      "summary": "Require one explicit confirmation seam before a read or plan flow crosses into a mutating action so the action stays reviewable without widening into a multi-step autonomous loop.",
      "one_line_intent": "Keep the boundary between read or plan work and mutating work explicit so a...",
      "use_when_short": "Use when a read or plan flow is enough until one specific mutating step is ready or a mutating step...",
      "do_not_use_short": "Avoid when the task is already a full multi-step workflow that needs planning, diff review, validation, and reporting or the...",
      "core_contract_short": "Core contract: read or plan work stays distinct from mutating work; the confirmation seam is the center of the contract.",
      "main_risk_short": "Main risk: the confirmation step becomes so weak that it no longer feels like a real gate.",
      "validation_short": "Validate by checking a read or plan flow can pause before mutation; the mutation is named explicitly before it runs; the confirmation...",
      "technique_path": "techniques/execution/agent-workflows-core/confirmation-gated-mutating-action/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0029",
      "name": "nested-rule-loading",
      "summary": "Load hierarchical rule layers with explicit precedence so nested additions stay subordinate to one canonical source of ownership.",
      "one_line_intent": "Load rule content through a hierarchy of layers so shared defaults, scoped overrides, and...",
      "use_when_short": "Use when repositories or instruction trees that already organize rules into parent and nested layers or projects that need explicit...",
      "do_not_use_short": "Avoid when repositories that only need one flat instruction surface or workflows where the real need is one canonical rule...",
      "core_contract_short": "Core contract: one canonical source owns the shared meaning; nested layers are scoped additions, not independent canonical homes.",
      "main_risk_short": "Main risk: precedence becomes implicit, so nested layers override parent meaning in ways reviewers cannot predict.",
      "validation_short": "Validate by checking one canonical source is still the owner of shared meaning; nested layers resolve in the documented precedence order; removing...",
      "technique_path": "techniques/instruction/instruction-surface/nested-rule-loading/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0030",
      "name": "fragmented-agent-context",
      "summary": "Keep agent context in bounded fragments before deterministic assembly so modular authoring stays reviewable without collapsing into the final generated artifact.",
      "one_line_intent": "Keep agent context authored in smaller bounded fragments so source partitioning, local ownership, and...",
      "use_when_short": "Use when repositories where one large hand-maintained agent context file has become hard to review or extend or projects that...",
      "do_not_use_short": "Avoid when repositories that only need one short context file and do not benefit from fragment boundaries or workflows where...",
      "core_contract_short": "Core contract: fragments remain the editable source of truth for the partitioned context layer; each fragment carries bounded scope rather...",
      "main_risk_short": "Main risk: fragment boundaries become arbitrary, so the context is split across files without clearer ownership.",
      "validation_short": "Validate by checking the fragment set is the editable source of truth; each fragment has bounded scope that a reviewer can explain...",
      "technique_path": "techniques/instruction/instruction-surface/fragmented-agent-context/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0031",
      "name": "shell-composable-agent-invocation",
      "summary": "Make agent runs composable as shell-side one-shot tools through explicit stdin, stdout, files, and pipes without widening into generic shell advice or autonomous loops.",
      "one_line_intent": "Keep agent invocations composable as shell tools so one-shot runs can read from stdin...",
      "use_when_short": "Use when shell-side workflows where an agent should behave like one more composable command or cases where files, pipes, and...",
      "do_not_use_short": "Avoid when workflows where the real need is a visible confirmation seam before mutation or tasks that need multi-step planning...",
      "core_contract_short": "Core contract: the agent run stays one-shot and shell-visible; stdin, stdout, files, or pipes remain the primary composition boundary.",
      "main_risk_short": "Main risk: the invocation stops behaving like a shell tool and starts depending on hidden session state.",
      "validation_short": "Validate by checking the run behaves like one shell-visible invocation; inputs and outputs can move through stdin, stdout, files, or pipes; the...",
      "technique_path": "techniques/execution/agent-workflows-core/shell-composable-agent-invocation/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0032",
      "name": "context-report-for-ci",
      "summary": "Emit CI-facing reports for context composition, source coverage, token-estimate drift, and related composition checks without turning the report surface into the composition technique itself.",
      "one_line_intent": "Produce a bounded CI-facing report that tells reviewers how well a composed context covered...",
      "use_when_short": "Use when CI jobs that need one readable report about context composition health or repositories that want source coverage and...",
      "do_not_use_short": "Avoid when when the main task is deterministic context composition itself or when the task is to create a remediation...",
      "core_contract_short": "Core contract: the report stays read-only and CI-facing; source coverage is visible without exposing the composition engine as the technique.",
      "main_risk_short": "Main risk: the report starts acting like a hidden remediation engine instead of a read-only CI view.",
      "validation_short": "Validate by checking the CI output is readable without inspecting the composition engine; source coverage is visible and bounded; token-estimate drift is...",
      "technique_path": "techniques/proof/evaluation-chain/context-report-for-ci/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0033",
      "name": "decision-rationale-recording",
      "summary": "Keep one meaningful decision in a reviewable note with context, options, rationale, and consequences while staying out of source-of-truth governance and architecture taxonomy.",
      "one_line_intent": "Record one meaningful decision in a compact, reviewable note that preserves context, options, rationale...",
      "use_when_short": "Use when a real choice has been made and the reason needs to stay reviewable or multiple viable options were...",
      "do_not_use_short": "Avoid when trivial obvious edits that do not deserve a decision note or tasks whose real need is source-of-truth clarification.",
      "core_contract_short": "Core contract: the note must preserve context, options, rationale, and consequences; the note must stay bounded to one decision rather...",
      "main_risk_short": "Main risk: the note captures a summary but not the actual decision tradeoff.",
      "validation_short": "Validate by checking one real decision is named clearly; context, options, rationale, and consequences are all visible; the not-chosen option and the...",
      "technique_path": "techniques/instruction/docs-boundary/decision-rationale-recording/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0034",
      "name": "public-safe-artifact-sanitization",
      "summary": "Turn sensitive technical material into a shareable artifact by removing, redacting, or generalizing details while preserving the lesson and staying distinct from approval gating or execution planning.",
      "one_line_intent": "Convert potentially sensitive technical material into a shareable artifact that keeps the lesson while...",
      "use_when_short": "Use when logs, configs, diagnostics, reports, or examples contain sensitive details or a result needs to be shared with a...",
      "do_not_use_short": "Avoid when the material is already clearly public-safe and minimal or the real question is whether sharing is allowed at...",
      "core_contract_short": "Core contract: the shared artifact does not leak secrets or private infrastructure detail; sanitization preserves meaning where possible.",
      "main_risk_short": "Main risk: over-sanitizing until the artifact stops being useful.",
      "validation_short": "Validate by checking obvious sensitive surfaces were checked deliberately; the resulting artifact is still understandable; the sanitization level matches the intended audience.",
      "technique_path": "techniques/instruction/docs-boundary/public-safe-artifact-sanitization/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0035",
      "name": "profile-preset-composition",
      "summary": "Compose small reusable profiles into named presets so runtime posture stays reviewable without flattening composition into one opaque config or launcher doctrine.",
      "one_line_intent": "Keep runtime posture reviewable by separating atomic modules, ordered profiles, and named presets into...",
      "use_when_short": "Use when a stack has several reusable runtime pieces that need legible grouping or optional layers should compose onto a...",
      "do_not_use_short": "Avoid when one small static stack does not need profile or preset layers or the main need is pre-start rendered...",
      "core_contract_short": "Core contract: the module, profile, and preset layers each have explicit ownership; profiles own ordered module lists; presets own ordered...",
      "main_risk_short": "Main risk: unrelated concerns get stuffed into one oversized profile or preset.",
      "validation_short": "Validate by checking module, profile, and preset ownership are all explicit; preset-expanded profiles resolve before direct profile additions; duplicate profiles and modules...",
      "technique_path": "techniques/instruction/instruction-surface/profile-preset-composition/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0036",
      "name": "render-truth-before-startup",
      "summary": "Render the actual composed runtime truth before startup so operators review the effective service and config view instead of relying only on declared profiles.",
      "one_line_intent": "Expose the actual composed runtime truth before startup so operators can review the effective...",
      "use_when_short": "Use when layered profiles or presets can change the final runtime view in ways that are hard to infer from...",
      "do_not_use_short": "Avoid when the main need is profile and preset composition itself rather than the final composed view or the main...",
      "core_contract_short": "Core contract: the render step shows the actual composed runtime view rather than only declared module, profile, or preset intent...",
      "main_risk_short": "Main risk: teams inspect declared profiles and skip the actual rendered view even when overlays can change the final result.",
      "validation_short": "Validate by checking the selected runtime can be rendered before startup; the effective service list comes from the actual composed runtime view...",
      "technique_path": "techniques/execution/runtime-truth-lifecycle/render-truth-before-startup/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0037",
      "name": "contextual-host-doctor",
      "summary": "Run selector-aware host-readiness checks before startup so environment drift becomes visible for the chosen runtime without widening into generic monitoring or lifecycle control.",
      "one_line_intent": "Expose whether the current host is shaped enough for the selected runtime before startup...",
      "use_when_short": "Use when startup success depends on host-side conditions that vary by the selected profile, preset, or runtime path or different...",
      "do_not_use_short": "Avoid when the main need is layered runtime composition or rendered startup truth or the main need is smoke, health...",
      "core_contract_short": "Core contract: the doctor verdict is selector-aware rather than one global readiness score; the same selection inputs used by nearby...",
      "main_risk_short": "Main risk: a warning becomes ambient and stops influencing real preflight decisions.",
      "validation_short": "Validate by checking the readiness verdict changes when a different runtime selection changes what should matter; item-level ok, warn, and fail signals...",
      "technique_path": "techniques/execution/runtime-truth-lifecycle/contextual-host-doctor/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0038",
      "name": "one-command-service-lifecycle",
      "summary": "Start and stop a bounded local service stack through one explicit lifecycle entrypoint so prerequisite checks, visible runtime status, and clean shutdown stay reviewable without widening into generic launcher or platform doctrine.",
      "one_line_intent": "Keep a bounded local service stack startable and stoppable through one explicit lifecycle entrypoint...",
      "use_when_short": "Use when local agent-supporting stacks need more than one service, but operators still want one visible entrypoint or prerequisite checks...",
      "do_not_use_short": "Avoid when the main need is profile or preset composition rather than lifecycle control or the main need is pre-start...",
      "core_contract_short": "Core contract: one explicit operator-facing entrypoint owns local stack startup; prerequisite and build checks may sit inside that entrypoint, but...",
      "main_risk_short": "Main risk: the supposed one-command entrypoint still depends on hidden manual prep in other terminals.",
      "validation_short": "Validate by checking one explicit operator-facing entrypoint starts the bounded local stack; prerequisite or build checks fail early or are reported clearly...",
      "technique_path": "techniques/execution/runtime-truth-lifecycle/one-command-service-lifecycle/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0039",
      "name": "baseline-first-additive-profile-benchmarks",
      "summary": "Benchmark one stable baseline profile first, then compare additive profiles against the same measurement surface and artifact shape so richer profiles stay additive and off the default path.",
      "one_line_intent": "Keep comparison discipline honest by running one stable baseline profile first, then comparing additive...",
      "use_when_short": "Use when a baseline profile should anchor the benchmark before any richer profile is compared or additive profiles need to...",
      "do_not_use_short": "Avoid when the main need is profile composition, runtime rendering, host diagnosis, or service lifecycle control or you want benchmark-suite...",
      "core_contract_short": "Core contract: the baseline profile runs before any additive comparison; additive profiles reuse the same measurement surface and artifact shape...",
      "main_risk_short": "Main risk: the additive path quietly becomes the new default path.",
      "validation_short": "Validate by checking the baseline run happens before any additive run; the additive run uses the same measurement surface and artifact shape...",
      "technique_path": "techniques/execution/runtime-truth-lifecycle/baseline-first-additive-profile-benchmarks/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0040",
      "name": "skill-vs-command-boundary",
      "summary": "Separate reusable skill meaning from user-facing command invocation so shared capability stays portable without collapsing into slash-command syntax or command-specific workflow policy.",
      "one_line_intent": "Keep reusable capability meaning in a skill artifact and keep user-facing invocation behavior in...",
      "use_when_short": "Use when the same capability should survive outside any one user-facing command or a repository has both reusable skills and...",
      "do_not_use_short": "Avoid when one local command is the whole feature and no reusable capability survives outside it or the real need...",
      "core_contract_short": "Core contract: the skill owns reusable capability meaning; the command owns invocation syntax, arguments, workflow steps, and output format.",
      "main_risk_short": "Main risk: command files become the only place where reusable capability meaning actually lives.",
      "validation_short": "Validate by checking one skill artifact and one command artifact are named separately; the skill still makes sense without reading a specific...",
      "technique_path": "techniques/instruction/capability-boundary/skill-vs-command-boundary/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0041",
      "name": "skill-marketplace-curation",
      "summary": "Curate a local discoverability layer over upstream-owned skill sources so selection stays editorial and reviewable without pretending the catalog owns sync, capability meaning, or registry policy.",
      "one_line_intent": "Keep a local skill marketplace or catalog reviewable as a curated discovery layer over...",
      "use_when_short": "Use when a repository wants a local discovery surface for upstream-owned skills or selection quality, grouping, and short descriptions matter...",
      "do_not_use_short": "Avoid when the real need is manifest-driven mirroring plus provenance or the real need is a boundary between reusable skill...",
      "core_contract_short": "Core contract: the local marketplace or catalog is a discoverability layer, not the canonical source of the skills; upstream ownership...",
      "main_risk_short": "Main risk: the curated layer quietly becomes a disguised sync engine or registry.",
      "validation_short": "Validate by checking curated entries still show upstream ownership clearly; the local surface adds editorial discoverability beyond plain mirroring; installer, sync, registry...",
      "technique_path": "techniques/instruction/skill-discovery/skill-marketplace-curation/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0042",
      "name": "upstream-skill-health-checking",
      "summary": "Check upstream-owned skill sources for availability and manifest-readiness before surfacing them as selectable inputs so broken entries stay visible and reviewable without widening into generic monitoring, registry governance, or security doctrine.",
      "one_line_intent": "Expose whether an upstream-owned skill source is selectable enough before it reaches a catalog...",
      "use_when_short": "Use when a catalog, marketplace, or selector depends on upstream-owned skill sources that can disappear, move, or degrade or reviewers...",
      "do_not_use_short": "Avoid when the main need is upstream mirroring plus provenance preservation or the main need is editorial discovery and category...",
      "core_contract_short": "Core contract: the check stays upstream-source-facing and runs before catalog or selector surfacing; source availability and manifest-readiness remain the center...",
      "main_risk_short": "Main risk: transient network issues get mistaken for permanent source invalidity.",
      "validation_short": "Validate by checking an unreachable source is distinguishable from a malformed but reachable source; the verdict stays tied to source availability and...",
      "technique_path": "techniques/instruction/skill-discovery/upstream-skill-health-checking/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0043",
      "name": "multi-source-primary-input-provenance",
      "summary": "Mark primary versus supporting source inputs explicitly when bridging multiple source surfaces so downstream readers and synthesis keep provenance priority visible without turning the bridge into graph semantics or ranking doctrine.",
      "one_line_intent": "Keep the order of source inputs explicit when one bridge or docs surface combines...",
      "use_when_short": "Use when a docs surface combines more than one upstream source and the reader needs to know which one is...",
      "do_not_use_short": "Avoid when the only problem is note-level provenance handles such as evidence.kind and evidence.path or the real need is direct...",
      "core_contract_short": "Core contract: one source input is primary and the rest are supporting when the bridge needs a priority order; the...",
      "main_risk_short": "Main risk: all source inputs get flattened into equal status and the primary signal disappears.",
      "validation_short": "Validate by checking the bridge surface names one primary input and at least one supporting input when multiple sources are combined; the...",
      "technique_path": "techniques/instruction/capability-boundary/multi-source-primary-input-provenance/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0044",
      "name": "versionable-session-transcripts",
      "summary": "Package already-saved AI session transcripts as readable, versionable Markdown artifacts so review, handoff, and selective sharing stay possible without reopening capture semantics or turning transcript history into memory or instruction authority.",
      "one_line_intent": "Turn already-saved AI session history into readable, versionable transcript artifacts so teams can review...",
      "use_when_short": "Use when session history is already being captured, but reviewers need a cleaner transcript artifact than the raw saved layer...",
      "do_not_use_short": "Avoid when the main need is still to capture or persist sessions locally in the first place or the transcript...",
      "core_contract_short": "Core contract: the technique begins after capture and does not own whether sessions get saved at all; one transcript artifact...",
      "main_risk_short": "Main risk: the supposed transcript-export technique quietly re-owns capture because teams cannot explain what happens after the first save.",
      "validation_short": "Validate by checking the transcript package starts from already-saved session artifacts; one readable export or bundle exists for a bounded review or...",
      "technique_path": "techniques/history/history-artifacts/versionable-session-transcripts/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0045",
      "name": "witness-trace-as-reviewable-artifact",
      "summary": "Preserve a bounded witness trace as a reviewable artifact with step visibility, state-delta notes, and human-readable summary so a nontrivial run can be inspected before any writeback or promotion without creating a new memory-object kind.",
      "one_line_intent": "Preserve a nontrivial run as one reviewable witness trace artifact so humans can inspect...",
      "use_when_short": "Use when a run is substantial enough that one reviewable trace should survive it or reviewers need more structured visibility...",
      "do_not_use_short": "Avoid when the main need is still session capture or transcript packaging rather than a structured witness trace or the...",
      "core_contract_short": "Core contract: WitnessTrace remains a trace export contract rather than a memory object; the witness trace is the reviewable source...",
      "main_risk_short": "Main risk: the witness artifact quietly becomes a new memory-object kind because writeback mapping is not kept separate.",
      "validation_short": "Validate by checking the artifact names the bounded run and its goal; step order, tool visibility, and state deltas remain visible where...",
      "technique_path": "techniques/history/history-artifacts/witness-trace-as-reviewable-artifact/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0046",
      "name": "repo-doc-surface-lift",
      "summary": "Lift one bounded set of authoritative repo docs and status files into derived routing knowledge without replacing the authored docs or widening into a docs taxonomy.",
      "one_line_intent": "Lift the repository's bounded public docs/status layer into derived routing knowledge so readers and...",
      "use_when_short": "Use when the question is about which public repo doc should anchor navigation, contribution, safety, or release/status lookup or the...",
      "do_not_use_short": "Avoid when local planning docs such as TODO.md, PLANS.md, or ROADMAP.md or deeper guide docs beyond the bounded repo-doc source...",
      "core_contract_short": "Core contract: the authored docs remain the source of meaning; the derived surface stays bounded to the explicit public docs/status...",
      "main_risk_short": "Main risk: the bounded docs/status set widens until the surface stops being a clear routing aid.",
      "validation_short": "Validate by checking the docs/status source set is bounded and explicit; the derived surface points back to the authored repo docs; local...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/repo-doc-surface-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0047",
      "name": "github-review-template-lift",
      "summary": "Lift authored GitHub issue and pull-request review templates into derived intake knowledge without turning templates into workflow automation or policy scoring.",
      "one_line_intent": "Lift authored GitHub issue and pull-request review templates into a bounded derived intake surface...",
      "use_when_short": "Use when repositories that keep review prompts in authored GitHub issue or pull-request templates or intake paths where proposal, import...",
      "do_not_use_short": "Avoid when cases that need workflow automation, approval policy, triage, or state transitions instead of bounded prompt lookup or repos...",
      "core_contract_short": "Core contract: authored GitHub templates remain the source of review prompt meaning; the derived manifest stays bounded to prompt shape...",
      "main_risk_short": "Main risk: template scopes drift from the authored .github files and the manifest stops matching the real intake shape.",
      "validation_short": "Validate by checking the derived surface matches the authored GitHub templates; the template scopes stay bounded to prompt shape and section inventory...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/github-review-template-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0048",
      "name": "semantic-review-surface-lift",
      "summary": "Lift authored semantic-review docs into derived boundary-review knowledge without creating automatic semantic verdicts.",
      "one_line_intent": "Lift authored _SEMANTIC_REVIEW.md docs into one derived boundary-review surface so readers and tooling can...",
      "use_when_short": "Use when repositories that already have authored semantic-review docs and review-backed working sets or review flows where the question is...",
      "do_not_use_short": "Avoid when repos without authored semantic-review docs or workflows that want semantic scoring, automated verdicts, or status transitions.",
      "core_contract_short": "Core contract: authored semantic-review docs remain the source of review meaning; the derived surface stays cluster-bounded and review-shaped.",
      "main_risk_short": "Main risk: clusters expand until the derived surface stops reflecting one real bounded seam.",
      "validation_short": "Validate by checking the authored semantic-review doc exists and stays readable as the source of review meaning; the derived surface can be...",
      "technique_path": "techniques/knowledge-lift/kag-source-lift/semantic-review-surface-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0049",
      "name": "dependency-aware-task-graph",
      "summary": "Model multi-step coding work as explicit dependency nodes and edges so blocked state and ready work stay reviewable instead of hiding in chat memory.",
      "one_line_intent": "Represent multi-step coding work as an explicit dependency graph so blocked state, ready state...",
      "use_when_short": "Use when several bounded tasks depend on one another or the next safe slice should come from real prerequisite state...",
      "do_not_use_short": "Avoid when one bounded task can be handled without dependency modeling or the real need is a full tracker with...",
      "core_contract_short": "Core contract: dependency edges are explicit; ready work is derived from graph state, not guessed from memory or inferred from...",
      "main_risk_short": "Main risk: stale edges keep work blocked after the blocker is gone.",
      "validation_short": "Validate by checking a known blocked node becomes ready only when its prerequisite flips; blocked tasks can point to a real unmet...",
      "technique_path": "techniques/execution/ready-work-graphs/dependency-aware-task-graph/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0050",
      "name": "ready-work-from-blocker-graph",
      "summary": "Derive the next bounded work queue from blocker-free graph state so operators choose from what is truly ready instead of narrating readiness from memory.",
      "one_line_intent": "Turn an existing blocker graph into a bounded next-work queue so the next step...",
      "use_when_short": "Use when you already have explicit dependency or blocker state or multiple possible next tasks compete for attention.",
      "do_not_use_short": "Avoid when the graph itself is missing, stale, or untrusted or the real need is broad prioritization, scheduling, staffing, or...",
      "core_contract_short": "Core contract: ready work depends on blocker-free state; blocked tasks are not silently promoted into the queue.",
      "main_risk_short": "Main risk: stale blocker state yields a wrong ready queue.",
      "validation_short": "Validate by checking only blocker-free eligible nodes appear in the queue; blocked reasons remain visible for excluded tasks; queue updates track graph...",
      "technique_path": "techniques/execution/ready-work-graphs/ready-work-from-blocker-graph/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0051",
      "name": "commit-triggered-background-review",
      "summary": "Trigger a bounded background review after a commit so findings survive as inspectable artifacts without widening into autonomous merge, rewrite, or CI governance.",
      "one_line_intent": "Launch a bounded review pass after a visible commit boundary and preserve the result...",
      "use_when_short": "Use when commits are the cleanest review trigger in the workflow or review should happen asynchronously from the commit itself.",
      "do_not_use_short": "Avoid when the workflow expects interactive pair review rather than artifact output or the system would auto-apply code changes, auto-merge...",
      "core_contract_short": "Core contract: review runs after a visible commit boundary; findings remain inspectable artifacts rather than hidden transient output.",
      "main_risk_short": "Main risk: stale findings outlive the code they reviewed.",
      "validation_short": "Validate by checking the review artifact names the triggering commit or diff; findings survive as read-only output; no automatic merge or rewrite...",
      "technique_path": "techniques/continuity/review-compaction/commit-triggered-background-review/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0052",
      "name": "review-findings-compaction",
      "summary": "Compact and revalidate review findings against current code so repeated or stale findings do not overwhelm the current review surface.",
      "one_line_intent": "Turn a noisy or repeated findings set into a smaller current review surface by...",
      "use_when_short": "Use when repeated review runs produce overlapping findings or stale findings need to be filtered out before acting on them.",
      "do_not_use_short": "Avoid when the main problem is issue triage or backlog policy rather than review findings or findings must remain fully...",
      "core_contract_short": "Core contract: compaction never invents new findings; current code is checked before a finding survives as current truth.",
      "main_risk_short": "Main risk: real distinct findings are merged incorrectly.",
      "validation_short": "Validate by checking duplicate findings collapse into one representative; invalidated findings are removed or marked stale; current references still point to live...",
      "technique_path": "techniques/continuity/review-compaction/review-findings-compaction/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0053",
      "name": "local-first-session-index",
      "summary": "Build a local searchable index over already-saved session artifacts so teams can browse or query saved history without reopening capture semantics or turning the index into memory or dashboard doctrine.",
      "one_line_intent": "Build a local searchable index over already-saved session artifacts so operators can find and...",
      "use_when_short": "Use when session artifacts are already being saved locally or the history layer has become large enough that browse and...",
      "do_not_use_short": "Avoid when the real problem is still capturing or persisting session history in the first place or the workflow mainly...",
      "core_contract_short": "Core contract: the index remains derivative and rebuildable from local source artifacts; source artifacts stay authoritative even when the index...",
      "main_risk_short": "Main risk: the index drifts away from current source artifacts.",
      "validation_short": "Validate by checking session artifacts already exist before indexing starts; the index can be rebuilt from local artifacts without hidden memory state...",
      "technique_path": "techniques/history/history-artifacts/local-first-session-index/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0054",
      "name": "compaction-resilient-skill-loading",
      "summary": "Re-seed skill availability after context compaction so agents can reload needed skills from canonical sources without widening into full context reconstruction or prompt stuffing.",
      "one_line_intent": "Restore a bounded skill-availability surface after context compaction so the session can rediscover and...",
      "use_when_short": "Use when long-running sessions are expected to compact older context or skills are real capability artifacts with canonical sources.",
      "do_not_use_short": "Avoid when the real problem is how skills or context are authored before runtime or the workflow needs deterministic multi-fragment...",
      "core_contract_short": "Core contract: canonical skill sources remain authoritative; compaction recovery is explicit rather than hidden.",
      "main_risk_short": "Main risk: the wrong skill list is reintroduced after compaction.",
      "validation_short": "Validate by checking a compaction event can happen without permanently losing skill discoverability; post-compaction sessions can still identify or reload needed skills...",
      "technique_path": "techniques/continuity/review-compaction/compaction-resilient-skill-loading/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0055",
      "name": "requirements-design-tasks-ladder",
      "summary": "Separate requirements, design, and task slices so implementation planning stays reviewable without importing a full spec-driven methodology stack.",
      "one_line_intent": "Keep requirements, design, and tasks as visibly separate planning layers so work can move...",
      "use_when_short": "Use when a feature or change needs more than a one-line plan or the next execution slice depends on a...",
      "do_not_use_short": "Avoid when the work is one tiny change with no real design question or the main need is a full...",
      "core_contract_short": "Core contract: requirements, design, and tasks remain distinct layers; design responds to a visible requirement instead of standing alone.",
      "main_risk_short": "Main risk: design stays too vague to produce bounded tasks.",
      "validation_short": "Validate by checking tasks can be traced back to a visible design choice; design responds to a visible requirement; the three layers...",
      "technique_path": "techniques/execution/ready-work-graphs/requirements-design-tasks-ladder/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0056",
      "name": "channelized-agent-mailbox",
      "summary": "Keep agent communication inside durable named channels with ordered replay and explicit acknowledgment so coordination survives session gaps without widening into a full messaging platform or handoff-governance stack.",
      "one_line_intent": "Keep agent communication inside durable named channels with ordered replay and explicit acknowledgment so...",
      "use_when_short": "Use when agents need one durable communication surface that survives beyond a single transient session or messages should be replayed...",
      "do_not_use_short": "Avoid when the real need is a handoff contract that decides when the next agent is allowed to continue or...",
      "core_contract_short": "Core contract: channels are named explicitly and remain stable enough for replay; message order is reviewable through a visible sequence...",
      "main_risk_short": "Main risk: ack state drifts away from what receivers actually handled.",
      "validation_short": "Validate by checking a receiver can replay messages from a visible last-seen cursor or equivalent sequence marker; acknowledgment state is explicit and...",
      "technique_path": "techniques/continuity/handoff-continuation/channelized-agent-mailbox/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0057",
      "name": "structured-handoff-before-compaction",
      "summary": "Write one structured handoff artifact before compaction or session rollover so the next session can resume from explicit state instead of hidden memory or transcript replay.",
      "one_line_intent": "Write one structured handoff artifact before compaction or session rollover so the next session...",
      "use_when_short": "Use when a real compaction, rollover, or episode boundary may drop useful working context or unfinished work must survive to...",
      "do_not_use_short": "Avoid when there is no real context-loss boundary and a normal status note is enough or the main artifact should...",
      "core_contract_short": "Core contract: the handoff artifact exists before compaction or rollover completes; the artifact distinguishes completed work, in-progress or blocked work...",
      "main_risk_short": "Main risk: the handoff artifact is written too late and context is already lost.",
      "validation_short": "Validate by checking a handoff artifact is written before the boundary that would reduce context; the artifact names completed work, in-progress or...",
      "technique_path": "techniques/continuity/handoff-continuation/structured-handoff-before-compaction/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0058",
      "name": "receipt-confirmed-handoff-packet",
      "summary": "Require an explicit receipt state for a handoff packet before the receiving side continues so ownership transfer stays reviewable instead of being inferred from delivery or silence.",
      "one_line_intent": "Require the receiving side to record explicit receipt of a handoff packet before continuing...",
      "use_when_short": "Use when a handoff packet already exists and continuation should wait for visible acceptance or work crosses a session, agent...",
      "do_not_use_short": "Avoid when the real need is to create the handoff packet itself before compaction or message delivery, replay, or durable...",
      "core_contract_short": "Core contract: the handoff packet exists before receipt is recorded; receipt links to a specific packet and a specific receiver...",
      "main_risk_short": "Main risk: the receiver records receipt without actually reviewing the packet.",
      "validation_short": "Validate by checking a handoff packet exists before receipt is recorded; receipt state is visible and separate from delivery or assignment state...",
      "technique_path": "techniques/continuity/handoff-continuation/receipt-confirmed-handoff-packet/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0059",
      "name": "git-verified-handoff-claims",
      "summary": "Verify concrete handoff claims against visible git state before continuation so the next session trusts repo evidence rather than memory or summary prose alone.",
      "one_line_intent": "Verify concrete handoff claims against visible git state before continuation so the next session...",
      "use_when_short": "Use when a handoff packet claims that code, files, or commits changed and the next session will rely on that...",
      "do_not_use_short": "Avoid when there is no git-backed worktree or the relevant change is not represented in visible repo state or the...",
      "core_contract_short": "Core contract: concrete handoff claims are checked against visible git evidence before continuation; the verification output distinguishes verified, mismatched, and...",
      "main_risk_short": "Main risk: stale local git state produces a false sense of verification.",
      "validation_short": "Validate by checking at least one concrete handoff claim can be tied to visible git evidence; the verification result names the evidence...",
      "technique_path": "techniques/continuity/handoff-continuation/git-verified-handoff-claims/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0060",
      "name": "session-opening-ritual-before-work",
      "summary": "Start a resumed or handed-off session with one visible read-and-verify ritual before the first mutation so work begins from current state rather than stale assumptions.",
      "one_line_intent": "Start a resumed or handed-off session with one visible read-and-verify ritual before the first...",
      "use_when_short": "Use when work is resuming after a session boundary, handoff, or context gap or a new operator or agent needs...",
      "do_not_use_short": "Avoid when work is continuing inside one uninterrupted session and the current state is already in view or there is...",
      "core_contract_short": "Core contract: the resumed session includes a visible read step before the first mutation; at least one current-state surface is...",
      "main_risk_short": "Main risk: the ritual becomes a symbolic checklist and no real baseline is actually checked.",
      "validation_short": "Validate by checking the opening ritual happens before the first mutation; at least one explicit current-state surface is checked, not just reread...",
      "technique_path": "techniques/continuity/handoff-continuation/session-opening-ritual-before-work/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0061",
      "name": "cross-repo-resource-map-bootstrap",
      "summary": "Bootstrap cross-repo work from one explicit resource map so the next session can see which repos and surfaces matter before deeper continuation begins.",
      "one_line_intent": "Bootstrap cross-repo work from one explicit resource map so the next session can see...",
      "use_when_short": "Use when the next step spans more than one repository or a receiving operator or agent needs one compact cross-repo...",
      "do_not_use_short": "Avoid when the work is truly single-repo and a normal local starting surface is enough or the main need is...",
      "core_contract_short": "Core contract: the map names real repositories and real resource surfaces; each listed repo has an explicit role tied to...",
      "main_risk_short": "Main risk: the map includes too much inventory and the real first-look path disappears.",
      "validation_short": "Validate by checking every listed repo or resource has a stated role in the current task; a reader can tell where to...",
      "technique_path": "techniques/continuity/handoff-continuation/cross-repo-resource-map-bootstrap/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0062",
      "name": "episode-bounded-agent-loop",
      "summary": "Break longer work into explicit episodes with checkpoints and continue, stop, or escalate decisions so continuation stays reviewable instead of slipping into open-ended autonomy.",
      "one_line_intent": "Break longer work into explicit episodes with checkpoints and continue, stop, or escalate decisions...",
      "use_when_short": "Use when the work is too large or risky for one bounded pass or checkpoints are needed between slices of...",
      "do_not_use_short": "Avoid when one bounded single-shot pass is enough or the main missing seam is just handoff writing, startup ritual, or...",
      "core_contract_short": "Core contract: each episode has one bounded goal; each episode reaches a visible checkpoint or stop condition before the next...",
      "main_risk_short": "Main risk: episodes are too large to review safely.",
      "validation_short": "Validate by checking each episode has a bounded goal; every episode ends at a checkpoint or stop condition; the continue, stop, or...",
      "technique_path": "techniques/continuity/handoff-continuation/episode-bounded-agent-loop/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0063",
      "name": "versioned-agent-registry-contract",
      "summary": "Keep registry-facing capability entries reviewable as named versioned records with explicit references and metadata so publication stays bounded without widening into discovery policy or registry product doctrine.",
      "one_line_intent": "Keep registry-facing capability publication reviewable by expressing entries as named versioned records with explicit...",
      "use_when_short": "Use when a capability, agent, or similar object must be published into a directory or registry as a reviewable entry...",
      "do_not_use_short": "Avoid when the real need is a single versioned capability spec with no registry-entry surface or the real need is...",
      "core_contract_short": "Core contract: one registry-facing entry has explicit identity through name, version, and record reference; metadata needed to interpret the entry...",
      "main_risk_short": "Main risk: entry versions change without any contract review, so the entry surface stops signaling meaningful publication changes.",
      "validation_short": "Validate by checking one registry entry has explicit name, version, and record reference; schema version and other bounded metadata remain readable without...",
      "technique_path": "techniques/instruction/capability-registry/versioned-agent-registry-contract/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0064",
      "name": "capability-discovery",
      "summary": "Keep capability lookup reviewable as explicit bounded queries over published registry entries so discovery stays separate from ranking, marketplace curation, trust policy, and registry product doctrine.",
      "one_line_intent": "Keep capability discovery reviewable by expressing lookup as one explicit bounded query contract over...",
      "use_when_short": "Use when a directory, registry, or catalog needs one reviewable lookup surface for published capability records or the reusable object...",
      "do_not_use_short": "Avoid when the main need is the versioned capability contract itself rather than how records are discovered or the main...",
      "core_contract_short": "Core contract: discovery works over already-published entries or records rather than hidden runtime state; query fields and match rules remain...",
      "main_risk_short": "Main risk: query behavior changes without contract review, so discovery semantics drift silently.",
      "validation_short": "Validate by checking discovery uses one explicit bounded query surface over published entries; query fields and match behavior are readable without opening...",
      "technique_path": "techniques/instruction/capability-registry/capability-discovery/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0065",
      "name": "mcp-gateway-proxy",
      "summary": "Front multiple configured MCP servers through one bounded gateway proxy so callers use one reviewable tool surface with explicit metadata and sanitization instead of binding directly to each upstream server.",
      "one_line_intent": "Front multiple configured MCP servers through one bounded gateway proxy so callers can use...",
      "use_when_short": "Use when more than one MCP server or tool provider must be exposed behind one caller-facing surface or callers should...",
      "do_not_use_short": "Avoid when one direct MCP server is enough and a gateway adds only ceremony or the main need is local...",
      "core_contract_short": "Core contract: the gateway is an explicit intermediary rather than an invisible pass-through; callers interact with one bounded proxy surface...",
      "main_risk_short": "Main risk: the gateway quietly becomes a full security platform instead of one bounded proxy seam.",
      "validation_short": "Validate by checking more than one upstream server or tool surface can be fronted through one gateway seam; callers can inspect proxied...",
      "technique_path": "techniques/tool-use/tool-gateway/mcp-gateway-proxy/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0066",
      "name": "transcript-replay-artifact",
      "summary": "Turn already-saved session history into a replayable artifact so reviewers can inspect message flow and timeline without reopening capture semantics or widening into hosted replay-platform doctrine.",
      "one_line_intent": "Turn already-saved session history into a replayable artifact so reviewers can inspect message flow...",
      "use_when_short": "Use when session artifacts already exist and reviewers need more temporal flow than a plain transcript file conveys or demos...",
      "do_not_use_short": "Avoid when the real problem is still saving session history in the first place or a plain readable transcript is...",
      "core_contract_short": "Core contract: replay begins after session capture and does not own first-save persistence; one replayable artifact is derivative from one...",
      "main_risk_short": "Main risk: the replay artifact quietly re-owns capture because the saved source seam disappears.",
      "validation_short": "Validate by checking replay starts from an already-saved session artifact; message order or equivalent flow cues survive into the replay surface; the...",
      "technique_path": "techniques/history/history-artifacts/transcript-replay-artifact/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0067",
      "name": "transcript-linked-code-lineage",
      "summary": "Link code history back to saved session evidence so reviewers can reopen the originating transcript or rationale without widening the bundle into generic repo analytics or memory doctrine.",
      "one_line_intent": "Link code history back to saved session evidence so reviewers can reopen the originating...",
      "use_when_short": "Use when saved agent sessions or transcript evidence already exist alongside code changes or reviewers need to trace which saved...",
      "do_not_use_short": "Avoid when there is no saved session evidence to link back to or the main need is generic git analytics...",
      "core_contract_short": "Core contract: code anchors link back to already-saved evidence artifacts; the lineage link is stable enough that another reviewer can...",
      "main_risk_short": "Main risk: lineage links break because code anchors or evidence references are unstable.",
      "validation_short": "Validate by checking code anchors can be linked back to already-saved evidence artifacts; another reviewer can reopen the source evidence from the...",
      "technique_path": "techniques/history/history-artifacts/transcript-linked-code-lineage/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0068",
      "name": "fail-closed-evidence-gate",
      "summary": "Stop mutating execution at the boundary unless an explicit allow verdict exists, and emit reviewable evidence for blocked or allowed paths instead of relying on best-effort warnings.",
      "one_line_intent": "Stop mutating execution at the boundary unless an explicit allow verdict exists, and emit...",
      "use_when_short": "Use when tool execution or another mutating boundary should not continue on ambiguous or non-allow outcomes or the gate should...",
      "do_not_use_short": "Avoid when the path is read-only and no real side effects are at stake or the real gap is still...",
      "core_contract_short": "Core contract: the gate sits directly in front of mutating execution; non-allow verdicts block side effects rather than merely warning.",
      "main_risk_short": "Main risk: the gate says non-allow but side effects still happen.",
      "validation_short": "Validate by checking the gate sits before a real mutating boundary; non-allow outcomes actually block side effects; one evidence artifact records the...",
      "technique_path": "techniques/governance/approval-evidence/fail-closed-evidence-gate/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0069",
      "name": "approval-bound-durable-jobs",
      "summary": "Keep longer-running work durable across one explicit approval seam so checkpoint, pause, and resume remain reviewable without widening into a scheduler or orchestration platform.",
      "one_line_intent": "Keep longer-running work durable across one explicit approval seam so checkpoint, pause, and resume...",
      "use_when_short": "Use when work can span longer than one immediate interactive step or execution must pause at a visible approval seam...",
      "do_not_use_short": "Avoid when the work is short enough that a simple fail-closed gate or confirmation seam is enough or the main...",
      "core_contract_short": "Core contract: the job has a stable identity across pause and resume; checkpoint or status state survives the approval seam.",
      "main_risk_short": "Main risk: job state is not durable enough to support safe resume.",
      "validation_short": "Validate by checking a stable job identity survives across pause and resume; checkpoint or status state remains inspectable at the approval seam...",
      "technique_path": "techniques/governance/approval-evidence/approval-bound-durable-jobs/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0070",
      "name": "two-stage-document-ocr-pipeline",
      "summary": "Stage OCR as detect or layout -> recognize -> structured handoff so downstream extraction stays reviewable, interchangeable, and confidence-aware instead of collapsing OCR and field logic into one opaque step.",
      "one_line_intent": "Turn screenshots, scans, or document images into a bounded OCR handoff by keeping text-region...",
      "use_when_short": "Use when a later stage needs OCR output as an explicit intermediate object rather than hidden inside end-to-end extraction or...",
      "do_not_use_short": "Avoid when the source is already structured and OCR is unnecessary or the real reusable object is post-OCR field extraction...",
      "core_contract_short": "Core contract: OCR staging stays separate from downstream field extraction and app logic; region, line, or layout ambiguity remains visible...",
      "main_risk_short": "Main risk: skewed, cropped, or noisy inputs lose important text regions before recognition.",
      "validation_short": "Validate by checking OCR handoff remains distinct from downstream extraction logic; region or layout references survive into the handoff; low-confidence spans remain...",
      "technique_path": "techniques/ingest/media-ingest/two-stage-document-ocr-pipeline/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0071",
      "name": "template-backed-field-extraction-after-ocr",
      "summary": "Extract bounded fields after OCR through explicit templates, heuristics, and missing-or-conflict signaling so structured receipt-like data stays reviewable instead of being guessed by one opaque parser.",
      "one_line_intent": "Turn OCR handoff text into a bounded field object such as merchant, date, amount...",
      "use_when_short": "Use when a prior OCR stage already exists and the next reusable seam is post-OCR field extraction or the target...",
      "do_not_use_short": "Avoid when the source is already structured and no OCR-derived extraction is needed or the real reusable object is still...",
      "core_contract_short": "Core contract: OCR staging and field extraction remain separate steps; the target field set stays explicit and bounded.",
      "main_risk_short": "Main risk: amount, subtotal, tax, or tip lines are confused.",
      "validation_short": "Validate by checking OCR handoff is the only bounded parsing input; the extracted field set is explicit and small enough to review...",
      "technique_path": "techniques/ingest/media-ingest/template-backed-field-extraction-after-ocr/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0072",
      "name": "perceptual-media-dedupe-with-threshold-review",
      "summary": "Group near-duplicate media through perceptual similarity and thresholded review buckets so cleanup stays reviewable instead of collapsing into silent deletion or one-threshold dogma.",
      "one_line_intent": "Make screenshot, meme, or photo deduplication reviewable by grouping near-duplicate media through perceptual similarity...",
      "use_when_short": "Use when an image set contains exact duplicates, crops, edits, or recompressions that still need duplicate review or the reusable...",
      "do_not_use_short": "Avoid when exact hashes alone are enough and near-duplicate handling is unnecessary or the real reusable object is semantic bucketing...",
      "core_contract_short": "Core contract: the technique groups and flags near-duplicates; it does not own file deletion policy; thresholds stay explicit and tunable.",
      "main_risk_short": "Main risk: edited memes collapse into the wrong groups.",
      "validation_short": "Validate by checking the corpus includes exact duplicates, crops, and edited variants; high-confidence groups and uncertain groups are visibly separated; thresholds can...",
      "technique_path": "techniques/ingest/media-ingest/perceptual-media-dedupe-with-threshold-review/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0073",
      "name": "semantic-media-bucketing-with-vision-plus-ocr",
      "summary": "Bucket mixed media through bounded visual semantics plus OCR side text so screenshots, memes, receipts, and other media classes remain reviewable under explicit confidence gates instead of widening into open-ended multimodal automation.",
      "one_line_intent": "Provide one bounded classification route for mixed media by combining visual semantics with OCR...",
      "use_when_short": "Use when a media set needs coarse bucket labels before later routing or review or text-heavy images matter and OCR...",
      "do_not_use_short": "Avoid when duplicate grouping is the real problem and taxonomy is unnecessary or the workflow needs identity inference, moderation policy...",
      "core_contract_short": "Core contract: taxonomy stays bounded and explicit; OCR remains a side-channel, not hidden truth.",
      "main_risk_short": "Main risk: memes and screenshots collide in the same bucket.",
      "validation_short": "Validate by checking the golden set includes memes, receipts, screenshots, and an other class; bucket labels stay inside the bounded taxonomy; low-confidence...",
      "technique_path": "techniques/ingest/media-ingest/semantic-media-bucketing-with-vision-plus-ocr/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0074",
      "name": "telegram-export-normalization-to-local-store",
      "summary": "Normalize Telegram messages and media into a resumable local store with visible provenance so later workflows can inspect, route, or distill the data without collapsing auth, session, or memory doctrine into the storage contract.",
      "one_line_intent": "Turn Telegram export or sync output into a bounded, provenance-preserving local store so later...",
      "use_when_short": "Use when Telegram messages or Saved Messages need to become a local structured store or media references and reply edges...",
      "do_not_use_short": "Avoid when the real problem is account auth, session conversion, or bootstrap or the workflow needs a live agent-control surface...",
      "core_contract_short": "Core contract: auth posture stays separate from normalization; message provenance remains visible.",
      "main_risk_short": "Main risk: media references lose source linkage.",
      "validation_short": "Validate by checking a sample export with replies and media retains source ids and media references; resume after interruption preserves progress without...",
      "technique_path": "techniques/ingest/media-ingest/telegram-export-normalization-to-local-store/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0075",
      "name": "session-donor-harvest",
      "summary": "Distill a reviewed session artifact into a bounded donor pack of reusable units so candidate practice, workflow, and scenario objects can be evaluated without turning session history into memory or forcing promotion.",
      "one_line_intent": "Turn one reviewed session artifact into a bounded donor pack of reusable candidates so...",
      "use_when_short": "Use when a session transcript, compaction note, review packet, or bounded recap already exists and has been reviewed or the...",
      "do_not_use_short": "Avoid when the session is still live, unreviewed, or only partially captured or the real need is raw session capture...",
      "core_contract_short": "Core contract: invocation is explicit and post-session; the technique starts from a reviewed artifact rather than raw live session state.",
      "main_risk_short": "Main risk: mixed clusters survive and later owner placement has to guess what the unit really is.",
      "validation_short": "Validate by checking the source artifact is reviewed and bounded; each kept candidate names one reusable unit rather than one topic cluster...",
      "technique_path": "techniques/continuity/donor-harvest/session-donor-harvest/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0076",
      "name": "owner-layer-triage",
      "summary": "Route one bounded reusable unit to one primary owner layer and one rejected nearest-wrong target so practice, workflow, scenario, proof, recall, and role surfaces stay distinct instead of collapsing into generic reuse.",
      "one_line_intent": "Take one bounded reusable unit and assign it to one primary owner layer, one...",
      "use_when_short": "Use when one reusable unit has already been isolated from its source artifact or several nearby owner layers look plausible...",
      "do_not_use_short": "Avoid when the source still contains several mixed units that have not been split yet or the real need is...",
      "core_contract_short": "Core contract: one candidate unit maps to one primary owner layer; usefulness is a reuse signal, not an owner layer...",
      "main_risk_short": "Main risk: one mixed unit is forced into one owner layer before it is actually split.",
      "validation_short": "Validate by checking the candidate unit is bounded and singular; one primary owner layer is named explicitly; the nearest wrong target is...",
      "technique_path": "techniques/governance/decision-routing/owner-layer-triage/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0077",
      "name": "harvest-packet-contract",
      "summary": "Keep one bounded HARVEST_PACKET contract over a reviewed session so downstream routing, diagnosis, repair, progression, and quest seams can consume explicit packet fields without silently replacing one another.",
      "one_line_intent": "Keep one bounded HARVEST_PACKET contract over a reviewed session artifact so later family seams...",
      "use_when_short": "Use when a reviewed session already produced reusable extracts and needs one explicit packet shape or later family seams such...",
      "do_not_use_short": "Avoid when the session is still live or not yet reviewed or the real task is donor extraction, owner placement...",
      "core_contract_short": "Core contract: the packet starts after review; the required spine stays small and explicit.",
      "main_risk_short": "Main risk: the packet becomes a recap blob instead of a bounded extract container.",
      "validation_short": "Validate by checking the packet starts from reviewed material; the required fields are explicit and present; each extract record remains bounded and...",
      "technique_path": "techniques/continuity/donor-harvest/harvest-packet-contract/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0078",
      "name": "decision-fork-cards",
      "summary": "Turn one reviewed session or harvest packet into explicit decision fork cards so materially different next routes stay visible with gains, costs, owner targets, and stop conditions instead of collapsing into one hidden recommendation.",
      "one_line_intent": "Turn one reviewed session or harvest packet into explicit decision fork cards so materially...",
      "use_when_short": "Use when the session is already reviewed and more than one honest next route remains or different branches have meaningfully...",
      "do_not_use_short": "Avoid when there is only one obvious next bounded move or donor extraction or packet shaping still has not happened.",
      "core_contract_short": "Core contract: fork cards describe choices; they do not decide authority; each card must represent one materially distinct route.",
      "main_risk_short": "Main risk: the cards describe variants of the same route instead of real forks.",
      "validation_short": "Validate by checking the source material is reviewed; each card represents a materially distinct route; each route names gains, costs, risks, and...",
      "technique_path": "techniques/governance/decision-routing/decision-fork-cards/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0079",
      "name": "risk-passport-lift",
      "summary": "Attach one small risk passport to each explicit next route so difficulty, risk, control mode, delegate tier, and stop-condition posture stay visible without turning branch analysis into hidden routing policy.",
      "one_line_intent": "Attach one small risk passport to each explicit next route so route choice keeps...",
      "use_when_short": "Use when explicit next routes already exist and need a smaller per-route posture summary or reviewers need to compare difficulty...",
      "do_not_use_short": "Avoid when there is only one route and no meaningful comparison surface or the real need is donor extraction, diagnosis...",
      "core_contract_short": "Core contract: one passport belongs to one route; the passport stays smaller than the branch card it complements.",
      "main_risk_short": "Main risk: the passport becomes a hidden scorecard instead of a small posture summary.",
      "validation_short": "Validate by checking each passport belongs to one explicit route; the field set stays small and reviewable; difficulty, risk, control mode, delegate...",
      "technique_path": "techniques/governance/decision-routing/risk-passport-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0080",
      "name": "session-drift-taxonomy",
      "summary": "Classify repeated post-session friction into bounded drift types so diagnosis can say what kind of problem is present before it claims one probable cause, owner hint, or repair shape.",
      "one_line_intent": "Classify repeated post-session friction into bounded drift types so a later diagnosis pass can...",
      "use_when_short": "Use when the session is reviewed and several friction signals survived it or the next honest move is diagnosis rather...",
      "do_not_use_short": "Avoid when the session is still live or unreviewed or the issue is already fully diagnosed.",
      "core_contract_short": "Core contract: taxonomy is read-only; drift type is not the same thing as probable cause.",
      "main_risk_short": "Main risk: vague labels replace real classification.",
      "validation_short": "Validate by checking the source evidence is reviewed; drift labels stay bounded and reusable; symptom, drift type, and probable cause remain distinct.",
      "technique_path": "techniques/recovery/diagnosis-repair/session-drift-taxonomy/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0081",
      "name": "diagnosis-from-reviewed-evidence",
      "summary": "Turn reviewed friction evidence into a bounded diagnosis packet that separates symptoms from probable causes, preserves unknowns, and names likely owner hints without mutating anything yet.",
      "one_line_intent": "Turn reviewed friction evidence into a bounded diagnosis packet so symptoms, probable causes, owner...",
      "use_when_short": "Use when the session is reviewed and repeated friction or contradiction survived it or the next honest move is diagnosis...",
      "do_not_use_short": "Avoid when the session is still live or unreviewed or diagnosis already exists and the next honest move is repair.",
      "core_contract_short": "Core contract: diagnosis starts from reviewed evidence; symptom and probable-cause layers stay distinct.",
      "main_risk_short": "Main risk: symptoms and causes collapse into one vague narrative.",
      "validation_short": "Validate by checking the source evidence is reviewed and bounded; symptoms and probable causes stay distinct; likely owner hints remain explicit but...",
      "technique_path": "techniques/recovery/diagnosis-repair/diagnosis-from-reviewed-evidence/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0082",
      "name": "repair-shape-from-diagnosis",
      "summary": "Turn a reviewed diagnosis packet into the smallest honest repair shape so the next artifact stays bounded, owner-aware, and smaller than a scenario rollout.",
      "one_line_intent": "Turn a reviewed diagnosis packet into the smallest honest repair shape so the next...",
      "use_when_short": "Use when a reviewed diagnosis already exists or the next honest move is a bounded repair packet rather than another...",
      "do_not_use_short": "Avoid when diagnosis does not exist yet or the repair is large enough to be a playbook or broader rollout.",
      "core_contract_short": "Core contract: diagnosis is a prerequisite; the chosen repair shape stays smaller than a scenario rollout.",
      "main_risk_short": "Main risk: the chosen repair shape is larger than the diagnosis justifies.",
      "validation_short": "Validate by checking a reviewed diagnosis exists; the chosen repair shape is the smallest honest shape; one primary owner target is explicit.",
      "technique_path": "techniques/recovery/diagnosis-repair/repair-shape-from-diagnosis/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0083",
      "name": "checkpoint-bound-self-repair",
      "summary": "Keep self-repair behind explicit checkpoint posture with approval, rollback, health checks, iteration limits, and improvement-log visibility so repair stays reviewable instead of feeling like silent self-modification.",
      "one_line_intent": "Keep self-repair behind explicit checkpoint posture so bounded repair stays reviewable and reversible instead...",
      "use_when_short": "Use when a bounded repair shape already exists or the repair may touch important system surfaces.",
      "do_not_use_short": "Avoid when no reviewed diagnosis or repair shape exists yet or the work is a small non-sensitive edit that does...",
      "core_contract_short": "Core contract: self-repair is not free self-modification; important mutations require checkpoint posture.",
      "main_risk_short": "Main risk: checkpoint posture is partial and one critical field is missing.",
      "validation_short": "Validate by checking a bounded repair shape exists first; checkpoint fields are all explicit; rollback and health-check posture are present.",
      "technique_path": "techniques/recovery/diagnosis-repair/checkpoint-bound-self-repair/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0084",
      "name": "progression-evidence-lift",
      "summary": "Lift reviewed session evidence into a bounded multi-axis progression delta with explicit verdicts and small unlock hints so growth stays descriptive and evidence-backed instead of collapsing into one score.",
      "one_line_intent": "Lift reviewed session evidence into a bounded multi-axis progression delta so growth stays legible...",
      "use_when_short": "Use when a reviewed session produced meaningful mastery evidence or the route needs progression legibility without mutating role or owner...",
      "do_not_use_short": "Avoid when there is no reviewed evidence or the request wants one universal power number.",
      "core_contract_short": "Core contract: progression remains evidence-backed; movement stays multi-axis rather than one-score.",
      "main_risk_short": "Main risk: movement is invented from vibe instead of evidence.",
      "validation_short": "Validate by checking meaningful axis claims cite reviewed evidence; the output stays multi-axis; the verdict matches the evidence.",
      "technique_path": "techniques/continuity/donor-harvest/progression-evidence-lift/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0085",
      "name": "multi-axis-quest-overlay",
      "summary": "Add quest-, RPG-, or chronicle-shaped reflection to a bounded multi-axis progression result so route legibility improves without letting flavor overwrite owner truth, proof, or routing authority.",
      "one_line_intent": "Add quest-, RPG-, or chronicle-shaped reflection to a bounded progression or route-reading surface so...",
      "use_when_short": "Use when a reviewed session already produced a bounded progression delta or route reflection or quest-, RPG-, or chronicle-shaped language...",
      "do_not_use_short": "Avoid when no reviewed evidence exists underneath the overlay or quest or RPG flavor is being used to grant rights...",
      "core_contract_short": "Core contract: the overlay always rests on reviewed evidence; the overlay remains adjunct, not sovereign.",
      "main_risk_short": "Main risk: narrative flavor starts replacing the underlying evidence-backed result.",
      "validation_short": "Validate by checking the overlay rests on reviewed evidence; the underlying progression or route note remains explicit; flavor remains adjunct rather than...",
      "technique_path": "techniques/continuity/donor-harvest/multi-axis-quest-overlay/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0086",
      "name": "automation-fit-matrix",
      "summary": "Classify one recurring manual route across repeat signal, determinism, proof posture, reversibility, and approval sensitivity so automation desire becomes a bounded verdict rather than vague enthusiasm.",
      "one_line_intent": "Classify one recurring manual route with a small automation-fit matrix so the result says...",
      "use_when_short": "Use when a reviewed session or recurring project slice exposes a repeated manual route or the team needs an explicit...",
      "do_not_use_short": "Avoid when the route only happened once and still looks exploratory or the real task is choosing the final owner...",
      "core_contract_short": "Core contract: the matrix classifies one route; it does not create automation authority; row descriptions stay evidence-backed and small.",
      "main_risk_short": "Main risk: the matrix hides missing evidence behind confident labels.",
      "validation_short": "Validate by checking one reviewed recurring route is named explicitly; each row is evidence-backed or honestly marked unknown; the verdict matches the...",
      "technique_path": "techniques/governance/automation-readiness/automation-fit-matrix/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0087",
      "name": "human-loop-to-first-landing",
      "summary": "Route one recurring human loop to the first honest automation-facing landing so seed-ready candidates become bounded skills or playbook seeds while unstable routes stay manual, repair-bound, or deferred.",
      "one_line_intent": "Lift one recurring human loop into the first honest automation-facing landing without skipping the...",
      "use_when_short": "Use when a recurring reviewed route already has enough shape for a next-artifact decision or the real question is where...",
      "do_not_use_short": "Avoid when no reviewed recurring route exists yet or the route still needs fit classification or approval-checkpoint analysis first.",
      "core_contract_short": "Core contract: the lift chooses the first honest landing; it does not grant live automation authority; schedule hints remain hints...",
      "main_risk_short": "Main risk: the route is forced into a skill when it really wants a scenario seed or defer verdict.",
      "validation_short": "Validate by checking one recurring reviewed loop is named; the first landing stays smaller than a full implementation; owner-layer and next-artifact posture...",
      "technique_path": "techniques/governance/automation-readiness/human-loop-to-first-landing/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0088",
      "name": "approval-sensitivity-check",
      "summary": "Classify whether an automation candidate crosses approval, rollback, or self-change boundaries so checkpoint-required posture appears before any seed-ready claim becomes credible.",
      "one_line_intent": "Classify whether one automation candidate crosses approval, rollback, hidden authority, or self-change boundaries so...",
      "use_when_short": "Use when an automation candidate may mutate important system surfaces or authority, approval, rollback, or health-check posture is unclear.",
      "do_not_use_short": "Avoid when the route is clearly low-risk and read-only or the real task is generic confirmation before mutation rather than...",
      "core_contract_short": "Core contract: the check classifies one candidate's approval burden; it does not approve execution; checkpoint_required is a boundary flag, not...",
      "main_risk_short": "Main risk: approval-heavy candidates are mislabeled as safe or seed-ready.",
      "validation_short": "Validate by checking one automation candidate is named explicitly; mutation, authority, rollback, and health-check posture are visible; checkpoint_required is explicit when the...",
      "technique_path": "techniques/governance/automation-readiness/approval-sensitivity-check/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0089",
      "name": "quest-unit-promotion-review",
      "summary": "Review one repeated reviewed quest unit and emit one bounded promotion verdict so leaf workflow, route, role, proof, and recall surfaces do not collapse into generic reuse pressure.",
      "one_line_intent": "Review one repeated, reviewed quest-shaped unit and decide whether it should stay a quest...",
      "use_when_short": "Use when one repeated reviewed quest unit is already isolated from the wider session family or the remaining question is...",
      "do_not_use_short": "Avoid when the route is still active, unreviewed, or only happened once or the source still contains several mixed reusable...",
      "core_contract_short": "Core contract: the technique starts after review and after the repeated unit is already isolated; one repeated unit receives one...",
      "main_risk_short": "Main risk: a mixed or weakly repeated unit is treated as promotion-ready.",
      "validation_short": "Validate by checking one repeated reviewed unit is named explicitly; the chosen owner target matches the repeat shape; keep-quest or defer posture...",
      "technique_path": "techniques/governance/promotion-boundary/quest-unit-promotion-review/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0090",
      "name": "nearest-wrong-target-rejection",
      "summary": "Reject the nearest wrong promotion target explicitly so repeated reviewed work does not collapse into the most convenient adjacent owner layer.",
      "one_line_intent": "Make the nearest wrong target explicit when writing a bounded owner or promotion verdict...",
      "use_when_short": "Use when one chosen owner or promotion target already looks plausible, but at least one adjacent target also feels tempting...",
      "do_not_use_short": "Avoid when there is no meaningful adjacent target to reject or the real need is still donor extraction, diagnosis, or...",
      "core_contract_short": "Core contract: the rejection stays paired to one chosen target; the rejected target must be adjacent and plausible, not theatrical.",
      "main_risk_short": "Main risk: the rejected target is not actually the nearest wrong one.",
      "validation_short": "Validate by checking the rejected target is adjacent and plausible; the rejection reason clarifies one concrete boundary; the chosen target becomes clearer...",
      "technique_path": "techniques/governance/promotion-boundary/nearest-wrong-target-rejection/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0091",
      "name": "workspace-root-ingress-and-mutation-gate",
      "summary": "Enter federated workspaces through one explicit ingress pass and gate risky mutation through one explicit guard pass so session posture stays reviewable instead of hiding in operator memory.",
      "one_line_intent": "Enter federated workspaces through one explicit ingress pass and require one explicit guard pass...",
      "use_when_short": "Use when work starts from a sibling workspace that contains several related repositories under one root or the next step...",
      "do_not_use_short": "Avoid when the task is truly single-repo and no meaningful workspace-root posture exists or the main need is just one...",
      "core_contract_short": "Core contract: the workspace root is explicit before ingress runs; one primary repo root is named for the current pass...",
      "main_risk_short": "Main risk: ingress becomes symbolic and nobody actually reads the returned posture.",
      "validation_short": "Validate by checking ingress runs before substantial work begins; the current repo root and workspace root are explicit; risky mutation triggers a...",
      "technique_path": "techniques/proof/owner-truth-closeout/workspace-root-ingress-and-mutation-gate/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0092",
      "name": "audit-to-closeout-proof-loop",
      "summary": "Turn a reviewed audit finding set into a live-confirmed, proof-backed closeout loop so remediation claims rest on named evidence instead of audit wording alone.",
      "one_line_intent": "Turn a reviewed audit finding set into a proof-backed closeout loop by requiring live...",
      "use_when_short": "Use when a reviewed audit, review packet, or bounded findings set already exists or the route must prove that each...",
      "do_not_use_short": "Avoid when the source findings are still raw, unreviewed, or too vague to bound or the work is a generic...",
      "core_contract_short": "Core contract: no finding closes without live confirmation or an explicit non-repro explanation; fixes land in the owning source repository...",
      "main_risk_short": "Main risk: audit wording is treated as truth without live confirmation.",
      "validation_short": "Validate by checking at least one finding was re-confirmed against live code or explicitly marked non-repro; each closed finding names a targeted...",
      "technique_path": "techniques/proof/owner-truth-closeout/audit-to-closeout-proof-loop/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0093",
      "name": "recommendation-truth-vs-host-actionability",
      "summary": "Keep router recommendation truth separate from host actionability so non-executable recommendations stay visible, canonical install roots stay authoritative, and runnable actions do not masquerade as merely relevant advice.",
      "one_line_intent": "Keep router recommendation truth and host actionability separate so control-plane reports stay honest, activation...",
      "use_when_short": "Use when a control plane recommends skills, capabilities, or bounded workflow objects from a corpus that may be larger than...",
      "do_not_use_short": "Avoid when every recommended object is always bundled with the same runtime and host executability can never diverge or the...",
      "core_contract_short": "Core contract: router recommendation truth is computed separately from host executability; host inventory source and precedence remain explicit.",
      "main_risk_short": "Main risk: host actionability leaks back into recommendation truth, so relevant items disappear when they are merely unavailable.",
      "validation_short": "Validate by checking a recommendation can remain visible even when it is not directly executable on the host; activate_now contains only host-executable...",
      "technique_path": "techniques/instruction/capability-boundary/recommendation-truth-vs-host-actionability/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0094",
      "name": "canonical-owner-with-validated-mirror",
      "summary": "Keep one canonical cross-repo contract owner and allow local mirrors only when explicit parity validation keeps owner metadata and vocabulary exactly aligned.",
      "one_line_intent": "Keep one canonical owner for a cross-repo contract while still permitting nearby mirrors, as...",
      "use_when_short": "Use when one shared schema, contract, or vocabulary is consumed across several repositories or a neighboring repository needs a local...",
      "do_not_use_short": "Avoid when every repository can depend directly on the canonical contract and no local mirror is needed or two repositories...",
      "core_contract_short": "Core contract: exactly one repository owns the shared contract; a mirror is legal only when it stays subordinate to the...",
      "main_risk_short": "Main risk: a mirror starts accepting local edits and becomes a shadow source of truth.",
      "validation_short": "Validate by checking the shared contract names exactly one canonical owner; each mirror carries explicit canonical-reference metadata; parity validation fails when owner...",
      "technique_path": "techniques/proof/owner-truth-closeout/canonical-owner-with-validated-mirror/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0095",
      "name": "github-only-owner-endcap-with-reality-sync",
      "summary": "Close a remote-only owner surface through GitHub-native issue and PR flow, then rebind staging and reality checks to the merged owner anchors so seed-garden truth does not outlive the landing.",
      "one_line_intent": "Close a bounded remote-only owner surface through GitHub-native issue and PR flow, then immediately...",
      "use_when_short": "Use when the final owning repository is intentionally GitHub-only in the current route or the coordination layer can plan and...",
      "do_not_use_short": "Avoid when a real local source checkout exists and is the intended execution surface or the route still needs broader...",
      "core_contract_short": "Core contract: the owner repository remains the source of truth for landed meaning; GitHub-native execution does not create a second...",
      "main_risk_short": "Main risk: the coordination layer updates its own staging note before the owner PR is really merged.",
      "validation_short": "Validate by checking the owner-side goal, non-goals, and stop condition were explicit before the PR landed; the owner repository merged the bounded...",
      "technique_path": "techniques/proof/owner-truth-closeout/github-only-owner-endcap-with-reality-sync/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0096",
      "name": "pinned-validation-matrix-before-generated-publish",
      "summary": "Rebuild generated outputs against the same workflow-pinned sibling refs that CI will validate before publish so local green does not overstate merge-readiness.",
      "one_line_intent": "Rebuild and validate generated outputs against the same workflow-pinned sibling refs, mirrored surfaces, or...",
      "use_when_short": "Use when the repo publishes generated files or snapshots that depend on sibling repos or other bounded upstream surfaces or...",
      "do_not_use_short": "Avoid when the generated outputs are fully single-repo and CI reads only the current checkout or the task is ordinary...",
      "core_contract_short": "Core contract: the workflow-pinned validation matrix is explicit before rebuild begins; local workspace state never silently substitutes for pinned refs.",
      "main_risk_short": "Main risk: local rebuilds go green against workspace state while CI still reads older or pinned sibling refs and fails.",
      "validation_short": "Validate by checking the workflow-pinned sibling refs or mirrored inputs were named explicitly; the local rebuild or --check pass used that same...",
      "technique_path": "techniques/proof/owner-truth-closeout/pinned-validation-matrix-before-generated-publish/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0097",
      "name": "degrade-reground-recover",
      "summary": "Continue safely in a bounded degraded mode, reground against stronger sources, and recover later through explicit source-owned evidence instead of hidden repair theater.",
      "one_line_intent": "Keep partial failure honest and useful by moving through one bounded sequence: degrade safely...",
      "use_when_short": "Use when an optional or derived stage fails but earlier grounded evidence is still usable or retrieval, routing, memory, runtime...",
      "do_not_use_short": "Avoid when the degraded mode would become broader than the normal path or the surface cannot say what remains trustworthy...",
      "core_contract_short": "Core contract: degraded mode must stay weaker than the normal mode; blocked actions stay blocked during degradation.",
      "main_risk_short": "Main risk: degraded continuation quietly broadens authority or claims equivalent quality to the normal path.",
      "validation_short": "Validate by checking the degraded result or stop condition stayed bounded; the reground source stayed stronger than speculative completion; one source-owned receipt...",
      "technique_path": "techniques/recovery/antifragility-recovery/degrade-reground-recover/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0098",
      "name": "receipt-first-failure-analysis",
      "summary": "Start failure review from source-owned receipts, separate facts from hypotheses, and tie any recovery change to explicit evidence rather than folklore or dashboard mythology.",
      "one_line_intent": "Turn failure review into bounded evidence-led iteration by starting from source-owned receipts, separating facts...",
      "use_when_short": "Use when a degraded run completed and needs explicit follow-up learning or the same stressor family repeats across a bounded...",
      "do_not_use_short": "Avoid when the repo does not yet emit any trustworthy source-owned receipt surface or the main need is immediate runtime...",
      "core_contract_short": "Core contract: source-owned receipts remain the first trustworthy object after the stress event; facts and hypotheses stay explicitly separated.",
      "main_risk_short": "Main risk: dashboards, memory, or retrospective summaries replace source-owned evidence.",
      "validation_short": "Validate by checking the originating receipts are named explicitly; facts and hypotheses remain separate in the review; the proposed change is narrower...",
      "technique_path": "techniques/recovery/antifragility-recovery/receipt-first-failure-analysis/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0099",
      "name": "isolated-service-stop-on-shared-substrate",
      "summary": "Stop one bounded service while keeping shared substrate services alive, then verify both target absence and substrate continuity so closeout does not widen into unnecessary teardown.",
      "one_line_intent": "Stop one bounded service in a shared local stack without needlessly tearing down the...",
      "use_when_short": "Use when one helper, UI, worker, or edge service needs to stop while shared data services should stay available or...",
      "do_not_use_short": "Avoid when the target service owns exclusive mutable state that must be quiesced together with its dependencies or the shared...",
      "core_contract_short": "Core contract: the target stop stays singular and named; the shared substrate set is explicit before the stop happens.",
      "main_risk_short": "Main risk: operators stop more than the named target service and silently widen the route.",
      "validation_short": "Validate by checking the target service and shared substrate were named before the stop; the stop affected only the target service; one...",
      "technique_path": "techniques/recovery/antifragility-recovery/isolated-service-stop-on-shared-substrate/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0100",
      "name": "stress-receipt-reground-closeout",
      "summary": "Record one bounded stress event, preserve the smallest honest continuation, route through owner layers, and close out with reviewed evidence before any later proof reading.",
      "one_line_intent": "Provide a reusable workflow for bounded chaos or stress events where the right move...",
      "use_when_short": "Use when runtime timeout or overload events or degraded continuation that must remain operator-visible.",
      "do_not_use_short": "Avoid when the surface has no owner-local receipt or equivalent artifact yet or the real need is immediate containment only...",
      "core_contract_short": "Core contract: one bounded stress family and owner surface stay named explicitly; owner-local evidence comes before routing, playbook, stats, or...",
      "main_risk_short": "Main risk: a symbolic receipt is emitted without real evidence refs.",
      "validation_short": "Validate by checking another reviewer can see exactly what degraded and what stayed visible; the degraded continuation or hold is explicit, not...",
      "technique_path": "techniques/recovery/antifragility-recovery/stress-receipt-reground-closeout/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0101",
      "name": "local-pattern-adoption-gate",
      "summary": "Gate one shared pattern before local adoption by requiring owner consent, compatibility evidence, rollback, and retention watch so precedent does not silently become durable behavior.",
      "one_line_intent": "Gate one shared practice pattern before it becomes durable local behavior, so approval, precedent...",
      "use_when_short": "Use when a shared practice pattern has already been noticed, approved upstream, or proven useful elsewhere or a local repository...",
      "do_not_use_short": "Avoid when the source material is still several mixed patterns that have not been split or the real task is...",
      "core_contract_short": "Core contract: one gate result covers one shared pattern and one local behavior surface; upstream approval or useful precedent is...",
      "main_risk_short": "Main risk: a broad method-growth lifecycle is squeezed into one gate result.",
      "validation_short": "Validate by checking one shared pattern is named explicitly; one local owner and behavior surface are named explicitly; owner consent is explicit...",
      "technique_path": "techniques/governance/practice-adoption-lifecycle/local-pattern-adoption-gate/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0102",
      "name": "skill-proposal-handoff-packet",
      "summary": "Emit one bounded skill-proposal handoff packet from a technique-side adoption review so reusable practice does not become skill acceptance or activation by implication.",
      "one_line_intent": "Turn one technique-side adoption pressure into a bounded skill-proposal handoff packet, so the receiving...",
      "use_when_short": "Use when a reusable technique or technique candidate is repeatedly needed as part of agent-facing execution or an adoption review...",
      "do_not_use_short": "Avoid when the source material is still several unrelated practices or workflow needs or the real task is choosing whether...",
      "core_contract_short": "Core contract: one packet carries one skill proposal for one receiving owner; technique canon remains the source of reusable practice...",
      "main_risk_short": "Main risk: the packet quietly becomes a skill draft instead of a handoff.",
      "validation_short": "Validate by checking one reusable practice or technique candidate is named; one receiving skill owner is named; trigger boundary, inputs, outputs, workflow...",
      "technique_path": "techniques/governance/promotion-boundary/skill-proposal-handoff-packet/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0103",
      "name": "adopted-practice-retention-review",
      "summary": "Review one adopted practice against current evidence, usefulness, drift, and rollback posture so it stays active only while retention remains explicit.",
      "one_line_intent": "Review one already-adopted practice to decide whether it should remain active, be revised, be...",
      "use_when_short": "Use when a practice was previously adopted, shadowed, or made part of normal behavior or the adoption record included a...",
      "do_not_use_short": "Avoid when the practice has not passed a local adoption gate yet or the real question is whether to adopt...",
      "core_contract_short": "Core contract: one review covers one adopted or shadowed practice and one owner surface; past adoption does not guarantee current...",
      "main_risk_short": "Main risk: retention review becomes a ceremonial renewal with no current evidence.",
      "validation_short": "Validate by checking one adopted or shadowed practice is named; the original owner surface and adoption record are visible; current evidence is...",
      "technique_path": "techniques/governance/practice-adoption-lifecycle/adopted-practice-retention-review/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0104",
      "name": "superseded-practice-obsolescence-route",
      "summary": "Route one adopted practice toward supersession, merge, reanchor, defer, drop, or deprecation review with owner receipt, retained lesson, and provenance intact.",
      "one_line_intent": "Route one adopted or shadowed practice that should not remain active as-is toward supersession...",
      "use_when_short": "Use when a retention review says an adopted or shadowed practice should route toward obsolescence instead of staying active or...",
      "do_not_use_short": "Avoid when the practice has not passed a local adoption gate or shadow-use review yet or the only question is...",
      "core_contract_short": "Core contract: one route packet covers one adopted or shadowed practice and one owner receipt target; obsolescence is not erasure.",
      "main_risk_short": "Main risk: the route packet is misread as permission to delete or mark deprecated.",
      "validation_short": "Validate by checking one adopted or shadowed practice is named; current stage and owner receipt target are visible; the reason it should...",
      "technique_path": "techniques/governance/practice-adoption-lifecycle/superseded-practice-obsolescence-route/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0105",
      "name": "single-missing-evidence-request",
      "summary": "Ask for exactly one missing evidence object that could change a bounded review state so review can narrow without broad research, verdict overclaim, or proof theater.",
      "one_line_intent": "Ask for exactly one missing evidence object that could change a bounded review state...",
      "use_when_short": "Use when one claim, decision, generated artifact, route, or review state is already in view or the current blocker is...",
      "do_not_use_short": "Avoid when the real task is to prove correctness, score quality, or issue an evaluation verdict or the review surface...",
      "core_contract_short": "Core contract: one use of the technique asks for one missing evidence object; the request is tied to one bounded...",
      "main_risk_short": "Main risk: the request names a vague category instead of one concrete object.",
      "validation_short": "Validate by checking exactly one claim or decision point is named; exactly one missing evidence object is requested; the object is concrete...",
      "technique_path": "techniques/proof/review-evidence/single-missing-evidence-request/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0106",
      "name": "single-scoped-evidence-reference",
      "summary": "Offer exactly one scoped evidence reference with relevance, support limit, and reliance condition so review can use a source without treating it as proof, verdict, or source-truth transfer.",
      "one_line_intent": "Offer exactly one scoped evidence reference with relevance, support limit, and reliance condition so...",
      "use_when_short": "Use when one claim, decision, review state, or documentation statement is already in view or one available source, line, artifact...",
      "do_not_use_short": "Avoid when the real task is to prove correctness, score adequacy, or issue an evaluation verdict or the review needs...",
      "core_contract_short": "Core contract: one use of the technique offers one evidence reference; the reference is tied to one bounded review state.",
      "main_risk_short": "Main risk: the reference is vague and cannot be inspected.",
      "validation_short": "Validate by checking exactly one claim or decision point is named; exactly one evidence reference is offered; the reference is concrete enough...",
      "technique_path": "techniques/proof/review-evidence/single-scoped-evidence-reference/TECHNIQUE.md"
    },
    {
      "id": "AOA-T-0107",
      "name": "single-locus-claim-challenge",
      "summary": "Challenge exactly one claim at one vulnerable locus, naming pressure reason and next support question so review can apply pressure without turning challenge into proof, tone, or adjudication.",
      "one_line_intent": "Challenge exactly one claim at one vulnerable locus, naming pressure reason and next support...",
      "use_when_short": "Use when one claim, assertion, generated summary, route statement, or review sentence is already in view or the claim may...",
      "do_not_use_short": "Avoid when the real task is to prove or disprove the claim or several claims need to be compared, ranked...",
      "core_contract_short": "Core contract: one use of the technique challenges one target claim; the challenged locus is smaller than the whole topic...",
      "main_risk_short": "Main risk: the challenge targets a broad topic instead of one claim.",
      "validation_short": "Validate by checking exactly one target claim is named; exactly one vulnerable locus is named inside that claim; the pressure reason explains...",
      "technique_path": "techniques/proof/review-evidence/single-locus-claim-challenge/TECHNIQUE.md"
    }
  ]
}