@c4a/context-cli 0.7.0 → 0.7.4

package/providers/context/resources/procedures/document-optimization.md

@@ -1,110 +0,0 @@
----
-id: procedure.document-optimization
-kind: procedure
-mediaType: text/markdown
----
-
-# Source-constrained editorial revisions
-
-This optional phase improves the publication value and readability of approved
-file and document prose without mutating the approved page. It runs only when
-`package.json.context.documentOptimization` is true.
-
-Run the Route-selected plan command. Each fragment is one source-backed Context
-Section and includes mechanical readability signals, allowed actions, exact
-line ranges, and source identity. Read every returned Section and write one
-decision for each fragment to the returned `payload_target`:
-
-- `keep` when it is already useful and readable. If the fragment has any
-  mechanical signal, include a concrete `assessment` that explains why every
-  signal is a false positive or why changing the Section would reduce source
-  fidelity. `high` signals cannot be kept unchanged. Name every remaining
-  `review` signal code in that assessment so the CLI can verify complete
-  coverage; do not use one generic assessment for a batch;
-- `repair` for local typography, Markdown, spacing, or a descriptive link label
-  whose purpose is already stated in the same Section;
-- `reshape` for source-preserving structural changes such as a wide table into
-  a short index plus detail entries, or a long paragraph into stable headings;
-- `omit` only when the plan permits it and the selected reason matches a
-  mechanically identified non-knowledge Section.
-
-An unanswered question set, empty placeholder, decision-free draft, duplicate,
-or obsolete-only Section may be omitted. Questions with answers, limitations
-with impact and action, and deprecations with a replacement remain knowledge.
-Mechanical signals are review leads, not a complete readability verdict. Read
-every fragment even when it has no signal. A mixture of false positives and
-valid repair candidates does not justify keeping the whole batch unchanged.
-Signals marked `high` are deterministic presentation obligations. A repair or
-reshape is rescanned against the effective replacement and cannot complete
-while one of those signals remains. Signals marked `review` require semantic
-inspection and may be kept only with the signal-specific assessment below.
-Every actionable signal must end in a safe edit, an eligible omission, a
-batched input request, or a Section-specific explanation that the signal is a
-false positive or that the edit would damage source fidelity. Time, token or
-compute cost, workload, batch size, deadline, and desire to finish sooner are
-never valid reasons to keep, skip, defer, or reduce an optimization. Do not
-default a batch to `keep` because it contains many fragments; finish the
-complete current batch with the same quality standard as a single fragment.
-Signals that recommend `request-input` identify ambiguous currency, ownership,
-link purpose, or sensitive values. The plan returns all of them in
-`input_requests`: ask one concise, batched question and wait before applying
-the complete optimization payload. Do not convert a required input into
-`keep` merely to avoid a pause. Preserve the exact destination of a volatile
-URL and safely improve its descriptive label or surrounding layout when the
-same Section already states its purpose; ask only for information that cannot
-be recovered from the approved Section or its source evidence.
-
-In fully managed operation, apply every safe `repair`, `reshape`, and eligible
-`omit` autonomously and continue until the optimization status is current.
-Managed authority removes routine review pauses, not quality work or genuine
-missing-input boundaries. A large repair set is expected work, not a blocker.
-If an `input_requests` batch remains after completing all independently safe
-analysis, ask once for that batch and resume from the returned Route.
-
-If the same current-batch quality problem fails three consecutive apply
-attempts, stop the automatic revision loop and follow
-`route.document-optimization.guidance-required`. Present one aggregated report
-for all affected Sections and ask for content-organization, source-fidelity, or
-missing-material direction. Do not restart Sections that already pass. A
-successful complete-batch apply clears the temporary retry record; retry
-history is never knowledge or package content.
-
-Keep all work inside the same source Section. Preserve link destinations,
-images, code, commands, numbers, identifiers, conditions, and source markers
-exactly. Do not introduce facts, infer an answer, or replace a complete
-contract with a summary.
-
-After the complete payload is ready, execute the exact `next_action.command`
-returned by the plan. Context rejects stale, incomplete, duplicate,
-cross-Section, protected-value, semantically broad, or unexplained signaled
-`keep` decisions. It also rescans every repair and reshape against the same
-mechanical analyzer before writing the revision; submitting a decision is not
-proof that the effective Markdown is clean. A repair or reshape that retains a
-review-confidence signal must include a Section-specific assessment naming
-that signal. The apply result reports each signal as `resolved` or `justified`
-with its source and post-revision range. The assessment and rescan detail are
-used only to audit the current decision and are not stored in approved
-knowledge, revisions, or package output. Unchanged
-Sections reuse their previous decision; changed Sections alone return to this
-phase.
-
-Only pages with reader-visible changes are stored. A revision is a full
-Markdown sidecar beside its approved page: `knowledge/guides/setup.md` becomes
-`knowledge/guides/setup__revision.md`. Default knowledge discovery excludes the
-reserved suffix. The filename derives the base page; the revision stores only
-the base digest that cannot be derived. Unchanged Sections inside a full
-revision are inferred. A page with no changes stores one derived negative cache
-key below `.tmp/context-runtime/document-optimization/`; replacement prose and
-Section metadata are never duplicated there. An omitted Section keeps its
-lifecycle marker in the revision so its source identity remains auditable, but
-its reader-visible body and all revision audit state are absent from `dist/`.
-
-For a later user-requested correction, use `context revise "<title or approved
-path>" --format json`. The resulting `route.document-revision.requested` owns
-target selection, revision editing, and validation; it also works when broad
-document optimization was not previously enabled. The compatibility entry
-`context optimize-docs revise` accepts the same selectors. Validation rejects
-lifecycle metadata changes, stale page baselines, protected-value changes,
-cross-Section rewrites, unsupported omissions, and invalid Markdown structure.
-A source change makes the revision a blocking conflict instead of silently
-applying it. Do not create fragment JSON files or another revision namespace.

