[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C47JM42BS06G59N9AVKPD7":3,"skill-same:01M6C47JM42BS06G59N9AVKPD7":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":44,"install":45,"resources":58},"01M6C47JM42BS06G59N9AVKPD7","solution-authoring",null,"Reusable engagement-gate methodology for content-authoring decisions in upstream phases. Use when classifying a decision as load-bearing or routine, authoring a decision brief, handling an override or decline, capturing articulation, or evaluating skip rules. DO NOT USE FOR: GitHub setup, completion-marker ownership, or adversarial review pipeline orchestration.","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsolution-authoring\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32],"solution authoring","review","github","orchestration","setup","adversarial review","content","brief","pipeline","methodology","decision","Rules","decisions","use","engagement","2026-11-10 10:12:30",false,"---\nname: solution-authoring\ndescription: \"Reusable engagement-gate methodology for content-authoring decisions in upstream phases. Use when classifying a decision as load-bearing or routine, authoring a decision brief, handling an override or decline, capturing articulation, or evaluating skip rules. DO NOT USE FOR: GitHub setup, completion-marker ownership, or adversarial review pipeline orchestration.\"\n---\n\n\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Solution Authoring\n\nReusable methodology for preventing cognitive surrender during upstream phases. Fires before any content-authoring decision is put to the engineer, to classify the decision, render a decision brief when warranted, handle overrides, and capture articulation at phase exit.\n\n## When to Use\n\n- When the engineer's answer shapes content the agent will author into a durable artifact (issue body, plan comment, AC slice, marker payload, source\u002Ftest\u002Fconfig file)\n- When classifying a decision as load-bearing or routine before firing the gate\n- When rendering a decision brief and teaching before asking\n- When handling an engineer override or decline without argument\n- When capturing articulation at phase exit\n\n## When Not to Use (D-gate-scope)\n\nThe classification gate does NOT intercept questions that approve or reject an operation the agent is about to take (dedup approval, branch creation, file deletion), clarify factual state, or dispatch agent-to-agent prosecution or research. When the boundary is ambiguous, **default to intercepting** — false positives add audit_rationale text; false negatives miss load-bearing engagement.\n\n### Rule: Classification gate\n\nA decision is load-bearing iff ALL THREE legs pass:\n\n1. **Reversibility** — if wrong, requires rework to a published artifact.\n2. **Non-inheritance with artifact-citation falsifier** — the agent MUST attempt to cite a specific inherited artifact (umbrella comment, prior phase marker, named-decision row, settled methodology rule) that would have answered the decision. The citation is recorded verbatim in `audit_rationale`. If a plausible citation exists, the leg **fails** and the decision is routine. Only documented inability to cite — after a genuine attempt — establishes non-inheritable status. A plausible citation is one a reasonable reader would accept as topical for the decision at hand — it need not be exact; the four enumerated artifact types are exhaustive for v0. **Re-audit trigger**: if an engineer challenges a load-bearing classification with a citation claim after initial classification, the agent MUST re-attempt Leg 2 against that claim; if a plausible citation is found, emit a `**Recommendation shift**` with `trigger: classification-re-audit` (see Template: Free-text option treatment for the output shape).\n3. **Audit-plausibility** — the agent can write a substantive `audit_rationale` sentence.\n\nFailing any one leg collapses to routine. For load-bearing decisions, render the `audit_rationale` as **one sentence immediately above the decision brief** so the engineer can challenge the classification in-band.\n\n### Rule: Decision brief structure\n\nA decision brief has two tiers.\n\n**Base tier (default for every load-bearing decision)**: Three sentences — (1) **Concrete element** — names the specific artifact, section, or mechanism where the decision lands; (2) **Decision setup** — frames the choice in outcome terms, not implementation jargon; (3) **Conditional misconception** — names the plausible wrong path and its failure mode. The brief precedes the question. Teach before asking.\n\n**Escalation tier (override that fires for load-bearing adversarial-review dispositions)**: Same three-part spine expanded to full prose. Fires when a load-bearing adversarial-review disposition is being surfaced to the owner (keyed on the load-bearing classification, known before the question fires for that finding — consistent with the firing-position rule in the `## Applying the gate to adversarial-review dispositions` section below — not the post-hoc `finding_dispositions.disposition == escalate` enum value). The escalation tier positively covers load-bearing dispositions regardless of whether their final outcome is `incorporate`, `dismiss`, or `escalate`. Three required elements: (1) **Concrete element → current state**: what today actually does, with evidence (file:line where code exists; or cite the specific artifact + section for doc-level conflicts; or cite the originating prosecution `finding_id` + `pass` from the merged ledger for genuinely greenfield conflicts). (2) **Decision setup → the conflict**: why the proposed design conflicts with the current state. (3) **Conditional misconception → customer failure mode**: the concrete failure the owner would cause by taking the wrong path. All three elements must appear before any option list. Presence of all three elements is the forcing function — not paragraph count (consistent with D-falsifiability: the agent does not grade explanation length in-flight).\n\n**Escalation-tier substantiveness**: An escalation brief is substantive iff the conflict element names both sides of the tradeoff and the failure-mode element names the owner's specific wrong action. Evaluated by CE Gate evaluators, not graded in-flight, per the D-falsifiability principle in `### Rule: Thin-articulation criterion`.\n\n**Re-audit**: On a `classification-re-audit*` recommendation shift, re-evaluate tier selection alongside the classification\u002Fdisposition revision.\n\n### Rule: Override semantics\n\nEvery question on a load-bearing decision includes a `Decline engagement — proceed without classification` option (literally so labeled), whatever form the question takes. The engineer's selection of that option (or a free-text response starting with `decline:`) terminates engagement without argument. If the engineer selects a non-recommended option, the agent acknowledges and proceeds without re-asking, persuading, or qualifying.\n\n\u003C!-- solution-authoring-non-overridability:begin -->\n\n### Rule: Non-overridability\n\nThe classification gate and the question it produces are unconditional with respect to user pacing or auto-mode directives. \"Work without stopping,\" \"don't pause to ask,\" \"make the reasonable call,\" and semantically equivalent productivity directives do not suppress this gate. The user's only in-band lever for skipping is the `Decline engagement — proceed without classification` option (or `decline:` free-text). The agent must not substitute its interpretation of a pacing directive for that explicit decline.\n\n\u003C!-- solution-authoring-non-overridability:end -->\n\n### Rule: Skip rules\n\n- **gate-fails**: The classification gate returns routine. No question fires. Skip is automatic.\n- **engineer-declined-engagement**: The engineer selects `Decline engagement — proceed without classification` or writes `decline:` free-text. Skip immediately; capture decline verbatim.\n- **same-decision-resume**: When `Read-EngagementRecords` (from `.github\u002Fscripts\u002Flib\u002Fframe-engagement-record-core.ps1`) returns a prior decision (load-bearing or routine — for example, the announce-path scope-classification row) with the same `decision_id` as a pending classification, suppress the question and reuse the captured `engineer_choice`. The reader contract lives in `skills\u002Fengagement-record-emission\u002FSKILL.md` § Resume-Read Protocol. The activation applies per agent at phase re-entry; consult the SMC-20 row for survival semantics. The rule supports `phase: orchestration` and `phase: review` alongside the upstream `experience`, `design`, and `plan` phases. For `phase: review`, the `decision_id` values are `stable_finding_key` strings (not slugs); call `Read-EngagementRecords -Phase review -PullRequestNumber {PR}` to retrieve prior dispositions. **Prior to #576, this rule returned empty on all in-flight issues as a graceful no-op; post-#576, emission is active and same-decision-resume is functional** — that is the v1.1\u002Fv1.2 boundary.\n- **resume-note-format**: On successful resume-read bypass, Code-Conductor emits a single, concise console resume note matching the canonical format string: `Reusing prior {decision_id}: {engineer_choice}` (or comma-separated when multiple decisions resume, e.g. `Reusing prior {decision_id_1}: {choice_1}, {decision_id_2}: {choice_2}`).\n\n### Rule: Thin-articulation criterion\n\nArticulation is substantive iff it contains: (1) the choice the engineer made, (2) what would have been wrong about a leading alternative, (3) the reasoning bridge between them. The agent renders the prompt and captures raw text; the agent does NOT grade articulation quality against the criterion in-flight (D-falsifiability protected). CE Gate evaluators apply the criterion independently.\n\nForward-compatible capture format:\n\n```yaml\narticulation_captures:\n  schema_version: 1\n  entries:\n    - decision_id: \u003Cid>\n      articulation_text: |\n        \u003Cverbatim engineer text>\n      capture_phase: experience | design | plan\n      capture_session: manual-ce-gate-v0\n```\n\n**Glossary and harmonization note**: The YAML field `teaching_paragraph_excerpt` is preserved from the locked #571 engagement-record marker payload (`\u003C!-- engagement-record-design-571 -->`). This skill uses \"decision brief\" in prose; `decision_brief` and `teaching_paragraph_excerpt` refer to the same concept and both remain valid.\n\n## Applying the gate to adversarial-review dispositions\n\nFor each adversarial-review finding that the calling workflow must disposition, run the classification gate against the action the maintainer would take for that finding, not against the review pass as a whole. Use the Code-Critic Finding Categories contract for the input identity: `id` values are sequential `F1 | F2 | F3 | ...` labels within the review cycle, and `pass` is `1 | 2 | 3 | 4` for the finding origin that produced the disposition record. The disposition enum is `incorporate | dismiss | escalate`; the classification enum is `load-bearing | routine`. If a finding is routine, record the disposition without asking. If a finding is load-bearing, render the normal `audit_rationale`, decision brief, and question before recording the disposition.\n\nFor adversarial-review findings, the tier is keyed on the load-bearing classification (known before the question fires per the above ordering). Load-bearing adversarial-review dispositions use the **escalation tier**; all other load-bearing decisions (upstream content-authoring, orchestration scope-classification, and any non-adversarial surface) use the **base tier**.\n\nFiring-position rule: for an atomic multi-stage adapter declaring `integrity-contract.atomic: true` and more than one `pipeline-stages` entry, the classification gate fires only on terminal-stage sustained findings after the terminal stage. For adapters whose terminal stage is judge, those are judge-sustained findings after judge; for adapters whose terminal stage is defense, those are defense-sustained findings after defense. The gate does not fire on prosecution output or defense dialogue inside the atomic window. CLAUDE.md Engagement-gate non-overridability D3 still applies: once the terminal-stage sustained input exists, the gate fires unconditionally; only the firing position changes for atomic multi-stage adapters. For the prosecution-only `design-challenge` adapter, the gate fires on convergence-sustained findings per `skills\u002Fdesign-exploration\u002FSKILL.md` section `Convergence Filter` (#785) — the raw merged ledger passes through the convergence filter first, and only the kept subset enters the classification gate.\n\nThe marker payload schema is the `finding_dispositions:` block validated by `.github\u002Fscripts\u002FTests\u002Fdesign-disposition-audit.Tests.ps1`: `schema_version: 1`, non-empty `passes_run` as a subset of `[1, 2, 3, 4]`, and `entries[]` carrying `finding_id`, `pass`, `disposition`, `classification`, and `disposition_rationale`. Routine entries require `artifact_citation` when the routine classification rests on an inherited artifact settling the finding; routine entries classified for another non-load-bearing reason do not require a citation. Multi-pass concurrence may include `also_flagged_by` with secondary pass ids.\n\nThe `passes_run`\u002F`pass` vocabulary here is distinct from the `design-challenge` adapter's `prosecution-passes` field: `prosecution-passes` stays `[1, 2, 3]` and names the three finder dispatches the adapter runs (unchanged), while `passes_run`\u002F`pass` is the disposition schema's origin-tracking enum, which now additionally allows pass 4 to record findings whose origin is the convergence cold-read rather than a prosecution finder dispatch — the two vocabularies must not be conflated.\n\n`disposition_rationale` explains why this specific finding received this specific `incorporate`, `dismiss`, or `escalate` outcome. It is not the v0 `audit_rationale`: `audit_rationale` proves why a decision is load-bearing before asking; `disposition_rationale` persists the final per-finding outcome after the gate decision, including routine outcomes that never asked the maintainer.\n\nThe re-audit handler is symmetric. If a load-bearing disposition is challenged with a plausible artifact citation, rerun Leg 2 and, when the citation holds, emit `trigger: classification-re-audit` and revise the finding to routine. If a routine disposition is challenged with evidence that no inherited artifact actually settles the action, rerun all three legs and, when they hold, emit `trigger: classification-re-audit-routine` and revise the finding to load-bearing before asking.\n\nRe-audit timing: under an atomic multi-stage adapter, re-audit triggers apply to the terminal-stage sustained findings set, which is the input to the terminal-stage classification gate. For judge-terminal adapters, this remains the judge-sustained findings set after judge; for defense-terminal adapters, this is the defense-sustained findings set after defense. For the prosecution-only `design-challenge` adapter, re-audit applies to merged-ledger findings as today. Re-audit cannot retroactively invalidate a terminal-stage ruling or report; it can only revise the maintainer disposition classification\u002Fdecision.\n\nMap maintainer input to recommendation-shift triggers as follows: new facts or changed upstream content after the initial classification maps to `new-evidence`; direct disagreement with the recommended disposition or option maps to `engineer-pushback`; a claim that a load-bearing finding is already answered by an inherited artifact maps to `classification-re-audit`; a claim that a routine finding is not actually answered by inherited content maps to `classification-re-audit-routine`. If a maintainer message could fit more than one pattern or does not identify the challenged finding, ask one clarifying question before changing classification.\nYAML marker invariant: `finding_dispositions:` lives only on the `\u003C!-- design-phase-complete-{ID} -->` marker body, never on `\u003C!-- credit-input-{port}-{ID} -->` markers. Credit-input markers remain limited to frame credit deferred-emission payloads. The `finding_dispositions:` block lives only on `\u003C!-- design-phase-complete-{ID} -->` markers (SMC-19) and is independent of `\u003C!-- engagement-record-{phase}-{ID} -->` markers (SMC-20). The two payloads serve distinct audits — finding-dispositions tracks per-finding incorporate\u002Fdismiss outcomes; engagement-records track load-bearing classification with cross-session resume semantics via `same-decision-resume`. Do not mirror or merge content between them.\n\nWorked exemplar:\n\n```yaml\nfinding_dispositions:\n  schema_version: 1\n  passes_run: [1, 2, 3]\n  entries:\n    - finding_id: F1\n      pass: 1\n      disposition: dismiss\n      classification: routine\n      disposition_rationale: \"Dismissed because the cited acceptance criterion already requires the behavior the finding asks to add; no maintainer choice remains.\"\n      artifact_citation: \"Documents\u002FDesign\u002Fsession-memory-contract.md#durable-marker-precedence\"\n    - finding_id: F2\n      pass: 2\n      disposition: incorporate\n      classification: routine\n      disposition_rationale: \"Incorporated as a wording correction because the existing named-decision row already settles the outcome and only the citation text changes.\"\n      artifact_citation: \"skills\u002Fsolution-authoring\u002FSKILL.md#rule-classification-gate\"\n    - finding_id: F3\n      pass: 1\n      disposition: escalate\n      classification: load-bearing\n      disposition_rationale: \"Escalated because choosing whether to reject or preserve the review finding changes the durable design contract and no inherited artifact settles that tradeoff.\"\n      also_flagged_by: [2, 3]\n```\n\nThe exemplar rationales name the disposition outcome and why it follows from the finding evidence. They intentionally do not repeat the v0 `audit_rationale` tone, which is reserved for proving that a question is warranted before the gate fires.\n\n### Template: Decision brief\n\nRender as a block-quoted paragraph immediately after the `audit_rationale` sentence:\n\n> **Decision brief — {decision_id}**: {Concrete element sentence.} {Decision setup sentence in outcome terms.} {Conditional misconception sentence naming the plausible wrong path and its failure mode.}\n\n**Exemplar** (D-load-directive, from #571 R1+R2):\n\n_Audit rationale: The load-order direction for solution-authoring vs upstream-onboarding is not settled in any prior phase comment or umbrella decision — no named-decision row pins this ordering, so the non-inheritance leg holds._\n\n> **Decision brief — D-load-directive**: The `## Process` section of each agent body is where load-order instructions land. The decision is whether solution-authoring fires before upstream-onboarding or after — this determines whether the engagement gate runs before the brief surfaces inherited decisions. If upstream-onboarding fired first, the gate would intercept questions about content the engineer just read from someone else's output — manufacturing load-bearing signal on settled content.\n\n### Template: question shape\n\nPresent options with strong examples for ALL options — not just the recommended one. Option presentation asymmetry is itself a form of cognitive surrender (the engineer cannot compare without examples).\n\nInclude `Decline engagement — proceed without classification` as the last option on every load-bearing question.\n\n**Exemplar** (D-load-directive, from #571 R1+R2):\n\n- **Option 1 (Recommended)** — solution-authoring first: Classification runs before the brief surfaces prior decisions. Example: during `\u002Fdesign`, the inheritance audit evaluates the decision before any prior-phase context is rendered, so the falsifier operates on genuinely unanchored decisions only.\n- **Option 2** — upstream-onboarding first: The brief surfaces inherited decisions first, then solution-authoring fires. Example: the engineer sees inherited answers before being asked to classify them — but the gate would then intercept settled content and produce false load-bearing signal.\n- **Decline engagement — proceed without classification**\n\n### Template: Free-text option treatment\n\nWhen the engineer overrides via free-text or selects a non-recommended option: (1) accept without argument or re-asking; (2) if the choice materially differs from the recommended option, emit a `**Recommendation shift**` line; (3) proceed with the chosen direction.\n\n**Exemplar** (S1-negative correction, from #571 R1+R2 — engineer pushes back on mis-classification):\n\nEngineer: \"Gap-visibility was already answered in the umbrella.\"\nAgent re-audits, finds citation in #571 D-customer section, reclassifies, and emits:\n\n`**Recommendation shift** — D-gap-visibility: previously load-bearing (non-inheritance claimed); now routine (citation found in #571 D-customer); trigger: classification-re-audit; reason: the decision was answerable from inherited content and the artifact-citation falsifier applies.`\n\n### Template: Recommendation shift\n\nEmit immediately before the revised recommendation:\n\n> `**Recommendation shift** — {decision_id}: previously {old_recommendation}; now {new_recommendation}; trigger: {engineer-pushback | new-evidence | classification-re-audit | classification-re-audit-routine}; reason: {one-sentence reason}.`\n\n**Exemplar** (D-gap-visibility, from #571 R1+R2 — inline token, then phase-exit YAML aggregate):\n\n`**Recommendation shift** — D-gap-visibility: previously load-bearing; now routine; trigger: classification-re-audit; reason: the decision was answerable from inherited content.`\n\nAt phase exit, emit a YAML aggregate of all in-phase shifts:\n\n```yaml\nrecommendation_shifts:\n  schema_version: 1\n  entries:\n    - decision_id: \u003Cid>\n      previous: \u003Cold_recommendation>\n      revised: \u003Cnew_recommendation>\n      trigger: engineer-pushback | new-evidence | classification-re-audit | classification-re-audit-routine\n      reason: \u003Cone-sentence>\n      capture_phase: experience | design | plan\n```\n\n### Template: Articulation prompt\n\nRender at phase exit after all load-bearing decisions are locked:\n\n> For each locked load-bearing decision, describe in 2–4 sentences: the choice you made, what would have been wrong about a leading alternative, and why the bridge between them held for this case. Raw text is captured in manual CE Gate evidence; evaluators apply the three-part criterion independently.\n\n**Exemplar** (D-load-directive, from #571 R1+R2):\n\n> \"I chose solution-authoring first because upstream-onboarding surfaces prior decisions that have already been answered — if the engagement gate ran after, it would fire on settled content. If upstream-onboarding had run first, the gate would have intercepted the brief's inherited decisions and manufactured false load-bearing signal. The order had to put classification before context so the falsifier could operate on genuinely unanchored decisions only.\"\n\n## Related Guidance\n\n- Load `upstream-onboarding` after this skill per the D-load-directive declared in each agent body dispatcher.\n- Load `bdd-scenarios` when scenario IDs and G\u002FW\u002FT formatting are needed for CE Gate scenarios.\n\n## Gotchas\n\n| Trigger                                              | Gotcha                                                                                                | Fix                                                                                                       |\n| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |\n| Treating a pacing directive as an engagement decline | The agent silently skips a load-bearing classification gate even though no explicit decline was given | Fire the question unless the engineer selects the explicit decline option or writes `decline:` |\n| A routine decision is treated as load-bearing        | The agent asks for engagement on content already settled by an inherited artifact                     | Re-audit Leg 2 against the citation and emit the appropriate recommendation shift                         |\n| A load-bearing decision is treated as routine        | The durable artifact changes without surfacing the maintainer choice                                  | Rerun all three gate legs and ask before recording the final decision                                     |\n\n## L2 Reconciliation Gate (Review Path)\n\nAfter implementation steps complete and before the CE Gate, run the warn-only L2 reconciliation validator to produce a review-time ledger:\n\n```powershell\n$result = & .github\u002Fscripts\u002Flib\u002Fgate-reconciliation-core.ps1 -IssueNumber {ID}\nif ($result.status -eq 'findings') {\n    # Surface warn-only findings in the review step; do not block PR creation\n    $result.findings | ForEach-Object { Write-Warning \"Gate finding: $($_.decision_id) — $($_.issue)\" }\n}\n```\n\nThe validator is **warn-only**: it surfaces missed-gate signals for adversarial review and the CE Gate, but does NOT block `gh issue comment` marker writes or PR creation. Enforcement is **detection-at-review** — caught before merge, within the `d-intent-strictness` detection+recovery envelope.\n\nFor Code-Conductor, invoke this validator as part of the review-phase pre-PR checks, after the `standard` adversarial review pipeline completes.\n\n## L0 Gate Token (Classification-Decision Self-Report)\n\nAt each gate decision point, the agent MUST emit a classification-decision token to the session event log before putting the decision to the engineer (or before recording a lawful-skip outcome). The token schema is defined in `skills\u002Fsolution-authoring\u002Fschemas\u002Fgate-decision-token.schema.json`.\n\n**Emit contract:**\n\n- `decision_id` MUST match the `decision_id` used in the engagement-record or `finding_id` used in `finding_dispositions:`.\n- `outcome` MUST be one of `asked | gate-fails | declined | same-decision-resume | greenfield-defer`.\n- `window_position` MUST reflect the firing position per the Firing-position rule: `pre-ask` for upstream questions (also covers a determined-outcome announcement at that same pre-dispatch firing position — no question fired, but the same point in the pipeline; see the schema's `window_position` description), `disposition` for adversarial finding dispositions (#615 surface), `judge-merge` for plan judge-merge dispositions (#605 surface), `review-disposition` for PR review-verdict disposition gate (#655 surface).\n- `timestamp` MUST be the ISO-8601 UTC time of emission.\n- `issue_number` MUST be the GitHub issue number this decision belongs to — except for `window_position: review-disposition` tokens, which must carry `pull_request_number` instead (and omit `issue_number`). See `skills\u002Fsolution-authoring\u002Fschemas\u002Fgate-decision-token.schema.json` for the conditional schema.\n- `session_key` is optional and names the token's own log file. Derive it with `Resolve-GateSessionKey` (`skills\u002Fsolution-authoring\u002Fscripts\u002FResolve-GateSessionKey.ps1`).\n\n**Lawful-skip tokens** (`outcome ≠ asked`) MUST still be emitted — they are the discriminator that distinguishes a lawful skip from an illegitimate silent skip. A missing token for a load-bearing decision that also has no recorded decision is the signal the L2 validator and L3 Code-Critic use to flag a potential never-surfaced skip.\n\n**Event log location:** Append tokens to `\u002Fmemories\u002Fsession\u002Fgate-events-{session_key}.jsonl` (one JSON object per line), deriving `{session_key}` with `Resolve-GateSessionKey` (`skills\u002Fsolution-authoring\u002Fscripts\u002FResolve-GateSessionKey.ps1`). Fallback: `.copilot-tracking\u002Fgate-events.jsonl` when session memory is unavailable. Agents are the only producer of this stream; the hook-driven L1 producer was retired in issue #1003.\n\n**Parity:** Token emission applies identically on Claude and Copilot. No platform-specific divergence in the token contract.\n\n**The `phase` enum is closed on purpose, and open-for-work maps onto it rather than extending it.** Every checkpoint the open-for-work conversation runs — the worth-it doors, the affirmation gate, and brief approval on the routine arm — emits `phase: experience` (#957 D5). That conversation *is* the experience-replacement for standalone work, so the mapping is the honest one, and it keeps every existing consumer working: a token carrying a sixth enum value fails schema validation before it ever reaches `gate-reconciliation-core.ps1`, and that script filters on the five values above. Do not \"fix\" the mapping by adding an open-for-work phase; the per-checkpoint field table is in `skills\u002Fopen-for-work\u002FSKILL.md` § Gate-decision tokens.\n\n### Token emit example (load-bearing, asked)\n\n```json\n{\n  \"decision_id\": \"d-load-directive\",\n  \"phase\": \"design\",\n  \"outcome\": \"asked\",\n  \"classification\": \"load-bearing\",\n  \"window_position\": \"pre-ask\",\n  \"timestamp\": \"2026-06-02T00:00:00Z\",\n  \"session_key\": \"issue-617\",\n  \"issue_number\": 617\n}\n```\n\n### Token emit example (lawful skip — same-decision-resume)\n\n```json\n{\n  \"decision_id\": \"d-load-directive\",\n  \"phase\": \"design\",\n  \"outcome\": \"same-decision-resume\",\n  \"classification\": \"load-bearing\",\n  \"window_position\": \"pre-ask\",\n  \"timestamp\": \"2026-06-02T00:00:00Z\",\n  \"skip_reason\": \"Prior decision reused from engagement-record-design-617\",\n  \"issue_number\": 617\n}\n```\n\n## Frame Ports Filled By This Skill\n\nThis skill is **supporting methodology** — it declares no `provides:` field and fills no frame port. Classification per `Documents\u002FDesign\u002Fframe-architecture.md` Adapter Model: the credit-author test confirms this skill adds no frame credit row.\n","\u003C!-- markdownlint-disable-file MD041 MD003 -->\n\n# Solution Authoring\n\nReusable methodology for preventing cognitive surrender during upstream phases. Fires before any content-authoring decision is put to the engineer, to classify the decision, render a decision brief when warranted, handle overrides, and capture articulation at phase exit.\n\n## When to Use\n\n- When the engineer's answer shapes content the agent will author into a durable artifact (issue body, plan comment, AC slice, marker payload, source\u002Ftest\u002Fconfig file)\n- When classifying a decision as load-bearing or routine before firing the gate\n- When rendering a decision brief and teaching before asking\n- When handling an engineer override or decline without argument\n- When capturing articulation at phase exit\n\n## When Not to Use (D-gate-scope)\n\nThe classification gate does NOT intercept questions that approve or reject an operation the agent is about to take (dedup approval, branch creation, file deletion), clarify factual state, or dispatch agent-to-agent prosecution or research. When the boundary is ambiguous, **default to intercepting** — false positives add audit_rationale text; false negatives miss load-bearing engagement.\n\n### Rule: Classification gate\n\nA decision is load-bearing iff ALL THREE legs pass:\n\n1. **Reversibility** — if wrong, requires rework to a published artifact.\n2. **Non-inheritance with artifact-citation falsifier** — the agent MUST attempt to cite a specific inherited artifact (umbrella comment, prior phase marker, named-decision row, settled methodology rule) that would have answered the decision. The citation is recorded verbatim in `audit_rationale`. If a plausible citation exists, the leg **fails** and the decision is routine. Only documented inability to cite — after a genuine attempt — establishes non-inheritable status. A plausible citation is one a reasonable reader would accept as topical for the decision at hand — it need not be exact; the four enumerated artifact types are exhaustive for v0. **Re-audit trigger**: if an engineer challenges a load-bearing classification with a citation claim after initial classification, the agent MUST re-attempt Leg 2 against that claim; if a plausible citation is found, emit a `**Recommendation shift**` with `trigger: classification-re-audit` (see Template: Free-text option treatment for the output shape).\n3. **Audit-plausibility** — the agent can write a substantive `audit_rationale` sentence.\n\nFailing any one leg collapses to routine. For load-bearing decisions, render the `audit_rationale` as **one sentence immediately above the decision brief** so the engineer can challenge the classification in-band.\n\n### Rule: Decision brief structure\n\nA decision brief has two tiers.\n\n**Base tier (default for every load-bearing decision)**: Three sentences — (1) **Concrete element** — names the specific artifact, section, or mechanism where the decision lands; (2) **Decision setup** — frames the choice in outcome terms, not implementation jargon; (3) **Conditional misconception** — names the plausible wrong path and its failure mode. The brief precedes the question. Teach before asking.\n\n**Escalation tier (override that fires for load-bearing adversarial-review dispositions)**: Same three-part spine expanded to full prose. Fires when a load-bearing adversarial-review disposition is being surfaced to the owner (keyed on the load-bearing classification, known before the question fires for that finding — consistent with the firing-position rule in the `## Applying the gate to adversarial-review dispositions` section below — not the post-hoc `finding_dispositions.disposition == escalate` enum value). The escalation tier positively covers load-bearing dispositions regardless of whether their final outcome is `incorporate`, `dismiss`, or `escalate`. Three required elements: (1) **Concrete element → current state**: what today actually does, with evidence (file:line where code exists; or cite the specific artifact + section for doc-level conflicts; or cite the originating prosecution `finding_id` + `pass` from the merged ledger for genuinely greenfield conflicts). (2) **Decision setup → the conflict**: why the proposed design conflicts with the current state. (3) **Conditional misconception → customer failure mode**: the concrete failure the owner would cause by taking the wrong path. All three elements must appear before any option list. Presence of all three elements is the forcing function — not paragraph count (consistent with D-falsifiability: the agent does not grade explanation length in-flight).\n\n**Escalation-tier substantiveness**: An escalation brief is substantive iff the conflict element names both sides of the tradeoff and the failure-mode element names the owner's specific wrong action. Evaluated by CE Gate evaluators, not graded in-flight, per the D-falsifiability principle in `### Rule: Thin-articulation criterion`.\n\n**Re-audit**: On a `classification-re-audit*` recommendation shift, re-evaluate tier selection alongside the classification\u002Fdisposition revision.\n\n### Rule: Override semantics\n\nEvery question on a load-bearing decision includes a `Decline engagement — proceed without classification` option (literally so labeled), whatever form the question takes. The engineer's selection of that option (or a free-text response starting with `decline:`) terminates engagement without argument. If the engineer selects a non-recommended option, the agent acknowledges and proceeds without re-asking, persuading, or qualifying.\n\n\u003C!-- solution-authoring-non-overridability:begin -->\n\n### Rule: Non-overridability\n\nThe classification gate and the question it produces are unconditional with respect to user pacing or auto-mode directives. \"Work without stopping,\" \"don't pause to ask,\" \"make the reasonable call,\" and semantically equivalent productivity directives do not suppress this gate. The user's only in-band lever for skipping is the `Decline engagement — proceed without classification` option (or `decline:` free-text). The agent must not substitute its interpretation of a pacing directive for that explicit decline.\n\n\u003C!-- solution-authoring-non-overridability:end -->\n\n### Rule: Skip rules\n\n- **gate-fails**: The classification gate returns routine. No question fires. Skip is automatic.\n- **engineer-declined-engagement**: The engineer selects `Decline engagement — proceed without classification` or writes `decline:` free-text. Skip immediately; capture decline verbatim.\n- **same-decision-resume**: When `Read-EngagementRecords` (from `.github\u002Fscripts\u002Flib\u002Fframe-engagement-record-core.ps1`) returns a prior decision (load-bearing or routine — for example, the announce-path scope-classification row) with the same `decision_id` as a pending classification, suppress the question and reuse the captured `engineer_choice`. The reader contract lives in `skills\u002Fengagement-record-emission\u002FSKILL.md` § Resume-Read Protocol. The activation applies per agent at phase re-entry; consult the SMC-20 row for survival semantics. The rule supports `phase: orchestration` and `phase: review` alongside the upstream `experience`, `design`, and `plan` phases. For `phase: review`, the `decision_id` values are `stable_finding_key` strings (not slugs); call `Read-EngagementRecords -Phase review -PullRequestNumber {PR}` to retrieve prior dispositions. **Prior to #576, this rule returned empty on all in-flight issues as a graceful no-op; post-#576, emission is active and same-decision-resume is functional** — that is the v1.1\u002Fv1.2 boundary.\n- **resume-note-format**: On successful resume-read bypass, Code-Conductor emits a single, concise console resume note matching the canonical format string: `Reusing prior {decision_id}: {engineer_choice}` (or comma-separated when multiple decisions resume, e.g. `Reusing prior {decision_id_1}: {choice_1}, {decision_id_2}: {choice_2}`).\n\n### Rule: Thin-articulation criterion\n\nArticulation is substantive iff it contains: (1) the choice the engineer made, (2) what would have been wrong about a leading alternative, (3) the reasoning bridge between them. The agent renders the prompt and captures raw text; the agent does NOT grade articulation quality against the criterion in-flight (D-falsifiability protected). CE Gate evaluators apply the criterion independently.\n\nForward-compatible capture format:\n\n```yaml\narticulation_captures:\n  schema_version: 1\n  entries:\n    - decision_id: \u003Cid>\n      articulation_text: |\n        \u003Cverbatim engineer text>\n      capture_phase: experience | design | plan\n      capture_session: manual-ce-gate-v0\n```\n\n**Glossary and harmonization note**: The YAML field `teaching_paragraph_excerpt` is preserved from the locked #571 engagement-record marker payload (`\u003C!-- engagement-record-design-571 -->`). This skill uses \"decision brief\" in prose; `decision_brief` and `teaching_paragraph_excerpt` refer to the same concept and both remain valid.\n\n## Applying the gate to adversarial-review dispositions\n\nFor each adversarial-review finding that the calling workflow must disposition, run the classification gate against the action the maintainer would take for that finding, not against the review pass as a whole. Use the Code-Critic Finding Categories contract for the input identity: `id` values are sequential `F1 | F2 | F3 | ...` labels within the review cycle, and `pass` is `1 | 2 | 3 | 4` for the finding origin that produced the disposition record. The disposition enum is `incorporate | dismiss | escalate`; the classification enum is `load-bearing | routine`. If a finding is routine, record the disposition without asking. If a finding is load-bearing, render the normal `audit_rationale`, decision brief, and question before recording the disposition.\n\nFor adversarial-review findings, the tier is keyed on the load-bearing classification (known before the question fires per the above ordering). Load-bearing adversarial-review dispositions use the **escalation tier**; all other load-bearing decisions (upstream content-authoring, orchestration scope-classification, and any non-adversarial surface) use the **base tier**.\n\nFiring-position rule: for an atomic multi-stage adapter declaring `integrity-contract.atomic: true` and more than one `pipeline-stages` entry, the classification gate fires only on terminal-stage sustained findings after the terminal stage. For adapters whose terminal stage is judge, those are judge-sustained findings after judge; for adapters whose terminal stage is defense, those are defense-sustained findings after defense. The gate does not fire on prosecution output or defense dialogue inside the atomic window. CLAUDE.md Engagement-gate non-overridability D3 still applies: once the terminal-stage sustained input exists, the gate fires unconditionally; only the firing position changes for atomic multi-stage adapters. For the prosecution-only `design-challenge` adapter, the gate fires on convergence-sustained findings per `skills\u002Fdesign-exploration\u002FSKILL.md` section `Convergence Filter` (#785) — the raw merged ledger passes through the convergence filter first, and only the kept subset enters the classification gate.\n\nThe marker payload schema is the `finding_dispositions:` block validated by `.github\u002Fscripts\u002FTests\u002Fdesign-disposition-audit.Tests.ps1`: `schema_version: 1`, non-empty `passes_run` as a subset of `[1, 2, 3, 4]`, and `entries[]` carrying `finding_id`, `pass`, `disposition`, `classification`, and `disposition_rationale`. Routine entries require `artifact_citation` when the routine classification rests on an inherited artifact settling the finding; routine entries classified for another non-load-bearing reason do not require a citation. Multi-pass concurrence may include `also_flagged_by` with secondary pass ids.\n\nThe `passes_run`\u002F`pass` vocabulary here is distinct from the `design-challenge` adapter's `prosecution-passes` field: `prosecution-passes` stays `[1, 2, 3]` and names the three finder dispatches the adapter runs (unchanged), while `passes_run`\u002F`pass` is the disposition schema's origin-tracking enum, which now additionally allows pass 4 to record findings whose origin is the convergence cold-read rather than a prosecution finder dispatch — the two vocabularies must not be conflated.\n\n`disposition_rationale` explains why this specific finding received this specific `incorporate`, `dismiss`, or `escalate` outcome. It is not the v0 `audit_rationale`: `audit_rationale` proves why a decision is load-bearing before asking; `disposition_rationale` persists the final per-finding outcome after the gate decision, including routine outcomes that never asked the maintainer.\n\nThe re-audit handler is symmetric. If a load-bearing disposition is challenged with a plausible artifact citation, rerun Leg 2 and, when the citation holds, emit `trigger: classification-re-audit` and revise the finding to routine. If a routine disposition is challenged with evidence that no inherited artifact actually settles the action, rerun all three legs and, when they hold, emit `trigger: classification-re-audit-routine` and revise the finding to load-bearing before asking.\n\nRe-audit timing: under an atomic multi-stage adapter, re-audit triggers apply to the terminal-stage sustained findings set, which is the input to the terminal-stage classification gate. For judge-terminal adapters, this remains the judge-sustained findings set after judge; for defense-terminal adapters, this is the defense-sustained findings set after defense. For the prosecution-only `design-challenge` adapter, re-audit applies to merged-ledger findings as today. Re-audit cannot retroactively invalidate a terminal-stage ruling or report; it can only revise the maintainer disposition classification\u002Fdecision.\n\nMap maintainer input to recommendation-shift triggers as follows: new facts or changed upstream content after the initial classification maps to `new-evidence`; direct disagreement with the recommended disposition or option maps to `engineer-pushback`; a claim that a load-bearing finding is already answered by an inherited artifact maps to `classification-re-audit`; a claim that a routine finding is not actually answered by inherited content maps to `classification-re-audit-routine`. If a maintainer message could fit more than one pattern or does not identify the challenged finding, ask one clarifying question before changing classification.\nYAML marker invariant: `finding_dispositions:` lives only on the `\u003C!-- design-phase-complete-{ID} -->` marker body, never on `\u003C!-- credit-input-{port}-{ID} -->` markers. Credit-input markers remain limited to frame credit deferred-emission payloads. The `finding_dispositions:` block lives only on `\u003C!-- design-phase-complete-{ID} -->` markers (SMC-19) and is independent of `\u003C!-- engagement-record-{phase}-{ID} -->` markers (SMC-20). The two payloads serve distinct audits — finding-dispositions tracks per-finding incorporate\u002Fdismiss outcomes; engagement-records track load-bearing classification with cross-session resume semantics via `same-decision-resume`. Do not mirror or merge content between them.\n\nWorked exemplar:\n\n```yaml\nfinding_dispositions:\n  schema_version: 1\n  passes_run: [1, 2, 3]\n  entries:\n    - finding_id: F1\n      pass: 1\n      disposition: dismiss\n      classification: routine\n      disposition_rationale: \"Dismissed because the cited acceptance criterion already requires the behavior the finding asks to add; no maintainer choice remains.\"\n      artifact_citation: \"Documents\u002FDesign\u002Fsession-memory-contract.md#durable-marker-precedence\"\n    - finding_id: F2\n      pass: 2\n      disposition: incorporate\n      classification: routine\n      disposition_rationale: \"Incorporated as a wording correction because the existing named-decision row already settles the outcome and only the citation text changes.\"\n      artifact_citation: \"skills\u002Fsolution-authoring\u002FSKILL.md#rule-classification-gate\"\n    - finding_id: F3\n      pass: 1\n      disposition: escalate\n      classification: load-bearing\n      disposition_rationale: \"Escalated because choosing whether to reject or preserve the review finding changes the durable design contract and no inherited artifact settles that tradeoff.\"\n      also_flagged_by: [2, 3]\n```\n\nThe exemplar rationales name the disposition outcome and why it follows from the finding evidence. They intentionally do not repeat the v0 `audit_rationale` tone, which is reserved for proving that a question is warranted before the gate fires.\n\n### Template: Decision brief\n\nRender as a block-quoted paragraph immediately after the `audit_rationale` sentence:\n\n> **Decision brief — {decision_id}**: {Concrete element sentence.} {Decision setup sentence in outcome terms.} {Conditional misconception sentence naming the plausible wrong path and its failure mode.}\n\n**Exemplar** (D-load-directive, from #571 R1+R2):\n\n_Audit rationale: The load-order direction for solution-authoring vs upstream-onboarding is not settled in any prior phase comment or umbrella decision — no named-decision row pins this ordering, so the non-inheritance leg holds._\n\n> **Decision brief — D-load-directive**: The `## Process` section of each agent body is where load-order instructions land. The decision is whether solution-authoring fires before upstream-onboarding or after — this determines whether the engagement gate runs before the brief surfaces inherited decisions. If upstream-onboarding fired first, the gate would intercept questions about content the engineer just read from someone else's output — manufacturing load-bearing signal on settled content.\n\n### Template: question shape\n\nPresent options with strong examples for ALL options — not just the recommended one. Option presentation asymmetry is itself a form of cognitive surrender (the engineer cannot compare without examples).\n\nInclude `Decline engagement — proceed without classification` as the last option on every load-bearing question.\n\n**Exemplar** (D-load-directive, from #571 R1+R2):\n\n- **Option 1 (Recommended)** — solution-authoring first: Classification runs before the brief surfaces prior decisions. Example: during `\u002Fdesign`, the inheritance audit evaluates the decision before any prior-phase context is rendered, so the falsifier operates on genuinely unanchored decisions only.\n- **Option 2** — upstream-onboarding first: The brief surfaces inherited decisions first, then solution-authoring fires. Example: the engineer sees inherited answers before being asked to classify them — but the gate would then intercept settled content and produce false load-bearing signal.\n- **Decline engagement — proceed without classification**\n\n### Template: Free-text option treatment\n\nWhen the engineer overrides via free-text or selects a non-recommended option: (1) accept without argument or re-asking; (2) if the choice materially differs from the recommended option, emit a `**Recommendation shift**` line; (3) proceed with the chosen direction.\n\n**Exemplar** (S1-negative correction, from #571 R1+R2 — engineer pushes back on mis-classification):\n\nEngineer: \"Gap-visibility was already answered in the umbrella.\"\nAgent re-audits, finds citation in #571 D-customer section, reclassifies, and emits:\n\n`**Recommendation shift** — D-gap-visibility: previously load-bearing (non-inheritance claimed); now routine (citation found in #571 D-customer); trigger: classification-re-audit; reason: the decision was answerable from inherited content and the artifact-citation falsifier applies.`\n\n### Template: Recommendation shift\n\nEmit immediately before the revised recommendation:\n\n> `**Recommendation shift** — {decision_id}: previously {old_recommendation}; now {new_recommendation}; trigger: {engineer-pushback | new-evidence | classification-re-audit | classification-re-audit-routine}; reason: {one-sentence reason}.`\n\n**Exemplar** (D-gap-visibility, from #571 R1+R2 — inline token, then phase-exit YAML aggregate):\n\n`**Recommendation shift** — D-gap-visibility: previously load-bearing; now routine; trigger: classification-re-audit; reason: the decision was answerable from inherited content.`\n\nAt phase exit, emit a YAML aggregate of all in-phase shifts:\n\n```yaml\nrecommendation_shifts:\n  schema_version: 1\n  entries:\n    - decision_id: \u003Cid>\n      previous: \u003Cold_recommendation>\n      revised: \u003Cnew_recommendation>\n      trigger: engineer-pushback | new-evidence | classification-re-audit | classification-re-audit-routine\n      reason: \u003Cone-sentence>\n      capture_phase: experience | design | plan\n```\n\n### Template: Articulation prompt\n\nRender at phase exit after all load-bearing decisions are locked:\n\n> For each locked load-bearing decision, describe in 2–4 sentences: the choice you made, what would have been wrong about a leading alternative, and why the bridge between them held for this case. Raw text is captured in manual CE Gate evidence; evaluators apply the three-part criterion independently.\n\n**Exemplar** (D-load-directive, from #571 R1+R2):\n\n> \"I chose solution-authoring first because upstream-onboarding surfaces prior decisions that have already been answered — if the engagement gate ran after, it would fire on settled content. If upstream-onboarding had run first, the gate would have intercepted the brief's inherited decisions and manufactured false load-bearing signal. The order had to put classification before context so the falsifier could operate on genuinely unanchored decisions only.\"\n\n## Related Guidance\n\n- Load `upstream-onboarding` after this skill per the D-load-directive declared in each agent body dispatcher.\n- Load `bdd-scenarios` when scenario IDs and G\u002FW\u002FT formatting are needed for CE Gate scenarios.\n\n## Gotchas\n\n| Trigger                                              | Gotcha                                                                                                | Fix                                                                                                       |\n| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |\n| Treating a pacing directive as an engagement decline | The agent silently skips a load-bearing classification gate even though no explicit decline was given | Fire the question unless the engineer selects the explicit decline option or writes `decline:` |\n| A routine decision is treated as load-bearing        | The agent asks for engagement on content already settled by an inherited artifact                     | Re-audit Leg 2 against the citation and emit the appropriate recommendation shift                         |\n| A load-bearing decision is treated as routine        | The durable artifact changes without surfacing the maintainer choice                                  | Rerun all three gate legs and ask before recording the final decision                                     |\n\n## L2 Reconciliation Gate (Review Path)\n\nAfter implementation steps complete and before the CE Gate, run the warn-only L2 reconciliation validator to produce a review-time ledger:\n\n```powershell\n$result = & .github\u002Fscripts\u002Flib\u002Fgate-reconciliation-core.ps1 -IssueNumber {ID}\nif ($result.status -eq 'findings') {\n    # Surface warn-only findings in the review step; do not block PR creation\n    $result.findings | ForEach-Object { Write-Warning \"Gate finding: $($_.decision_id) — $($_.issue)\" }\n}\n```\n\nThe validator is **warn-only**: it surfaces missed-gate signals for adversarial review and the CE Gate, but does NOT block `gh issue comment` marker writes or PR creation. Enforcement is **detection-at-review** — caught before merge, within the `d-intent-strictness` detection+recovery envelope.\n\nFor Code-Conductor, invoke this validator as part of the review-phase pre-PR checks, after the `standard` adversarial review pipeline completes.\n\n## L0 Gate Token (Classification-Decision Self-Report)\n\nAt each gate decision point, the agent MUST emit a classification-decision token to the session event log before putting the decision to the engineer (or before recording a lawful-skip outcome). The token schema is defined in `skills\u002Fsolution-authoring\u002Fschemas\u002Fgate-decision-token.schema.json`.\n\n**Emit contract:**\n\n- `decision_id` MUST match the `decision_id` used in the engagement-record or `finding_id` used in `finding_dispositions:`.\n- `outcome` MUST be one of `asked | gate-fails | declined | same-decision-resume | greenfield-defer`.\n- `window_position` MUST reflect the firing position per the Firing-position rule: `pre-ask` for upstream questions (also covers a determined-outcome announcement at that same pre-dispatch firing position — no question fired, but the same point in the pipeline; see the schema's `window_position` description), `disposition` for adversarial finding dispositions (#615 surface), `judge-merge` for plan judge-merge dispositions (#605 surface), `review-disposition` for PR review-verdict disposition gate (#655 surface).\n- `timestamp` MUST be the ISO-8601 UTC time of emission.\n- `issue_number` MUST be the GitHub issue number this decision belongs to — except for `window_position: review-disposition` tokens, which must carry `pull_request_number` instead (and omit `issue_number`). See `skills\u002Fsolution-authoring\u002Fschemas\u002Fgate-decision-token.schema.json` for the conditional schema.\n- `session_key` is optional and names the token's own log file. Derive it with `Resolve-GateSessionKey` (`skills\u002Fsolution-authoring\u002Fscripts\u002FResolve-GateSessionKey.ps1`).\n\n**Lawful-skip tokens** (`outcome ≠ asked`) MUST still be emitted — they are the discriminator that distinguishes a lawful skip from an illegitimate silent skip. A missing token for a load-bearing decision that also has no recorded decision is the signal the L2 validator and L3 Code-Critic use to flag a potential never-surfaced skip.\n\n**Event log location:** Append tokens to `\u002Fmemories\u002Fsession\u002Fgate-events-{session_key}.jsonl` (one JSON object per line), deriving `{session_key}` with `Resolve-GateSessionKey` (`skills\u002Fsolution-authoring\u002Fscripts\u002FResolve-GateSessionKey.ps1`). Fallback: `.copilot-tracking\u002Fgate-events.jsonl` when session memory is unavailable. Agents are the only producer of this stream; the hook-driven L1 producer was retired in issue #1003.\n\n**Parity:** Token emission applies identically on Claude and Copilot. No platform-specific divergence in the token contract.\n\n**The `phase` enum is closed on purpose, and open-for-work maps onto it rather than extending it.** Every checkpoint the open-for-work conversation runs — the worth-it doors, the affirmation gate, and brief approval on the routine arm — emits `phase: experience` (#957 D5). That conversation *is* the experience-replacement for standalone work, so the mapping is the honest one, and it keeps every existing consumer working: a token carrying a sixth enum value fails schema validation before it ever reaches `gate-reconciliation-core.ps1`, and that script filters on the five values above. Do not \"fix\" the mapping by adding an open-for-work phase; the per-checkpoint field table is in `skills\u002Fopen-for-work\u002FSKILL.md` § Gate-decision tokens.\n\n### Token emit example (load-bearing, asked)\n\n```json\n{\n  \"decision_id\": \"d-load-directive\",\n  \"phase\": \"design\",\n  \"outcome\": \"asked\",\n  \"classification\": \"load-bearing\",\n  \"window_position\": \"pre-ask\",\n  \"timestamp\": \"2026-06-02T00:00:00Z\",\n  \"session_key\": \"issue-617\",\n  \"issue_number\": 617\n}\n```\n\n### Token emit example (lawful skip — same-decision-resume)\n\n```json\n{\n  \"decision_id\": \"d-load-directive\",\n  \"phase\": \"design\",\n  \"outcome\": \"same-decision-resume\",\n  \"classification\": \"load-bearing\",\n  \"window_position\": \"pre-ask\",\n  \"timestamp\": \"2026-06-02T00:00:00Z\",\n  \"skip_reason\": \"Prior decision reused from engagement-record-design-617\",\n  \"issue_number\": 617\n}\n```\n\n## Frame Ports Filled By This Skill\n\nThis skill is **supporting methodology** — it declares no `provides:` field and fills no frame port. Classification per `Documents\u002FDesign\u002Fframe-architecture.md` Adapter Model: the credit-author test confirms this skill adds no frame credit row.\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fsolution-authoring",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill solution-authoring",{"tool":51,"command":52},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill solution-authoring",{"tool":54,"command":55},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill solution-authoring","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsolution-authoring\u002FSKILL.md",true,[59,65,69,73,77],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"platforms\u002Fclaude.md","REFERENCE","参考文档",1553,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsolution-authoring\u002Fplatforms\u002Fclaude.md",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"platforms\u002Fcopilot.md",1526,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsolution-authoring\u002Fplatforms\u002Fcopilot.md",{"path":70,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":71,"sourceHtmlUrl":72},"schemas\u002Fgate-decision-token.schema.json",4082,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsolution-authoring\u002Fschemas\u002Fgate-decision-token.schema.json",{"path":74,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":75,"sourceHtmlUrl":76},"schemas\u002Freview-dispositions.schema.json",8050,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsolution-authoring\u002Fschemas\u002Freview-dispositions.schema.json",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"scripts\u002FResolve-GateSessionKey.ps1","SCRIPT","脚本",4313,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fsolution-authoring\u002Fscripts\u002FResolve-GateSessionKey.ps1",[84,118,142,154,180,201],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":98,"publishedAt":33},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing","Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[90,95],{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":96,"categoryName":97,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000009","前端开发",[99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,31],"testing","webapp testing","webapp","canvas","tdd","workflow","playwright","test","web","react","component","debugging","development","browser","ci","execution","e2e","game","coverage",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":33},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[125,126,19,127,128,129,130,131,132,133,134,135,113,136,137,138,139,31,140,141],"verification","verification before completion","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":33},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[149,27,150,19,151,21,22,23,133,152,114,31,153],"validation","validation methodology","triage","flow","dispatch",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":168,"publishedAt":33},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[160,163],{"categoryNo":161,"categoryName":162,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":164,"categoryName":165,"taxonomyType":166,"taxonomyTypeDesc":167},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[169,170,19,20,171,129,172,130,133,173,25,174,175,176,177,138,139,178,179,31],"onboarding","upstream onboarding","research","standards check","protocol","boundary","designer","subagent","planner","user","session",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":194,"publishedAt":33},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[186,187,188,191],{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},{"categoryNo":96,"categoryName":97,"taxonomyType":93,"taxonomyTypeDesc":94},{"categoryNo":189,"categoryName":190,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":192,"categoryName":193,"taxonomyType":166,"taxonomyTypeDesc":167},"01JBSEEDCAT000000000000032","设计师",[99,195,196,197,198,199,102,104,105,106,108,109,110,111,112,200,115,116,31,101],"ui","ui testing","frontend","design","writing","testing patterns",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":209,"publishedAt":33},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[207,208],{"categoryNo":96,"categoryName":97,"taxonomyType":93,"taxonomyTypeDesc":94},{"categoryNo":192,"categoryName":193,"taxonomyType":166,"taxonomyTypeDesc":167},[195,210,197,198,19,104,211,133,212,213,214,215,216,138,217,218,31,219],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]