@c4a/context-cli 0.7.14-beta.1 → 0.7.15

package/providers/context/resources/procedures/knowledge-updates.md

@@ -200,6 +200,48 @@ coverage by mechanically placing every new page under an unrelated catch-all.
 Build reports missing bindings for the Agent to resolve; it does not classify
 content. Moving a menu entry does not change the article URL.
 
+### Preserve established navigation intent
+
+Before placing new knowledge, read the workspace's AGENTS.md, current
+`src/knowledge-map.yaml`, existing overview pages and relevant category/article
+bodies. Reuse any settled directory intent in the current plan. Establish what
+each affected category helps readers do and why adjacent categories are separate;
+do not infer this from labels alone. Read only affected branches and enough
+neighboring content to distinguish them, not the entire library on every update.
+If intent remains ambiguous, state the proposed interpretation in the plan.
+
+Prefer, in order: revise an existing article; add a page to a matching category;
+add a coherent child category; propose a top-level change only when existing
+categories cannot serve a distinct, lasting reader need. Do not create a top-level
+category merely because a source, repository, product, team or batch is new.
+For example, a new assistant's usage guide, frontend integration and runtime
+architecture can belong in existing usage, frontend and backend categories, with
+cross-links for the shared product. Keep them together only when the site's
+established organizing principle supports that choice.
+
+In the work-start report or current plan, briefly state the affected articles'
+intended placements and reused category intent. For proposed top-level additions,
+renames, removals or changes of purpose, show the before/after tree, why reuse is
+insufficient, affected existing pages and reading order. Present that change for
+human review before applying it. This uses the existing report feedback where
+available; do not add a new CLI state, schema field or routine per-article gate.
+Explicit user approval of that concrete structure is sufficient; do not ask again.
+General permission to write knowledge or organize batches is not approval to
+change the site's top-level organization. If the need emerges after report
+approval, update the same plan and ask about that structural change only; continue
+independent work within the approved organization.
+
+Before delivery, compare the resulting map with the approved plan: article
+placement matches its main reader task, titles match the bodies, sibling ordering
+is deliberate, and directories are neither empty nor accidental duplicates.
+Honor the workspace's chosen directory depth and homogeneous sibling convention;
+where it requires directory-only or article-only siblings, do not mix them.
+Use an "Other" group last only for genuinely useful residual content, not to
+avoid classification. Apply supported map adjustments through the current CLI
+flow, retaining article identities and URLs. Record lasting category intent
+briefly in the workspace AGENTS.md or existing organization guide; do not create
+a separate taxonomy ledger or put planning instructions in reader articles.
+
 ### Reader tasks, names and reading order
 
 Read the affected articles' bodies before changing their categories or titles.
@@ -257,8 +299,8 @@ change does not require a prose rewrite or file migration; changing its label do
 not silently rename the approved article. Needed title or content revisions use
 the existing revision and Review flow. Splits and merges use ordinary article
 tasks, link repair and any explicit retirement after replacement content is
-delivered. These are Agent editorial decisions, not new CLI checks or approval
-gates.
+delivered. These are Agent editorial decisions, not new CLI checks or routine per-article
+approval gates. Top-level changes follow the focused review described above.
 
 ## Edit one section or review part of a batch
 
@@ -283,6 +325,12 @@ input without that flag to continue. A preview is not approval and does not make
 a stale revision valid.
 
 Review can approve checked pages while leaving repair pages pending. The HTML
+report shows the current site navigation, candidate changes and expected file
+paths. Unchanged approved pages retain their titles with omitted bodies. Enter
+revision instructions directly in the report; the copied code and following
+instruction lines must be returned together without edits. The CLI binds them to
+the reviewed content and baseline and returns repair commands while leaving
+those pages pending. Changed candidates require a fresh review. The HTML
 review code includes pending positions; managed Review provides the same current
 scope as a JSON template. Send decisions only for pages actually reviewed. Omit
 means a durable exclusion, not repair. Partial approval alone does not build.

package/providers/context/resources/procedures/production-requirements.md

@@ -59,3 +59,26 @@ contains `path`, `question`, `sources` and `batch`, with optional `brief` and
 command to prepare those tasks without a separate investigation-plan submission.
 This does not approve the report or permit writing before user feedback.
 When targets are unclear, use normal preparation and investigate the skeletons.