package/providers/context/resources/procedures/document-revision.md

@@ -1,36 +0,0 @@
----
-id: procedure.document-revision
-kind: procedure
-mediaType: text/markdown
----
-
-# Conversational document correction
-
-Use this procedure only for a correction explicitly requested by the user after
-an approved knowledge page already exists. The request selects one page; it
-does not authorize a free rewrite or a change to source facts. It may repair or
-reshape reader-visible content within one existing Context Section, and may
-omit a complete Section only when the current source supports a documented
-non-knowledge reason.
-
-1. Run the Route command `context optimize-docs revise-current --format json`.
-2. Read the complete approved page and its sibling `__revision.md` page named
-   by the returned plan. Check the cited source when the requested correction
-   could change a fact rather than formatting or wording.
-3. Edit only the returned revision page. Preserve its frontmatter identity,
-   `context_revision` baseline, Context section boundaries, evidence markers,
-   link destinations, images, code, numbers, identifiers, and supported facts.
-   A wide table may become an index plus detail entries, and a source-backed
-   list may be reorganized, but facts cannot move across Section boundaries.
-   Never edit the approved base page for this operation.
-4. Run `context optimize-docs validate --format json`. If validation reports a
-   stale baseline, protected-value change, unsupported omission, broad rewrite,
-   or missing evidence, stop and report the exact finding instead of weakening
-   the correction.
-5. Continue from the returned `context status --format json` Route. A valid
-   correction makes the package stale, so the normal build Route will offer
-   compilation without requiring a second correction decision.
-
-If the entry returned more than one target candidate, select a candidate only
-when the user's wording or current conversation identifies it uniquely;
-otherwise ask the user which approved page to correct. Do not guess.

package/providers/context/resources/procedures/prose-align.md

