@c4a/context-cli 0.7.5 → 0.7.8

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

@@ -0,0 +1,68 @@
+---
+id: procedure.knowledge-maintenance
+kind: procedure
+mediaType: text/markdown
+---
+
+# Maintain knowledge while production continues
+
+Use `context task maintain --input <file|-> --format json` to register multiple
+approved pages or an approved-output rebuild. The machine-readable input is
+[maintenance input](../../schemas/knowledge-maintenance-input.schema.json). This accepts a request; it does
+not discard the current task or immediately rewrite a page.
+
+```yaml
+id: clarify-existing-guides
+operation: revise
+timing: after-batch
+targets:
+  - path: knowledge/guides/overview.md
+    instruction: Clarify the selected explanation using its existing sources.
+```
+
+Reuse the same id and input when retrying a registration. A changed request uses
+a new id; cancel a pending request with `context task cancel-maintenance <id>
+--format json` before replacing it. Do not manufacture repeated requests from
+the same user feedback.
+
+`operation` selects `revise`, `regenerate`, or `rebuild`. Rebuild has no targets;
+it packages approved content without completing the production task. It cannot
+repair a table stored in an existing page. To publish newly accepted Author
+results earlier, use the current Route’s `delivery.request.command`
+(`context run --deliver --format json`) instead of a rebuild request. Finish
+the current Author batch and follow composition, Review, close and build, then
+resume production. Regenerate prepares the currently
+supported programmatic API blocks from the selected registered code material,
+even when its source version is unchanged. Follow the resulting Author Route,
+select relevant program tokens and retain unrelated prose. This is not a
+universal rerun of every business Composer. If a required program/material is
+not available, report the exact gap; do not hand-write generated rows.
+
+Ordinary revisions need no source reacquisition or parsing. New factual notes
+and conversation summaries still use the normal source preparation and scope
+adjustment procedures. A regenerated table does not advance a whole-source
+processed baseline. A changed upstream version still requires source impact
+assessment, including other affected approved pages and new topics.
+
+`after-batch` waits for the current delivery boundary. Use `priority` when the
+user asks to handle the correction first: the Graph requests early delivery
+of complete pages, retaining ordinary Review gates. Never interrupt a running
+submission, silently approve its drafts, or start parallel workspace writers.
+Inspect `maintenance` in status for the active request, pending targets and
+the actual waiting condition. Continue the original task only within the user's
+existing authorization; registration is not new authority to publish it.
+
+The transition command is supplied by the current Route. Do not invoke it with
+a remembered revision. On a preparation failure the request remains visible;
+repair the named materials and retry the current Route, or cancel that request
+before it creates a draft. Active drafts use the current revision/Review path;
+queue cancellation does not silently roll them back. To explicitly discard its
+unfinished drafts, first read `context task maintenance-status --format json`,
+then use `cancel-maintenance <id> --discard-revision <returned revision> --format
+json`. Already approved pages are retained and rebuilt; this is not a rollback
+of delivered knowledge. Shared-source adjustments wait until this maintenance
+batch is finished or cancelled, then use the production task's source adjustment
+route. If status says `target-still-in-production`, the original task still owns
+an unfinished page of that subject: let that writer settle before revising its
+latest approved text. After completion, read the
+new Route to resume production. Never resubmit an accepted old batch.

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

@@ -24,7 +24,7 @@ Without explicit session-managed authority:
 
 - open the report returned by the route;
 - let the user publish or durably omit candidates;
-- apply the exact returned decision payload; and
+- apply the exact copied review code through the returned review apply command; and
 - retain the exact report reference and reviewed scope in this conversation for
   the final completion summary.
 
@@ -38,10 +38,12 @@ With explicit session-managed authority, materialize the required
 `context.review-current` Markdown Resource once. Read its index and every
 reader-facing batch file listed there. Each Candidate appears in exactly one
 bounded batch; keep the decisions in the current Agent context and do not write
