@c4a/context-cli 0.5.39-beta.2 → 0.5.39-beta.3

package/package.json

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

package/plugin/README.md

@@ -113,8 +113,8 @@ Measured behavior of Agent + model combinations across instruction following, pa
 |---|---|---:|---|---:|
 | Codex | GPT 5.5 xh | 95 | Almost none | 96 |
 | Claude | Opus 4.6 / 4.7 | 95 | Almost none | 95 |
-| Cursor | Opus 4.6 / 4.7 | 92 | Almost none | 85 |
-| Claude | DeepSeek V4 | 70 | Frequent | 55 |
+| Cursor | Opus 4.6 / 4.7 | 92 | Almost none | 88 |
+| Claude | DeepSeek V4 | 88 | Almost none | 84 |
 | Claude | DeepSeek V4 Flash | 55 | Frequent | 45 |
 
 **Recommendation**: prefer GPT or Opus for now. DeepSeek V4 still lags in instruction following and extraction quality and needs further CLI optimization; full DeepSeek V4 adaptation is planned for v0.5.40, targeting an overall score above 90.

package/plugin/README_CN.md

@@ -111,8 +111,8 @@ bun add -g @c4a/context-cli
 |---|---|---:|---|---:|
 | Codex | GPT 5.5 xh | 95 | 几乎无 | 96 |
 | Claude | Opus 4.6 / 4.7 | 95 | 几乎无 | 95 |
-| Cursor | Opus 4.6 / 4.7 | 92 | 几乎无 | 85 |
-| Claude | DeepSeek V4 | 70 | 经常 | 55 |
+| Cursor | Opus 4.6 / 4.7 | 92 | 几乎无 | 88 |
+| Claude | DeepSeek V4 | 88 | 几乎无 | 84 |
 | Claude | DeepSeek V4 Flash | 55 | 经常 | 45 |
 
 **建议**：目前优先使用 GPT 或 Opus；DeepSeek V4 在指令遵循与提取质量上仍有差距，需配合 CLI 进一步优化，预计 v0.5.40 完成 DeepSeek V4 适配并达到 90+ 综合得分。

package/plugin/commands/compile.md

@@ -77,7 +77,7 @@ For `review_reconcile_decisions`, load the prepare payload through CLI views suc
 
 Invoke `context:skill-compile-judge` only when the top-level `next_action.kind` is exactly `review_reconcile_decisions`. If `questions` are present but `next_action.kind` is `patch_compile_draft`, patch the draft first; do not infer judge mode from question counts.
 
-For `apply_reconcile_review`, `close_compile`, `finish_current_node`, `submit_coverage_disposition`, or `abandon_or_rescan`, execute the returned command exactly. If it rejects, follow the new `next_action` and `reason_code`.
+For `apply_reconcile_review`, execute the returned plain apply command exactly, typically `context reconcile apply --format json`; do not add `--decisions` or stdin. For `close_compile`, `finish_current_node`, `submit_coverage_disposition`, or `abandon_or_rescan`, execute the returned command exactly. If it rejects, follow the new `next_action` and `reason_code`.
 
 ### Step 3 — Repair From Diagnostics
 

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

