[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF081VB3PKAM251BNNMYKF":3,"skill-same:01M6CF081VB3PKAM251BNNMYKF":112},{"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":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":75,"commitSha":76,"skillDirectory":77,"forksCount":78,"repositoryHtmlUrl":79,"repositoryHomepageUrl":6,"ownerHtmlUrl":80,"ownerBlogUrl":6,"ownerDescription":81,"updatedAt":82,"install":83,"resources":96},"01M6CF081VB3PKAM251BNNMYKF","issue\u002Fcontract",null,"Write the contract sections of a cnos issue — problem, impact, status truth, source of truth, scope, non-goals, and closure condition.","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\u002Fissue\u002Fcontract\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],"issue","issue contract","design","status","artifacts","constraints","verify","how","table","write","context","embedded","implementation","guidance","surfaces","goals","2026-11-10 10:12:30",false,"---\nname: issue\u002Fcontract\ndescription: Write the contract sections of a cnos issue — problem, impact, status truth, source of truth, scope, non-goals, and closure condition.\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: How does γ write the contract sections of an issue so α can act, β can verify, and γ can close without hidden context?\nvisibility: internal\nparent: issue\ntriggers:\n  - issue contract\n  - problem statement\n  - status truth\n  - scope\n  - non-goals\nscope: task-local\ninputs:\n  - selected gap\n  - affected surfaces\n  - current implementation status\noutputs:\n  - problem section (exists \u002F expected \u002F diverges)\n  - impact section\n  - status truth table\n  - source-of-truth table\n  - scope section (in scope \u002F out of scope \u002F deferred \u002F blocked by)\n  - non-goals section\n  - skills to load section\n  - active design constraints section\n  - related artifacts section\n  - implementation guidance section\n  - success \u002F closure condition\n---\n\n# Issue Contract\n\n## Core Principle\n\nA contract section names one truth. It does not argue, qualify, or gesture. Each section answers one question so precisely that α can implement without asking and β can verify without recovering hidden conversation context.\n\nFailure mode: **authority drift** — docs, implementation, and issue body disagree about what exists, what is required, and what is excluded.\n\n---\n\n## 1. Define\n\n### 1.1 Identify the parts\n\nContract sections:\n\n- **Problem** — the incoherence in three lines\n- **Impact** — who is affected and what is blocked\n- **Status truth** — what exists vs. what is expected vs. what is draft\u002Fplanned\n- **Source of truth** — one canonical path per load-bearing claim\n- **Scope** — the execution boundary (in \u002F out \u002F deferred \u002F blocked)\n- **Non-goals** — what must not appear in ACs\n- **Skills to load** — Tier 3 skills only\n- **Active design constraints** — stable policy vs. volatile decisions\n- **Related artifacts** — canonical links\n- **Implementation guidance** — branch, identity, known migration debt\n- **Success \u002F closure condition** — when γ may close\n\n### 1.2 Articulate how they fit\n\nProblem → Impact establishes why this work matters.\nStatus truth → Source of truth establishes what is real now.\nScope + Non-goals establish the execution boundary.\nSkills + Constraints establish the generation constraints for α.\nClosure establishes when β's merge and γ's close are justified.\n\n### 1.3 Name the failure mode\n\nContract fails through **authority drift**: two sections disagree about whether something is in scope, or the implementation cites a different canonical source than the issue does.\n\n---\n\n## 2. Unfold\n\n### 2.1 Problem format\n\n```markdown\n## Problem\n\nWhat exists:\nWhat is expected:\nWhere they diverge:\n```\n\nKeep the problem 3–5 lines. Link to deeper evidence instead of reproducing design discussion.\n\n- ❌ `The package system is inconsistent and needs cleanup.`\n- ✅ `SKILL.md frontmatter has a CTB v0.1 schema in LANGUAGE-SPEC.md, but no CI gate validates the 54 package skill files. Missing fields can drift indefinitely.`\n\n### 2.2 Impact format\n\nAnswer:\n\n- Who or what is affected?\n- What breaks or drifts?\n- Why now?\n- What is blocked if this remains unresolved?\n\n- ❌ `This would be nice to have.`\n- ✅ `Without this gate, CTB frontmatter conformance depends on reviewer memory. v0.2 promotion inherits unchecked v0.1 drift.`\n\n### 2.3 Status truth\n\nDistinguish shipped reality from expected or draft targets:\n\n| Status | Meaning |\n|---|---|\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| `Not in scope` | Explicitly excluded |\n| `Unknown` | Not verified yet |\n\n- ❌ Describe draft behavior as runtime behavior.\n- ✅ `CTB v0.2 draft defines witnessed close-outs. The shipped runtime does not yet enforce them.`\n\n### 2.4 Source-of-truth table\n\n```markdown\n## Source of truth\n\n| Claim \u002F surface | Canonical source | Status | Notes |\n|---|---|---|---|\n| CTB v0.1 frontmatter fields | docs\u002Freference\u002Fctb\u002FLANGUAGE-SPEC.md §2, §11 | current spec | governs current skill frontmatter |\n```\n\nEvery load-bearing claim must link to a path, issue, or upstream document. No \"the docs say\" without a path.\n\n### 2.5 Scope section\n\n```markdown\n## Scope\n\nIn scope:\n- ...\n\nOut of scope:\n- ...\n\nDeferred:\n- ...\n\nBlocked by:\n- ...\n```\n\nRules:\n\n- Non-goals are mandatory for issues with 3+ ACs.\n- Every noun in ACs must be in scope.\n- If a non-goal noun appears in an AC, fix the issue before filing.\n- If a deferred item is necessary for success, it is a dependency, not deferred.\n\n### 2.6 Non-goals\n\nName what must not appear in ACs or implementation work. Non-goals exist to close the scope leak failure mode.\n\n- ❌ Non-goal says \"no runtime enforcement,\" but AC4 says \"runtime enforces the schema.\"\n- ✅ Non-goal says \"no runtime enforcement,\" and AC4 says \"CI rejects malformed frontmatter using a script.\"\n\n### 2.7 Skills to load\n\nName Tier 3 skills only. Tier 1 and Tier 2 are mandatory and not repeated.\n\n```markdown\n## Skills to load\n\nTier 3:\n- cnos.core\u002Fskills\u002Fdesign\n- eng\u002Ftool\n\nWhy:\n- design: boundary decisions and source-of-truth clarity.\n- tool: shell script standards.\n```\n\nDo not list skills as decoration. If a skill changes the issue shape, explain why.\n\n### 2.8 Active design constraints\n\nState constraints in plain language.\n\n- ❌ `Follow project conventions.`\n- ✅ `Schema owns field shape\u002Ftype\u002Fenum validation; shell script owns discovery and diagnostics. Do not duplicate schema rules in shell.`\n\n### 2.9 Related artifacts\n\nLink exact paths. If a companion artifact is being drafted in parallel, say how conflicts are resolved.\n\n- ❌ `Related: CTB docs.`\n- ✅ `docs\u002Freference\u002Fctb\u002FLANGUAGE-SPEC.md §2.1`\n\n### 2.10 Implementation guidance\n\nUse for: branch name, git identity, file paths, resolution base, known migration debt.\n\nDo not use to replace a plan when the work requires multi-step execution.\n\n```markdown\n## Implementation guidance\n\nBranch: cycle\u002F324\nIdentity: alpha \u003Calpha@cdd.cnos>\nNotes: ...\n```\n\n### 2.11 Success \u002F closure condition\n\nState precisely when γ may close:\n\n- all ACs met\n- non-goals remain unviolated\n- known gaps either resolved or carried as named debt\n\n---\n\n## 3. Rules\n\n3.1. **State what exists before what is expected.** Every problem statement leads with current state, then target, then divergence.\n\n3.2. **Status must be explicit.** Never describe draft behavior as shipped or planned enforcement as current.\n\n3.3. **Source of truth is a path, not a claim.** Every load-bearing fact must link to a file or issue.\n\n3.4. **Non-goals must not appear in ACs.** If a non-goal noun appears in an AC, fix the issue.\n\n3.5. **Contradiction resolution is the author's job.** When two sections contradict, resolve before filing. α does not choose silently between contradictory interpretations.\n\n---\n\n## 4. Kata\n\n### Scenario\n\nYou are filing an issue to add a CI gate that validates SKILL.md frontmatter against a CUE schema. The shipped runtime has no frontmatter validation. A draft CTB v0.2 spec proposes a witnessed close-out field.\n\n### Task\n\nWrite the contract sections:\n\n- problem (3–5 lines)\n- status truth (table)\n- source of truth (table with 3 rows)\n- scope (in \u002F out \u002F deferred)\n- non-goals (2 items)\n- success \u002F closure condition\n\n### Expected artifacts\n\n- Problem that names exists\u002Fexpected\u002Fdiverges without describing draft behavior as shipped.\n- Status truth that distinguishes `Shipped`, `Current spec`, and `Draft target`.\n- Source of truth that gives exact file paths.\n- Scope that does not list any non-goal noun in \"In scope.\"\n- Non-goals that do not contradict ACs.\n\n### Common failures\n\n- Status truth says \"CTB enforces witnessed close-outs\" (draft claim as shipped).\n- Source of truth says \"CTB docs\" without a path.\n- Non-goal says \"no v0.2 semantics\" while an AC requires a v0.2 check.\n- Scope says \"in scope: full CI validation suite\" while non-goals say \"not in scope: CI enforcement.\"\n","# Issue Contract\n\n## Core Principle\n\nA contract section names one truth. It does not argue, qualify, or gesture. Each section answers one question so precisely that α can implement without asking and β can verify without recovering hidden conversation context.\n\nFailure mode: **authority drift** — docs, implementation, and issue body disagree about what exists, what is required, and what is excluded.\n\n---\n\n## 1. Define\n\n### 1.1 Identify the parts\n\nContract sections:\n\n- **Problem** — the incoherence in three lines\n- **Impact** — who is affected and what is blocked\n- **Status truth** — what exists vs. what is expected vs. what is draft\u002Fplanned\n- **Source of truth** — one canonical path per load-bearing claim\n- **Scope** — the execution boundary (in \u002F out \u002F deferred \u002F blocked)\n- **Non-goals** — what must not appear in ACs\n- **Skills to load** — Tier 3 skills only\n- **Active design constraints** — stable policy vs. volatile decisions\n- **Related artifacts** — canonical links\n- **Implementation guidance** — branch, identity, known migration debt\n- **Success \u002F closure condition** — when γ may close\n\n### 1.2 Articulate how they fit\n\nProblem → Impact establishes why this work matters.\nStatus truth → Source of truth establishes what is real now.\nScope + Non-goals establish the execution boundary.\nSkills + Constraints establish the generation constraints for α.\nClosure establishes when β's merge and γ's close are justified.\n\n### 1.3 Name the failure mode\n\nContract fails through **authority drift**: two sections disagree about whether something is in scope, or the implementation cites a different canonical source than the issue does.\n\n---\n\n## 2. Unfold\n\n### 2.1 Problem format\n\n```markdown\n## Problem\n\nWhat exists:\nWhat is expected:\nWhere they diverge:\n```\n\nKeep the problem 3–5 lines. Link to deeper evidence instead of reproducing design discussion.\n\n- ❌ `The package system is inconsistent and needs cleanup.`\n- ✅ `SKILL.md frontmatter has a CTB v0.1 schema in LANGUAGE-SPEC.md, but no CI gate validates the 54 package skill files. Missing fields can drift indefinitely.`\n\n### 2.2 Impact format\n\nAnswer:\n\n- Who or what is affected?\n- What breaks or drifts?\n- Why now?\n- What is blocked if this remains unresolved?\n\n- ❌ `This would be nice to have.`\n- ✅ `Without this gate, CTB frontmatter conformance depends on reviewer memory. v0.2 promotion inherits unchecked v0.1 drift.`\n\n### 2.3 Status truth\n\nDistinguish shipped reality from expected or draft targets:\n\n| Status | Meaning |\n|---|---|\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| `Not in scope` | Explicitly excluded |\n| `Unknown` | Not verified yet |\n\n- ❌ Describe draft behavior as runtime behavior.\n- ✅ `CTB v0.2 draft defines witnessed close-outs. The shipped runtime does not yet enforce them.`\n\n### 2.4 Source-of-truth table\n\n```markdown\n## Source of truth\n\n| Claim \u002F surface | Canonical source | Status | Notes |\n|---|---|---|---|\n| CTB v0.1 frontmatter fields | docs\u002Freference\u002Fctb\u002FLANGUAGE-SPEC.md §2, §11 | current spec | governs current skill frontmatter |\n```\n\nEvery load-bearing claim must link to a path, issue, or upstream document. No \"the docs say\" without a path.\n\n### 2.5 Scope section\n\n```markdown\n## Scope\n\nIn scope:\n- ...\n\nOut of scope:\n- ...\n\nDeferred:\n- ...\n\nBlocked by:\n- ...\n```\n\nRules:\n\n- Non-goals are mandatory for issues with 3+ ACs.\n- Every noun in ACs must be in scope.\n- If a non-goal noun appears in an AC, fix the issue before filing.\n- If a deferred item is necessary for success, it is a dependency, not deferred.\n\n### 2.6 Non-goals\n\nName what must not appear in ACs or implementation work. Non-goals exist to close the scope leak failure mode.\n\n- ❌ Non-goal says \"no runtime enforcement,\" but AC4 says \"runtime enforces the schema.\"\n- ✅ Non-goal says \"no runtime enforcement,\" and AC4 says \"CI rejects malformed frontmatter using a script.\"\n\n### 2.7 Skills to load\n\nName Tier 3 skills only. Tier 1 and Tier 2 are mandatory and not repeated.\n\n```markdown\n## Skills to load\n\nTier 3:\n- cnos.core\u002Fskills\u002Fdesign\n- eng\u002Ftool\n\nWhy:\n- design: boundary decisions and source-of-truth clarity.\n- tool: shell script standards.\n```\n\nDo not list skills as decoration. If a skill changes the issue shape, explain why.\n\n### 2.8 Active design constraints\n\nState constraints in plain language.\n\n- ❌ `Follow project conventions.`\n- ✅ `Schema owns field shape\u002Ftype\u002Fenum validation; shell script owns discovery and diagnostics. Do not duplicate schema rules in shell.`\n\n### 2.9 Related artifacts\n\nLink exact paths. If a companion artifact is being drafted in parallel, say how conflicts are resolved.\n\n- ❌ `Related: CTB docs.`\n- ✅ `docs\u002Freference\u002Fctb\u002FLANGUAGE-SPEC.md §2.1`\n\n### 2.10 Implementation guidance\n\nUse for: branch name, git identity, file paths, resolution base, known migration debt.\n\nDo not use to replace a plan when the work requires multi-step execution.\n\n```markdown\n## Implementation guidance\n\nBranch: cycle\u002F324\nIdentity: alpha \u003Calpha@cdd.cnos>\nNotes: ...\n```\n\n### 2.11 Success \u002F closure condition\n\nState precisely when γ may close:\n\n- all ACs met\n- non-goals remain unviolated\n- known gaps either resolved or carried as named debt\n\n---\n\n## 3. Rules\n\n3.1. **State what exists before what is expected.** Every problem statement leads with current state, then target, then divergence.\n\n3.2. **Status must be explicit.** Never describe draft behavior as shipped or planned enforcement as current.\n\n3.3. **Source of truth is a path, not a claim.** Every load-bearing fact must link to a file or issue.\n\n3.4. **Non-goals must not appear in ACs.** If a non-goal noun appears in an AC, fix the issue.\n\n3.5. **Contradiction resolution is the author's job.** When two sections contradict, resolve before filing. α does not choose silently between contradictory interpretations.\n\n---\n\n## 4. Kata\n\n### Scenario\n\nYou are filing an issue to add a CI gate that validates SKILL.md frontmatter against a CUE schema. The shipped runtime has no frontmatter validation. A draft CTB v0.2 spec proposes a witnessed close-out field.\n\n### Task\n\nWrite the contract sections:\n\n- problem (3–5 lines)\n- status truth (table)\n- source of truth (table with 3 rows)\n- scope (in \u002F out \u002F deferred)\n- non-goals (2 items)\n- success \u002F closure condition\n\n### Expected artifacts\n\n- Problem that names exists\u002Fexpected\u002Fdiverges without describing draft behavior as shipped.\n- Status truth that distinguishes `Shipped`, `Current spec`, and `Draft target`.\n- Source of truth that gives exact file paths.\n- Scope that does not list any non-goal noun in \"In scope.\"\n- Non-goals that do not contradict ACs.\n\n### Common failures\n\n- Status truth says \"CTB enforces witnessed close-outs\" (draft claim as shipped).\n- Source of truth says \"CTB docs\" without a path.\n- Non-goal says \"no v0.2 semantics\" while an AC requires a v0.2 check.\n- Scope says \"in scope: full CI validation suite\" while non-goals say \"not in scope: CI enforcement.\"\n",{"name":5,"scope":50,"inputs":51,"parent":29,"outputs":55,"triggers":67,"visibility":72,"description":7,"kata_surface":40,"artifact_class":73,"governing_question":74},"task-local",[52,53,54],"selected gap","affected surfaces","current implementation status",[56,57,58,59,60,61,62,63,64,65,66],"problem section (exists \u002F expected \u002F diverges)","impact section","status truth table","source-of-truth table","scope section (in scope \u002F out of scope \u002F deferred \u002F blocked by)","non-goals section","skills to load section","active design constraints section","related artifacts section","implementation guidance section","success \u002F closure condition",[30,68,69,70,71],"problem statement","status truth","scope","non-goals","internal","skill","How does γ write the contract sections of an issue so α can act, β can verify, and γ can close without hidden context?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Fissue\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":84,"prompt":94,"zipAvailable":95},[85,88,91],{"tool":86,"command":87},"npx","npx skills add usurobor\u002Fcnos --skill issue\u002Fcontract",{"tool":89,"command":90},"bunx","bunx skills add usurobor\u002Fcnos --skill issue\u002Fcontract",{"tool":92,"command":93},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill issue\u002Fcontract","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Fissue\u002Fcontract\u002FSKILL.md",true,[97,102,108],{"path":98,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"LICENSE","许可证",1074,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fkraken-official-order-types\u002FLICENSE",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"SOURCE.md","REFERENCE","参考文档",171,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fkraken-official-order-types\u002FSOURCE.md",{"path":109,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":110,"sourceHtmlUrl":111},"TRUST.auto.yaml",2197,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fexchanges\u002Fkraken-official-order-types\u002FTRUST.auto.yaml",[113,130,145,167,183,203],{"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":45},"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",[],[120,121,122,123,124,36,125,126,127,128,29,129],"triage","issues","issues triage","issue triage","SET","decision","public","use","dispatch","doctrine",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":45},"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",[],[121,137,138,139,32,140,124,141,126,142,127,128,143,29,144],"taxonomy","issues taxonomy","github","protocol","open","board","github issue","issue labels",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":155,"publishedAt":45},"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",[151,154],{"categoryNo":152,"categoryName":153,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[121,156,139,157,158,159,124,160,137,141,36,161,162,142,163,164,165,166,127,29],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":168,"name":121,"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":45},"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",[],[121,139,173,174,175,33,176,177,178,137,141,36,125,179,162,180,127,181,128,182],"pr","current state","run","state","package","boundary","branch","command","only","cds",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":45},"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",[],[190,191,33,140,192,36,193,194,195,126,196,197,198,199,127,40,200,201,202,129],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","patch","shape","cdd",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":209,"publishedAt":45},"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",[],[210,139,211,212,213,214,36,215,216,179,196,198,127,181,128,217,143,218,219,220],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]