@c4a/context-cli 0.5.41-beta.5 → 0.5.41-beta.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@c4a/context-cli",
-  "version": "0.5.41-beta.5",
+  "version": "0.5.41-beta.6",
   "type": "module",
   "bin": {
     "context": "./cli.js"

package/plugin/commands/align.md

@@ -27,7 +27,7 @@ For protocol discovery, prefer narrow commands:
 
 - `context schema workflow.next-action-envelope.v2 --view minimal --format json`
 - `context protocol show align-compile --format json`
-- `context schema align-structure-intent --view minimal --format json` — includes required fields, enums, mount matrix, and a minimal authoring example; use full schema only for extended notes.
+- `context schema align-structure-intent --view minimal --format json` — includes required fields, enums, section kind priority/triggers, mount matrix, and a minimal authoring example; use full schema only for extended notes.
 
 ### Step 2 — Read Evidence Through The Single Evidence Path
 

package/plugin/commands/capture.md

@@ -32,7 +32,7 @@ Before choosing a local Markdown capture route, honor the surrounding task conte
 - `$ARGUMENTS` contains `--refresh` → `context capture --refresh`. This refreshes active Feishu URL sources and local Markdown sources whose stored origin file still exists; code sources use `context capture --code`.
 - User asks for code capture with explicit `--module` flags → run `context capture --code $ARGUMENTS`, preserving code flags such as `--module`, `--version`, `--version-from`, and `--no-runner-cache`.
 - User asks to refresh/re-capture an already configured code source → run `context capture --code` unless the user explicitly wants to change package selection or version flags. The CLI reuses stored `capture_config`, appends a new snapshot only when code/version content changes, and never overwrites prior snapshots.
-- User asks to run a configured custom aspect capture → run `context capture --aspect <name...> --format json`. Do not use `context capture --aspect code`; code capture remains `context capture --code` because it owns target path, `--module`, version, and runner-cache flags.
+- User asks to run a configured custom aspect capture → run `context capture --aspect <name...> --format json`. Prefer configured aspect names. If an automation script already supplies a path, it must point to an installed aspect directory in the current workspace and the CLI will treat it as that aspect name. Do not use `context capture --aspect code`; code capture remains `context capture --code` because it owns target path, `--module`, version, and runner-cache flags.
 - User provides one or more code target paths, or asks for code capture without explicit `--module` flags → run `context capture --code $ARGUMENTS --format json` directly. The CLI preflights every target first; if any target is ambiguous it returns candidates without writing, otherwise it captures all selected code targets serially.
   - If the CLI returns candidate packages, ask the user which package paths to capture.
   - Then run `context capture --code <original-target-if-present>` with one repeated `--module <path>` for every selected package. The CLI derives and stores path filtering silently from that selection.

package/plugin/skills/skill-align-workflow/SKILL.md

@@ -82,7 +82,7 @@ Use only `block_ids[]` in `section_groups[]`. Do not invent heading/range/window
 
 Emit `depends_on` edges only when cited source blocks explicitly say one Node consumes, requires, calls, is configured by, or is downstream of another Node as a prerequisite, capability provider, upstream input, runtime dependency, or data-flow source. Direction is consumer/downstream -> provider/upstream. Do not create `depends_on` for parent/child containment, `Related`/`See also` lists, sibling co-occurrence, shared table membership, name similarity, or a plain mention without a dependency predicate. `edges[].evidence_blocks[]` must include the block that states the dependency; if the relationship matters but evidence is missing, leave the edge out or add an unresolved question instead of guessing.
 
-Prefer the strongest source-backed `section_kind` that fits the current schema priority chain; avoid planning an entire dense source as `description` when the evidence clearly contains examples, comparison tables, Q&A, decisions, specs, warnings, or principles. Treat kind precision as a drafting quality preference, not a reason to block an otherwise source-backed write. Keep only raw-backed semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
+Prefer the strongest source-backed `section_kind` using the current schema's `section_kind_priority` and `section_kind_triggers`; avoid planning an entire dense source as `description` when the evidence clearly contains examples, comparison tables, Q&A, decisions, specs, warnings, or principles. Ordinary typical scenarios, case studies, and impact/result examples are `example`, not `incident`, unless the source is explicitly an outage, incident review, postmortem, or dated fault-handling timeline. Treat kind precision as a drafting quality preference, not a reason to block an otherwise source-backed write. Keep only raw-backed semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
 
 Canonical `align-structure-decision` is not a parallel authoring path. Use it only when `next_action.input_schema` explicitly asks for it or when auditing/repairing canonical output returned by the CLI.
 

package/plugin/skills/skill-align-workflow/references/gates.md

@@ -48,6 +48,8 @@ Relation-only sources should not force title copying or dangling graph edges. De
 
 Do not put `planned_sections` inside `domain_gate`. A kept placeholder needs support: `context_only` block(s) with `visible_to`, owned/shared evidence, or finalized graph support. `ignored` blocks only dispose unused material and do not support close materialization by themselves. For Domain placeholders, write only resolved current/existing children in `domain_gate.child_refs`; if all children are unresolved/deferred relation clues, use `child_refs: []` and keep those target hints in pending relation refs. If the source names only an atomic concept and that term is useful on its own, prefer a concise term Entity title without scope/process suffixes.
 
+For no-write placeholder summaries, describe only the preserved page identity and unresolved navigation clues. Do not say the Node "provides navigation/links/relations to X" unless those targets are resolved graph children or rendered links; say the source contains deferred navigation clues instead.
+
 ## Entity Tag Rules
 
 Use `tags` to state what the Entity is. Legal combinations:

package/plugin/skills/skill-compile-draft/SKILL.md

@@ -98,7 +98,7 @@ Confidence is optional. Omit it for ordinary confirmed claims; set it only when
 `description` is the kind for narrative claims that do not match any other form. Before locking in `kind: description` for a snippet, run three classification checks against the cited block:
 
 1. **Atomicity**: single narrative, or multi-step / multi-row / multi-config? Multi → split into the right kinds — each step into its own `spec` / `warning`, each row into a `comparison` Section, each config block into `example` (sample) or `spec` (constraint with a check method).
-2. **Kind-precision**: does a higher-priority kind fit better? A code / config / command block belongs in `example`; a comparison table belongs in `comparison`; a Q+A pair belongs in `faq`; a real incident with timeline belongs in `incident`; a versioned change record belongs in `changelog`; an explicit source-backed choice / tradeoff / adopted path with rationale belongs in `decision` even when only one chosen option is surfaced; a verifiable rule with a check method belongs in `spec`; explicit risks belong in `warning`; a stable design rule or core mechanism without a recorded choice or check method belongs in `principle`.
+2. **Kind-precision**: does a higher-priority kind fit better? A code / config / command block belongs in `example`; a comparison table belongs in `comparison`; a Q+A pair belongs in `faq`; a real incident with timeline belongs in `incident`; ordinary "typical scenario" / case-study / impact-result examples are `example`, not `incident`, unless the source is explicitly an outage, incident review, postmortem, or dated fault-handling timeline; a versioned change record belongs in `changelog`; an explicit source-backed choice / tradeoff / adopted path with rationale belongs in `decision` even when only one chosen option is surfaced; a verifiable rule with a check method belongs in `spec`; explicit risks belong in `warning`; a stable design rule or core mechanism without a recorded choice or check method belongs in `principle`.
 3. **Action threshold**: multi-step fragments that clear the Action bar → emit `op: skip` with a note "evidence warrants sub-Action; re-align needed"; do not create Nodes from this skill.
 
 A Node whose raw is genuinely narrative — definitions, summaries, plain prose without enumerations or normative wording — legitimately ends with description-dominant output. The smell fires the other way: when raw contained enumerations, normative rules, or code blocks, and the draft collapsed them to `description`. Redraft from Step 2 in that case, not from a percentage threshold. Navigation-only evidence is handled separately by the TL;DR navigation rule and Step 2 — the gates above are not the right place to second-guess that path.