@c4a/context-cli 0.7.9 → 0.7.10-alpha.2

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

@@ -18,7 +18,7 @@ Record new factual contributions as managed sources before expanding source
 ownership; an editing instruction alone is not a permanent factual source.
 
 Return the full revised Markdown in the supplied output schema, preserving the
-page's identity, source list, and source-bound section markup. Do not silently
+page's stable fragment markers and metadata. Do not silently
 turn paraphrased text into a verbatim quotation. Do not directly write knowledge
 files. Context prepares a Candidate and routes it through the existing Review,
 apply, close, and build steps. Managed mode delegates Review, not source truth.
@@ -27,18 +27,18 @@ If Context reports that the approved page changed, read that version and restart
 the revision. Never overwrite a concurrent edit with the old page snapshot.
 
 When `target.base_digest` is null, this is a new page in the confirmed update scope.
-The supplied Markdown contains only its stable identity and initial metadata.
+The supplied Markdown contains its initial metadata. Article identity stays in the structure.
 Read the specified source material and write the complete page with source-bound
 sections, using the existing purpose and page forms. Do not treat the initial
 heading as an already written page.
 
-Use `target.source_refs` as the final page source list. It can include explicitly
+Use `target.source_refs` as the allowed source scope, not as a list to copy onto the page. It can include explicitly
 selected supporting material absent from the old Markdown. Read that material
 before using it, add only its relevant explanation, and cite it in the affected
 sections. A session rationale is not proof of runtime behavior.
 
 When `target.previous_path` is present, the user explicitly selected a page move.
-Keep its stable Node/View identity. The supplied Markdown already rebases its
+Keep its stable article identity and fragment IDs. The supplied Markdown already rebases its
 relative links for `target.path`; do not put them back at the old location.
 Explain the move in the review summary. Approval moves the page and updates
 incoming Markdown navigation together; do not create a second copy or manually
@@ -49,13 +49,22 @@ For selected `note` inputs, read [note guidance](note.md). For `sessions`,
 read [sessions guidance](sessions.md). Read only the applicable source guide.
 
 
-Read `writing_context` for the selected Provider, reader profile, current sections
-and actual template resources. These apply to direct page corrections too.
+Read `writing_context` for the confirmed reader requirements, current sections,
+authorized source entries and any available skill guidance from this temporary
+work session. A missing skill selection does not invalidate the approved page
+or require restoring a former Provider registration. These inputs apply to
+direct page corrections too.
 Preserve the current page form; choose a different form only for an explicit
 change of purpose. Do not replace API tables with generic explanatory prose.
 The current sections are approved content, not freshly extracted API facts.
-For source updates or an explicit regeneration request, `program_blocks` contains API tables computed from current
-scoped Parser facts with the ordinary deterministic renderer. Select only the
+Ordinary source updates do not automatically parse the repository or generate
+API tables. Read the changed material relevant to the requested correction;
+use a suitable scoped analysis capability when needed. Do not wait for a
+Provider selection, version check or program block before revising ordinary
+prose. Keep actual source citations and the current revision baseline.
+
+When an explicit regeneration request supplies `program_blocks`, they contain
+API tables computed from scoped Parser facts with the deterministic renderer. Select only the
 relevant blocks and place their exact `token` inside the corresponding sourced
 section. The CLI expands it at submission; do not retype its rows. Do not use an
 unrelated declaration merely because it shares a module. If a needed block is
@@ -101,11 +110,21 @@ For a small change, submit `sections` instead of `markdown`. Select exact IDs fr
 `writing_context.current_sections`; each edit contains `section_id` and `content`,
 an ordered array of `{ "markdown": "replacement text" }` or
 `{ "program": "exact token from program_blocks" }`. The CLI retains untouched
-sections, page identity and the edited section's source references. Do not include
+sections and page identity. Omitted references preserve the previous citations. Do not include
 section wrappers in replacement text. Use full Markdown for new pages, changed
 structure or pages without unambiguous section IDs. Both forms use the current
 Action schema and the same source and baseline validation.
 