+
+## Configured coverage and the current request
+
+`src/indexers.yaml` describes the workspace's standing coverage configuration.
+Source registration or presence in that configuration does not, by itself, mean
+that the source needs investigation again for this request. For a bounded document
+addition or revision, identify its reader task and actual evidence dependencies;
+reuse existing approved articles and applicable completed work. Do not broaden a
+document task to unrelated code repositories merely because they are configured.
+
+In planning and completion reports distinguish:
+- work requested and completed in this task;
+- specific content gaps established by reading, with their affected reader tasks;
+- source/environment failures, and whether this task depends on those sources.
+
+A `pending_scopes` count is workflow state, not a count of missing topics,
+repositories to rewrite, or articles to produce. A Git spawn/baseline-read error
+means source availability could not be checked; it does not prove that existing
+knowledge is absent or obsolete. If unrelated configured sources remain blocked,
+say so as a workflow limitation rather than announcing new investigation work.
+Do not delete configured sources, invent exclusions, clear stage files, or mark
+unread material investigated to make the current task appear complete. Follow the
+returned resolution action when the workflow still needs a decision.

package/providers/context/resources/procedures/runtime-event-delivery.md

@@ -22,12 +22,18 @@ remove the Agent host's network approval boundary. Satisfy that boundary by
 requesting host network escalation in the tool invocation that executes the
 flush, not by turning it into another conversational approval gate.
 
-Before requesting network access, run:
+When first requesting host network access, or diagnosing an unknown destination, run:
 
 ```bash
 context logs plan --format json
 ```
 
+When delivery is already authorized and the fixed destination and data policy are
+unchanged, execute `context logs flush --format json` directly. A prior plan
+receipt is not a CLI prerequisite. Do not repeatedly plan or ask for consent on
+retries. `invalid_batch` from the command bridge is local protocol rejection before
+HTTP; repair/update the compatible sink client rather than retrying network access.
+
 The plan is the audit contract. It reports the canonical workspace outbox,
 normally `.tmp/context-runtime/logs/outbox.jsonl`, the event count and kinds,
 the allowlisted property names, the sink command, and the resolved HTTP

package/providers/context/resources/procedures/work-start-report.md

@@ -78,6 +78,53 @@ Estimate timing or savings only when supported by measurements and conditions.
 For a small addition to an existing site, describe only the affected reading
 position; reuse its layout and delivery choices instead of proposing them again.
 
+## Confirm image handling for large tasks
+
+Before bulk image interpretation or article writing, count distinct image resources
+across the current authorized task (all its sources, not each document or batch).
+Use source descriptors and capture reports; do not download images just to count
+or recount unchanged snapshots. If the count exceeds 30 and the user has not
+already selected a policy for this task, include one image-handling question in
+this planning confirmation, in the user's language:
+
+- **Process all (default): intelligent conversion and inclusion.** Read images as
+  needed; retain useful images or convert suitable content into text, tables or
+  diagrams. Conversion is an Agent writing decision supported by actual reading.
+- **Include all:** retain the image presentation; automatic compression and safe
+  processing still apply. An image that cannot be processed within limits becomes
+  a visible placeholder, not an unlimited original-byte delivery promise.
+- **Include none (placeholders):** skip image bytes and interpretation; preserve
+  placeholders and source document links. Do not claim image-content coverage.
+
+Default means the recommended option, not consent after silence. Wait for this
+choice together with the existing plan confirmation; never add per-image or
+per-batch approval. Reuse an explicit choice and any GIF exclusions throughout
+retries. Persist the choice in the existing plan/requirements. If discovery only
+reveals the threshold after initial capture, ask before further image work and
+writing; do not restart completed capture solely to show this question.
+
+Report the known count and unknown resources separately. If the scale was unknown
+and later crosses 30, ask once at that point. At content Review summarize retained,
+converted and placeholder outcomes with reasons, including automatic fallbacks;
+do not ask the same policy question again. A later material policy change belongs
+in the existing plan and normal Review, not a separate approval protocol.
+
+Use `captureLark.resources.images: reference-only` for excluded images and
+`resources.gifs: reference-only` for an explicit GIF exclusion. Both inclusion
+choices use normal capture and package optimization; the Agent controls semantic
+conversion. See the Lark resource guide for configuration and limitations.
+
+## Review navigation changes in context
+
+Read the knowledge-updates guidance on preserving established navigation intent.
+For an existing site, explain the category intent being reused and the affected
+article placements. A new source or product is not a reason for a new top-level
+menu. If a top-level addition, rename, removal or purpose change is warranted,
+include its before/after tree, reuse alternatives and impact in this report.
+Obtain explicit feedback before applying that structural change, reusing a
+concrete structure already approved by the user. If it emerges later, update this
+same plan and review only the changed decision; do not restart approved batches.
+
 ## Mandatory feedback
 
 Write the scratch report using the host file tool, show its clickable path,
