issues
cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot / 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.
- License 许可
- Apache-2.0
- 所属仓库
- usurobor/cnos
- 最近更新
- 2026-11-07
- Stars
- ★ 9
- Forks
- 0
01 前言 Front Matter
- name
- issues
- calls
- [ "skills/map/SKILL.md", "skills/taxonomy/SKILL.md", "skills/triage/SKILL.md" ]
- scope
- global
- inputs
- [ "open GitHub issues (labels, state, comments)", "the issue taxonomy (kind/area/priority/effort/status/protocol/dispatch labels)", "the observed fact snapshot for one issue (run state, branch, PR, CDD artifacts — see commands/issues-fsm)" ]
- outputs
- [ "issue-board records (taxonomy-aware, effort-weighted)", "static Issue Pivot board output (index.html, board-data.json, README.md)", "a read-only issue-state decision (current state, observed facts, enabled transition, blocked reason, proposed action)" ]
- triggers
- [ "issues", "issue board", "issue pivot", "board map", "taxonomy", "triage", "issues fsm", "issue state evaluator" ]
- visibility
- public
- description
- cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot / 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.
- kata_surface
- none
- artifact_class
- skill
- governing_question
- What owns issue taxonomy, board mapping, Issue Pivot generation, and issue-state evaluation, and how is that ownership realized through the current command-dispatch boundary?
02 资源文件 49
- 参考文档cn.package.json143 B
- 脚本commands/issues-dispatch/dispatch_test.go12.3 KB
- 脚本commands/issues-dispatch/dispatch.go7.9 KB
- 脚本commands/issues-dispatch/fetch_test.go3.2 KB
- 脚本commands/issues-dispatch/fetch.go6.3 KB
- 其他commands/issues-dispatch/go.mod87 B
- 脚本commands/issues-dispatch/issuesdispatch.go2.7 KB
- 脚本commands/issues-dispatch/reconcile_test.go3.0 KB
- 脚本commands/issues-dispatch/reconcile.go4.7 KB
- 脚本commands/issues-fsm/decision.go6.2 KB
- 脚本commands/issues-fsm/fetch.go18.6 KB
- 其他commands/issues-fsm/go.mod82 B
- 脚本commands/issues-fsm/issuesfsm_test.go64.8 KB
- 脚本commands/issues-fsm/issuesfsm.go14.9 KB
- 脚本commands/issues-fsm/scan_test.go19.1 KB
- 脚本commands/issues-fsm/scan.go16.7 KB
- 脚本commands/issues-fsm/snapshot.go7.0 KB
- 脚本commands/issues-fsm/table.go7.8 KB
- 脚本commands/issues-fsm/terminal_test.go19.1 KB
- 脚本commands/issues-fsm/terminal.go12.6 KB
- 参考文档commands/issues-fsm/testdata/changes-no-repair.json382 B
- 参考文档commands/issues-fsm/testdata/changes-with-repair.json400 B
- 参考文档commands/issues-fsm/testdata/in-progress-active.json359 B
- 参考文档commands/issues-fsm/testdata/in-progress-block-no-evidence.json393 B
- 参考文档commands/issues-fsm/testdata/in-progress-block-with-evidence.json413 B
- 参考文档commands/issues-fsm/testdata/in-progress-dead-no-matter.json363 B
- 参考文档commands/issues-fsm/testdata/in-progress-dead-with-commits.json402 B
- 参考文档commands/issues-fsm/testdata/in-progress-release-no-matter.json410 B
- 参考文档commands/issues-fsm/testdata/in-progress-release-with-matter.json437 B
- 参考文档commands/issues-fsm/testdata/in-progress-review-request-branch-only.json373 B
- 参考文档commands/issues-fsm/testdata/in-progress-review-request-no-matter.json403 B
- 参考文档commands/issues-fsm/testdata/in-progress-review-request-with-matter.json378 B
- 参考文档commands/issues-fsm/testdata/ready.json317 B
- 参考文档commands/issues-fsm/testdata/review-empty.json376 B
- 参考文档commands/issues-fsm/testdata/review-partial-evidence.json403 B
- 参考文档commands/issues-fsm/testdata/review-request-only.json397 B
- 参考文档commands/issues-fsm/testdata/review-with-pr.json424 B
- 参考文档commands/issues-fsm/testdata/scan-died-after-pr-before-review-request.json420 B
- 参考文档commands/issues-fsm/testdata/scan-died-after-review-request-before-review.json510 B
- 参考文档commands/issues-fsm/testdata/todo-claimable.json368 B
- 参考文档commands/issues-fsm/testdata/todo-competing-run.json385 B
- 参考文档commands/issues-fsm/testdata/todo-resume-existing-matter.json387 B
- 参考文档commands/issues-fsm/testdata/todo.json316 B
- 脚本commands/issues-map/fetch.go1.9 KB
- 其他commands/issues-map/go.mod82 B
- 脚本commands/issues-map/issuesmap_test.go6.1 KB
- 脚本commands/issues-map/issuesmap.go12.1 KB
- 参考文档commands/issues-map/templates/board.template.html326.7 KB
- 参考文档commands/issues-map/testdata/issues.json1.6 KB
03 SKILL.md 正文
cnos.issues
Core Principle
cnos.issues is the package home for issue-board cognition: it owns issue
taxonomy, board mapping, and Issue Pivot generation as a domain, distinct
from the CLI dispatch that invokes it.
cnos.issues owns:
- issue taxonomy — the label vocabulary an issue is judged against
(
skills/taxonomy/SKILL.md, citingdocs/development/issues/TAXONOMY.mdas the canonical source, not forking it); - triage doctrine — how a raw issue becomes coherently labeled and
dispatchable (
skills/triage/SKILL.md, citingdocs/development/issues/TRIAGE.md); - board mapping / Issue Pivot generation — the domain logic that fetches
open issues, derives taxonomy-aware records, computes effort, and renders
the interactive board (
skills/map/SKILL.md). - the generic issue-state fact model and evaluator engine — the
FactSnapshotmodel and the transition-table evaluator thatcn issues fsm evaluate(cnos#568, Phase 1) drives. This package owns the generic engine only: it is unaware of "CDS" as a concept beyond reading whatever transition-table file it is given. The CDS-specific transition table itself (states/triggers/guards/actions, declarative JSON) is owned bycnos.cdsat../cnos.cds/skills/cds/fsm/transitions.json, per cnos#568's ownership split. Phase 1 is strictly read-only: no--applyflag exists, and no code path incommands/issues-fsm/writes a GitHub label. Label-mutation authority is Phase 2 (cnos#569).
Command-dispatch disposition
The user-facing command cn issues map is a compiled-in kernel command
(SourceKernel / TierKernel), registered in src/go/cmd/cn/main.go and
dispatched by the thin src/go/internal/cli/cmd_issues_map.go (argument
parsing + delegation only).
The Go domain implementation — issuesmap.go, fetch.go,
issuesmap_test.go, templates/, testdata/ — lives under this package at
commands/issues-map/, as its own Go module
(module github.com/usurobor/cnos/packages/cnos.issues/commands/issues-map),
mirroring the cnos#392
cdd-verify precedent exactly: wired into src/go/go.mod via a
require+replace pair, added to go.work's use (...) list, and
dispatched by the thin cmd_issues_map.go shim (import + one-line
delegation only — no domain logic in the CLI file).
cn issues map is a temporary built-in shim until
#216: dispatch stays through
the compiled-in kernel registration, not the package-command exec-dispatch
mechanism (PACKAGE-SYSTEM.md §7).
commands/issues-map/ under this package is Go-source co-location, not
a declared package command: cn.package.json's commands object does not
list issues-map (matching cnos.cdd/cn.package.json, which likewise has
no cdd-verify entry despite cdd-verify's Go source living under
cnos.cdd/commands/cdd-verify/). Declaring one would create a dead entry —
the kernel built-in always shadows a same-named package command silently
per the command-discovery precedence rule — and would misrepresent the
command as package-provided exec-dispatch when it is not.
A future #216 cycle may move issues-map onto real package-command
exec-dispatch: removing the kernel registration in main.go, adding a
commands.issues-map entry to this package's cn.package.json with a
cn-issues-map entrypoint script, and adding package-install plumbing to
the board-map GitHub Action. None of that is done by this package as it
stands — physical co-location of the domain source is not the same as
declared package-command dispatch.
cn issues fsm evaluate (cnos#568, Phase 1) has the identical
disposition, mirroring issues-map exactly: a compiled-in kernel command
(SourceKernel/TierKernel) registered in src/go/cmd/cn/main.go as
reg.Register(&cli.IssuesFsmCmd{}), dispatched by the thin
src/go/internal/cli/cmd_issues_fsm.go shim (import + one-line delegation
only), with its Go domain implementation Go-source co-located under this
package at commands/issues-fsm/ as its own module
(module github.com/usurobor/cnos/packages/cnos.issues/commands/issues-fsm),
wired into src/go/go.mod via require+replace and into root
go.work's use (...) list. cn.package.json's commands object does
not list issues-fsm, for the same #216-shim reason given above. Registry
resolution: noun=issues, verb=fsm → registry key issues-fsm; the
command's own Run then dispatches on the first remaining arg (evaluate
is the only sub-verb in Phase 1 — apply is explicitly out of scope,
belonging to Phase 2 / cnos#569).
Non-goals
- Does not implement generic package-command discovery (out of scope; see #216).
- Does not fork the issue taxonomy or triage doctrine — it cites the canonical docs.
- Does not change board visual semantics, effort/priority/taxonomy semantics, or dispatch/wake/CDD/label behavior.
04 同仓库更多 Skills
issues/triage
Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close/supersede/defer.
issues/taxonomy
Issue label taxonomy pointer. Use when classifying an issue's kind/area/priority/effort/status/protocol/dispatch labels, or when the board needs to interpret them.
issues/map
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/HTML output contract.
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/iterations/INDEX.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.
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/main while α/β polling sessions are in-flight.
dispatch
Dispatch-time wire-format contract between γ (orchestrator) and α/β (workers). Use when γ authors a dispatch prompt for α or β, when δ enriches an under-specified prompt at routing time, or when α reads the implementation-contract block at intake.