[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF1JFFA11YA4PDDGH0SN24":3,"skill-same:01M6CF1JFFA11YA4PDDGH0SN24":93},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":71,"commitSha":72,"skillDirectory":73,"forksCount":74,"repositoryHtmlUrl":75,"repositoryHomepageUrl":6,"ownerHtmlUrl":76,"ownerBlogUrl":6,"ownerDescription":77,"updatedAt":78,"install":79,"resources":92},"01M6CF1JFFA11YA4PDDGH0SN24","review\u002Fdiff-context",null,"Diff and context inspection — structural closure, multi-format parity, snapshot consistency, stale-path validation, execution timeline, derivation, authority-surface conflict, module-truth audit, contract confinement, architecture leverage, process overhead, and design constraints checks.","usurobor\u002Fcnos","usurobor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F182342826?v=4","01M6CEXJCRMYD8HB2315FGB1Q8","Peter Lisovin","01M6CEXJH2RW04GQ2SNXY40F5S",9,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Freview\u002Fdiff-context\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"review","review diff context","diff","context","validation","audit","severity","execution","verify","how","format","branch","execution timeline","results","orchestrator","process","snapshot","architecture","issue contract","design","2026-11-10 10:12:30",false,"---\nname: review\u002Fdiff-context\ndescription: Diff and context inspection — structural closure, multi-format parity, snapshot consistency, stale-path validation, execution timeline, derivation, authority-surface conflict, module-truth audit, contract confinement, architecture leverage, process overhead, and design constraints checks.\nartifact_class: skill\nkata_surface: external\ngoverning_question: How does β verify that the diff is internally consistent, closes its claimed gap, and does not violate invariants across the full diff context?\nvisibility: internal\nparent: review\ntriggers:\n  - review diff\n  - review context\nscope: task-local\ninputs:\n  - branch\n  - diff\n  - issue contract results from Phase 2a\noutputs:\n  - findings with severity and type (mechanical \u002F judgment \u002F contract)\nrequires:\n  - Phase 1 (contract integrity) completed\n  - Phase 2a (issue contract walk) completed\n  - review orchestrator loaded\ncalls: []\n---\n\n# Review — Phase 2b: Diff and Context Inspection\n\n**PRE-GATE: Phase 2a (issue contract walk) must be completed.**\n\n---\n\n## §2.1 Diff and context inspection\n\n### 2.1.1 Structural closure and input-source enumeration\n\n**a)** When code claims \"structurally prevented\" or \"impossible by construction,\" enumerate all input sources at security-level rigor and verify the closure claim against every one. An unaudited input source makes any structural-prevention claim unchecked.\n\n- For filters\u002Fsanitizers\u002Fvalidators: trace every source through the full pipeline.\n- For new data surfaces: verify both write paths AND read paths.\n\n**b)** When one fallback\u002Fcompatibility path is touched, audit all sibling fallback paths. Compatibility code is a bundle — changes to one path can invalidate assumptions in a sibling.\n\n### 2.1.2 Multi-format semantic parity\n\nIf a value is rendered in multiple formats (prose, JSON, YAML, table, code block), verify all formats say the same thing. Format divergence is a common source of stale paths.\n\n### 2.1.3 Snapshot consistency\n\nIf the project uses snapshot\u002Fexpect tests, diff each snapshot change against the PR description.\n- ❌ Accept snapshot changes as \"expected\" without reading them.\n- ✅ Verify each snapshot change makes sense given the diff.\n\n### 2.1.4 Stale-path validation\n\nWhen a file is moved, renamed, or deleted:\n- Grep the old path across the full repo (excluding historical audit docs).\n- Check live consumers, imports, README links, docs, and source maps.\n\n### 2.1.5 Branch naming and conventions\n\nVerify branch name follows project convention. Check for duplicate list entries, convention violations, or inconsistencies introduced by the diff.\n\n### 2.1.6 Execution timeline for state-changing paths\n\nIf code crosses process or binary boundaries, trace which process owns which values at each step.\n- ❌ \"This reads the version in process, so it's current\"\n- ✅ \"Old process still holds old constants after replacement; re-exec before reading\"\n\n### 2.1.7 Derivation vs validation\n\nIf an AC claims \"single source of truth\" or \"one-file edit,\" verify that a generation step exists, not only a check.\n\n### 2.1.8 Authority-surface conflict\n\nWhen multiple surfaces claim to define the same thing, verify they agree. Common conflict sites:\n- canonical doc vs executable skill\n- runtime contract vs machine-readable JSON\n- issue ACs vs self-coherence.md\n- branch summary vs actual branch state\n\n### 2.1.9 Module-truth audit for model-correctness changes\n\nWhen a change is about correctness of a model, do not limit review to the diff. Scan the full touched module for other assumptions of the same kind.\n- Ask: \"What else in this module assumes the same thing the diff is fixing?\"\n\n### 2.1.10 Contract-implementation confinement check\n\nWhen a function's contract claims a restricted input domain, verify the implementation actually **rejects** inputs outside that domain. Silent acceptance of unclaimed inputs is a confinement gap.\n\n### 2.1.11 Architecture leverage check\n\nAsk whether the diff merely improves the current architecture or misses a higher-leverage boundary move. Is repeated pressure being treated as a one-off patch?\n\n### 2.1.12 Process overhead check\n\nIf the diff adds new docs, artifacts, gates, or procedures: What exact failure does this prevent? Who uses the new artifact? Could this be automated instead?\n\n### 2.1.13 Project design constraints check\n\nIf the project maintains a design constraints document, load it. Verify the change preserves, tightens, or explicitly revises each affected constraint. Silent violation is a D finding. Silent revision is a C finding.\n\n---\n\n## After Phase 2b\n\nCollect all diff\u002Fcontext findings with severity and type. Pass to Phase 2c (`review\u002Farchitecture\u002FSKILL.md`) for architecture check.\n\nReturn to orchestrator (`review\u002FSKILL.md`) after all Phase 2 sub-skills complete for verdict rules and output format.\n","# Review — Phase 2b: Diff and Context Inspection\n\n**PRE-GATE: Phase 2a (issue contract walk) must be completed.**\n\n---\n\n## §2.1 Diff and context inspection\n\n### 2.1.1 Structural closure and input-source enumeration\n\n**a)** When code claims \"structurally prevented\" or \"impossible by construction,\" enumerate all input sources at security-level rigor and verify the closure claim against every one. An unaudited input source makes any structural-prevention claim unchecked.\n\n- For filters\u002Fsanitizers\u002Fvalidators: trace every source through the full pipeline.\n- For new data surfaces: verify both write paths AND read paths.\n\n**b)** When one fallback\u002Fcompatibility path is touched, audit all sibling fallback paths. Compatibility code is a bundle — changes to one path can invalidate assumptions in a sibling.\n\n### 2.1.2 Multi-format semantic parity\n\nIf a value is rendered in multiple formats (prose, JSON, YAML, table, code block), verify all formats say the same thing. Format divergence is a common source of stale paths.\n\n### 2.1.3 Snapshot consistency\n\nIf the project uses snapshot\u002Fexpect tests, diff each snapshot change against the PR description.\n- ❌ Accept snapshot changes as \"expected\" without reading them.\n- ✅ Verify each snapshot change makes sense given the diff.\n\n### 2.1.4 Stale-path validation\n\nWhen a file is moved, renamed, or deleted:\n- Grep the old path across the full repo (excluding historical audit docs).\n- Check live consumers, imports, README links, docs, and source maps.\n\n### 2.1.5 Branch naming and conventions\n\nVerify branch name follows project convention. Check for duplicate list entries, convention violations, or inconsistencies introduced by the diff.\n\n### 2.1.6 Execution timeline for state-changing paths\n\nIf code crosses process or binary boundaries, trace which process owns which values at each step.\n- ❌ \"This reads the version in process, so it's current\"\n- ✅ \"Old process still holds old constants after replacement; re-exec before reading\"\n\n### 2.1.7 Derivation vs validation\n\nIf an AC claims \"single source of truth\" or \"one-file edit,\" verify that a generation step exists, not only a check.\n\n### 2.1.8 Authority-surface conflict\n\nWhen multiple surfaces claim to define the same thing, verify they agree. Common conflict sites:\n- canonical doc vs executable skill\n- runtime contract vs machine-readable JSON\n- issue ACs vs self-coherence.md\n- branch summary vs actual branch state\n\n### 2.1.9 Module-truth audit for model-correctness changes\n\nWhen a change is about correctness of a model, do not limit review to the diff. Scan the full touched module for other assumptions of the same kind.\n- Ask: \"What else in this module assumes the same thing the diff is fixing?\"\n\n### 2.1.10 Contract-implementation confinement check\n\nWhen a function's contract claims a restricted input domain, verify the implementation actually **rejects** inputs outside that domain. Silent acceptance of unclaimed inputs is a confinement gap.\n\n### 2.1.11 Architecture leverage check\n\nAsk whether the diff merely improves the current architecture or misses a higher-leverage boundary move. Is repeated pressure being treated as a one-off patch?\n\n### 2.1.12 Process overhead check\n\nIf the diff adds new docs, artifacts, gates, or procedures: What exact failure does this prevent? Who uses the new artifact? Could this be automated instead?\n\n### 2.1.13 Project design constraints check\n\nIf the project maintains a design constraints document, load it. Verify the change preserves, tightens, or explicitly revises each affected constraint. Silent violation is a D finding. Silent revision is a C finding.\n\n---\n\n## After Phase 2b\n\nCollect all diff\u002Fcontext findings with severity and type. Pass to Phase 2c (`review\u002Farchitecture\u002FSKILL.md`) for architecture check.\n\nReturn to orchestrator (`review\u002FSKILL.md`) after all Phase 2 sub-skills complete for verdict rules and output format.\n",{"name":5,"calls":54,"scope":55,"inputs":56,"parent":29,"outputs":58,"requires":60,"triggers":64,"visibility":67,"description":7,"kata_surface":68,"artifact_class":69,"governing_question":70},[],"task-local",[40,31,57],"issue contract results from Phase 2a",[59],"findings with severity and type (mechanical \u002F judgment \u002F contract)",[61,62,63],"Phase 1 (contract integrity) completed","Phase 2a (issue contract walk) completed","review orchestrator loaded",[65,66],"review diff","review context","internal","external","skill","How does β verify that the diff is internally consistent, closes its claimed gap, and does not violate invariants across the full diff context?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Freview\u002Fdiff-context",0,"https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos","https:\u002F\u002Fgithub.com\u002Fusurobor","Coherence engineer. Building git-CN.","2026-11-07 14:25:44",{"source":8,"skillName":5,"commands":80,"prompt":90,"zipAvailable":91},[81,84,87],{"tool":82,"command":83},"npx","npx skills add usurobor\u002Fcnos --skill review\u002Fdiff-context",{"tool":85,"command":86},"bunx","bunx skills add usurobor\u002Fcnos --skill review\u002Fdiff-context",{"tool":88,"command":89},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill review\u002Fdiff-context","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Freview\u002Fdiff-context\u002FSKILL.md",true,[],[94,112,128,150,166,186],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":49},"01M6CF8RWQPM0VXZG06XMR0FFX","issues\u002Ftriage","Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close\u002Fsupersede\u002Fdefer.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftriage\u002FSKILL.md",[],[101,102,103,104,105,38,106,107,108,109,110,111],"triage","issues","issues triage","issue triage","SET","decision","public","use","dispatch","issue","doctrine",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":49},"01M6CF8PJ812DD4APZ3WE8X67B","issues\u002Ftaxonomy","Issue label taxonomy pointer. Use when classifying an issue's kind\u002Farea\u002Fpriority\u002Feffort\u002Fstatus\u002Fprotocol\u002Fdispatch labels, or when the board needs to interpret them.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftaxonomy\u002FSKILL.md",[],[102,119,120,121,122,123,105,124,107,125,108,109,126,110,127],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":138,"publishedAt":49},"01M6CF8KBMZ4D0CDJQ3PF1YVTP","issues\u002Fmap","Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON\u002FHTML output contract.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Fmap\u002FSKILL.md",[134,137],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[102,139,121,140,141,142,105,143,119,124,38,144,145,125,146,147,148,149,108,110],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":151,"name":102,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":49},"01M6CF8CZQH7G7B7RZPANQWR4G","cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot \u002F issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002FSKILL.md",[],[102,121,156,157,158,159,160,161,162,119,124,38,106,40,145,163,108,164,109,165],"pr","current state","run","artifacts","state","package","boundary","command","only","cds",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":49},"01M6CF896XKSRQVB1CSHY8GSXB","receipt-stream","Cross-cycle receipt-stream doctrine for protocol-iteration. Use when γ closes a cycle and writes the per-cycle iteration artifact (`cdd-iteration.md`), when γ updates the cross-cycle aggregator at `.cdd\u002Fiterations\u002FINDEX.md`, when ε reads the receipt stream across cycles to surface protocol-gap patterns, when a finding's disposition lands a cross-repo patch and the cross-repo trace bundle attaches, or when a courtesy empty-findings stub is written for a `protocol_gap_count == 0` cycle.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Freceipt-stream\u002FSKILL.md",[],[173,174,159,123,175,38,176,39,177,107,178,179,180,181,108,182,183,184,185,111],"receipt stream","handoff","index","learning","trace","repo","closeout","read","channel","embedded","patch","shape","cdd",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":49},"01M6CF84VCBME6RK8V6HAVDM8Z","mid-flight","Mid-flight γ→in-flight-α rescue channel. Use when γ needs to change a load-bearing fact (pinned axis, scope, AC, blocker) after α has begun coding, when γ edits the cycle's GitHub issue body mid-cycle, or when a spec change lands on origin\u002Fmain while α\u002Fβ polling sessions are in-flight.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight\u002FSKILL.md",[],[193,121,194,195,196,197,38,198,199,40,178,180,108,164,109,200,126,201,202,203],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]