@c4a/context-cli 0.6.3 → 0.6.4

package/providers/context/resources/procedures/package-output.md

@@ -35,3 +35,24 @@ maintain the complete final Skill directory name in the template, such as
 
 Package output is incremental: a built package is current only for the approved
 knowledge and template digests recorded by its receipt.
+
+When declaring a new KB package, make resource delivery an explicit author
+choice. Offer Git raw when the workspace is in Git or the author supplies a
+raw `urlPrefix`; it keeps package payloads small and uses either the derived
+commit-pinned URL or that explicit prefix. Context does not check whether those
+files are committed, pushed, or remotely readable; that remains the package
+author's responsibility. If neither Git nor an explicit prefix is available,
+offer bundled resources or explicit omission; omission keeps unresolved links
+and must be described as such. Do not infer repository identity or invent a raw
+host URL.
+
+Large image optimization applies only to bundled delivery. Without an `assets`
+declaration, existing workspaces continue to copy selected resources
+byte-for-byte. If build or status reports
+`package.assets.optimization-recommended`, explain that the current package is
+valid but contains more than 20 MiB of eligible PNG/JPEG resources. Do not
+install a dependency or edit project configuration automatically. If the user
+chooses to optimize the package, use the exact reported setup command and add
+the reported `kbPackage().assets.optimize` value. The processor is installed in the
+Context workspace, not bundled into Context itself. Optimization changes only
+`dist/`; source snapshots and approved resources remain unchanged.

package/providers/context/resources/semantic/align/gates.md

@@ -249,7 +249,7 @@ Each source must include `rationale` when inferred and at least one of `source_r
 ## Final Reflection
 
 - 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, or add source-backed structure that reaches at least two distinct Section kinds / one child Action. The CLI does not use source prose keywords to grant an exception.
+- Action only supports one Section -> confirm its standalone retrieval value, write it as a Section under its owner, or add another source-backed Section / child Action. Multiple source-backed Sections may use the same kind; the CLI does not manufacture semantic variety to validate an Action.
 - 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.
 
@@ -267,7 +267,7 @@ checks as deterministic diagnostics:
 | `node.thin_concrete_entity` | A concrete Entity has one Section and no child Nodes. | Keep it only when it has stable standalone retrieval value; otherwise merge it into the owning Node. |
 | `node.children_should_be_sections` | One parent contains many same-source, single-section child Entities with no stable shape tag. | Merge those children into parent Sections unless the user confirms each child has standalone lookup value. |
 | `node.term_expanded_beyond_definition` | A `term` Entity has grown past a compact definition or owns children. | Move rules, procedures, designs, and examples to the owning Node; keep the term entry narrow. |
-| `node.action_too_thin` | An Action has fewer than two distinct planned Section kinds and no child Action. | Downgrade it to a Section under the owning Node, add a distinct Section kind, or add a child Action; the CLI does not infer a single-section exception from source text. |
+| `node.action_too_thin` | An Action has one planned Section and no child Action. | Confirm its standalone retrieval value, keep it as a Section under the owning Node, add another source-backed Section, or add a child Action. This warning does not require artificial Section-kind diversity. |
 | `node.domain_without_children` | A Domain has no source-backed `contains` child edge. | Add supported children, keep an explicitly confirmed no-write placeholder, or reclassify the Node. |
 | `tags.child_inherits_system` | A child Entity repeats its parent `system` / `application` scope tag. | Retag by the child’s own shape/scope, or keep the child as a Section if it is only a local aspect. |
 | `edge.confidence_invalid` | An edge declares a confidence value outside the current schema. | Use only `possible` or `hypothesis`, or omit the field for source-certain relations. |

package/providers/context/resources/semantic/align/structure-planning.md

@@ -256,9 +256,14 @@ It splits non-contiguous Section mirrors and can expand a broad cross-heading
 Section into Markdown structural groups within the same View. Apply the
 non-blocking repair hint when the groups should be independently retrievable;
 otherwise keep the Section and explain the grouping in structure review.
-Oversized Views still require the Agent to apply the returned child-View and contains-edge suggestions while
-classifying every child Node from evidence. The repair command does not resolve
-orphan ownership, unsupported evidence, or competing semantic groupings.
+Oversized Views still require the Agent to apply the returned child-View and
+contains-edge suggestions while classifying every child Node from evidence.
+Those suggestions preserve Section order and place adjacent Sections into
+bounded groups; `part-N` names are placeholders, not semantic titles. Rename
+and classify each child from evidence instead of expanding one child View per
+Section or treating the suggested grouping as a content decision. The repair
+command does not resolve orphan ownership, unsupported evidence, or competing
+semantic groupings.
 
 When the cited source sentence itself is uncertain, preserve that uncertainty on
 the edge with `confidence: possible` or `confidence: hypothesis`. This is only