-a Review ledger. Only after every batch is publishable may the Agent run the
-single managed atomic approval command. Do not generate, open, or parse the
-ordinary HTML report. If any page needs repair, do not approve any batch;
-reopen the owning Author or Composer through the current repair route. The
+a Review ledger. Use the current scope template in that index with the Route's
+atomic apply command. Add explicit decisions only for reviewed pages; leave
+repair or undecided pages out of decisions and do not set a default. For a fully
+reviewed acceptable set, default approval remains available. Do not generate,
+open, or parse the ordinary HTML report. Reopen repair pages through their
+current repair command; unrelated approvals remain valid. The
 authority exists only in the current conversation. It does not bypass source
 permission, validation, close, or verify, and it is not proof that the files
 were read.
@@ -51,5 +53,66 @@ Do not persist a duplicate review-report ledger in the workspace.
 
 The Review UI names the internal `rejected` decision **Omit** because it is a
 durable content decision, not a request to rewrite the page. When a page needs
-changes, leave the whole batch unapplied and use `context revise` so the owning
+changes, leave that page pending and use `context revise` so the owning
 Author or Composer produces a new Candidate through the same lifecycle.
+
+Use the affected page's `Repair` command in the review material, replacing only
+the correction instruction. Current candidates are repaired within this batch;
+`--timing priority` is not needed and does not queue them behind delivery.
+`--regenerate` schedules program regeneration for approved pages. If supplied
+for a current candidate, follow the CLI's returned repair command instead.
+After the repair, read the new Route and review the changed material before
+approving the batch. Pending maintenance requests for other pages remain queued.
+
+For a repaired generated table, inspect the new Candidate's affected rows, not
+only its Repair ID or accepted Author/Composer outcome. Check the reported error
+against the available source version and facts. A missing value is not always a
+missing source: the source may be present but unsupported by the parser, or the
+correct fact may have been lost during rendering. Describe which case the
+available material establishes. An explicit limitation may be acceptable for the
+reader's task; a known false value must be repaired. If the same error remains
+after regeneration, preserve the batch and report the affected page, field and
+source/fact comparison. Repeating the same repair without new material or a tool
+fix is not progress. Do not approve, omit, or hand-edit a block to hide the error.
+
+## Interpreting generated API output
+
+Check fields, types, requiredness and supported defaults against the selected
+source version. A table can completely express a simple declaration; omitting
+that duplicate folded declaration is intentional. Complex relationships or
+constraints not represented in rows remain in a named declaration. Program
+`declaration_status`, when present, distinguishes `table-complete`,
+`component-wrapper`, `retained` and `not-provided`; its `fact_ref` and `source_ref`
+locate the input. Missing folds alone do not establish a parser failure.
+
+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.
+
+## Delivering approved pages while others need repair
+
+A partial decision keeps remaining pages in Review. It does not build after each
+approval. When the user asks to see approved results now, use
+`context run --deliver --format json` and follow its new Route through close and
+build. The CLI checks that the approved pages do not depend on unresolved pages;
+if they do, finish the linked pages first. No draft is approved or omitted by
+this request. Remaining drafts, accepted work and source baselines stay in place,
+and the Route returns to their Review/repair after the selected output builds.
+
+## Check usefulness as well as factual accuracy
+
+Use the current requirements and agreed scope to check whether a reader can
+complete the promised task with these pages. Source citations and a valid API
+table alone do not establish that. Compare representative pages with their
+actual definitions: keep defaults and members attached to the correct callable
+or type; inspect inherited members and static entry points when needed for the
+reader's task. Do not infer that an unexpanded type has no options or callbacks.
+
+Look for promised integration steps, examples or troubleshooting answers that
+may be missing across the relevant pages. Check neighboring pages before
+requesting additions. Repeated prose is a reason to inspect the actual content,
+not an automatic rejection rule. If the source is insufficient, identify what
+is unavailable and its effect on the reader instead of inventing content or
+forcing another identical regeneration. Keep correct pages eligible for the
+partial approval and delivery path above.

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

