[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3DRBSEXRZ3KAW7744536C":3,"skill-same:01M6K3DRBSEXRZ3KAW7744536C":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":72},"01M6K3DRBSEXRZ3KAW7744536C","remediate",null,"Use when build_review fails or, at SHIP, when prd-audit, the as-built architecture review, or finish verification blocks. Guides remediation toward the owning step and HALTs only for gaps that need a human.","jstoup111\u002Fai-conductor","jstoup111","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1585332?v=4","01M6K374Y0VEFPVCT2KPBAN4HC","James Stoup","01M6K3751X0GFKNBD0198F50XN",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fremediate\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"advisory","gaps","when","remediation","audit","build","human","verify","verification","claims","guides","review","architecture","use","only","true","for","architecture review","as","2026-11-10 10:12:30",false,"---\nname: remediate\ndisable-model-invocation: true\ndescription: \"Use when build_review fails or, at SHIP, when prd-audit, the as-built architecture review, or finish verification blocks. Guides remediation toward the owning step and HALTs only for gaps that need a human.\"\nmodel: opus\nenforcement: advisory\nphase: ship\nstandalone: true\nrequires: [verify-claims]\n---\n\n## Purpose\n\nTurns a **blocking gate into action**. When `build_review` fails, or when `prd-audit`,\n`architecture-review --as-built`, or the `finish` verification blocks at SHIP, reason over each\nblocking gap and decide how the daemon should proceed. The default is to **remediate**: translate\neach gap into concrete, file-scoped work routed to the owning SDLC step. HALT only for the three\ncases in **Gap-plan judgment guidance**. This skill plans only: it does **not** edit code, write\ntests, or amend the PRD; the owning step does that.\n\n## Engine-selected PRD widening reconciliation mode\n\nUse this branch **only when the engine-stamped context declares**\n`mode: \"prd-widening-reconciliation\"`. It is one bounded equivalence judgment through the\nexisting `remediate` dispatch, not a lifecycle step, a new skill, or a BUILD remediation plan.\n\nJudge only the engine-supplied projection. For each current source, decide whether the supplied\nevidence supports the same retained case, a different case, or uncertainty. A same-case judgment\nmust name only an existing supplied case and explain the substantive behavioral equivalence; when\nthe supplied evidence cannot establish that relation, choose uncertainty rather than guessing from\nsummary wording, ordinal, commit, or path similarity. Do not inspect the repository, seek extra\nevidence, or invent a new case, source, decision, or operator authority.\n\nThe engine owns the projection, native schema, terminal-result validation, durable IDs, and every\neffect. Do not create BUILD work, amend a plan, write a remediation artifact, or recover a result\nfrom markdown\u002Fprose. For every other mode, including `build_review` `case-v1`\u002F`case-v2` and legacy gap\nplanning, skip this branch and follow the existing instructions unchanged.\n\n## As-built gap-plan reconciliation\n\nWhen the engine supplies `priorAsBuiltCases` in an ordinary gap-plan projection, every\nas-built finding disposition must include its engine-owned `reconciliation`. Judge the\nsupplied evidence, not wording alone: use `same` for the same unresolved case,\n`recurrence` when an earlier repair recurred, `materially-changed` when the prior case\nis relevant but the failure is materially different, and `new` when no prior case fits.\nA prior-case source without a `summary` is still pending: read its text from the\n`pendingAsBuiltFindings` entry whose `finding` equals that source's `findingId`.\n\n`same` and `recurrence` name the supplied `priorCaseId`. They may only use\n`existing-task` (binding at least one repair task from that case, plus a cited owner\ntask when present) or `halt`; they never append replacement work. `materially-changed`\nnames its prior case but plans a new repair under normal admission. `new` has no prior\ncase id and follows normal admission. Supply a specific non-empty reason for every\nrelation. The engine validates and persists these fields; do not create case ids,\nevent records, or a parallel reconciliation artifact.\n\n## Engine-selected refusal-rework mode\n\nUse this branch **only when the engine-stamped dispatch context carries refusal evidence** for a\nSHIP `prd_audit` over-scope report whose blocking outside-visible findings were all refused by the\noperator. It is one removal\u002Frework judgement by the existing `remediate` planner — not a new skill,\na second dispatch, or a new store. For every other context, follow the applicable engine-selected\nmode or the gap-plan judgment guidance below.\n\n### Removal-only rule\n\nA refusal gap is removal-only. Every emitted task must remove the refused behavior or rework it to\nfit within the recorded decision; no task may introduce new capability, and no new behavior may be\nintroduced. If the planner cannot produce such tasks — or returns a human\u002Fdeferral disposition or\nan empty, unbound task list — the engine writes the existing refused HALT, never a generic\nneeds-human halt that drops the decision.\n\n## Engine-selected build_review case-v1 mode\n\nUse this branch **only when this engine context is the engine-stamped `build_review` `case-v1` case context declaring `domain: \"build_review\"` and `mode: \"case-v1\"` or `\"case-v2\"`**. It is one judgement by\nthe existing `remediate` skill, not a new skill or a second dispatch. Do not create a skill or dispatch another agent. For every other context, including all SHIP and stall remediation, skip this\nsection and follow the legacy gap-plan instructions below unchanged.\n\n### Supplied input — complete or stop\n\nJudge only the frozen, byte-bounded projection supplied in the engine context. Its exact input fields\nare:\n\n- `domain`: `build_review`.\n- `currentFindings`: every current operator-unresolved content finding, each with its rubric id,\n  stable finding id, anchor, summary, and evidence locations.\n- `priorCases`: all feature-local prior cases, each with outcome, source links, effect status, and\n  resolution evidence, and `priorCases[].bindableDispositions`.\n  - A prior source may carry `finding`, a bounded digest of the earlier finding: `rubric`,\n    `concernKind`, a bounded `summary`, bounded `evidenceLocations`, and `lapId`.\n  - Treat a supplied `finding` digest as binding context when deciding whether a current finding is\n    an equivalent re-raise of that prior source. It is never report text: do not copy, quote, or\n    treat it as a new finding; use it only to bind or distinguish the current source and case.\n- `planContract`: the active approved-plan contract that determines whether work is admitted.\n- `taskStatus`: the engine-supplied task-status evidence.\n- `effectPointers`: the engine-supplied prior effect and BUILD-attempt pointers.\n- `suppressionHistory`: engine-owned sub-floor finding history. It is context only, never a\n  current source and therefore receives no `sourceOutcomes` row.\n\nAll feature-local prior cases must be present or stop: never infer, truncate, or silently ignore\nhistory. Every supplied current finding must receive exactly one source outcome. Use the supplied\nstable identifiers and evidence to make semantic judgements; do not match summaries as identity.\n\nDo not re-audit the source tree. Do not read sibling rubric prompts, inspect a different review\nartifact, or seek additional repository evidence. The engine already selected the scope, excluded exact\noperator-resolved findings, assembled all history, and bounded the input. If the supplied projection\ncannot support a justified judgement, return the required schema with the most supportable\ncase-level disposition; do not substitute a legacy gap plan or invent missing evidence.\n\n### Required additive artifact\n\nOverwrite `.pipeline\u002Fremediation.json` with one JSON object using exactly these top-level keys:\n`mode`, `domain`, `sourceOutcomes`, `cases`. Set `mode` to `\"case-v1\"` and `domain` to\n`\"build_review\"`; do not add legacy `dispositions` or any other keys.\n\n`sourceOutcomes` contains one exact row with `sourceId`, `outcome`, `caseRef` for every and only the\nsupplied `currentFindings` identifier. `outcome` is closed: `acted` | `deferred` | `rejected` | `merged` | `refuted`.\nEach `caseRef` is a provider-local reference to one canonical row in `cases`; it is not a durable id.\nSeveral source rows may reference one canonical case only when the judgement is that they are the same\nrepair case.\n\nEach `cases` row has exactly `caseRef`, optional `existingCaseId`, `disposition`, `priority`,\n`rationale`, `confidence`, `effect`; a `refute` row additionally carries `refutation`:\n\n- `caseRef` is the provider-local reference used by source rows. `existingCaseId`, when supplied by\n  the engine in `priorCases`, may bind that existing case only.\n- A non-escalation row binding an `existingCaseId` must use a disposition listed in that prior case's\n  `bindableDispositions`.\n- A refused binding is named in `bindingCorrections` for one corrected judgement. This is the single\n  correction retry; correct the named binding without changing the\n  supplied sources or inventing a new case.\n- `disposition` is closed: `act` | `defer` | `reject` | `refute` | `advisory` when the context declares severity thresholds.\n- `priority` is closed: `critical` | `high` | `medium` | `low`.\n- `rationale` is bounded, evidence-grounded prose explaining the judgement, and `confidence` is\n  closed: `high` | `medium` | `low`.\n- An `act` effect is exactly `{ \"kind\": \"action\", \"route\": \"build\", \"tasks\": [{ \"title\": \"...\" }] }`.\n  It contains one or more concrete, ordered, file-scoped task titles.\n- An unbound `act` row (one without `existingCaseId`) may add `distinctFrom`: one or more\n  `{ \"caseId\": \"...\", \"reason\": \"...\" }` entries declaring it distinct from resolved action\n  owners of its sources. A reason must be non-empty. A re-raise over a resolved action case is\n  a recurrence unless declared distinct with a reason; its lineage gets three applied attempts.\n  A malformed `distinctFrom` shape rejects the artifact. An entry may name either a provenance\n  candidate of the row or a resolved act owner of a row source; an entry not naming a resolved action owner of a row source is ignored unless it names a provenance candidate.\n- A bound `act` row on a resolved `act` case with an applied action effect may carry `reRaise`\n  `{ \"kind\": \"residual-gap\" | \"repeat\", \"reason\": \"...\" }`; its reason is non-empty.\n  `residual-gap` routes the repair to BUILD under the lineage limit of three applied attempts;\n  `repeat` halts the lap. An absent `reRaise` is treated as a residual gap.\n- A `defer` effect is exactly `{ \"kind\": \"deferral\", \"title\": \"...\", \"body\": \"...\",\n  \"exclusionRationale\": \"...\" }`. Its `exclusionRationale` explains why no current plan task admits\n  the work.\n- A `reject` effect is exactly `{ \"kind\": \"none\" }` and its rationale explains why the raw finding\n  is non-actionable under the supplied rubric and plan contract.\n- An `advisory` row adds `adjudicatedSeverity`. It is allowed only when its source rubric declares a\n  threshold, its severity is strictly below that threshold and never above the reviewer severity,\n  it has a rationale grounded in the plan or prior cases, and its effect is exactly `{ \"kind\": \"none\" }`.\n- A `refute` row MUST bind an `existingCaseId` for an already attempted `act` case, use confidence\n  `high`, and use either `{ \"kind\": \"none\" }` or a complete deferral effect. Its `refutation` is\n  exactly `{ \"claim\": \"...\", \"assertions\": [...] }`; every assertion has `assertion`, a `refuted` or\n  `upheld` verdict, and evidence entries containing only `path` and `excerpt`. Evidence proves current\n  tree content: use no line numbers, hunks, commits, or SHAs. A case may be refuted once only; a later\n  attempt to refute the same case is rejected for human review.\n- A re-raised finding judged no longer present on an attempted applied action receives an\n  evidence-backed `refute`, not a bound `reject`.\n\n### Authority boundaries\n\nThe provider must not mint durable case ids or effect ids;\nthe engine validates the graph, stamps durable ids, and applies every effect.\n\nNever omit, duplicate, or replace a supplied source outcome. A `merged` source is a trace outcome,\nnot a case disposition; it still names its canonical `caseRef`. A same-substance finding may be bound\nby `existingCaseId` to a prior case marked `operatorAccepted`. Never assert or create operator\nacceptance, and never treat an autonomous case outcome as accepted risk. Do not apply an effect, file\nan intake issue, navigate BUILD, charge a budget, or mutate durable state. Do not append to the\napproved plan. In this mode the only write is the schema-constrained `.pipeline\u002Fremediation.json`\nartifact.\n\n### case-v2 consistency, admission, and decision stops\n\nWhen the engine stamps `mode: \"case-v2\"`, write exactly the v1 graph fields plus a top-level\n`consistency` object; its exact top-level keys are `mode`, `domain`, `sourceOutcomes`, `cases`, and\n`consistency`. The `consistency` object is exactly `{ \"verdict\": \"consistent\" | \"blocked\",\n\"sourceIds\": [\"...\"], \"caseRefs\": [\"...\"], \"rationale\": \"...\" }`. It names the implicated\ncurrent sources and canonical case rows, and gives bounded, evidence-grounded rationale. Do not\ndrop merge rows: every merged source still cites its canonical case, so the graph retains its\noriginal source and merge provenance.\n\nFor a v2 `act`, every effect task is exactly `{ \"title\": \"...\", \"admittedTaskIds\": [\"...\"],\n\"admissionRationale\": \"...\" }`. `admittedTaskIds` names the existing active-plan tasks that admit\nthat repair, and `admissionRationale` explains the approved-scope fit. Never invent a task id or\nappend a plan task.\n\n`planContract.index` lists every active-plan task without its body. `admittedTaskIds` must name supplied task bodies.\nAn index-only task admission triggers at most one engine-run\nexpansion round; after that round, an unsupplied admission halts.\n\nv2 adds `escalate` as both a source outcome and a case disposition. An escalation case has exactly\nthe ordinary case fields plus `\"escalation\": { \"owner\": \"product\" | \"plan\" | \"architecture\" }`\nand its effect is exactly `{ \"kind\": \"none\" }`. Its source rows, case rationale, and consistency\nrecord are the operator-facing evidence. It creates no action, operator acceptance, tracker effect,\nplan mutation, BUILD navigation, or budget charge. Use `blocked` consistency for an unresolved\ncontradiction; a `consistent` verdict still does not authorize work outside the admitted task ids.\n\nThe inherited `refute`\u002F`refuted` record is unchanged in v2: keep its existing-case binding,\nhigh-confidence assertion evidence, and terminal semantics. Do not create a parallel refutation\nshape.\n\n## Mode-neutral remediation context\n\nWhen the dispatch context includes `plan contract:` or `prior attempts:` pointers, read every\nreferenced file before judging repairs. Treat the referenced plan task's **Steps** as the governing\ncontract for the repair; prior-attempt artifacts supply earlier same-anchor context, not a replacement\ncontract. When no pointers appear, inspect `.docs\u002Fplans\u002F` and `.pipeline\u002Fbuild-review\u002F` directly\nbefore judging the repair.\n\nWhen used interactively, produce a human-readable remediation plan for the operator. It is advice,\nnot a managed persisted result, and does not replace the engine's selected input, validation, or\nrouting.\n\n## Gap-plan judgment guidance\n\n**Environmental stalls — check first, halt cheaply.** Before any other analysis of a stall question,\ndecide whether its cause is the environment rather than the work: a service, container, database,\nnetwork dependency, credential, or tool the build or test gate needs is down, crashing, or\nunreachable. No plan, story, ADR, or code change repairs the machine, so committed artifacts cannot\nanswer the question. Halt it as `unanswerable` immediately: preserve the question verbatim, state\nthat the cause is environmental, and name the failing dependency as the question reports it. Do not\ndispatch `remediation-planner`, delegate, diagnose the dependency, read source, or propose\nconfiguration changes as a workaround.\n\n**HALT is reserved for `architectural-clarity`, `product-scope`, and `unanswerable` stall questions\nonly.** Use `architectural-clarity` when an architectural gap needs a human decision before any code\ncan be right; use `product-scope` when the initial design never covered the functionality; use\n`unanswerable` only when a stall question cannot be answered from committed artifacts alone. Every\nother gap should be turned into concrete work.\n\n- **Sealed-artifact amendments return to DECIDE.** When a gap requires amending another feature's\n  artifact under `.docs\u002Farchitecture\u002F`, `.docs\u002Fdecisions\u002F`, `.docs\u002Fplans\u002F`, `.docs\u002Fspecs\u002F`, or\n  `.docs\u002Fstories\u002F`, do not route it to BUILD or acceptance-spec work. Return it to the owning DECIDE\n  step through the existing operator gate and kickback path; make no request, ledger, record, or new\n  artifact to bypass that ownership.\n- **Prefer autonomous remediation.** When approved architecture remains authoritative, clear\n  implementation\u002Ftest\u002Fdocumentation drift belongs in BUILD, including a conforming as-built finding\n  and an answerable build-stall question. Its audit origin or finding id alone does not determine the\n  route. Use `architecture_review` only when a change to, or clarification of, approved architecture\n  is required; do not use it where no architectural decision is needed.\n- **Reject contradictory dispositions.** Selecting `architecture_review` when no architectural\n  decision or product decision is needed is invalid; route clear conforming implementation, test, or\n  documentation work to BUILD instead. Selecting `build` when an unresolved or ambiguous\n  architectural decision remains is invalid; use `architecture_review` when approved architecture\n  must change or be clarified, or HALT for architectural clarity when a human decision is required.\n- **Coverage and planning judgment.** An implementation gap is ordinarily BUILD work; use\n  `acceptance_specs` when the real miss is acceptance coverage. A baseline-passing test that needs\n  strengthening within an existing task's RED\u002FGREEN work is BUILD work, not a planning omission. A `plan` route is for an in-scope planning omission, not an architecture or design decision: before selecting `plan`, examine the approved tasks and use `plan` only when none admits the repair. A file missing from an admitting task's Files list does not make it inadmissible; BUILD records it with a `Scope:` trailer. A `plan` route is terminal in a daemon run and never re-plans.\n- **Recorded RED exception.** An acceptance-spec repair may waive separate RED proof only when the\n  acceptance spec and its implementation must be repaired atomically. Record a non-empty reason and\n  attributable approval; report the result as waived, never as proven RED. Otherwise use the ordinary\n  failing-spec RED path.\n- **Preserve completed behavior and coverage.** A repair that removes, replaces, rewrites, or\n  relaxes existing code, tests, or assertions must identify the completed plan task or story\n  criterion whose behavior and coverage survive it. If a removal makes coverage genuinely redundant,\n  include the replacement in the same repair.\n- **Close the defect class within plan admission.** Check sibling sites and what a removal would\n  orphan. Include a sibling only when an existing plan task admits it; otherwise record it as found\n  and excluded with the reason. Do not widen the work beyond approved scope merely because the same\n  shape occurs elsewhere.\n- **Low confidence halts.** Do not route on an unverified assumption about a gap's nature. When the\n  nature is genuinely uncertain, rather than merely the fix, HALT for a human instead of guessing a\n  route, as required by `verify-claims`.\n","## Purpose\n\nTurns a **blocking gate into action**. When `build_review` fails, or when `prd-audit`,\n`architecture-review --as-built`, or the `finish` verification blocks at SHIP, reason over each\nblocking gap and decide how the daemon should proceed. The default is to **remediate**: translate\neach gap into concrete, file-scoped work routed to the owning SDLC step. HALT only for the three\ncases in **Gap-plan judgment guidance**. This skill plans only: it does **not** edit code, write\ntests, or amend the PRD; the owning step does that.\n\n## Engine-selected PRD widening reconciliation mode\n\nUse this branch **only when the engine-stamped context declares**\n`mode: \"prd-widening-reconciliation\"`. It is one bounded equivalence judgment through the\nexisting `remediate` dispatch, not a lifecycle step, a new skill, or a BUILD remediation plan.\n\nJudge only the engine-supplied projection. For each current source, decide whether the supplied\nevidence supports the same retained case, a different case, or uncertainty. A same-case judgment\nmust name only an existing supplied case and explain the substantive behavioral equivalence; when\nthe supplied evidence cannot establish that relation, choose uncertainty rather than guessing from\nsummary wording, ordinal, commit, or path similarity. Do not inspect the repository, seek extra\nevidence, or invent a new case, source, decision, or operator authority.\n\nThe engine owns the projection, native schema, terminal-result validation, durable IDs, and every\neffect. Do not create BUILD work, amend a plan, write a remediation artifact, or recover a result\nfrom markdown\u002Fprose. For every other mode, including `build_review` `case-v1`\u002F`case-v2` and legacy gap\nplanning, skip this branch and follow the existing instructions unchanged.\n\n## As-built gap-plan reconciliation\n\nWhen the engine supplies `priorAsBuiltCases` in an ordinary gap-plan projection, every\nas-built finding disposition must include its engine-owned `reconciliation`. Judge the\nsupplied evidence, not wording alone: use `same` for the same unresolved case,\n`recurrence` when an earlier repair recurred, `materially-changed` when the prior case\nis relevant but the failure is materially different, and `new` when no prior case fits.\nA prior-case source without a `summary` is still pending: read its text from the\n`pendingAsBuiltFindings` entry whose `finding` equals that source's `findingId`.\n\n`same` and `recurrence` name the supplied `priorCaseId`. They may only use\n`existing-task` (binding at least one repair task from that case, plus a cited owner\ntask when present) or `halt`; they never append replacement work. `materially-changed`\nnames its prior case but plans a new repair under normal admission. `new` has no prior\ncase id and follows normal admission. Supply a specific non-empty reason for every\nrelation. The engine validates and persists these fields; do not create case ids,\nevent records, or a parallel reconciliation artifact.\n\n## Engine-selected refusal-rework mode\n\nUse this branch **only when the engine-stamped dispatch context carries refusal evidence** for a\nSHIP `prd_audit` over-scope report whose blocking outside-visible findings were all refused by the\noperator. It is one removal\u002Frework judgement by the existing `remediate` planner — not a new skill,\na second dispatch, or a new store. For every other context, follow the applicable engine-selected\nmode or the gap-plan judgment guidance below.\n\n### Removal-only rule\n\nA refusal gap is removal-only. Every emitted task must remove the refused behavior or rework it to\nfit within the recorded decision; no task may introduce new capability, and no new behavior may be\nintroduced. If the planner cannot produce such tasks — or returns a human\u002Fdeferral disposition or\nan empty, unbound task list — the engine writes the existing refused HALT, never a generic\nneeds-human halt that drops the decision.\n\n## Engine-selected build_review case-v1 mode\n\nUse this branch **only when this engine context is the engine-stamped `build_review` `case-v1` case context declaring `domain: \"build_review\"` and `mode: \"case-v1\"` or `\"case-v2\"`**. It is one judgement by\nthe existing `remediate` skill, not a new skill or a second dispatch. Do not create a skill or dispatch another agent. For every other context, including all SHIP and stall remediation, skip this\nsection and follow the legacy gap-plan instructions below unchanged.\n\n### Supplied input — complete or stop\n\nJudge only the frozen, byte-bounded projection supplied in the engine context. Its exact input fields\nare:\n\n- `domain`: `build_review`.\n- `currentFindings`: every current operator-unresolved content finding, each with its rubric id,\n  stable finding id, anchor, summary, and evidence locations.\n- `priorCases`: all feature-local prior cases, each with outcome, source links, effect status, and\n  resolution evidence, and `priorCases[].bindableDispositions`.\n  - A prior source may carry `finding`, a bounded digest of the earlier finding: `rubric`,\n    `concernKind`, a bounded `summary`, bounded `evidenceLocations`, and `lapId`.\n  - Treat a supplied `finding` digest as binding context when deciding whether a current finding is\n    an equivalent re-raise of that prior source. It is never report text: do not copy, quote, or\n    treat it as a new finding; use it only to bind or distinguish the current source and case.\n- `planContract`: the active approved-plan contract that determines whether work is admitted.\n- `taskStatus`: the engine-supplied task-status evidence.\n- `effectPointers`: the engine-supplied prior effect and BUILD-attempt pointers.\n- `suppressionHistory`: engine-owned sub-floor finding history. It is context only, never a\n  current source and therefore receives no `sourceOutcomes` row.\n\nAll feature-local prior cases must be present or stop: never infer, truncate, or silently ignore\nhistory. Every supplied current finding must receive exactly one source outcome. Use the supplied\nstable identifiers and evidence to make semantic judgements; do not match summaries as identity.\n\nDo not re-audit the source tree. Do not read sibling rubric prompts, inspect a different review\nartifact, or seek additional repository evidence. The engine already selected the scope, excluded exact\noperator-resolved findings, assembled all history, and bounded the input. If the supplied projection\ncannot support a justified judgement, return the required schema with the most supportable\ncase-level disposition; do not substitute a legacy gap plan or invent missing evidence.\n\n### Required additive artifact\n\nOverwrite `.pipeline\u002Fremediation.json` with one JSON object using exactly these top-level keys:\n`mode`, `domain`, `sourceOutcomes`, `cases`. Set `mode` to `\"case-v1\"` and `domain` to\n`\"build_review\"`; do not add legacy `dispositions` or any other keys.\n\n`sourceOutcomes` contains one exact row with `sourceId`, `outcome`, `caseRef` for every and only the\nsupplied `currentFindings` identifier. `outcome` is closed: `acted` | `deferred` | `rejected` | `merged` | `refuted`.\nEach `caseRef` is a provider-local reference to one canonical row in `cases`; it is not a durable id.\nSeveral source rows may reference one canonical case only when the judgement is that they are the same\nrepair case.\n\nEach `cases` row has exactly `caseRef`, optional `existingCaseId`, `disposition`, `priority`,\n`rationale`, `confidence`, `effect`; a `refute` row additionally carries `refutation`:\n\n- `caseRef` is the provider-local reference used by source rows. `existingCaseId`, when supplied by\n  the engine in `priorCases`, may bind that existing case only.\n- A non-escalation row binding an `existingCaseId` must use a disposition listed in that prior case's\n  `bindableDispositions`.\n- A refused binding is named in `bindingCorrections` for one corrected judgement. This is the single\n  correction retry; correct the named binding without changing the\n  supplied sources or inventing a new case.\n- `disposition` is closed: `act` | `defer` | `reject` | `refute` | `advisory` when the context declares severity thresholds.\n- `priority` is closed: `critical` | `high` | `medium` | `low`.\n- `rationale` is bounded, evidence-grounded prose explaining the judgement, and `confidence` is\n  closed: `high` | `medium` | `low`.\n- An `act` effect is exactly `{ \"kind\": \"action\", \"route\": \"build\", \"tasks\": [{ \"title\": \"...\" }] }`.\n  It contains one or more concrete, ordered, file-scoped task titles.\n- An unbound `act` row (one without `existingCaseId`) may add `distinctFrom`: one or more\n  `{ \"caseId\": \"...\", \"reason\": \"...\" }` entries declaring it distinct from resolved action\n  owners of its sources. A reason must be non-empty. A re-raise over a resolved action case is\n  a recurrence unless declared distinct with a reason; its lineage gets three applied attempts.\n  A malformed `distinctFrom` shape rejects the artifact. An entry may name either a provenance\n  candidate of the row or a resolved act owner of a row source; an entry not naming a resolved action owner of a row source is ignored unless it names a provenance candidate.\n- A bound `act` row on a resolved `act` case with an applied action effect may carry `reRaise`\n  `{ \"kind\": \"residual-gap\" | \"repeat\", \"reason\": \"...\" }`; its reason is non-empty.\n  `residual-gap` routes the repair to BUILD under the lineage limit of three applied attempts;\n  `repeat` halts the lap. An absent `reRaise` is treated as a residual gap.\n- A `defer` effect is exactly `{ \"kind\": \"deferral\", \"title\": \"...\", \"body\": \"...\",\n  \"exclusionRationale\": \"...\" }`. Its `exclusionRationale` explains why no current plan task admits\n  the work.\n- A `reject` effect is exactly `{ \"kind\": \"none\" }` and its rationale explains why the raw finding\n  is non-actionable under the supplied rubric and plan contract.\n- An `advisory` row adds `adjudicatedSeverity`. It is allowed only when its source rubric declares a\n  threshold, its severity is strictly below that threshold and never above the reviewer severity,\n  it has a rationale grounded in the plan or prior cases, and its effect is exactly `{ \"kind\": \"none\" }`.\n- A `refute` row MUST bind an `existingCaseId` for an already attempted `act` case, use confidence\n  `high`, and use either `{ \"kind\": \"none\" }` or a complete deferral effect. Its `refutation` is\n  exactly `{ \"claim\": \"...\", \"assertions\": [...] }`; every assertion has `assertion`, a `refuted` or\n  `upheld` verdict, and evidence entries containing only `path` and `excerpt`. Evidence proves current\n  tree content: use no line numbers, hunks, commits, or SHAs. A case may be refuted once only; a later\n  attempt to refute the same case is rejected for human review.\n- A re-raised finding judged no longer present on an attempted applied action receives an\n  evidence-backed `refute`, not a bound `reject`.\n\n### Authority boundaries\n\nThe provider must not mint durable case ids or effect ids;\nthe engine validates the graph, stamps durable ids, and applies every effect.\n\nNever omit, duplicate, or replace a supplied source outcome. A `merged` source is a trace outcome,\nnot a case disposition; it still names its canonical `caseRef`. A same-substance finding may be bound\nby `existingCaseId` to a prior case marked `operatorAccepted`. Never assert or create operator\nacceptance, and never treat an autonomous case outcome as accepted risk. Do not apply an effect, file\nan intake issue, navigate BUILD, charge a budget, or mutate durable state. Do not append to the\napproved plan. In this mode the only write is the schema-constrained `.pipeline\u002Fremediation.json`\nartifact.\n\n### case-v2 consistency, admission, and decision stops\n\nWhen the engine stamps `mode: \"case-v2\"`, write exactly the v1 graph fields plus a top-level\n`consistency` object; its exact top-level keys are `mode`, `domain`, `sourceOutcomes`, `cases`, and\n`consistency`. The `consistency` object is exactly `{ \"verdict\": \"consistent\" | \"blocked\",\n\"sourceIds\": [\"...\"], \"caseRefs\": [\"...\"], \"rationale\": \"...\" }`. It names the implicated\ncurrent sources and canonical case rows, and gives bounded, evidence-grounded rationale. Do not\ndrop merge rows: every merged source still cites its canonical case, so the graph retains its\noriginal source and merge provenance.\n\nFor a v2 `act`, every effect task is exactly `{ \"title\": \"...\", \"admittedTaskIds\": [\"...\"],\n\"admissionRationale\": \"...\" }`. `admittedTaskIds` names the existing active-plan tasks that admit\nthat repair, and `admissionRationale` explains the approved-scope fit. Never invent a task id or\nappend a plan task.\n\n`planContract.index` lists every active-plan task without its body. `admittedTaskIds` must name supplied task bodies.\nAn index-only task admission triggers at most one engine-run\nexpansion round; after that round, an unsupplied admission halts.\n\nv2 adds `escalate` as both a source outcome and a case disposition. An escalation case has exactly\nthe ordinary case fields plus `\"escalation\": { \"owner\": \"product\" | \"plan\" | \"architecture\" }`\nand its effect is exactly `{ \"kind\": \"none\" }`. Its source rows, case rationale, and consistency\nrecord are the operator-facing evidence. It creates no action, operator acceptance, tracker effect,\nplan mutation, BUILD navigation, or budget charge. Use `blocked` consistency for an unresolved\ncontradiction; a `consistent` verdict still does not authorize work outside the admitted task ids.\n\nThe inherited `refute`\u002F`refuted` record is unchanged in v2: keep its existing-case binding,\nhigh-confidence assertion evidence, and terminal semantics. Do not create a parallel refutation\nshape.\n\n## Mode-neutral remediation context\n\nWhen the dispatch context includes `plan contract:` or `prior attempts:` pointers, read every\nreferenced file before judging repairs. Treat the referenced plan task's **Steps** as the governing\ncontract for the repair; prior-attempt artifacts supply earlier same-anchor context, not a replacement\ncontract. When no pointers appear, inspect `.docs\u002Fplans\u002F` and `.pipeline\u002Fbuild-review\u002F` directly\nbefore judging the repair.\n\nWhen used interactively, produce a human-readable remediation plan for the operator. It is advice,\nnot a managed persisted result, and does not replace the engine's selected input, validation, or\nrouting.\n\n## Gap-plan judgment guidance\n\n**Environmental stalls — check first, halt cheaply.** Before any other analysis of a stall question,\ndecide whether its cause is the environment rather than the work: a service, container, database,\nnetwork dependency, credential, or tool the build or test gate needs is down, crashing, or\nunreachable. No plan, story, ADR, or code change repairs the machine, so committed artifacts cannot\nanswer the question. Halt it as `unanswerable` immediately: preserve the question verbatim, state\nthat the cause is environmental, and name the failing dependency as the question reports it. Do not\ndispatch `remediation-planner`, delegate, diagnose the dependency, read source, or propose\nconfiguration changes as a workaround.\n\n**HALT is reserved for `architectural-clarity`, `product-scope`, and `unanswerable` stall questions\nonly.** Use `architectural-clarity` when an architectural gap needs a human decision before any code\ncan be right; use `product-scope` when the initial design never covered the functionality; use\n`unanswerable` only when a stall question cannot be answered from committed artifacts alone. Every\nother gap should be turned into concrete work.\n\n- **Sealed-artifact amendments return to DECIDE.** When a gap requires amending another feature's\n  artifact under `.docs\u002Farchitecture\u002F`, `.docs\u002Fdecisions\u002F`, `.docs\u002Fplans\u002F`, `.docs\u002Fspecs\u002F`, or\n  `.docs\u002Fstories\u002F`, do not route it to BUILD or acceptance-spec work. Return it to the owning DECIDE\n  step through the existing operator gate and kickback path; make no request, ledger, record, or new\n  artifact to bypass that ownership.\n- **Prefer autonomous remediation.** When approved architecture remains authoritative, clear\n  implementation\u002Ftest\u002Fdocumentation drift belongs in BUILD, including a conforming as-built finding\n  and an answerable build-stall question. Its audit origin or finding id alone does not determine the\n  route. Use `architecture_review` only when a change to, or clarification of, approved architecture\n  is required; do not use it where no architectural decision is needed.\n- **Reject contradictory dispositions.** Selecting `architecture_review` when no architectural\n  decision or product decision is needed is invalid; route clear conforming implementation, test, or\n  documentation work to BUILD instead. Selecting `build` when an unresolved or ambiguous\n  architectural decision remains is invalid; use `architecture_review` when approved architecture\n  must change or be clarified, or HALT for architectural clarity when a human decision is required.\n- **Coverage and planning judgment.** An implementation gap is ordinarily BUILD work; use\n  `acceptance_specs` when the real miss is acceptance coverage. A baseline-passing test that needs\n  strengthening within an existing task's RED\u002FGREEN work is BUILD work, not a planning omission. A `plan` route is for an in-scope planning omission, not an architecture or design decision: before selecting `plan`, examine the approved tasks and use `plan` only when none admits the repair. A file missing from an admitting task's Files list does not make it inadmissible; BUILD records it with a `Scope:` trailer. A `plan` route is terminal in a daemon run and never re-plans.\n- **Recorded RED exception.** An acceptance-spec repair may waive separate RED proof only when the\n  acceptance spec and its implementation must be repaired atomically. Record a non-empty reason and\n  attributable approval; report the result as waived, never as proven RED. Otherwise use the ordinary\n  failing-spec RED path.\n- **Preserve completed behavior and coverage.** A repair that removes, replaces, rewrites, or\n  relaxes existing code, tests, or assertions must identify the completed plan task or story\n  criterion whose behavior and coverage survive it. If a removal makes coverage genuinely redundant,\n  include the replacement in the same repair.\n- **Close the defect class within plan admission.** Check sibling sites and what a removal would\n  orphan. Include a sibling only when an existing plan task admits it; otherwise record it as found\n  and excluded with the reason. Do not widen the work beyond approved scope merely because the same\n  shape occurs elsewhere.\n- **Low confidence halts.** Do not route on an unverified assumption about a gap's nature. When the\n  nature is genuinely uncertain, rather than merely the fix, HALT for a human instead of guessing a\n  route, as required by `verify-claims`.\n",{"name":5,"model":48,"phase":49,"requires":50,"standalone":52,"description":7,"enforcement":24,"disable-model-invocation":52},"opus","ship",[51],"verify-claims",true,"main","34b11234d8660783bd73a6d88385cf96cd86d0d7","skills\u002Fremediate",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 22:26:29",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":52},[62,65,68],{"tool":63,"command":64},"npx","npx skills add jstoup111\u002Fai-conductor --skill remediate",{"tool":66,"command":67},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill remediate",{"tool":69,"command":70},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill remediate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fremediate\u002FSKILL.md",[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fremediate\u002Fagents\u002Fopenai.yaml",[80,97,133,154,173,189],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":43},"01M70YKSA2H7Q9WSRD1ECEGY20","build-review-dependency-hygiene","Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-review-dependency-hygiene\u002FSKILL.md",[],[29,87,88,89,90,35,91,92,93,94,39,95,96],"dependency hygiene","dependency","hygiene","build review dependency hygiene","feature","diff","dependencies","license","judge","gating",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":114,"publishedAt":43},"01M6K3EQQ6ADH3G2RMYK6XE26E","writing-system-tests","Use BEFORE implementing any feature that has stories in .docs\u002Fstories\u002F — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP\u002Frequest-level acceptance tests for headless\u002FAPI projects, end-to-end UI tests for projects with a frontend, using the project's own test framework and directory conventions.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-system-tests\u002FSKILL.md",[103,108,111],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":109,"categoryName":110,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[115,116,117,118,119,120,121,122,123,124,125,126,33,127,128,129,130,96,131,132],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","directory","ui","framework","failing","phase","request",{"skillNo":134,"name":51,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":43},"01M6K3EHR0QQ1QY1S9RC6D1WTD","Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fverify-claims\u002FSKILL.md",[],[139,33,31,140,141,40,142,143,39,144,38,37,145,146,147,148,149,150,151,152,153,96,26],"verify claims","do","adr","decision","claim","mechanics","workflow","code","reports","plan","active","questions","about","spec","invoke",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":43},"01M6K3ED4NF5DJA2Y35MH2JCRC","tdd","Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[156,161,162,163,123,164,35,165,166,167,168,91,169,39,37,170,171,172,26,131],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":43},"01M6K3E6PEXBXYY2K8TSRTN1JT","stories","Use only within active engineer\u002Fconduct DECIDE after architecture approval, when a committed `.docs\u002Fstories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstories\u002FSKILL.md",[],[175,180,140,40,181,182,183,39,38,37,125,184,36,185,33,186,31,187,149,188,153,96,26],"conduct","decide","engineer","general","requirements","examples","artifact","requests","implementation",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":43},"01M6K3E1HE7267YKFJQ3YFCGW5","stack-land","Use when an operator needs to land reviewed manual changes on the correct closed child of a stacked feature. Operator-invoked only: inspect ownership, propose the safe child with evidence, and require confirmation before opening the landing.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstack-land\u002FSKILL.md",[],[196,197,198,170,33,199,200,201,31,91,202,203,204,205,206,39,207,38,37,208,26,24],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation"]