[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3B7DAYK5KMDJCG98BE0BA":3,"skill-same:01M6K3B7DAYK5KMDJCG98BE0BA":73},{"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":18,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":72},"01M6K3B7DAYK5KMDJCG98BE0BA","conflict-check",null,"Use only within active engineer\u002Fconduct DECIDE after accepted stories and before plan, or when that workflow explicitly rechecks remediated stories. Detects story interactions; do not invoke for Git conflicts, merge conflicts, or general requirements discussion.","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\u002Fconflict-check\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"check","conflict check","conflict","do","when","invoke","gating","stories","conduct","for","claims","true","requirements","active","workflow","conflicts","general","merge conflicts","git conflicts","engineer","only","use","decide","plan","verify","2026-11-10 10:12:30",false,"---\nname: conflict-check\nimplicit_invocation: required\ndescription: \"Use only within active engineer\u002Fconduct DECIDE after accepted stories and before plan, or when that workflow explicitly rechecks remediated stories. Detects story interactions; do not invoke for Git conflicts, merge conflicts, or general requirements discussion.\"\nenforcement: gating\nphase: decide\nstandalone: true\nrequires: [verify-claims]\n---\n\n## Purpose\n\nDetects when new stories contradict, overlap, or create impossible states with existing ones.\nProvides guided resolution so conflicts are resolved before implementation begins — preventing\nthe expensive discovery of contradictions during or after coding.\n\n**Correctness gate:** \"these two stories conflict\" (or \"clean\") is a judgment call. Per the\n`\u002Fverify-claims` protocol, ground each asserted conflict in the specific contradicting text with a\nconfidence %, and do not declare a clean pass on the *assumption* that two stories are compatible\nwhen their interaction was never actually reasoned through — an unexamined pair is not a verified\nclean pass.\n\n## Practices\n\n### 1. Inventory\n\nLoad ALL stories and specs:\n- All files in `.docs\u002Fstories\u002F` (existing + newly written)\n- Active specs from `.docs\u002Fspecs\u002F` (for design-level context)\n- Approved ADRs from `.docs\u002Fdecisions\u002F` (as selected below)\n- Previous conflict reports from `.docs\u002Fconflicts\u002F` (to check for recurring patterns)\n\nThe ADR corpus is always repo-wide: load all approved ADRs, narrow the corpus to ADRs whose\nsubject overlaps the current spec's stories, and record both the examined and narrowed-out ADRs in\nthe conflict report. Exclude an ADR only when it is unambiguously fully superseded; retain an ADR\nwith a partial or ambiguous supersession because its remaining decision may still conflict with a\nstory.\n\n### 1b. As-Built Story Handling\n\nWhen stories have `[AS-BUILT]` markers (from `\u002Fbootstrap`), they document **existing working\ncode**. Overlap between as-built stories is expected — the same endpoint may appear in multiple\nstories describing different aspects of the same feature.\n\n**Scoring adjustment for as-built pairs:**\n- Two `[AS-BUILT]` stories sharing an endpoint → **not a conflict** unless they assert\n  contradictory behavior. Same endpoint, same behavior, different story angle = normal.\n- `[AS-BUILT]` vs new story → check normally. New work may genuinely conflict with existing behavior.\n- Two new stories → check normally.\n\nThis prevents false positives when bootstrapping an existing codebase where stories naturally\noverlap because they were reverse-engineered from the same working system.\n\n### 2. Conflict Scan\n\nCheck each pair of stories for these conflict types:\n\nAlso compare each selected ADR against every story whose behavior, entity, field, resource, or\ngate it addresses. Apply the same six conflict types and the same two-directional heuristic to\nan ADR-versus-story pair; ADRs are a comparison party, not a seventh conflict type.\n\n#### Contradiction\nStories that directly oppose each other.\n- Story A: \"Users must authenticate to view orders\"\n- Story B: \"Anonymous users can browse the order catalog\"\n- Conflict if both reference the same resource\u002Fendpoint.\n\n#### Behavioral Overlap\nStories that modify the same entity, flow, or endpoint in incompatible ways.\n- Story A: \"Admins can soft-delete users\" (sets `deleted_at`)\n- Story B: \"Users with activity in the last 30 days cannot be deleted\"\n- Overlap: What happens when an admin tries to soft-delete an active user?\n\n#### State Conflict\nCombined stories create impossible or ambiguous system states.\n- Story A: \"Orders are immutable after confirmation\"\n- Story B: \"Customer support can edit confirmed order addresses\"\n- Conflict: An order cannot be both immutable and editable.\n\n#### Resource Contention\nStories assume exclusive access to shared resources.\n- Story A: \"The `status` column tracks order lifecycle\"\n- Story B: \"The `status` column tracks payment state\"\n- Conflict: Same column, different semantic meanings.\n\n#### Sequencing Conflict\nStories that each assume they run first, or create circular dependencies.\n- Story A: \"User profile must exist before creating an order\"\n- Story B: \"First order creation triggers profile setup\"\n- Conflict: Circular dependency on which comes first.\n\n#### Oscillating Conflict\nTwo requirements that are each individually satisfiable but **mutually exclusive in\npractice**, so satisfying one re-breaks the other. This is the costliest conflict type\nand the hardest to see, because nothing looks wrong at authoring time — both stories\nread as reasonable, and each is implementable on its own.\n\n- Story A: \"Every build change has current aggregate test-suite evidence before SHIP\"\n- Story B: \"The test-suite gate may reuse current aggregate evidence without rerunning it\"\n- Conflict: a build that requires a fresh rerun can never reuse current evidence. An\n  implementation satisfying A fails B's gate; the fix for B then fails A's gate.\n\nThe damage is not a failed build — it is a **loop that does not terminate on its own**.\nGate A kicks the work back, the fix trips gate B, gate B kicks it back, and each lap\ncosts a full agent session. A static contradiction announces itself the first time\nsomeone tries to write the code; an oscillation only announces itself as unexplained\nrework, several steps downstream, where nobody is looking at the stories any more.\n\n**Detection heuristic:** for each pair of stories touching the same behavior, entity,\nfield, or gate, ask **\"if I fully satisfy A, does B still hold?\"** — then ask it in the\nother direction. Two \"no\" answers is an oscillation, however sensible each story reads\nalone. One \"no\" is an ordinary contradiction or overlap; classify it as those instead.\n\nOscillations are almost always **blocking**, even when each story looks harmless,\nbecause there is no implementation that satisfies both and no amount of rework will\nfind one. Resolving it requires changing what is being asked for, not how it is built —\nwhich usually means the root lives upstream (see 5c) in the PRD's FRs or in the design,\nnot in story phrasing.\n\n**Layer ownership.** Story↔story pairs belong to `\u002Fconflict-check`. Cross-layer and task versus task\npairs belong to plan review at Medium and Large tier, and to the plan's §7b at Small tier.\n`\u002Fconflict-check` runs before `\u002Fplan` and cannot see tasks.\n\n### 3. Generate Conflict Report\n\nFor each conflict found:\n\n```markdown\n## Conflict: [Short description]\n\n**Stories involved:** [Story A title] vs [Story B title]\n**Files:** [.docs\u002Fstories\u002Ffile-a.md] vs [.docs\u002Fstories\u002Ffile-b.md]\n**Type:** contradiction | overlap | state-conflict | resource-contention | sequencing | oscillating\n**Severity:** blocking | degrading\n\n**Description:**\nWhat specifically conflicts and why both cannot be true simultaneously.\n\n**Resolution Options:**\n1. [Least disruptive option — modify one story to accommodate the other]\n2. [Moderate option — modify both stories to meet in the middle]\n3. [Most disruptive option — introduce new mediating behavior]\n\n**Recommendation:** Option [N] because [rationale].\n```\n\nFor an ADR-versus-story conflict, use the same report format and additionally include this\ngrounding block. `ADR filename stem` is the ADR filename without `.md`; `Story ID` is the story's\ndeclared identifier.\n\n```markdown\n**ADR filename stem:** adr-YYYY-MM-DD-decision-slug\n**Story ID:** STORY-N\n**ADR opposing sentence (verbatim):** \"\u003Cexact sentence from the ADR>\"\n**Story opposing sentence (verbatim):** \"\u003Cexact sentence from the story>\"\n```\n\nRecord an ADR-versus-story conflict only when both opposing sentences are present and demonstrate\nthe incompatibility. An ungrounded suspicion is an assumption, not a recorded conflict; verify it\nagainst the ADR and story text or report it as an assumption under the `\u002Fverify-claims` protocol.\nWhen the opposing passage spans multiple sentences, quote the needed sentences verbatim in their\noriginal order and put `[…]` at every omitted span. Do not silently truncate, join, or reword the\npassage: the report must make both the quoted evidence and every omission explicit.\n\nWorked ADR-versus-story report:\n\n```markdown\n## Conflict: Session-based access contradicts token-only API story\n\n**Stories involved:** Token-only API access vs ADR: Browser session authentication\n**Files:** [.docs\u002Fstories\u002Fapi-access.md] vs [.docs\u002Fdecisions\u002Fadr-2026-08-10-browser-session-authentication.md]\n**Type:** contradiction\n**Severity:** blocking\n**ADR filename stem:** adr-2026-08-10-browser-session-authentication\n**Story ID:** STORY-12\n**ADR opposing sentence (verbatim):** \"The API authenticates browser requests with server-side sessions.\"\n**Story opposing sentence (verbatim):** \"The API accepts only bearer tokens and does not create sessions.\"\n\n**Description:** The same API requests cannot require server-side sessions while accepting only\nbearer tokens and creating no sessions.\n\n**Resolution Options:**\n1. Amend STORY-12 to use the ADR's session mechanism.\n2. Define an explicit session-and-token compatibility boundary.\n3. Create a superseding ADR that selects token-only authentication.\n\n**Recommendation:** Option 1 because it preserves the approved architectural decision.\n```\n\n**Severity definitions:**\n- **blocking** — Cannot proceed to implementation. Stories are mutually exclusive.\n- **degrading** — Can proceed with a known compromise. Both stories work but with reduced functionality in the overlap area.\n\n### 4. Guided Resolution\n\nPresent all conflicts to the user at once, grouped by severity (blocking first).\n\nFor each conflict:\n1. Explain what conflicts and why\n2. Present resolution options ranked by impact (least disruptive first)\n3. Include a recommendation with rationale\n4. User selects a resolution\n\nAfter user selects:\n1. Update the affected stories in `.docs\u002Fstories\u002F` to reflect the resolution by replacing\n   superseded assertions in place; leave no amendment record in a story artifact\n2. Save the conflict report to `.docs\u002Fconflicts\u002FYYYY-MM-DD-\u003Cdescription>.md`\n\n**Accepted-artifact amendment:** When the resolution falsifies an assertion in an accepted\nDECIDE artifact, perform the amendment during the DECIDE pass in that artifact — never defer it\nas a later BUILD task. Story artifacts under `.docs\u002Fstories\u002F` are the narrow exception: replace\nthe superseded assertion in place and leave no amendment record. For all other accepted DECIDE\nartifacts already on the base branch, add this note beside the original assertion:\n\n```markdown\n> **Amended YYYY-MM-DD by #NNN:** \u003Cwhat the assertion now says, and why>\n```\n\nFor these non-story artifacts, the amendment is additive: the original assertion remains; do not\nrewrite or delete it, and create no separate record. This makes the correction part of the\nspec-branch baseline before BUILD starts.\n\nAn accepted DECIDE artifact absent from the base branch is a draft: revise it in place, remove\nsuperseded text, and add no amendment note or revision log.\n\n**Conflict reports are overwritten on re-run.** If a re-check after resolution finds new or\nchanged conflicts, overwrite the existing conflict report file. The report reflects the CURRENT\nstate — git has the history.\n\n**Conflict resolutions that change architectural decisions create new ADRs.** Never overwrite\nan existing ADR. Instead:\n1. Write a new ADR in `.docs\u002Fdecisions\u002F` (named `adr-YYYY-MM-DD-\u003Ckebab-slug>.md`, no\n   sequential numbers) that supersedes the old one\n2. Update the old ADR's status to `Superseded by \u003Cnew-adr-slug>` (the new ADR's filename stem)\n3. The new ADR references the old one and explains why the decision changed\n\nExample: If conflict resolution changes the API authentication approach from\n`adr-2026-05-01-api-auth-strategy`, create `adr-2026-06-29-api-auth-token-exchange` with the new\napproach and mark the old one as superseded.\n\n### 5. Re-Check\n\nAfter all resolutions are applied, re-run the full conflict check.\n\n**GATE: Loop until the check passes clean (zero blocking conflicts).**\n\nDegrading conflicts may remain if the user explicitly accepts the compromise.\n\n### 5c. Route a Blocking Conflict by Root Cause (kickback)\n\nA story-vs-story conflict is usually a *symptom*; fix it where the contradiction is rooted, not\nalways in the stories. Classify each blocking conflict's root and route the kickback to the right\nupstream gate (`prd` and `architecture_review` are kickback targets; the recovery\u002Fback-navigation\nmenu lists them):\n\n- **Contradictory product requirements (FRs)** → kick back to **`prd`** (product track). The two\n  stories conflict because the PRD's FRs themselves conflict; the PRD must be reconciled first.\n- **Incompatible design \u002F ADR** → kick back to **`architecture`** (architecture-review). The conflict\n  stems from the chosen design; architecture-review re-opens in *amendment* mode to resolve the\n  specific structural gap, then stories re-derive.\n- **Pure story-phrasing overlap** → resolve in **`stories`** (the default — Section 4).\n\nOnly route up when the root genuinely lives upstream; a phrasing nit stays in stories. In an\ninteractive run, surface the root + target and navigate back to it. In an unattended\u002Fdaemon run a\nblocking conflict HALTs for a human (no silent pass).\n\n### 6. Clean Pass\n\nWhen no blocking conflicts remain:\n- Report \"Conflict check passed\" with summary\n- Note any accepted degrading conflicts\n- Suggest invoking the `plan` skill\n\n### 7. Signal Review Requirement\n\nBefore exiting, decide whether the conductor should prompt the user to review\nthe conflict report(s). Review mode for this step is **conditional** — auto-approved\nunless you write a marker file.\n\nWrite `.pipeline\u002Freview-required-conflict_check` (any content; the file's\nexistence is the signal) if ANY of the following is true:\n\n- Blocking conflicts were found (even if resolved — the user should see what\n  was reconciled)\n- Degrading conflicts were accepted\n- Any conflict resolution created a superseding ADR\n\nIf the report shows zero conflicts and zero resolutions, do NOT write the\nmarker — the conductor will auto-approve and move to the next step.\n\n```bash\n# Example: write the marker when issues were found\nmkdir -p .pipeline\necho \"blocking conflicts resolved: 2, degrading accepted: 1\" > .pipeline\u002Freview-required-conflict_check\n```\n\n## Verification\n\n- [ ] All stories in `.docs\u002Fstories\u002F` scanned (not just new ones)\n- [ ] All approved ADRs from `.docs\u002Fdecisions\u002F` considered, narrowed to the stories' subject, and\n      compared against relevant stories\n- [ ] Examined and narrowed-out ADRs recorded in the conflict report\n- [ ] Only unambiguously fully superseded ADRs excluded; partial or ambiguous supersessions retained\n      for comparison\n- [ ] All 6 conflict types checked (contradiction, overlap, state, resource, sequencing, oscillating)\n- [ ] Every pair sharing a behavior\u002Fentity\u002Ffield\u002Fgate was tested in BOTH directions —\n      \"if A is fully satisfied, does B still hold?\" — since one-directional checking\n      cannot distinguish an oscillation from an ordinary contradiction\n- [ ] Each conflict has severity, description, and resolution options\n- [ ] User selected resolution for each blocking conflict\n- [ ] Affected stories updated to reflect resolutions\n- [ ] Conflict reports saved to `.docs\u002Fconflicts\u002F`\n- [ ] Re-check passed clean after resolutions\n- [ ] Zero blocking conflicts remain before proceeding\n- [ ] `.pipeline\u002Freview-required-conflict_check` marker written IF any conflict\n      was found\u002Fresolved or degrading conflict was accepted (skip if truly clean)\n","## Purpose\n\nDetects when new stories contradict, overlap, or create impossible states with existing ones.\nProvides guided resolution so conflicts are resolved before implementation begins — preventing\nthe expensive discovery of contradictions during or after coding.\n\n**Correctness gate:** \"these two stories conflict\" (or \"clean\") is a judgment call. Per the\n`\u002Fverify-claims` protocol, ground each asserted conflict in the specific contradicting text with a\nconfidence %, and do not declare a clean pass on the *assumption* that two stories are compatible\nwhen their interaction was never actually reasoned through — an unexamined pair is not a verified\nclean pass.\n\n## Practices\n\n### 1. Inventory\n\nLoad ALL stories and specs:\n- All files in `.docs\u002Fstories\u002F` (existing + newly written)\n- Active specs from `.docs\u002Fspecs\u002F` (for design-level context)\n- Approved ADRs from `.docs\u002Fdecisions\u002F` (as selected below)\n- Previous conflict reports from `.docs\u002Fconflicts\u002F` (to check for recurring patterns)\n\nThe ADR corpus is always repo-wide: load all approved ADRs, narrow the corpus to ADRs whose\nsubject overlaps the current spec's stories, and record both the examined and narrowed-out ADRs in\nthe conflict report. Exclude an ADR only when it is unambiguously fully superseded; retain an ADR\nwith a partial or ambiguous supersession because its remaining decision may still conflict with a\nstory.\n\n### 1b. As-Built Story Handling\n\nWhen stories have `[AS-BUILT]` markers (from `\u002Fbootstrap`), they document **existing working\ncode**. Overlap between as-built stories is expected — the same endpoint may appear in multiple\nstories describing different aspects of the same feature.\n\n**Scoring adjustment for as-built pairs:**\n- Two `[AS-BUILT]` stories sharing an endpoint → **not a conflict** unless they assert\n  contradictory behavior. Same endpoint, same behavior, different story angle = normal.\n- `[AS-BUILT]` vs new story → check normally. New work may genuinely conflict with existing behavior.\n- Two new stories → check normally.\n\nThis prevents false positives when bootstrapping an existing codebase where stories naturally\noverlap because they were reverse-engineered from the same working system.\n\n### 2. Conflict Scan\n\nCheck each pair of stories for these conflict types:\n\nAlso compare each selected ADR against every story whose behavior, entity, field, resource, or\ngate it addresses. Apply the same six conflict types and the same two-directional heuristic to\nan ADR-versus-story pair; ADRs are a comparison party, not a seventh conflict type.\n\n#### Contradiction\nStories that directly oppose each other.\n- Story A: \"Users must authenticate to view orders\"\n- Story B: \"Anonymous users can browse the order catalog\"\n- Conflict if both reference the same resource\u002Fendpoint.\n\n#### Behavioral Overlap\nStories that modify the same entity, flow, or endpoint in incompatible ways.\n- Story A: \"Admins can soft-delete users\" (sets `deleted_at`)\n- Story B: \"Users with activity in the last 30 days cannot be deleted\"\n- Overlap: What happens when an admin tries to soft-delete an active user?\n\n#### State Conflict\nCombined stories create impossible or ambiguous system states.\n- Story A: \"Orders are immutable after confirmation\"\n- Story B: \"Customer support can edit confirmed order addresses\"\n- Conflict: An order cannot be both immutable and editable.\n\n#### Resource Contention\nStories assume exclusive access to shared resources.\n- Story A: \"The `status` column tracks order lifecycle\"\n- Story B: \"The `status` column tracks payment state\"\n- Conflict: Same column, different semantic meanings.\n\n#### Sequencing Conflict\nStories that each assume they run first, or create circular dependencies.\n- Story A: \"User profile must exist before creating an order\"\n- Story B: \"First order creation triggers profile setup\"\n- Conflict: Circular dependency on which comes first.\n\n#### Oscillating Conflict\nTwo requirements that are each individually satisfiable but **mutually exclusive in\npractice**, so satisfying one re-breaks the other. This is the costliest conflict type\nand the hardest to see, because nothing looks wrong at authoring time — both stories\nread as reasonable, and each is implementable on its own.\n\n- Story A: \"Every build change has current aggregate test-suite evidence before SHIP\"\n- Story B: \"The test-suite gate may reuse current aggregate evidence without rerunning it\"\n- Conflict: a build that requires a fresh rerun can never reuse current evidence. An\n  implementation satisfying A fails B's gate; the fix for B then fails A's gate.\n\nThe damage is not a failed build — it is a **loop that does not terminate on its own**.\nGate A kicks the work back, the fix trips gate B, gate B kicks it back, and each lap\ncosts a full agent session. A static contradiction announces itself the first time\nsomeone tries to write the code; an oscillation only announces itself as unexplained\nrework, several steps downstream, where nobody is looking at the stories any more.\n\n**Detection heuristic:** for each pair of stories touching the same behavior, entity,\nfield, or gate, ask **\"if I fully satisfy A, does B still hold?\"** — then ask it in the\nother direction. Two \"no\" answers is an oscillation, however sensible each story reads\nalone. One \"no\" is an ordinary contradiction or overlap; classify it as those instead.\n\nOscillations are almost always **blocking**, even when each story looks harmless,\nbecause there is no implementation that satisfies both and no amount of rework will\nfind one. Resolving it requires changing what is being asked for, not how it is built —\nwhich usually means the root lives upstream (see 5c) in the PRD's FRs or in the design,\nnot in story phrasing.\n\n**Layer ownership.** Story↔story pairs belong to `\u002Fconflict-check`. Cross-layer and task versus task\npairs belong to plan review at Medium and Large tier, and to the plan's §7b at Small tier.\n`\u002Fconflict-check` runs before `\u002Fplan` and cannot see tasks.\n\n### 3. Generate Conflict Report\n\nFor each conflict found:\n\n```markdown\n## Conflict: [Short description]\n\n**Stories involved:** [Story A title] vs [Story B title]\n**Files:** [.docs\u002Fstories\u002Ffile-a.md] vs [.docs\u002Fstories\u002Ffile-b.md]\n**Type:** contradiction | overlap | state-conflict | resource-contention | sequencing | oscillating\n**Severity:** blocking | degrading\n\n**Description:**\nWhat specifically conflicts and why both cannot be true simultaneously.\n\n**Resolution Options:**\n1. [Least disruptive option — modify one story to accommodate the other]\n2. [Moderate option — modify both stories to meet in the middle]\n3. [Most disruptive option — introduce new mediating behavior]\n\n**Recommendation:** Option [N] because [rationale].\n```\n\nFor an ADR-versus-story conflict, use the same report format and additionally include this\ngrounding block. `ADR filename stem` is the ADR filename without `.md`; `Story ID` is the story's\ndeclared identifier.\n\n```markdown\n**ADR filename stem:** adr-YYYY-MM-DD-decision-slug\n**Story ID:** STORY-N\n**ADR opposing sentence (verbatim):** \"\u003Cexact sentence from the ADR>\"\n**Story opposing sentence (verbatim):** \"\u003Cexact sentence from the story>\"\n```\n\nRecord an ADR-versus-story conflict only when both opposing sentences are present and demonstrate\nthe incompatibility. An ungrounded suspicion is an assumption, not a recorded conflict; verify it\nagainst the ADR and story text or report it as an assumption under the `\u002Fverify-claims` protocol.\nWhen the opposing passage spans multiple sentences, quote the needed sentences verbatim in their\noriginal order and put `[…]` at every omitted span. Do not silently truncate, join, or reword the\npassage: the report must make both the quoted evidence and every omission explicit.\n\nWorked ADR-versus-story report:\n\n```markdown\n## Conflict: Session-based access contradicts token-only API story\n\n**Stories involved:** Token-only API access vs ADR: Browser session authentication\n**Files:** [.docs\u002Fstories\u002Fapi-access.md] vs [.docs\u002Fdecisions\u002Fadr-2026-08-10-browser-session-authentication.md]\n**Type:** contradiction\n**Severity:** blocking\n**ADR filename stem:** adr-2026-08-10-browser-session-authentication\n**Story ID:** STORY-12\n**ADR opposing sentence (verbatim):** \"The API authenticates browser requests with server-side sessions.\"\n**Story opposing sentence (verbatim):** \"The API accepts only bearer tokens and does not create sessions.\"\n\n**Description:** The same API requests cannot require server-side sessions while accepting only\nbearer tokens and creating no sessions.\n\n**Resolution Options:**\n1. Amend STORY-12 to use the ADR's session mechanism.\n2. Define an explicit session-and-token compatibility boundary.\n3. Create a superseding ADR that selects token-only authentication.\n\n**Recommendation:** Option 1 because it preserves the approved architectural decision.\n```\n\n**Severity definitions:**\n- **blocking** — Cannot proceed to implementation. Stories are mutually exclusive.\n- **degrading** — Can proceed with a known compromise. Both stories work but with reduced functionality in the overlap area.\n\n### 4. Guided Resolution\n\nPresent all conflicts to the user at once, grouped by severity (blocking first).\n\nFor each conflict:\n1. Explain what conflicts and why\n2. Present resolution options ranked by impact (least disruptive first)\n3. Include a recommendation with rationale\n4. User selects a resolution\n\nAfter user selects:\n1. Update the affected stories in `.docs\u002Fstories\u002F` to reflect the resolution by replacing\n   superseded assertions in place; leave no amendment record in a story artifact\n2. Save the conflict report to `.docs\u002Fconflicts\u002FYYYY-MM-DD-\u003Cdescription>.md`\n\n**Accepted-artifact amendment:** When the resolution falsifies an assertion in an accepted\nDECIDE artifact, perform the amendment during the DECIDE pass in that artifact — never defer it\nas a later BUILD task. Story artifacts under `.docs\u002Fstories\u002F` are the narrow exception: replace\nthe superseded assertion in place and leave no amendment record. For all other accepted DECIDE\nartifacts already on the base branch, add this note beside the original assertion:\n\n```markdown\n> **Amended YYYY-MM-DD by #NNN:** \u003Cwhat the assertion now says, and why>\n```\n\nFor these non-story artifacts, the amendment is additive: the original assertion remains; do not\nrewrite or delete it, and create no separate record. This makes the correction part of the\nspec-branch baseline before BUILD starts.\n\nAn accepted DECIDE artifact absent from the base branch is a draft: revise it in place, remove\nsuperseded text, and add no amendment note or revision log.\n\n**Conflict reports are overwritten on re-run.** If a re-check after resolution finds new or\nchanged conflicts, overwrite the existing conflict report file. The report reflects the CURRENT\nstate — git has the history.\n\n**Conflict resolutions that change architectural decisions create new ADRs.** Never overwrite\nan existing ADR. Instead:\n1. Write a new ADR in `.docs\u002Fdecisions\u002F` (named `adr-YYYY-MM-DD-\u003Ckebab-slug>.md`, no\n   sequential numbers) that supersedes the old one\n2. Update the old ADR's status to `Superseded by \u003Cnew-adr-slug>` (the new ADR's filename stem)\n3. The new ADR references the old one and explains why the decision changed\n\nExample: If conflict resolution changes the API authentication approach from\n`adr-2026-05-01-api-auth-strategy`, create `adr-2026-06-29-api-auth-token-exchange` with the new\napproach and mark the old one as superseded.\n\n### 5. Re-Check\n\nAfter all resolutions are applied, re-run the full conflict check.\n\n**GATE: Loop until the check passes clean (zero blocking conflicts).**\n\nDegrading conflicts may remain if the user explicitly accepts the compromise.\n\n### 5c. Route a Blocking Conflict by Root Cause (kickback)\n\nA story-vs-story conflict is usually a *symptom*; fix it where the contradiction is rooted, not\nalways in the stories. Classify each blocking conflict's root and route the kickback to the right\nupstream gate (`prd` and `architecture_review` are kickback targets; the recovery\u002Fback-navigation\nmenu lists them):\n\n- **Contradictory product requirements (FRs)** → kick back to **`prd`** (product track). The two\n  stories conflict because the PRD's FRs themselves conflict; the PRD must be reconciled first.\n- **Incompatible design \u002F ADR** → kick back to **`architecture`** (architecture-review). The conflict\n  stems from the chosen design; architecture-review re-opens in *amendment* mode to resolve the\n  specific structural gap, then stories re-derive.\n- **Pure story-phrasing overlap** → resolve in **`stories`** (the default — Section 4).\n\nOnly route up when the root genuinely lives upstream; a phrasing nit stays in stories. In an\ninteractive run, surface the root + target and navigate back to it. In an unattended\u002Fdaemon run a\nblocking conflict HALTs for a human (no silent pass).\n\n### 6. Clean Pass\n\nWhen no blocking conflicts remain:\n- Report \"Conflict check passed\" with summary\n- Note any accepted degrading conflicts\n- Suggest invoking the `plan` skill\n\n### 7. Signal Review Requirement\n\nBefore exiting, decide whether the conductor should prompt the user to review\nthe conflict report(s). Review mode for this step is **conditional** — auto-approved\nunless you write a marker file.\n\nWrite `.pipeline\u002Freview-required-conflict_check` (any content; the file's\nexistence is the signal) if ANY of the following is true:\n\n- Blocking conflicts were found (even if resolved — the user should see what\n  was reconciled)\n- Degrading conflicts were accepted\n- Any conflict resolution created a superseding ADR\n\nIf the report shows zero conflicts and zero resolutions, do NOT write the\nmarker — the conductor will auto-approve and move to the next step.\n\n```bash\n# Example: write the marker when issues were found\nmkdir -p .pipeline\necho \"blocking conflicts resolved: 2, degrading accepted: 1\" > .pipeline\u002Freview-required-conflict_check\n```\n\n## Verification\n\n- [ ] All stories in `.docs\u002Fstories\u002F` scanned (not just new ones)\n- [ ] All approved ADRs from `.docs\u002Fdecisions\u002F` considered, narrowed to the stories' subject, and\n      compared against relevant stories\n- [ ] Examined and narrowed-out ADRs recorded in the conflict report\n- [ ] Only unambiguously fully superseded ADRs excluded; partial or ambiguous supersessions retained\n      for comparison\n- [ ] All 6 conflict types checked (contradiction, overlap, state, resource, sequencing, oscillating)\n- [ ] Every pair sharing a behavior\u002Fentity\u002Ffield\u002Fgate was tested in BOTH directions —\n      \"if A is fully satisfied, does B still hold?\" — since one-directional checking\n      cannot distinguish an oscillation from an ordinary contradiction\n- [ ] Each conflict has severity, description, and resolution options\n- [ ] User selected resolution for each blocking conflict\n- [ ] Affected stories updated to reflect resolutions\n- [ ] Conflict reports saved to `.docs\u002Fconflicts\u002F`\n- [ ] Re-check passed clean after resolutions\n- [ ] Zero blocking conflicts remain before proceeding\n- [ ] `.pipeline\u002Freview-required-conflict_check` marker written IF any conflict\n      was found\u002Fresolved or degrading conflict was accepted (skip if truly clean)\n",{"name":5,"phase":41,"requires":49,"standalone":51,"description":7,"enforcement":25,"implicit_invocation":52},[50],"verify-claims",true,"required","main","136b34ec6792f53d0beba330dfa2dffad6c93484","skills\u002Fconflict-check",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 08:28:50",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":51},[62,65,68],{"tool":63,"command":64},"npx","npx skills add jstoup111\u002Fai-conductor --skill conflict-check",{"tool":66,"command":67},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill conflict-check",{"tool":69,"command":70},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill conflict-check","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fconflict-check\u002FSKILL.md",[],[74,92,130,146,165,176],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":44},"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",[],[81,82,83,84,85,86,87,88,89,90,30,91,25],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","judge",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":111,"publishedAt":44},"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",[98,103,106],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":104,"categoryName":105,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[112,113,114,115,116,117,118,119,120,121,122,123,29,124,125,126,127,25,128,129],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","directory","ui","framework","failing","phase","request",{"skillNo":131,"name":50,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":44},"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",[],[136,29,43,22,137,28,138,139,30,140,39,40,33,141,142,42,32,143,144,145,24,25,23],"verify claims","adr","decision","claim","mechanics","code","reports","questions","about","spec",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":44},"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",[],[148,153,154,155,120,156,86,157,158,159,160,87,161,30,40,162,163,164,23,128],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":166,"name":26,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":44},"01M6K3E6PEXBXYY2K8TSRTN1JT","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",[],[26,27,22,28,41,38,35,30,39,40,122,31,171,172,29,173,43,174,32,175,24,25,23],"architecture","examples","artifact","requests","implementation",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":44},"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",[],[183,184,185,162,29,186,187,188,43,87,189,190,191,192,193,30,194,39,40,195,23,196],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation","advisory"]