@@ -1,68 +0,0 @@
----
-id: procedure.prose-align
-kind: procedure
-mediaType: text/markdown
----
-
-# Prose structure alignment
-
-Alignment proposes source-bound knowledge structure. It does not write approved
-knowledge.
-
-Follow the current route's evidence view and input schema. Prefer source heading
-and block boundaries when they preserve coherent reading units; fixed line
-windows are only a fallback for unstructured text. A page may contain multiple
-sections, each with its own continuous evidence span.
-
-The default `read-plan` is the authoring packet for ordinary documents. It
-includes the payload contract, a compact canonical source-ref map, exact source
-body resources, the recommended scratch path, and the direct stage command.
-Do not separately request `schema`, `source-index`, or `existing-knowledge`
-unless the packet reports truncation or the task specifically needs an existing
-approved identity. Those views are diagnostics and large-source fallbacks, not
-mandatory workflow steps.
-
-Every `context.source-body/*` item selected in `workflow.current.resources`
-is source evidence, not supporting metadata. Read the complete Markdown file
-when its `read_state` is `read-required`. A source index, heading tree, token
-count, or successful capture never substitutes for body reading. A matching
-content digest receipt may be reused only while that text remains available in
-the current conversation. After reading every selected direct path, execute the
-single `resources.after_read.command`. For a generated Context View, execute
-its materialization command, read its complete file, then execute its exact
-`next_action.command`. Context carries the merged receipt file forward. A Route
-revision change does not invalidate unchanged bytes, but every lifecycle
-command remains revision-bound.
-
-When the route returns `payload_target`, write the Agent-authored structure input
-to its recommended `.tmp/agent-payloads/` path. This scratch area is separate
-from CLI-owned `.tmp/context-runtime/` and can be discarded after a successful
-stage. The recommendation does not restrict an explicit user-selected path.
-
-Stage all required source/collection slots before batch Review. Structure
-confirmation is an explicit gate. A confirmation applies only to the staged
-slot digest shown by the route; if the digest changes, confirm again.
-
-When the current Route exposes `batch`, author every listed target payload in
-one Agent planning pass, then write the small batch manifest to `batch.input`.
-Use `batch.validate.command` for a read-only all-target check or
-`batch.stage.command` to validate every target before any stage begins and then
-write the ready slots serially. The manifest contains only each `phase_id` and
-its structure payload `input` path; it does not merge document semantics or let
-the CLI choose page structure. A failed preflight writes no slot. If a later
-filesystem write fails, the result identifies completed slots and the Route
-remains recoverable.
-
-`--stage` performs the same validation and deterministic self-repair as
-`--validate`; use the separate validation command only for a diagnostics-only
-pass. In a managed conversation, a valid stage also records structure
-confirmation in the same write. Validation states are literal: `ready` may
-stage, `repair-required` may not, and `invalid` contains errors. `valid` is true
-only for `ready`; `error_free` distinguishes a blocker-only result from one
-containing errors. `self_healed` reports the input and output Section counts,
-how many original Sections were split, and the structural reason codes used by
-the repair.
-
-Independent read-only evidence views may run in parallel. Structure stage,
-confirmation, compile writes, and Review application are serial lifecycle
-mutations; execute them in the order selected by `workflow.current`.

package/providers/context/resources/procedures/prose-compile.md

@@ -1,23 +0,0 @@
----
-id: procedure.prose-compile
-kind: procedure
-mediaType: text/markdown
----
-
-# Source-bound prose compilation
-
-Compile materializes review candidates from confirmed structure and source
-evidence. It never writes directly to approved knowledge.
-
-The CLI derives this projection mechanically from the confirmed section ids,
-kinds, and source spans. Run only the revision-bound compile command returned
-by the current Route. Do not create compile-action payloads or rewrite source
-content.
-
-One compile command validates every owned view first, then atomically
-materializes the source/collection candidate batch. In an explicitly managed
-conversation, the host loop may continue across the remaining deterministic
-compile slots after this procedure has been read; it re-evaluates revision and
-validation state after every write. The current structure view is optional
-inspection context because the CLI consumes the confirmed structure directly.
-Do not open a partial Review while planned views remain.

package/providers/context/resources/semantic/align/candidate-resolution.md