@@ -108,3 +155,39 @@ Reports, plans, skills, candidates, confirmation and transaction process stay in
 `.tmp`. Only formal results and necessary long-term source/requirement decisions
 belong in non-temporary storage. On a new machine, start new production from those
 formal inputs, without requiring the previous report or production session.
+
+## Inputs for the content Review report
+
+Keep approved article titles, paths, reading order and intended placements in the
+normal article plan and knowledge map. Complete their existing structure workflow
+before presenting content Review. The CLI collects those inputs and the actual
+candidate bodies to render the report; do not ask an Agent to fabricate a site
+snapshot, infer approved content from titles, or maintain a second report model.
+For a new workspace, plan the initial categories through the same workflow; the
+report will label its candidate pages New. If it shows unplaced articles, finish
+those placements rather than presenting the fallback as an approved new category.
+Content Review displays changes; it does not replace specific authorization for
+a top-level navigation change already required by this procedure.
+
+## Configured coverage and the current request
+
+`src/indexers.yaml` describes the workspace's standing coverage configuration.
+Source registration or presence in that configuration does not, by itself, mean
+that the source needs investigation again for this request. For a bounded document
+addition or revision, identify its reader task and actual evidence dependencies;
+reuse existing approved articles and applicable completed work. Do not broaden a
+document task to unrelated code repositories merely because they are configured.
+
+In planning and completion reports distinguish:
+- work requested and completed in this task;
+- specific content gaps established by reading, with their affected reader tasks;
+- source/environment failures, and whether this task depends on those sources.
+
+A `pending_scopes` count is workflow state, not a count of missing topics,
+repositories to rewrite, or articles to produce. A Git spawn/baseline-read error
+means source availability could not be checked; it does not prove that existing
+knowledge is absent or obsolete. If unrelated configured sources remain blocked,
+say so as a workflow limitation rather than announcing new investigation work.
+Do not delete configured sources, invent exclusions, clear stage files, or mark
+unread material investigated to make the current task appear complete. Follow the
+returned resolution action when the workflow still needs a decision.

package/providers/context/resources/templates/work-start-report.md

@@ -44,7 +44,13 @@ modules, public capabilities, product operations or another evidenced structure.
 Distinguish navigation groups from sourced articles; reuse articles rather than
 duplicating bodies. Retain existing KB, website and LLMS delivery choices.
 
-For website delivery, add a compact sketch showing the site title, top-level
+For an existing site, summarize the existing categories' intent and affected
+article placements. For a proposed top-level change, show the before/after tree,
+why existing categories cannot accommodate it and the affected pages/order.
+Mark it as a decision for review; omit this comparison when top-level structure
+is unchanged. Reuse explicit prior approval of the concrete structure.
+
+For a new website or an approved navigation redesign, add a compact sketch showing the site title, top-level
 groups, a representative left menu, article chapters and on-page outline.
 For a new homepage or requested redesign, also propose a short title, slogan,
 description and the verified optional resource cards. Briefly explain mobile

package/providers/context/skills/work-production-stage/SKILL.md

@@ -9,7 +9,9 @@ in the user's conversation language.
 When planning or revising article placement, titles or reading order, read
 [reader organization guidance](../../resources/procedures/knowledge-updates.md#reader-tasks-names-and-reading-order).
 Apply it to the affected topics within the user's scope; it adds no production
-stage or permission gate.
+stage. Reuse existing category intent; propose top-level changes in the current
+report/plan for explicit review before applying them, unless the concrete
+structure is already approved. Ordinary placements need no additional gate.
 
 For investigation, use the supplied directory and its submission schema. Start
 with code skeletons and document outlines; selectively read original material