@@ -71,7 +71,7 @@ Use `next_action.input_schema` or the matching `context schema <name> --view min
 
 For the default `align-structure-intent` path, produce one intent document with semantic Nodes, `section_groups[]`, `ownership_groups[]`, optional explicit `block_ownership[]` patches, and edges. Let CLI generate `section_id` values and expand ownership groups into canonical defaults/exceptions.
 
-Use only `block_ids[]` in `section_groups[]`. Do not invent heading/range/window selectors inside the intent. Every block you leave as `owned` or `shared` citation evidence must appear in some section group; otherwise reclassify it as `context_only` or `ignored`. If a no-write/navigation-only/placeholder-only Node has no section group, set `planned_sections: []` explicitly so the CLI knows this was intentional.
+Use only `block_ids[]` in `section_groups[]`. Do not invent heading/range/window selectors inside the intent. Treat source heading changes as section-planning signals: sibling sub-headings under a shared parent may stay in one Section when they form one coherent semantic topic; headings with no shared parent should usually split unless you intentionally want one Section to span them. The CLI reports cross-heading groups but does not rewrite your semantic grouping. If one semantic section spans non-contiguous citation-eligible blocks, align may accept the grouping, but finalized ownership will split it into compile draft-ready contiguous runs; compile source-refs templates should stay separate by default. Every block you leave as `owned` or `shared` citation evidence must appear in some section group; otherwise reclassify it as `context_only` or `ignored`. If a no-write/navigation-only/placeholder-only Node has no section group, set `planned_sections: []` explicitly so the CLI knows this was intentional.
 
 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 source-supported semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
 

package/plugin/skills/skill-align-workflow/references/density-profile.md

@@ -11,6 +11,8 @@ This reference applies only when the current envelope asks for `next_action.kind
 | `micro` | The source is fragmented, note-like, or dense with short independent claims. | Keep section proposals narrow and avoid bundling unrelated blocks into one candidate. |
 | `single_pass` | The source is short enough that one read can safely discover all relevant structure. | Still emit the `align-coarse-read` artifact, but keep anchors minimal and avoid over-segmentation. |
 
+Treat Markdown heading changes as section-planning hints, not hard boundaries. Sibling sub-headings under a shared parent can remain in one `section_groups[]` entry when they form one coherent semantic topic for that parent. Headings with no shared parent should usually split unless you intentionally want one Section to span them. When a dense source has many headings, split by heading first, then merge adjacent or sibling groups only when the merged Section is still one coherent fact group.
+
 ## Content Signals
 
 `content_signals` are neutral shape signals used later by action/domain gates. They must not directly claim `node_type`, tags, or recommendations.

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

@@ -105,7 +105,7 @@ Use `node_type: domain` only for a scope that groups child Nodes. Fill:
 | `child_refs[]` | Candidate ids, local refs, or final slugs for children in the scope. |
 | `grouping_reason` | Why these children belong together under this domain. |
 
-If a domain has no resolvable child refs, no clear grouping reason, or only one same-file child without a broader scope, emit an Entity instead.
+If a domain has no resolvable child refs, no clear grouping reason, or only one same-file child without a broader scope, emit an Entity instead and choose its Entity tag yourself. The CLI rejects invalid Domain gates; it does not auto-downgrade a Domain or choose fallback tags.
 
 Scope-name titles such as "X 业务域", "Y 领域", "business domain", or "technical area" are a warning sign when proposed as Entity. Keep them as Entity only when the subject is an atomic term or concrete object; otherwise use Domain with `domain_gate.child_refs`.
 
