[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF1FJS3X97ZZ0VQMRAWAV9":3,"skill-same:01M6CF1FJS3X97ZZ0VQMRAWAV9":95},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":6,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6CF1FJS3X97ZZ0VQMRAWAV9","review\u002Fcontract",null,"Contract integrity preflight — verify the work contract is truthful, consistent, and non-contradictory before reading the diff.","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\u002Fcontract\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"review","review contract","pr","integrity","verify","preflight","how","table","work","branch","check","orchestrator","diff","implementation","issue","2026-11-10 10:12:30",false,"---\nname: review\u002Fcontract\ndescription: Contract integrity preflight — verify the work contract is truthful, consistent, and non-contradictory before reading the diff.\nartifact_class: skill\nkata_surface: external\ngoverning_question: How does β verify that the work contract is truthful, scoped, sourced, and non-contradictory before inspecting implementation?\nvisibility: internal\nparent: review\ntriggers:\n  - review contract\nscope: task-local\ninputs:\n  - issue\n  - PR body\n  - branch summary\noutputs:\n  - contract integrity table (yes\u002Fno\u002Fn\u002Fa per check)\nrequires:\n  - review orchestrator loaded\ncalls: []\n---\n\n# Review — Phase 1: Contract Integrity\n\n**GATE: Complete this phase before reading the diff.** A branch can be locally well-implemented and still not review-ready if the contract it claims to satisfy is contradictory, stale, or overclaims shipped behavior.\n\nFill the Contract Integrity table. If any row is \"no,\" the review cannot approve unless the row is explicitly out of scope and the reviewer names why it does not affect merge readiness.\n\n```markdown\n## §2.0.0 Contract Integrity\n\n| Check | Result | Notes |\n|---|---|---|\n| Status truth preserved | yes \u002F no \u002F n\u002Fa | |\n| Canonical sources\u002Fpaths verified | yes \u002F no \u002F n\u002Fa | |\n| Scope\u002Fnon-goals consistent | yes \u002F no \u002F n\u002Fa | |\n| Constraint strata consistent | yes \u002F no \u002F n\u002Fa | |\n| Exceptions field-specific\u002Freasoned | yes \u002F no \u002F n\u002Fa | |\n| Path resolution base explicit | yes \u002F no \u002F n\u002Fa | |\n| Proof shape adequate | yes \u002F no \u002F n\u002Fa | |\n| Cross-surface projections updated | yes \u002F no \u002F n\u002Fa | |\n| No witness theater \u002F false closure | yes \u002F no \u002F n\u002Fa | |\n| PR body matches branch files | yes \u002F no \u002F n\u002Fa | |\n```\n\n---\n\n## Checks\n\n### 1. Status truth\n\nVerify that the issue, PR body, branch artifacts, and docs distinguish:\n- **shipped:** implemented and enforced today\n- **current spec:** normative document currently governing conformance\n- **draft target:** proposed or draft spec not yet promoted\n- **planned:** accepted direction, not implemented\n- **non-goals:** explicitly excluded\n- **unknown:** not verified yet\n\nFindings:\n- D if the branch claims runtime enforcement that does not exist.\n- C if draft\u002Ftarget state is described as current but the diff does not rely on it.\n- mechanical if the status label is plainly stale across docs\u002FREADME\u002Fsource map.\n\n- ❌ \"CTB enforces witnessed close-outs\" when only the v0.2 draft defines them.\n- ✅ \"CTB v0.2 draft defines witnessed close-outs; ctb-check\u002Fruntime enforcement is not shipped.\"\n\n### 2. Source-of-truth map\n\nFor every load-bearing claim in the issue or PR body, verify the canonical source. Check:\n- exact file path;\n- branch\u002Fref if relevant;\n- current vs draft status;\n- upstream repo links;\n- generated vs authored source;\n- README\u002Fdocs\u002Fsource-map projections.\n\nIf paths changed, grep old paths across live docs and code.\n\n- ❌ \"Manifesto lives under doctrine\u002F\" when canonical path is `docs\u002Fpapers\u002FMANIFESTO.md`.\n- ✅ Root README, docs README, and source map all point to the same canonical path.\n\n### 3. Scope and non-goal consistency\n\nCheck whether any AC, implementation note, PR claim, or output artifact contradicts the non-goals.\n\nFindings:\n- D if an out-of-scope behavior is implemented or claimed as shipped.\n- C if the PR body implies out-of-scope work but files do not.\n- mechanical if the contradiction is textual and deterministic.\n\n- ❌ Non-goal: \"do not implement runtime enforcement.\" PR body: \"runtime now enforces CTB v0.2.\"\n- ✅ PR body: \"adds structural checker issue; runtime enforcement remains out of scope.\"\n\n### 4. Constraint strata\n\nIf the issue defines required\u002Foptional\u002Fexception-backed fields or rules, verify that examples and implementation obey the strata. Check:\n- hard gates are not exception-backed;\n- exception-backed fields have field-specific exceptions;\n- optional\u002Fdefaulted fields name defaults;\n- validated-if-present fields are actually checked when present;\n- deferred fields are not silently enforced or claimed.\n\n- ❌ Hard gate: `scope`. Exception example: `\"allowed_missing\": [\"scope\"]`.\n- ✅ Exception example only lists exception-backed fields such as `artifact_class` or `kata_surface`.\n\n### 5. Exception discipline\n\nExceptions are debt, not blanket permission. Verify:\n- exceptions are field-specific;\n- each exception has a reason;\n- JSON exceptions do not rely on comments;\n- exceptions do not exempt hard gates;\n- cleanup\u002Fremoval condition is named where appropriate.\n\n- ❌ `{ \"path\": \"...\", \"ignore\": true }`\n- ✅ `{ \"path\": \"...\", \"allowed_missing\": [\"artifact_class\"], \"reason\": \"legacy skill migration pending\" }`\n\n### 6. Path resolution semantics\n\nIf the issue or implementation validates paths, verify the resolution base. Check whether paths are:\n- repo-root-relative;\n- package-root-relative;\n- caller-file-relative;\n- branch-relative;\n- generated-artifact-relative.\n\nRequire at least one concrete example when path validation is part of the change.\n\n- ❌ \"Validate calls relative to the skill's parent directory\" when current skills use package-root-relative calls.\n- ✅ `alpha\u002FSKILL.md` with `calls: design\u002FSKILL.md` resolves to `src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Fdesign\u002FSKILL.md`.\n\n### 7. Proof shape\n\nFor checker, schema, parser, runtime, CI, and validation issues, verify that the branch includes:\n- invariant;\n- oracle;\n- positive case;\n- negative case;\n- operator-visible projection;\n- known gap.\n\nExisting CI passing is the floor, not the proof.\n\n- ❌ \"CI passes\" but no invalid fixture proves the checker rejects malformed input.\n- ✅ Valid fixture passes; missing hard-gate field fails with expected diagnostic.\n\n### 8. Cross-surface projections\n\nWhen the diff adds or changes a status, checker, command, CI job, source map, schema, or runtime surface, verify every projection that should expose it.\n\nExamples:\n- CI job added → notify aggregation updated.\n- README source map changed → docs README changed.\n- Schema added → schema README \u002F fixtures \u002F CI invocation added.\n- Runtime status changed → help \u002F doctor \u002F status \u002F docs agree.\n- Upstream formal source added → source map and further-reading sections agree.\n\n- ❌ Add CI job I5 but leave Telegram\u002Fnotify aggregation unaware of I5.\n- ✅ I5 is added and notify job result summary includes I5.\n\n### 9. False closure \u002F witness theater\n\nIf the change adds witnesses, close-outs, review artifacts, checker outputs, debt records, or governance structure, verify that the structure is accountable to evidence. Ask:\n- What rejects a malformed artifact?\n- What preserves failed evidence?\n- What prevents accepted closure from hiding active debt?\n- What fields are required but non-vacuous?\n- What is still only prose discipline?\n\nFindings:\n- D if the branch claims enforcement but only adds prose.\n- C if the structure is useful but lacks the promised rejection mechanism.\n- B if the rejection mechanism is correctly deferred but the deferral could be clearer.\n\n- ❌ 10-field close-out shape exists, but no checker or issue says which fields are required.\n- ✅ Spec names required fields; checker issue requires invalid fixtures and diagnostics.\n\n### 10. PR body \u002F branch summary consistency\n\nVerify that the PR description still matches the corrected branch files. After fix rounds, PR bodies can describe an older state.\n\n- ❌ PR body says \"nested └─ layer diagram\" but branch files now show sibling `├─` architecture.\n- ✅ PR body updated after fix to match the branch head state.\n\n---\n\n## After Phase 1\n\nIf all rows are \"yes\" or \"n\u002Fa,\" proceed to Phase 2 (implementation review).\n\nIf any row is \"no,\" file findings immediately. The implementation review may still proceed, but verdict must account for the contract-level findings.\n\n**Return to orchestrator** (`review\u002FSKILL.md`) → **Load Phase 2** starting with `review\u002Fissue-contract\u002FSKILL.md`.\n","# Review — Phase 1: Contract Integrity\n\n**GATE: Complete this phase before reading the diff.** A branch can be locally well-implemented and still not review-ready if the contract it claims to satisfy is contradictory, stale, or overclaims shipped behavior.\n\nFill the Contract Integrity table. If any row is \"no,\" the review cannot approve unless the row is explicitly out of scope and the reviewer names why it does not affect merge readiness.\n\n```markdown\n## §2.0.0 Contract Integrity\n\n| Check | Result | Notes |\n|---|---|---|\n| Status truth preserved | yes \u002F no \u002F n\u002Fa | |\n| Canonical sources\u002Fpaths verified | yes \u002F no \u002F n\u002Fa | |\n| Scope\u002Fnon-goals consistent | yes \u002F no \u002F n\u002Fa | |\n| Constraint strata consistent | yes \u002F no \u002F n\u002Fa | |\n| Exceptions field-specific\u002Freasoned | yes \u002F no \u002F n\u002Fa | |\n| Path resolution base explicit | yes \u002F no \u002F n\u002Fa | |\n| Proof shape adequate | yes \u002F no \u002F n\u002Fa | |\n| Cross-surface projections updated | yes \u002F no \u002F n\u002Fa | |\n| No witness theater \u002F false closure | yes \u002F no \u002F n\u002Fa | |\n| PR body matches branch files | yes \u002F no \u002F n\u002Fa | |\n```\n\n---\n\n## Checks\n\n### 1. Status truth\n\nVerify that the issue, PR body, branch artifacts, and docs distinguish:\n- **shipped:** implemented and enforced today\n- **current spec:** normative document currently governing conformance\n- **draft target:** proposed or draft spec not yet promoted\n- **planned:** accepted direction, not implemented\n- **non-goals:** explicitly excluded\n- **unknown:** not verified yet\n\nFindings:\n- D if the branch claims runtime enforcement that does not exist.\n- C if draft\u002Ftarget state is described as current but the diff does not rely on it.\n- mechanical if the status label is plainly stale across docs\u002FREADME\u002Fsource map.\n\n- ❌ \"CTB enforces witnessed close-outs\" when only the v0.2 draft defines them.\n- ✅ \"CTB v0.2 draft defines witnessed close-outs; ctb-check\u002Fruntime enforcement is not shipped.\"\n\n### 2. Source-of-truth map\n\nFor every load-bearing claim in the issue or PR body, verify the canonical source. Check:\n- exact file path;\n- branch\u002Fref if relevant;\n- current vs draft status;\n- upstream repo links;\n- generated vs authored source;\n- README\u002Fdocs\u002Fsource-map projections.\n\nIf paths changed, grep old paths across live docs and code.\n\n- ❌ \"Manifesto lives under doctrine\u002F\" when canonical path is `docs\u002Fpapers\u002FMANIFESTO.md`.\n- ✅ Root README, docs README, and source map all point to the same canonical path.\n\n### 3. Scope and non-goal consistency\n\nCheck whether any AC, implementation note, PR claim, or output artifact contradicts the non-goals.\n\nFindings:\n- D if an out-of-scope behavior is implemented or claimed as shipped.\n- C if the PR body implies out-of-scope work but files do not.\n- mechanical if the contradiction is textual and deterministic.\n\n- ❌ Non-goal: \"do not implement runtime enforcement.\" PR body: \"runtime now enforces CTB v0.2.\"\n- ✅ PR body: \"adds structural checker issue; runtime enforcement remains out of scope.\"\n\n### 4. Constraint strata\n\nIf the issue defines required\u002Foptional\u002Fexception-backed fields or rules, verify that examples and implementation obey the strata. Check:\n- hard gates are not exception-backed;\n- exception-backed fields have field-specific exceptions;\n- optional\u002Fdefaulted fields name defaults;\n- validated-if-present fields are actually checked when present;\n- deferred fields are not silently enforced or claimed.\n\n- ❌ Hard gate: `scope`. Exception example: `\"allowed_missing\": [\"scope\"]`.\n- ✅ Exception example only lists exception-backed fields such as `artifact_class` or `kata_surface`.\n\n### 5. Exception discipline\n\nExceptions are debt, not blanket permission. Verify:\n- exceptions are field-specific;\n- each exception has a reason;\n- JSON exceptions do not rely on comments;\n- exceptions do not exempt hard gates;\n- cleanup\u002Fremoval condition is named where appropriate.\n\n- ❌ `{ \"path\": \"...\", \"ignore\": true }`\n- ✅ `{ \"path\": \"...\", \"allowed_missing\": [\"artifact_class\"], \"reason\": \"legacy skill migration pending\" }`\n\n### 6. Path resolution semantics\n\nIf the issue or implementation validates paths, verify the resolution base. Check whether paths are:\n- repo-root-relative;\n- package-root-relative;\n- caller-file-relative;\n- branch-relative;\n- generated-artifact-relative.\n\nRequire at least one concrete example when path validation is part of the change.\n\n- ❌ \"Validate calls relative to the skill's parent directory\" when current skills use package-root-relative calls.\n- ✅ `alpha\u002FSKILL.md` with `calls: design\u002FSKILL.md` resolves to `src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Fdesign\u002FSKILL.md`.\n\n### 7. Proof shape\n\nFor checker, schema, parser, runtime, CI, and validation issues, verify that the branch includes:\n- invariant;\n- oracle;\n- positive case;\n- negative case;\n- operator-visible projection;\n- known gap.\n\nExisting CI passing is the floor, not the proof.\n\n- ❌ \"CI passes\" but no invalid fixture proves the checker rejects malformed input.\n- ✅ Valid fixture passes; missing hard-gate field fails with expected diagnostic.\n\n### 8. Cross-surface projections\n\nWhen the diff adds or changes a status, checker, command, CI job, source map, schema, or runtime surface, verify every projection that should expose it.\n\nExamples:\n- CI job added → notify aggregation updated.\n- README source map changed → docs README changed.\n- Schema added → schema README \u002F fixtures \u002F CI invocation added.\n- Runtime status changed → help \u002F doctor \u002F status \u002F docs agree.\n- Upstream formal source added → source map and further-reading sections agree.\n\n- ❌ Add CI job I5 but leave Telegram\u002Fnotify aggregation unaware of I5.\n- ✅ I5 is added and notify job result summary includes I5.\n\n### 9. False closure \u002F witness theater\n\nIf the change adds witnesses, close-outs, review artifacts, checker outputs, debt records, or governance structure, verify that the structure is accountable to evidence. Ask:\n- What rejects a malformed artifact?\n- What preserves failed evidence?\n- What prevents accepted closure from hiding active debt?\n- What fields are required but non-vacuous?\n- What is still only prose discipline?\n\nFindings:\n- D if the branch claims enforcement but only adds prose.\n- C if the structure is useful but lacks the promised rejection mechanism.\n- B if the rejection mechanism is correctly deferred but the deferral could be clearer.\n\n- ❌ 10-field close-out shape exists, but no checker or issue says which fields are required.\n- ✅ Spec names required fields; checker issue requires invalid fixtures and diagnostics.\n\n### 10. PR body \u002F branch summary consistency\n\nVerify that the PR description still matches the corrected branch files. After fix rounds, PR bodies can describe an older state.\n\n- ❌ PR body says \"nested └─ layer diagram\" but branch files now show sibling `├─` architecture.\n- ✅ PR body updated after fix to match the branch head state.\n\n---\n\n## After Phase 1\n\nIf all rows are \"yes\" or \"n\u002Fa,\" proceed to Phase 2 (implementation review).\n\nIf any row is \"no,\" file findings immediately. The implementation review may still proceed, but verdict must account for the contract-level findings.\n\n**Return to orchestrator** (`review\u002FSKILL.md`) → **Load Phase 2** starting with `review\u002Fissue-contract\u002FSKILL.md`.\n",{"name":5,"calls":44,"scope":45,"inputs":46,"parent":24,"outputs":49,"requires":51,"triggers":53,"visibility":54,"description":7,"kata_surface":55,"artifact_class":56,"governing_question":57},[],"task-local",[38,47,48],"PR body","branch summary",[50],"contract integrity table (yes\u002Fno\u002Fn\u002Fa per check)",[52],"review orchestrator loaded",[25],"internal","external","skill","How does β verify that the work contract is truthful, scoped, sourced, and non-contradictory before inspecting implementation?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Freview\u002Fcontract",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":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add usurobor\u002Fcnos --skill review\u002Fcontract",{"tool":72,"command":73},"bunx","bunx skills add usurobor\u002Fcnos --skill review\u002Fcontract",{"tool":75,"command":76},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill review\u002Fcontract","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Freview\u002Fcontract\u002FSKILL.md",true,[80,85,91],{"path":81,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"LICENSE","许可证",1074,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fkraken-official-recipe-drawdown-circuit-breaker\u002FLICENSE",{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"SOURCE.md","REFERENCE","参考文档",171,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fkraken-official-recipe-drawdown-circuit-breaker\u002FSOURCE.md",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"TRUST.auto.yaml",2217,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fkraken-official-recipe-drawdown-circuit-breaker\u002FTRUST.auto.yaml",[96,113,129,153,168,189],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":39},"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",[],[103,104,105,106,107,30,108,109,110,111,38,112],"triage","issues","issues triage","issue triage","SET","decision","public","use","dispatch","doctrine",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":39},"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",[],[104,120,121,122,123,124,107,125,109,126,110,111,127,38,128],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":130,"name":131,"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":141,"publishedAt":39},"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",[135,140],{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[104,142,122,143,144,145,107,146,120,125,30,147,148,126,149,150,151,152,110,38],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":154,"name":104,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":39},"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",[],[104,122,26,159,160,161,162,163,164,120,125,30,108,33,148,165,110,166,111,167],"current state","run","artifacts","state","package","boundary","command","only","cds",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":39},"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",[],[175,176,161,124,177,30,178,179,180,109,181,182,183,184,110,185,186,187,188,112],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","embedded","patch","shape","cdd",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":39},"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",[],[196,122,197,198,199,200,30,201,202,33,181,183,110,166,111,203,127,204,205,206],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]