+When a fragment's support changes, include `references` with its actual
+`source_ref` and `locator` (`path`, `start_line`, `end_line`). Each fragment allows
+up to three positions; Context reads the captured region and computes its digest.
+For full Markdown, optional `sections` contains only `{ section_id, references }`
+entries; for local edits it can accompany `content` or update references alone.
+An explicit empty list removes that fragment's citations. Deleted fragments lose
+their references; new fragments need their own selected sources, not copied IDs.
+Uniquely moved unchanged text can retain its fingerprint at its new position;
+changed or ambiguous regions remain visible for review, not silently refreshed.
+
 For example, after substituting IDs/tokens from this Route:
 
 ```json
@@ -131,29 +150,3 @@ If the user explicitly requires a different presentation, explain the difference
 and resolve that choice before accepting it. Do not rerun unchanged Repair to
 force a format the program deliberately omits. Check the actual resulting page;
 accepted tasks or an empty Composer result alone do not demonstrate a correction.
-
-## Changed supporting articles
-
-`knowledge_input` separates approved interpretation from source-bound facts.
-Recheck the relevant interpretation when an upstream article changes; ordinary
-revision refreshes its version only after Review. Waiting input does not make
-old statements current, and a wording-only edit must retain the review warning.
-
-For a split, merge or removed upstream, use the existing `context task adjust
---input - --format json` with `instruction` and `knowledge_dependencies`:
-
-```json
-{"instruction":"Rebind the affected explanation to the approved replacement","knowledge_dependencies":{"dependencies":[{"artifact_ref":"<approved article identity>","section_refs":[],"required":true}]}}
-```
-
-Select identities from the authorized approved article catalog; do not guess
-paths or promote prose into parser facts. Read the new current Route's
-`knowledge_input`, then repeat the adjustment with the same dependencies plus
-`sections`: each item has the retained `section_key`, selected `fact_refs` and
-`evidence_refs`. These are a full support replacement for those sections, not an
-append. Use only the supplied replacement facts or still-valid direct facts.
-An empty dependency list explicitly removes the old relationship; the remaining
-explanation still needs valid direct evidence. Revise the text to match the
-selection before submitting. The CLI checks identity, scope and version; the
-Agent and Review judge the explanation. Pending upstream approval remains a
-concrete task to finish or adjust, not a reason to clear the warning manually.

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

@@ -11,7 +11,7 @@ Open one report for the complete current candidate set and apply only a payload
 that matches its collection scope and candidate-set digest.
 
 Before Review, Context checks both sides of approved page identity: whether a
-candidate path is already owned by another `view_ref` / `node_ref`, and whether
+candidate path is already owned by another `article_id`, and whether
 the candidate `view_ref` is already approved at another path. Either conflict
 blocks Review. Follow the returned identity-coordination route: the default
 mechanical repair preserves the approved identity and approved path, then

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

@@ -36,6 +36,20 @@ optional: preserve the original URL without falling back to body retrieval or
 changing credentials. Resolve intent from the conversation; refine provisional
 chapters and module boundaries from evidence after formal capture.
 
+## Agent-planned writing order
+
+Within the tasks available in the current Route, the Agent may choose a writing
+order from the reader's needs and relationships between topics. There is no
+fixed code-first or document-first rule. Prefer foundational concepts and shared
+terminology before walkthroughs or summaries that benefit from them, when this
+reduces rework. Independent topics can proceed without waiting; adjust the order
+as writing progresses instead of maintaining a separate scheduling artifact.
+
+This is an Agent working preference, not a new dependency or completion gate.
+Do not add dependency fields, fetch extra material, or delay useful work merely
+to establish an order. Keep current task boundaries, source permissions and
+submission rules; do not pull future batches forward or change the CLI Route.
+
 ## Workspace versions and changelog
 
 `package.json.version` is the workspace SemVer. At completed-scope delivery the
@@ -139,6 +153,13 @@ ordered `content` list of `{ "markdown": "new text" }` and/or
 selected section's source references remain intact. Use full Markdown when
 changing structure, adding a page or when a section has no unambiguous ID.
 
+To change a fragment's citations, include `references` alongside its `section_id`:
+each entry supplies `source_ref` and `locator` (`path`, `start_line`, `end_line`).
+Context computes the region fingerprint. This uses the same revision submission,
+with at most three source positions per fragment. Full Markdown may include a
+`sections` list of reference edits; local section edits may change content,
+references, or both. Omission preserves citations; an empty list removes them.
+
 For an optional check, append `--preview` to the current `action complete-current`
 command with the same revision and input file. It validates and returns the
 assembled page and previous text without accepting the edit. Submit the same
@@ -412,17 +433,17 @@ Indexer's read scope. Its `task adjust` scope also supplies the explicit
 `requirement_ref`. This extends the current page's available sources and keeps
 queued pages; it does not silently start another task or another Indexer.
 
-### Replacing supporting article identities
-
-When an upstream article is split, merged or removed, start `context revise` for
-its consumer and use `context task adjust --input - --format json` with
-`instruction` and `knowledge_dependencies: { dependencies }`. Each dependency
-uses an approved `artifact_ref`, optional `section_refs`, and `required` flag.
-The current Author input returns authorized replacement facts and their evidence.
-Repeat the adjustment with `knowledge_dependencies.sections`, selecting each
-retained `section_key` and its full `fact_refs` and `evidence_refs` support. Then
-revise the explanation and complete normal Review, close and build. An explicit
-empty dependency list removes the relationship only when remaining sections have
-valid direct support. Missing dependencies, changed approvals and invalid source
-references cannot silently become current evidence. Writing quality remains an
-Agent/Review decision; no chapter-count or wording gate is introduced.
+### Revising material reused from another article
+
+When a supporting article changes, revise the affected explanation using
+`context revise`. Read the relevant approved text and, where needed, its original
+sources. Keep direct source regions on the affected output fragments; do not
+recreate an article dependency graph or copy facts and evidence IDs.
+
+Revision section edits may supply `references` as `source_ref` plus a
+`locator` containing `path`, `start_line`, and `end_line`. Context computes the
+regional digest. Omitted references preserve the current fragment's citations;
+an explicit empty list removes them, and deleting a fragment removes its
+citations. Each fragment may cite at most three source positions. Register and
+authorize new material before citing it, then follow normal Review, close and
+build. Article links alone do not authorize reading new sources or prove a claim.

package/providers/context/resources/procedures/parallel-agent-batch.md

@@ -4,137 +4,36 @@ kind: procedure
 mediaType: text/markdown
 ---
 
-# Parallel Partition and Author tasks
-
-This procedure applies only to a current Partition or Author Action with
-`tasks[]`. The Host runs the workers; Context does not launch models. The current
-Route, required readings and output schema remain authoritative. Delegation does
-not grant source access, approve a Gate or change the accepted scope.
-
-## Choose execution once per batch
-
-Use available native Host delegation only when current user/Host permissions
-allow it, at least two independent tasks are ready, and workers can read the
-assigned material and return their result without writing files. Respect an
-explicit single-Agent preference and Host capacity or budget limits. Do not
-install another agent runner, start nested CLI sessions or request broader
-permissions just to parallelize. If these conditions are absent, continue the
-same batch sequentially without a new user question.
-
-Resolve any existing scope or human decision before dispatching dependent tasks.
-Permission to use multiple Agents does not waive that decision.
-
-Choose `min(4, ready task count, available worker slots)` concurrent workers,
-excluding the coordinator. Use parallel mode only when that value is at least
-two. Do not split one task or enlarge a CLI batch to fill slots. Schedule later
-tasks from the same batch as workers finish; never prepare the next batch while
-this one is active. Known dependencies between tasks require sequential handling
-by the coordinator. A worker result never becomes evidence for a peer.
-
-Tell the user briefly, in their language, how many planning or writing workers
-will run when first enabling delegation or changing its concurrency/mode. Reuse
-that announcement across unchanged batches. Report a fallback once when it happens. Worker completion is draft
-progress; only CLI receipts establish accepted production progress.
-
-## Single coordinator and read-only workers
-
-The coordinator reads the Route, output schema and shared instructions, resolves
-existing human decisions, and owns all Context commands, receipts and writes.
-Workers consume only their assigned task reading and its authorized shared/detail
-files and captured source access. Material requiring CLI preparation is requested
-from the coordinator. Never let a worker run `context status`, a materializer,
-preview, completion, capture, parser, review, close or build.
-
-Use a Host read-only worker/tool profile when available. Workers must not run
-shell commands, Git, scripts or other tools that can change files or external
-state, and must not spawn workers. If the Host cannot honor this boundary, use
-single-Agent execution. Workers return results through Host messages; they do
-not write even scratch files. If a task cannot fit a complete response within
-the Host's output budget, the coordinator handles it sequentially and writes
-the payload itself. Do not truncate a result or publish a stub to fit transport.
-
-The coordinator alone writes the final payload under the workspace's
-`.tmp/agent-payloads/`, using a new file for each submission attempt. Never edit
-runtime readings or ledgers. This prevents worker file collisions without
-depending on filenames, worktrees or the project write lock to isolate them.
-
-## Assign and collect
-
-Use `template.indexer-agent-worker` from the current Route. Bind each assignment
-in coordinator memory to the current Route revision, Action `input_digest`,
-task manifest, instruction/resource digests and a unique attempt identifier.
-Task keys repeat across batches, so `task_key` alone is not an assignment ID.
-Copy these values; never compute or repair authority values from prose.
-
-Send one task entry, its exact Route-provided reading location and applicable
-shared instructions, the relevant output schema, and settled reader/scope
-decisions. Give enough instruction content or exact resource locations for the
-worker to read independently. A parent's reading does not populate a worker's
-context or authorize an unread receipt. Do not broadcast the entire batch,
-conversation, live repository or sibling task readings.
-
-Keep a mapping from Host worker ID to assignment attempt. Before dispatch, choose
-a finite task deadline supported by the Host (default ten minutes; shorten to
-the remaining session budget). Wait using native completion notifications or
-bounded waits while continuing user progress updates. A deadline is a Host
-execution limit, not a statement that evidence is missing.
-
-Accept a reply only from the active attempt for that task and only after it is
-complete. The worker uses the template's Host reply envelope to echo assignment
-identifiers separately from its single `{task_key, result}` entry. Check the Host
-worker ID and that binding against the saved assignment;
-do not insert coordination metadata into the Context semantic Result. Retain
-successful drafts in coordinator memory until the batch is assembled.
-
-## Merge and submit
-
-Reconcile Partition proposals against the settled reader purpose and accepted
-subjects, especially overlapping identities, primary member ownership and
-unresolved cross-task boundaries. Do not silently rename a subject or discard a
-member to make proposals fit. Resolve disagreements from authorized material
-in the coordinator; use the current schema's unresolved outcome when necessary.
-
-For Author, review consistency with the accepted page plans, evidence boundaries
-and reader terminology. A task may contain several planned articles: assign the
-whole task, not independent writers for its sections or articles. CLI performs
-the existing schema, ownership, reference and coverage validation.
-
-Assemble one entry per current task in task-key order, keeping the normal
-single-Agent output shape. Use the current Author preview when needed, then
-submit the complete batch once through the saved revision-bound command. Do not
-submit as each worker finishes or turn Host errors into `unsupported`,
-`catalog-only` or empty semantic results. Resolve unfinished work locally first.
-
-Finish or revoke every active assignment before any command that may change the batch or its material.
-Do not poll status merely to check workers. The revision-bound CLI command is
-the final freshness check; if an external change is observed, invalidate the
-assignments and obtain the current Route before submitting.
-
-## Failures and sequential fallback
-
-| Event | Coordinator action |
-| --- | --- |
-| Delegation unavailable, denied, or capacity below two before dispatch | Execute the batch sequentially. Do not retry permission prompts or simulate workers. |
-| Spawn failure, rate limit, timeout, tool failure, context loss or truncated reply | Stop dispatching for this batch. Revoke the failed attempt, cancel/close it if supported, and finish that task and unassigned tasks sequentially. Let healthy read-only peers finish within their deadlines. |
-| Missing/foreign task key, wrong attempt/revision, malformed or incomplete result | Discard that reply; take over its task sequentially using the original authorized input. Do not repeatedly respawn or treat the draft as committed. |
-| Conflicting proposals | Reconcile affected tasks in the coordinator; preserve unaffected drafts. Unresolved scope decisions follow the existing human Gate. |
-| Worker attempts a write, unauthorized tool or source access | Revoke all workers and stop parallel dispatch. Inspect any reported effects before continuing. If workspace integrity or authority is uncertain, follow current recovery guidance or report the concrete blocker. |
-| Route, task set or material binding changes | Revoke old attempts; discard incompatible drafts and follow the fresh Route. Never relabel an old reply with new digests or task keys. |
-| CLI accepts only part of a submission | Read `outcomes` and the returned next Route/task-only retry. Preserve committed peers; repair only the returned unfinished tasks sequentially. |
-| Completion reply is lost or next preparation fails | Inspect current status or the supplied recovery command before retrying. Accepted tasks may already be saved; never blindly replay the payload. |
-| Project write lock is held | Wait for the active writer using existing recovery guidance. Never remove its lock or launch another writer. |
-
-Revocation means marking the attempt inactive before taking over. Ignore all late
-replies, even if cancellation is unsupported. Such workers remain read-only;
-do not reuse their slots until the Host confirms termination. Do not start a
-new parallel batch while revoked workers are still active. A revoked read-only
-worker does not block the coordinator's sequential takeover or completion;
-its obsolete reply can no longer be accepted. If its read-only boundary is in
-doubt, use the violation handling above instead. After any execution
-failure, keep the rest of this batch sequential and reassess capability only at
-the next fresh batch. A user request to stay single-Agent persists.
-
-Sequential fallback preserves evidence, scope, review and completion requirements.
-If the coordinator also cannot complete the task, retain drafts and report the
-actual missing material, permission or Host limit through the existing workflow.
-Do not clear runtime state, widen sources or lower coverage to force progress.
+# Coordinate issued batch directories
+
+CLI owns stage boundaries and determines which batches are eligible. The Agent
+chooses how to finish the issued work. Enable `--multi-agent` only when this host
+can coordinate child Agents and current permissions allow them. Otherwise use
+the default single batch; do not simulate workers or seek extra permissions just
+to parallelize. A capability declaration does not waive any user decision.
+
+Assign disjoint output directories from the issued batches. Give each worker
+its task goals, relevant shared guidance, authorized source entrypoints and
+designated draft paths. Workers can read source text and write their assigned
+drafts. They do not change CLI-owned materials, formal articles, shared runtime
+state or a peer's drafts. One coordinator submits to Context and performs all
+shared-state CLI writes; workers return completed paths and unresolved issues.
+
+The host's capacity and the tasks determine scheduling; there is no fixed worker
+count, mandatory attempt ledger or new handoff schema. Use host completion
+notifications and ordinary bounded waits. Do not poll full Context status to
+check worker progress, or confuse a finished draft with a received article.
+
+The coordinator checks the outputs against their tasks, resolves cross-article
+terminology and source ambiguity where needed, and submits any completed subset
+through the stage file contract. Keep task input handles as supplied by CLI.
+Do not require every worker to finish before submitting independent work.
+
+If a worker fails or loses context, retain completed files and take over or
+redispatch only its unfinished work. Stop the old worker before another writer
+uses the same output paths, and ignore late results from revoked work. Ordinary
+host errors are not source exclusions or evidence that a task is complete.
+
+When capability is unavailable, omit `--multi-agent` on the next call. Already
+issued tasks and drafts stay valid. Source changes or task replacement use the
+CLI's existing task-local refresh and repair protocol, not skill-version checks.

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

@@ -0,0 +1,61 @@
+---
+id: procedure.production-requirements
+kind: procedure
+mediaType: text/markdown
+---
+
+# Long-term production requirements
+
+Use the reader purpose and source boundaries already confirmed by the user.
+Ask for missing decisions before writing; registering a source does not authorize
+unrelated modules. This is not the work-start report: the report follows the
+lightweight investigation and must still wait for user feedback.
+
+Write `src/indexers.yaml` with this minimal shape, replacing the example values
+with the user's actual purpose and registered source reference:
+
+```yaml
+requirements:
+  - id: service-readers
+    purpose: Explain the service responsibilities and supported usage
+    target_scope:
+      targets:
+        - source_ref: repo:service
+```
+
+Optional long-term decisions are `reader_goals` and `questions` (text lists),
+`coverage_domains` (domain to `required`, `optional` or `out-of-scope`), and
+`evidence_source_scope` with the same `targets` shape for authorized supporting
+sources. Existing `module_refs` are reading focus, not a module-to-path permission
+map. Use an ordinary task brief for relevant directories; no additional module
+mapping or scope receipt is required.
+
+An explicit exclusion belongs inside its requirement:
+
+```yaml
+exclusions:
+  - scope:
+      targets:
+        - source_ref: repo:service
+    paths: [generated]
+    reason: Generated outputs are outside the requested reader purpose
+```
+
+`paths` contains exact source-relative files or directories, not glob patterns;
+omit it only for a confirmed exclusion of the whole selected source scope.
+Do not automatically exclude something merely because it is large or costly.
+
+Do not add Provider selections, versions, hashes, run identifiers, candidate
+receipts or task assignments. Those are not long-term requirements. Skills and
+writing batches are declared in the temporary investigation plan.
+
+After editing, run `context status --format json` and consume its current Route.
+
+When article targets and source grouping are already clear, put the existing
+plan fields (`capabilities`, `articles`, optional `indexer_usage`) in a file under
+`.tmp/agent-work/`, omitting only `stage`, which does not exist yet. Each article
+contains `path`, `question`, `sources` and `batch`, with optional `brief` and
+`after`. Add `--input <that-file>` to the returned `action prepare-current`
+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.

package/providers/context/resources/procedures/production-stage-files.md

@@ -0,0 +1,57 @@
+---
+id: procedure.production-stage-files
+kind: procedure
+mediaType: text/markdown
+---
+
+# Production stage files
+
+The stage entry links CLI-owned requirements, planned skill guidance and task
+directories. Read relevant source text before writing; a skeleton is navigation,
+not semantic evidence. Skill names guide work, not article ownership or versions.
+
+Choose relevant code directories while planning or writing. A task brief may
+name useful reading scope; module labels do not imply directory permissions.
+No module mapping file, version receipt or article-level scope fields are needed.
+Read related code as needed within the user's authorized sources.
+
+Write results under the returned Agent directory. All submission paths are
+relative to that stage directory, even when the manifest is in `submissions/`.
+Copy the CLI's submission template, keep completed tasks only, and keep each
+task's prefilled `input`. Submit the manifest using the returned command.
+Do not edit submitted files until the command returns.
+
+A complete article uses `content` (Markdown) and `references` (YAML/JSON).
+Markdown has reader-facing title and description frontmatter, followed by the
+complete article with stable `context:section` markers. References contain
+`sections`, each with its matching `id` and `references` list. A reference is
+`source_ref` plus `locator: {path, start_line, end_line}` from actual authorized
+text. CLI computes source digests. A fragment may cite at most three distinct
+source positions; an article may have multiple fragments.
+
+A revision uses `edits` instead of `content`/`references`. The file contains an
+`edits` list. Each item maps `replace: [old-fragment-ids]` to `with: [...]`, whose
+entries contain `id` and the changed `markdown` and/or `references`.
+Omitted fields retain the previous value only for the same fragment identity.
+New identities require both fields. Empty `with` deletes the named fragments.
+A split or merge explicitly names old and new identities; merging cannot
+silently delete intervening article text. Insert with empty `replace` and
+`after: <existing-id>`, or `after: null` before the first fragment.
+Fragment Markdown excludes its outer markers, which CLI generates.
+
+The same edits format can repair a failed complete draft retained temporarily
+by CLI. If that draft is missing or structurally unusable, resubmit a corrected
+complete article. Failed tasks report a file/fragment when available; accepted
+tasks remain saved even if preparation of the next directory fails.
+
+The default is one batch. Supply `--multi-agent` only when this caller supports
+coordinating multiple batch directories. Omitting it safely downgrades scheduling
+without invalidating already-issued tasks or overwriting worker drafts.
+
+If the user explicitly asks to receive completed articles before the remaining
+work finishes, run `context run --deliver --format json`. This pauses writing,
+not approval: follow the returned Review, close and build routes. A successful
+build resumes the same stage; a failed build retains the pause and all tasks.
+To cancel that pause explicitly, use `context run --resume-writing --format json`.
+It preserves approved articles, candidates and existing task input handles.
+Partial delivery must include the approved articles needed by its local links.

package/providers/context/resources/procedures/source-boundary.md

@@ -10,16 +10,14 @@ A source boundary is a user decision about which repositories, modules, or
 documents may become approved knowledge. It affects extraction scope,
 provenance, output paths, and freshness checks.
 
-For the first production task in a newly initialized workspace, source
-registration is the boundary after work-start intake. Read the required work-start
-procedure and template, treat a supplied checklist as task guidance, read batch
-metadata titles under that procedure's limits and fallback without fetching bodies
-or outlines, resolve the required information,
-present the completed report and wait for user feedback before preparing this
-action's payload. Do not start registration, capture or extraction while any start
-condition remains unresolved. The payload must carry the report path required by
-the current schema; the CLI verifies the report exists and records its digest but
-does not judge its prose or infer decisions from it.
+For the first production task, confirm the reader purpose and authorized material
+scope, reusing choices already explicit in the conversation. A supplied checklist
+is task guidance unless the user also selects it as source material. Register and
+capture the confirmed sources so lightweight investigation can produce code
+skeletons and document overviews. The formal work-start report belongs after that
+investigation and planning, before bulk writing; its presence or digest is never
+source-registration evidence or user approval. Do not broaden source authorization
+while gathering the plan.
 
 Do not infer this boundary by using the current directory, monorepo layout,
 package names, or Git remotes to select additional sources. Once the user has named a concrete local module

package/providers/context/resources/procedures/task-recovery.md

@@ -21,28 +21,23 @@ its progress is changing. Never start a competing writer or delete a writer lock
   the recorded effect, then apply its digest when completion of those writes is
   authorized. This finishes prior writes and may touch approved knowledge; it is
   not draft rollback. Invalid journals or unclear ownership require escalation.
-- Failed Author work: preview `task recover --operation author --workset <digest...>
-  --instruction <concrete correction> --format json`. Explicit article dependencies
-  can expand the affected worksets. Read the entire affected scope before applying.
-- Restore the active accepted planning baseline: use `--operation plan` with the
-  same selection/instruction arguments. The checkpoint contains references to the
-  already stored immutable requests, not copies of all source or parser data. It
-  is available only after structure acceptance and is removed by lifecycle cleanup.
-  A changed registered source/configuration/approved-knowledge baseline prevents
-  restoration; use normal revision or replan instead. It does not recover deleted
-  runtime data from Git or choose arbitrary historical versions.
+- Failed writing: repair the reported article or fragment in the current stage
+  directory and resubmit its files. Accepted peers remain valid. If the selected
+  article has already been accepted, use its ordinary `context revise` action.
+- Changed materials or plan: use the current preparation or plan-amendment route.
+  There is no separate workset/accepted-plan restoration operation. If temporary
+  state has been removed, begin a new production run from formal content and
+  long-term requirements; do not reconstruct old candidates or process state.
 
-The preview lists affected worksets and discarded candidates. Within an explicit
-repair task or delegated authorization covering those unfinished drafts, explain
-that scope and apply without another ritual approval. Obtain a decision only if
-the expanded scope discards work outside that authorization. Never treat a digest
-as permission to undo published knowledge. CLI validates mechanical identities,
+The transaction preview lists affected files and previously started writes.
+Complete them only within existing authorization. Never treat a digest as
+permission to undo published knowledge. CLI checks current task identities,
 references and transaction consistency; the Agent diagnoses prose and planning.
 
-A repair changes request identities, archives replaced local draft/projection state,
-and preserves approved pages, menu, sources and existing packages. Read the fresh
-Route after success; do not reuse old task keys/results. Unrelated accepted results
-stay valid. Rebuilding whole-batch projections is not re-authoring their content.
+A task refresh may change its input identity; use the refreshed files and receipt.
+Ordinary failed-draft repair retains the task when its inputs are unchanged.
+Approved pages, navigation, sources and existing packages are not discarded by
+inspection. Unrelated accepted results stay valid.
 Do not silently exclude a failing module, weaken evidence or mark unfinished work
 complete to escape an error.
 
@@ -50,7 +45,7 @@ complete to escape an error.
 
 If the same cause persists after a correction without new evidence, do not repeat
 the same operation. Try a different supported recovery only when its prerequisites
-and effect justify it. If the ledger/checkpoint is unreadable, ownership cannot be
+and effect justify it. If the current stage is unreadable, ownership cannot be
 established, the baseline changed, or a CLI defect prevents safe recovery, retain
 current work and write `issue/YYYY-MM-DD-short-description.md` using
 [the issue template](../templates/recovery-issue.md). Use the user's local date and