@@ -0,0 +1,330 @@
+---
+id: procedure.knowledge-updates
+kind: procedure
+mediaType: text/markdown
+---
+
+# Update existing knowledge
+
+Use the same Context conversation and the current workspace. Identify whether
+this is a continuation, an adjustment to the current task, a correction to one
+page, or an independent task. An old Route does not incorporate a new request.
+For explicit workspace preparation, Git commit or historical restoration, use
+[prepare](workspace-prepare.md), [commit](workspace-commit.md) or
+[restore](workspace-restore.md); these Agent-led operations do not automatically
+start production. Otherwise, do not start an independent task while another remains: explain what is saved
+and unfinished, and obtain the user's choice to finish or roll back the current
+work. Do not delete runtime files to simulate rollback.
+
+For an unambiguous page correction, use `context revise "<path or title>"
+--instruction "<correction>" --format json`. Context supplies the existing text
+and continues through Review and delivery. Expression-only changes need no
+source capture or Parser. Preserve prior confirmed contributions; distinguish
+actual behavior, a confirmed decision, and a proposal that is not implemented.
+
+## Edit one section or review part of a batch
+
+For a reading-directory-only change, use the existing `context task adjust
+--input <file|-> --format json` action with `reading_structure`. Supply its
+current `expected_revision`, explicit `upsert` entries and `remove` keys. Each
+entry retains its stable key, parent, title and order; optional targets use
+article identity and section key. The current structure preview supplies those
+identities. Use `expected_revision: null` only when no reading structure exists.
+After adjustment, follow status to rebuild affected packages. This changes the
+reading organization without capturing sources or rewriting approved prose.
+Do not directly edit generated package navigation or use titles as identities.
+
+The current approved-revision Route accepts either full `markdown` or explicit
+`sections` edits. Use an existing `writing_context.current_sections` ID and an
+ordered `content` list of `{ "markdown": "new text" }` and/or
+`{ "program": "exact current program token" }`. Unchanged sections and the
+selected section's source references remain intact. Use full Markdown when
+changing structure, adding a page or when a section has no unambiguous ID.
+
+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
+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
+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.
+
+When the user requests an earlier delivery, use the Route's `context run
+--deliver` request. Independently approved pages can pass close/build while
+pending candidates remain for Review or repair. Links to pending or missing
+pages keep their necessary scope together. Source processing baselines advance
+only after the entire update finishes. Failed builds retain the selected delivery
+and pending work; repair the cause and follow the current Route.
+
+## Acquire the selected change once
+
+Use the host's existing Git, code-hosting or document tools and their installed
+guidance. Context does not poll a platform, discover remote changes, or infer
+that a merge request is merged. Reading an already selected source does not
+require a new permission question when access was already authorized. Do not
+change the user's checkout or fetch another repository without that scope.
+
+For a branch or MR/PR, establish the repository, intended target branch, merge
+state and actual fixed target commit. An unmerged proposal is not the current
+mainline. A merge, squash or rebase can produce different commit identities;
+use the target branch's actual result, not the feature branch SHA. Include
+other intervening changes between the last processed version and the selected
+target when they affect the registered modules. Reverts are real changes.
+
+Use already available local Git objects to compare the selected module trees
+and necessary diffs. A new repository commit with unchanged module trees can
+be a no-knowledge-change conclusion. That conclusion must also account for any
+new note or development context. If a baseline is unavailable after force push,
+a shallow checkout or history cleanup, state that a complete old diff is
+unavailable; compare current material with approved knowledge in the confirmed
+scope. Do not claim no change because a Git command failed. A repeated MR may
+still bring new relevant context; it does not justify moving the code baseline
+backwards or summarizing unrelated commits as part of that MR.
+
+For documents, a revision shortcut is valid only if the host actually exposes a
+reliable version for the selected document and its needed images/attachments.
+Otherwise read that selected document and resources. Keep the returned bytes
+for the existing capture/import action; do not fetch them again as verification.
+An unchanged body does not prove images are unchanged. Distinguish lack of
+permission, deleted content, and moved content; a read failure is not permission
+to retire a knowledge page. CLI status describes local acquisition only.
+
+After the current source configuration and material identify the chosen fixed
+versions, submit the update with `context update --input <file|-> --format json`.
+Write ordinary YAML or JSON with the host's editor, without a generated wrapper
+program. Input files belong under this workspace's `.tmp/`.
+
+```yaml
+scopes:
+  - requirement_ref: reader-guide
+    source_ref: repo:20260901/library
+changes: The selected change adds one public option; inspect its explanation and examples.
+```
+
+`requirement_ref` is the existing requirement id. Omit `module_refs` for a whole
+confirmed source scope. `processed_version` may be supplied to bind the exact
+acquired commit or document content digest; otherwise Context captures it from
+the existing local material. A supplied version must match that material.
+Follow the returned Route. The candidate list is a conservative source match,
+not a list of pages that must change. Read the actual change and current pages,
+also checking additions that have no old page reference. The scope is complete
+only after every required change is reviewed, closed and built, or after an
+explicit conclusion that it needs no knowledge changes.
+
+Before importing a `note`, read [note source preparation](note.md).
+Before importing `sessions`, read [development summary preparation](sessions.md).
+Choose the reference for the actual input; do not read both by default.
+
+## Save text without an external file
+
+Use `context source import --input <file|-> --format json`:
+
+```yaml
+type: note
+name: 20260907/decision-context.md
+markdown: |
+  # Decision context
+
+  The selected discussion confirmed this exception for the stated situation.
+  The implementation has not yet changed. Source: the discussion supplied here.
+```
+
+The body is saved directly under `sources/note/` or `sources/sessions/`; no
+external `local`, capture, registry or second copy is required. Use a readable
+semantic filename under an eight-digit date directory. Do not put a date, hash
+or session id into the filename again. Keep the path for retries and later
+edits. To revise an existing source, read it and pass its current `base_digest`
+with the replacement Markdown. Distinct same-day material needs a distinct
+semantic name, never a silent overwrite. `source list`, `source get` and
+`source inspect` expose the actual source paths. Removal uses the existing
+preview and exact plan digest, and refuses still-referenced text.
+
+Saving alone does not start indexing. If the user only wants the source saved,
+report its path and stop. For production, reuse the existing requirement:
+put independent content in `target_scope`; put supporting material in
+`evidence_source_scope` and ensure the selected Indexer's existing `read_scope`
+covers it. Do not create a separate Markdown production target for a supporting
+explanation of a code page. In the source-update decision, include its exact
+`supporting_sources` on the affected page. Include that source's scope in this
+update so completion can distinguish code from newly processed context.
+
+## Development context accompanying a commit
+
+Use `trace-session` only as this conditional source-preparation step. If the MR,
+code and existing design already explain the relevant information, cite them.
+Write a `sessions` source only when real, explicitly available development
+context contains useful decisions, reasons or limits missing from those sources.
+Do not fabricate discussion from a diff, search host session storage, ask for
+nonessential history, or create an empty/skip report. This is only the code-related subcase. An authorized conversation summary
+without an MR or commit is also `sessions`; see the sessions source guide.
+Optional `changes` belongs in the source frontmatter, not knowledge headers.
+
+Use the available merge date, or commit date for a pure commit, for the initial
+directory; if unavailable or saving an unmerged discussion explicitly, use the
+current collection date and explain the context. Do not query a platform just
+for this date. Keep the path when later adding a reference or retrying another
+day. One coherent change can share one summary; separate unrelated changes.
+
+The shortest useful body is the real repository/MR/commit reference plus one
+paragraph explaining what the code does not tell a later reader. Describe only
+the actually associated commit subset. Omit a full change recap, transcript,
+test log, session id and formal approval claim. Write confirmed decisions as
+such, alternatives as alternatives, and unresolved proposals as unresolved.
+Do not claim execution or tests that were not observed. The writing aid below
+is optional; no section is mandatory:
+
+```markdown
+# <Change topic>
+
+<Reference the actual repository and MR or concrete commits already available.>
+
+<Explain the useful decision, reason or constraint absent from the code/design.
+State its applicability and distinguish implemented behavior from a proposal.>
+```
+
+Late context can update a page even when the code version is already processed.
+Reuse that fixed code version and current approved prose; do not restart Parser
+merely because a summary arrived. Import once, then include the necessary
+context with the same knowledge update. Saved context survives a failed build;
+saving it does not mean its knowledge impact has been delivered.
+
+## Optional correction of an upstream document
+
+Local knowledge approval and fully managed execution do not authorize a remote
+write. First determine whether the knowledge misunderstood correct source text,
+a confirmed decision has not reached the source, or the conclusion is still
+uncertain. The first needs only a local correction; the second can use a note
+locally while an upstream change is considered; uncertainty is not a fact.
+
+Present the exact document, affected passage, proposed before/after text, reason
+and affected knowledge. Reuse existing authorization for that concrete edit;
+otherwise ask for it. Before writing, read the affected passage again using the
+host document tool. Adapt only within the authorized scope if another person
+has edited it; ask again only when the requested change materially differs.
+
+Execute with the host tool and read back the result. If the write result is
+uncertain, read back before retrying an insertion. Only the actual returned
+source text and resources may refresh its snapshot. Feed them into the same
+local capture/update route; a note or proposed patch is not a remote snapshot.
+If the remote edit succeeded but local build failed, resume local delivery;
+do not repeat the remote edit. Explain remote and local outcomes separately.
+Do not automatically delete an absorbed note, post comments, notify groups or
+change permissions. Permission failure can leave a concrete suggestion for
+the user without blocking an independently supported local correction.
+
+## Import a document response already read by the host
+
+For a registered Lark source, retain the actual full JSON response from
+`lark-cli docs +fetch` and each returned continuation page. Do not reconstruct a
+response from a summary. Use the same source import command:
+
+```yaml
+type: lark
+name: 20260907/guide
+access_identity: user
+response_files: [.tmp/guide-response.json]
+media_files:
+  actual-image-token: .tmp/downloaded-image.png
+```
+
+Only include real media tokens and downloaded files. Context runs the ordinary
+capture normalization and resource checks on these bytes. It does not fetch the
+provided document again; missing required resources follow existing capture
+handling. Partial outline/section fragments cannot replace a full snapshot.
+Use the identity that actually produced the response, not a credential fallback
+chosen to bypass permissions. Subsequent local updates use the captured version
+and the same Review/build route.
+
+## Adjust or roll back current work
+
+For an explicit same-task change to native Indexer source inputs, use
+`context task adjust --input <file|-> --format json` with `scopes` containing the
+selected `source_ref` and optional `module_refs`, plus an `instruction` explaining
+the adjustment. It invalidates those old worksets and retains independent work.
+Import the fixed replacement material before following the refreshed Route.
+Do not execute the old batch payload. A local page correction still uses
+`revise`; it is not a reason to invalidate an entire source.
+
+For an independent task, complete the old Route unless the user chooses a
+concrete rollback. Without an identifiable baseline or attribution of changes,
+ask about that gap or offer completion; never guess original bytes. Prepare
+`context task rollback --input <file|-> --format json` using:
+
+```yaml
+summary: Restore the selected page and discard unfinished follow-up drafts; keep other work.
+discard_unfinished: true
+files:
+  - path: knowledge/guides/selected-page.md
+    base_digest: sha256:<current-file-digest>
+    content: |
+      <exact recoverable original Markdown, not a newly generated replacement>
+```
+
+`files` contains only the explicitly selected reversions. `content: null` removes
+an explicitly selected file that this task added; `base_digest: null` is for
+restoring an absent file. Include changed sources/configuration/processed scopes
+when they belong to the rollback. Leave unrelated and pre-existing edits alone.
+An empty list only discards unfinished work and must not be described as undoing
+already delivered pages. The preview shows actual before/after contents and
+draft loss. Once the user approves that exact scope, run the preview's apply
+command with its plan digest. Then follow the rollback Route through close,
+build and cleanup. A failed build retries delivery, not the already-applied
+reversions. Begin the independent task only after cleanup succeeds.
+
+A managed source can be explicitly renamed with `context source rename
+"<note:... or sessions:...>" --name "YYYYMMDD/new-name.md" --format json` after
+its active work is finished. Review the file/reference changes, then apply the
+returned digest-bound command. Existing references move with it; the original
+body is not copied into another source type. Follow status to refresh affected
+knowledge structure and packages.
+
+To move an approved page, use `context revise "<old path>" --move-to "<new path>"
+--instruction "<requested move and content changes>" --format json`. The new
+path stays in the same collection. The revision retains the page identity,
+rebases outgoing links and updates incoming Markdown links at approval. A new
+subject name alone only needs a title/content revision; do not create duplicate
+pages. Retirement is a content decision: explain the inapplicable material and
+supported replacement before changing its page and referring navigation.
+
+### Adjust inputs while a local update is unfinished
+
+`context task adjust --input <file> --format json` also applies to an active
+approved-page revision or source-update queue. Keep `scopes` and `instruction`
+explicit. First call without `refresh`; it authorizes replacing only those
+inputs and blocks page completion while acquisition is pending. Import the
+selected new material, then repeat with `refresh: true` to bind the actual local
+versions and obtain the new Route. Do not submit the old revision. Current
+prose and queued pages remain; an affected draft returns to writing/review.
+An unrelated queued page does not revoke an unchanged current page's review.
+If a page has already been applied, finish its close/build before changing its
+inputs. Only the final completed scope advances its processed baseline.
+
+For several documents, `source import` also accepts a JSON/YAML array of the same
+single-document inputs. Its receipt reports each zero-based input index and
+success or error separately; a partial batch returns a nonzero exit code.
+Keep successful sources and retry only failed entries. It does not fetch a
+successful prefetched document again or roll back an unrelated saved note.
+
+To add a new supporting source to an unfinished local revision, first save it
+and include it in the current requirement's evidence scope and the selected
+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.

package/providers/context/resources/procedures/note.md

@@ -0,0 +1,43 @@
+---
+id: procedure.note
+kind: procedure
+mediaType: text/markdown
+---
+
+# Prepare a note source
+
+Read this before importing or correcting a note. The CLI saves supplied Markdown;
+source preparation happens before knowledge production.
+
+A note may contain supplied original text, selected verbatim excerpts, a summary,
+or a useful combination. Do not require raw text plus a summary for every note.
+If both exist, distinguish them with readable headings or prose. Preserve short
+original text when useful; do not duplicate it just to fill a form. Label an
+external or Agent summary as a summary, never an original transcript.
+
+For long inputs, retain relevant excerpts or summarize within the agreed purpose.
+Keep qualifications, exceptions, disagreement and unresolved questions that affect
+the conclusion. State the available origin and selected scope, including material
+omissions when consequential. Quote only actual verbatim input. Do not invent
+links, speakers, dates or confirmation. A link does not mean its target was read;
+ask about essential missing context rather than fetching everything for a label.
+
+Save the body under sources/note/YYYYMMDD/topic.md with the existing import action.
+No extra raw/summary fields, sidecar, duplicate file or mandatory section template
+is needed. Saving alone does not start indexing. Independent reader topics can
+use the selected Note Provider (default or business replacement); supporting
+explanations use the current page's evidence/read scope, retaining its primary.
+When specialized interpretation is needed, explicitly select a compatible
+extension layer. Do not enable another skill merely because a note exists.
+
+Knowledge integrates the useful information into explanations, rules or steps
+for the reader. Do not copy the note wholesale or turn proposals into facts.
+An exact short passage is appropriate when its wording matters. Cite the stored
+material actually read, without claiming access to an unavailable original.
+
+If the note misrepresents the supplied material, explicitly correct the source
+with its current base_digest, following task adjust first for pinned inputs.
+Do not overwrite original text merely to fit new prose. If the source is correct
+but the knowledge is misleading, revise only that page through Author/Review.
+A confirmed future decision may differ from current implementation; make the
+boundary clear. Knowledge approval does not change or remove the note.

package/providers/context/resources/procedures/project-configuration.md

@@ -9,6 +9,12 @@ mediaType: text/markdown
 Use the current route facts and Context SDK documentation to make only the
 declaration requested by the route in `src/index.ts`.
 
+Complete the required readings and run their `acknowledge-current` / `after_read`
+command **before editing**. Use the resulting current configuration Route for the
+edit. Editing changes the revision: afterwards refresh status, never run an
+acknowledgement bound to the pre-edit revision. Reading acknowledgement confirms
+the inputs, not approval or completion of the configuration change.
+
 - Do not invent sources, modules, collections, or output types.
 - Ask for a user decision when the route is gated and no current-session
   authority is present.

package/providers/context/resources/procedures/sessions.md

@@ -0,0 +1,56 @@
+---
+id: procedure.sessions
+kind: procedure
+mediaType: text/markdown
+---
+
+# Prepare a conversation-summary source
+
+Use sessions for a bounded summary formed from an authorized conversation:
+requirements, design, troubleshooting, operational or general knowledge.
+Code association is optional. An Agent or external supplier prepares the summary
+before import. Do not scan host history, ingest the full transcript, invent a
+conversation from a diff, or move an unrelated conversation into note merely
+because it lacks a commit.
+
+Keep the problem, confirmed decisions, useful reasons, constraints and open
+questions. Remove repetitive turns, tool logs and abandoned attempts unless they
+explain a current limit. Preserve whether each statement was proposed, agreed,
+implemented or verified. If only a supplied summary is available, say so; do not
+claim to have read the original. Do not make up speakers, dates or approval.
+A session with no reusable information can remain outside the workspace.
+
+Save through `context source import --input <file> --format json`, using
+`type: sessions`, `name: YYYYMMDD/topic.md` and the prepared `markdown` string.
+Choose the actual conversation date, or collection date if unknown, and retain
+the same path for corrections. The summary needs no mandatory body headings.
+
+Optional `changes` associates one or several code changes. Each row accepts
+`commit` (full 40/64 hexadecimal Git SHA), `mr` (HTTP(S) MR/PR URL), and optional
+`repository`. At least commit or mr is needed per row; omit the entire field
+for unrelated sessions. Use actual known identifiers, never fabricated hashes.
+A reference does not prove merge, deployment, tests or authorize fetching code.
+The CLI stores this field in the source's YAML frontmatter, discovers it from
+that same file, and does not introduce a sidecar or separate registry.
+
+For example, an import may have `changes: [{mr: "https://git.example.org/team/project/merge_requests/42"}]`.
+This is an illustrative URL, not a lookup target. The same payload without
+changes imports an independent requirements discussion normally. Use the current
+base_digest to change text or associations; explicit `changes: []` clears the
+associations. Omission leaves the source's inline changes intact. When replacing
+only the summary body, preserve existing associations unless explicitly removed.
+Do not duplicate commit/MR fields into knowledge frontmatter.
+
+Saving alone does not start indexing. Select a compatible Sessions Provider for
+an independent reader topic, or keep an existing page's Code/Markdown primary
+and include the summary in its authorized evidence/read scope. If specialized
+interpretation is needed, explicitly select an extension from the Sessions or
+business Provider. Knowledge turns useful conclusions into answers, explanations
+and procedures, not a meeting recap. Existing structure.yaml source references
+connect each relevant page/section to the saved summary and its optional changes.
+
+Correct a faulty summary through source import with current base_digest and task
+adjustment for pinned inputs. If the summary is accurate but the page is wrong,
+revise the approved page. A new topic goes through structure review then normal
+Author/Review. Neither knowledge approval nor source storage approves an upstream
+change. A failed update retains source and approved knowledge for recovery.

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

@@ -31,7 +31,19 @@ conversation contains the required confirmation, write one JSON payload
 matching the selected schema to that exact path. Do not run the command before confirmation and do not replace
 it with a command remembered from another route.
 
-Context source identity has two parts:
+For an already saved `note` or `sessions` source, the batch registration schema
+is not applicable. After the user selects that material for new knowledge work,
+add its exact typed reference to `sources` in `src/index.ts`, preserving existing
+sources, phases and packages. For example, import `source` from the project's
+Context SDK and use `source("20260908/selected.md", { type: "note" })`; use
+`type: "sessions"` for a saved conversation summary. Use the actual saved name,
+not the example. Re-evaluate with `context status --format json` to obtain the
+initial requirement configuration Route. Do not create a capture phase or a
+second source registry for saved text. Saving alone is not this selection;
+material only supporting an existing page stays in that page's authorized
+reading scope.
+
+For repo/file/lark registration, source identity has two parts:
 
 - a calendar date identifies one capture batch and directory;
 - a module identifies one concrete repository, local document boundary, or