@@ -146,7 +146,7 @@ Each source must include `rationale` when inferred and at least one of `evidence
 
 ## Final Reflection
 
-- Entity cannot pick a legal tag, or depends on its upstream title to make sense -> downgrade to Section or change type.
-- Action only supports one Section -> downgrade to Section. The discriminator is scale, not the presence of "step" words.
+- Entity cannot pick a legal tag, or depends on its upstream title to make sense -> write it as a Section under the upstream Node or change type before submit.
+- Action only supports one Section -> write it as a Section instead of an Action. The discriminator is scale, not the presence of "step" words.
 - Action "steps" are parallel options/configs -> route to Entity `comparison` / `spec` / `description`.
 - Domain has no children -> delete it or merge it into a larger Domain.

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

@@ -157,7 +157,7 @@ For each classified snippet:
    - There is no separate default `evidence-echo` warning. Treat "echo" as an anti-pattern: raw copied only to show basis/evidence, while `source_ref` already provides traceability.
    - For `description` / `spec`, a concise summary plus the cited bullet list is acceptable when the bullets are the useful user-facing knowledge. It becomes echo only when the copied text is not meant to be read as active knowledge.
    - For `example` Sections that cite a code, config, or command fence, keep `content` centered on the cited fenced block. Put framing prose such as "basic configuration example" in `summary`, or cite a separate prose block in a separate action when that prose is itself source-backed knowledge.
-3. For long `content`, add `summary` when it helps readers or query output. Summary is LLM-authored reader/query aid: one plain paragraph, no Markdown, and should stay compact. The CLI only reports advisory hints for missing summaries on long content, Markdown/multi-paragraph formatting, or clearly overlong summaries; it does not enforce a content-length ratio and does not treat summary quality as an evidence failure. Lexical `source_support` checks `content` (and legacy `detail` when present), not `summary`; keep summaries faithful to `content`, but do not copy raw-only keywords into `summary` for lexical scoring.
+3. For long `content`, add `summary` when it helps readers or query output. Summary is LLM-authored reader/query aid: one plain paragraph, no Markdown, and should stay compact. If you cannot write a meaningful summary, omit the field entirely; generic placeholders like "description section covering N evidence blocks" are worse than no summary. The CLI only reports advisory hints for missing summaries on long content, placeholder-like summaries, Markdown/multi-paragraph formatting, or clearly overlong summaries; it does not enforce a content-length ratio and does not treat summary quality as an evidence failure. Lexical `source_support` checks `content` (and legacy `detail` when present), not `summary`; keep summaries faithful to `content`, but do not copy raw-only keywords into `summary` for lexical scoring.
 4. Preserve `required_preserved_literals[]` from the CLI evidence view when the literal is part of the source-backed knowledge. For link-heavy citation-eligible evidence, keep meaningful URLs in `content` when the action writes knowledge; for supporting-only literals, keep them in the repair/challenge context instead of citing them. Do not patch only to satisfy non-blocking URL or style advisories.
 5. Omit `confidence` for ordinary confirmed claims. Assign it only when the evidence is clearly verified, inferred, or speculative according to the schema enum.
 6. Fill `refers_to_nodes[]` per [Glossary and refers_to_nodes](#glossary-and-refers_to_nodes).

package/plugin/skills/skill-compile-draft/references/action-domain-gates.md

@@ -15,7 +15,7 @@ Treat `node.action_gate` as the compile boundary for procedural claims. An Actio
 
 If `action_gate` is absent on a Node whose `type` is `action`, treat it as a structural defect — emit a `structure_challenge` (see `references/structural-challenges.md`) instead of inventing process semantics.
 
-If the current evidence can only support one thin Section or only a parallel option/config list, do not stretch it into procedure prose. Emit `skip` or `structure_challenge` so align can downgrade it to the owning Entity/Domain Section.
+If the current evidence can only support one thin Section or only a parallel option/config list, do not stretch it into procedure prose. Emit `skip` or `structure_challenge` so align can revise the structure; the CLI does not auto-downgrade an Action or choose replacement Entity tags.
 
 ## Domain Nodes (`node.type === "domain"`)
 

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

@@ -17,7 +17,9 @@ decisions only; the CLI reviews, applies, and writes every workspace change.
 ## TL;DR — Non-negotiables
 
 - Invoke this skill only when the caller's top-level envelope has `next_action.kind: "review_reconcile_decisions"` or the prepare payload contains `judge_handoff`. If the active envelope asks for `patch_compile_draft`, `continue_compile_cycle`, or another action, stop and follow that `next_action.command` instead.
-- Input is the budget-safe compile prepare summary. For items with candidates, load only that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`.
+- Input is the budget-safe compile prepare summary. If `page.has_more` is true, follow `next_command` until every prepare item is listed.
+- The summary is an index: use `item_detail_command` only when the full proposed content or full source-support repair details are needed.
+- For items with candidates, load only that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`.
 - Do not inspect workspace storage directly or run ad-hoc scripts to reconstruct candidates. Use only `items[]`, `evidence[]`, `source_support` diagnostics, `candidates[]`, `previous_decisions[]`, and `judge_handoff`.
 - Output exactly one JSON or YAML document with `schema_version: "compile.judge-decisions.v2"` and `decisions[]`.
 - Keep one decision per prepared `item_id`, preserving prepare order.