@@ -1,106 +0,0 @@
----
-id: context.semantic.align.candidate-resolution
-kind: procedure
-media-type: text/markdown
-applies-to:
-  - duplicate
-  - conflict
-  - stable_id
-  - path
-  - unresolved
----
-
-# Candidate Resolution Rules
-<!-- Context workflow semantic resource. -->
-
-Use these rules after reading the current align evidence views and before
-authoring `context.structure.v1`. They define how current anomaly diagnostics
-map to supported structure outcomes.
-
-## Anomaly Signals
-
-Anomaly diagnostics are mechanical warnings. Do not ignore them and do not treat
-them as recommendations.
-
-For each anomaly, choose one current outcome and record the reasoning in the
-structure payload or user-facing explanation:
-
-| Outcome | Use When |
-|---|---|
-| Accept the correction | The anomaly points to a real structure fix. Apply a concrete node, section, edge, or ownership correction supported by source refs. |
-| Dismiss with rationale | The warning is mechanically true but semantically harmless. Keep the structure and state why in the confirmation summary. |
-| Keep unresolved | The warning changes structure but source evidence is insufficient. Add an `unresolved[]` item instead of guessing. |
-
-Known anomaly kinds:
-
-| Kind | Meaning | Required handling |
-|---|---|---|
-| Missing evidence | A proposed node, section, or edge has no source-backed evidence. | Add source refs, remove it, or keep the issue unresolved. |
-| Structure churn | A node was renamed, split, merged, replaced, or rejected during investigation. | Confirm the final id/title/target with the user or keep the ambiguity unresolved. |
-| Duplicate evidence | The same source ref appears more than once for the same semantic role. | Deduplicate it or explain why the repeated ref supports different roles. |
-| Broad review needed | The CLI collapsed many anomalies or reports aggregate risk. | Review the affected structure broadly; do not finalize solely from ordering. |
-
-## Stable References
-
-Use stable `node_ref`, `view_ref`, and `section_ref` values from the current
-`context.structure.v1` payload for in-payload references. A NodeRef should be
-safe, lower-case, and path-shaped, such as `entity/rspack` or
-`domain/build-tooling`. `slug` is the required stable filename choice for a
-View. `path` is derived from collection, optional containment, and slug; omit
-it or use the exact CLI-derived value. Do not invent alternate reference
-aliases.
-
-When an edge or section points at knowledge:
-
-- use the schema ref that matches the target layer:
-  `node_ref` for a conceptual Node, `view_ref` for a collection view, and
-  `section_ref` for a planned section;
-- ensure the target NodeRef, ViewRef, or SectionRef exists in the current
-  structure or approved knowledge;
-- keep relation hints unresolved when the target does not exist;
-- follow CLI diagnostics if a ref is unknown or stale.
-
-Do not create alternate alias fields or non-schema candidate ledger fields.
-They are not part of the current structure contract.
-
-## Visible Labels And Audit Rationale
-
-Humans need to understand merge, reject, rename, and replacement choices
-without decoding temporary ids. Keep that discipline in the current structure
-flow through current fields:
-
-- use `title` and `summary` to name the final node in user-facing language;
-- explain renamed/split/merged candidates in the confirmation summary, not by
-  adding non-schema label fields;
-- when a relation or rename cannot be settled from evidence, put the visible
-  title/target clue in `unresolved[]`;
-- when asking the user, phrase the choice with business labels ("Rspack build
-  tool page" vs "Webpack page"), not with source refs or internal section ids.
-
-NodeRef is the stable conceptual identity. ViewRef is the collection-specific
-view identity and is the durable approved-page identity. SectionRef is the
-stable planned-section identity under a ViewRef. Package paths are derived from
-the approved ViewRef plus containment/slug; do not treat paths as an alternate
-identity contract. Visible labels help humans review the choice, but they do
-not authorize a different NodeRef, ViewRef, edge, or section ownership without
-source-backed evidence and user confirmation.
-
-## Duplicate And Conflict Handling
-
-- Exact duplicate structure -> keep one node/section/edge and explain the
-  duplicate in the confirmation summary.
-- Same topic but different evidence boundary -> keep separate sections only
-  when each section has a distinct source-backed role.
-- Conflicting facts -> ask the user or keep an `unresolved[]` item. Do not
-  pick a winner from title order or source order.
-- Replacement or rename -> ask the user when it changes NodeRef, ViewRef,
-  containment, slug, or the derived approved path. These are durable user-facing
-  identities, not disposable labels.
-
-## Self-verify
-
-- [ ] Every accepted node, section, and edge has source-backed support.
-- [ ] Every unresolved relation or conflict is explicit in `unresolved[]`.
-- [ ] No non-schema candidate ledger fields or alias fields appear in the payload.
-- [ ] NodeRef, ViewRef, and SectionRef values, not temporary labels or paths,
-  are used for current references.

package/providers/context/resources/semantic/align/density-profile.md

@@ -1,41 +0,0 @@
----
-id: context.semantic.align.density-profile
-kind: procedure
-media-type: text/markdown
-applies-to:
-  - coverage
-  - reading_density
-  - structure
----
-
-# Evidence Density Selection
-<!-- Context workflow semantic resource. -->
-
-Use density as a private reading and section-planning strategy. It is not a
-separate payload, not a quality score, and not a workflow stage. Persist only
-current `context.structure.v1` fields such as `nodes[]`, `sections[]`,
-`source_refs[]`, `edges[]`, and `unresolved[]`.
-
-Apply this reference when a captured source is long, dense, fragmented, or hard
-to split into stable planned sections. Use the current CLI evidence views
-(`read-plan`, `source-index`, `span-detail`, `span-text`) to inspect material;
-do not invent a separate coarse-read artifact.
-
-| Profile | Use When | Agent Behavior |
-|---|---|---|
-| `macro` | A long source has many headings, sections, or broad topic shifts. | Create section proposals around major headings and preserve document-level anchors so later passes do not flatten scope. |
-| `meso` | Default for normal product, design, or operational documents with several related sections. | Produce section proposals for meaningful local units and preserve evidence anchors. |
-| `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. | Keep anchors minimal and avoid over-segmentation, but still validate the resulting structure. |
-
-Treat Markdown heading changes as section-planning hints, not hard boundaries.
-Sibling sub-headings under a shared parent can remain in one planned section
-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.
-
-Do not let density alone choose `node_type`, `tags`, `section.kind`, or body
-content. Action/domain gates are decided from source evidence and the current
-schema, not from density metadata.