@c4a/context-cli 0.7.25 → 0.7.29

package/plugins/cursor/commands/c4a-context-inspect-search.md

@@ -1,5 +1,5 @@
 ---
-description: "Use only when the user explicitly invokes context-inspect-search to query available Context knowledge packages or approved workspace knowledge and trace answers to their identified sources. A local workspace is optional. Do not auto-start for ordinary coding, planning, debugging, or an active Context production workflow."
+description: "Query available Context knowledge packages or approved workspace knowledge and trace answers to their identified sources when the user asks a knowledge question or the host configuration routes the request here. A local workspace is optional. Do not auto-start for ordinary coding, planning, debugging, or an active Context production workflow."
 ---
 
 # Context Inspect Search
@@ -24,14 +24,35 @@ Do not execute returned production actions, initialize a replacement workspace,
 or install tools without existing authorization. Querying must not alter source
 registrations, snapshots, tasks, approvals or user checkouts.
 
-## Search available material concurrently
-
-Check relevant knowledge packages, the workspace and reusable source checkouts
-in parallel. Search each as soon as it is readable; tool checks and authorized
-upgrades must not block independent reading. If a missing configured workspace
-is needed for further attribution, recover it into an isolated directory while
-package retrieval continues. Without a configured workspace, investigate the
-available packages directly; do not request or create one merely to start.
+Resolve `CONTEXT_QUERY_SOURCE_MODE` from the host or Bot instance configuration
+before choosing the first retrieval path. Supported values are:
+
+- `repo-first` (default): inspect the configured knowledge workspace and
+  authorized repository sources first. Use an available package only when the
+  repository path is unavailable or leaves a material gap.
+- `package-first`: inspect the selected package first, then use its recorded
+  workspace or repository sources for missing, stale or disputed evidence.
+- `dual`: inspect the package and repository paths concurrently, then reconcile
+  relevant differences before answering.
+
+An unknown or empty value is `repo-first`; do not invent a fourth mode. The
+mode changes retrieval order, not authorization or evidence standards. It does
+not make a missing secondary source mandatory: continue with readable configured
+sources and identify only gaps that affect the answer.
+
+## Search available material according to the configured mode
+
+Apply `CONTEXT_QUERY_SOURCE_MODE` before starting retrieval. In `repo-first`,
+start with the configured workspace and reusable source checkouts; do not fetch
+or install a package merely to begin the query. In `package-first`, start with
+the selected readable package. In `dual`, start both paths concurrently. Search
+each selected path as soon as it is readable; tool checks and authorized
+upgrades must not block independent reading. If a configured primary path is
+missing, continue with the readable fallback instead of stopping. If a missing
+configured workspace is needed for further attribution, recover it into an
+isolated directory while other selected retrieval continues. Without a
+configured workspace, investigate available packages directly; do not request
+or create one merely to start.
 
 A knowledge package may be workspace build output (usually `dist/`), a global
 installation, or an equivalent host-provided directory. Locate it from available
@@ -117,7 +138,21 @@ not prove a historical snapshot.
 
 ## Answer with evidence and hand off updates
 
-Lead with the conclusion and a concise evidence chain. Distinguish implementation,
+Answer the user's question directly, keeping conditions that change the conclusion
+beside it. For complex questions, explain the mechanism that determines the result,
+not just the verdict and source links. Explain its practical meaning before using
+a short code excerpt or concrete rule when that helps the reader verify or act.
+Keep decisive evidence beside the claim it supports; separate supplementary facts
+from the proof. State where a local rule applies rather than generalizing it to
+the whole system, and do not infer presentation or behavior from data retrieval
+alone without checking the controlling logic.
+
+Adapt depth and structure to the question: keep simple answers short; use short
+headings and, where supported, separators between major semantic sections in
+longer answers. Do not impose a fixed outline, separate every paragraph, repeat
+the conclusion, or remove necessary explanation just to shorten the answer.
+Keep conditions affecting the answer prominent and supplementary reading secondary.
+Distinguish implementation,
 declared contracts, test assertions, runtime observations and inferences. Perform
 bounded non-destructive validation only when useful; inspect its effects first
 and do not run unrelated scripts, builds or tests.

package/plugins/cursor/skills/context-inspect-search/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: context-inspect-search
+description: Query available Context knowledge packages or approved workspace knowledge and trace answers to their identified sources when the user asks a knowledge question or the host configuration routes the request here. A local workspace is optional. Do not auto-start for ordinary coding, planning, debugging, or an active Context production workflow.
+---
+
+# Context Inspect Search
+
+## Entry and boundaries
+
+Use on explicit invocation and related follow-up questions; use the conversation
+language. The invocation authorizes read-only investigation of the selected
+knowledge packages, available workspace and identified sources within that scope,
+including isolated source retrieval and bounded non-destructive checks. The Skill
+can run from a global installation with host-provided packages and no workspace.
+Resolve scope from the request, conversation and configuration before asking.
+Continue through non-blocking issues; ask only for missing access, genuinely
+unresolved scope or effects outside existing authorization.
+
+Start from the supplied package locations or workspace configuration. If a
+workspace exists, read its `AGENTS.md` and relevant configuration;
+`context entry [project-dir] --format json` may help locate instructions.
+Neither a workspace nor a working Context CLI is required for package retrieval;
+do not call entry in an arbitrary directory just to satisfy a prerequisite.
+Do not execute returned production actions, initialize a replacement workspace,
+or install tools without existing authorization. Querying must not alter source
+registrations, snapshots, tasks, approvals or user checkouts.
+
+Resolve `CONTEXT_QUERY_SOURCE_MODE` from the host or Bot instance configuration
+before choosing the first retrieval path. Supported values are:
+
+- `repo-first` (default): inspect the configured knowledge workspace and
+  authorized repository sources first. Use an available package only when the
+  repository path is unavailable or leaves a material gap.
+- `package-first`: inspect the selected package first, then use its recorded
+  workspace or repository sources for missing, stale or disputed evidence.
+- `dual`: inspect the package and repository paths concurrently, then reconcile
+  relevant differences before answering.
+
+An unknown or empty value is `repo-first`; do not invent a fourth mode. The
+mode changes retrieval order, not authorization or evidence standards. It does
+not make a missing secondary source mandatory: continue with readable configured
+sources and identify only gaps that affect the answer.
+
+## Search available material according to the configured mode
+
+Apply `CONTEXT_QUERY_SOURCE_MODE` before starting retrieval. In `repo-first`,
+start with the configured workspace and reusable source checkouts; do not fetch
+or install a package merely to begin the query. In `package-first`, start with
+the selected readable package. In `dual`, start both paths concurrently. Search
+each selected path as soon as it is readable; tool checks and authorized
+upgrades must not block independent reading. If a configured primary path is
+missing, continue with the readable fallback instead of stopping. If a missing
+configured workspace is needed for further attribution, recover it into an
+isolated directory while other selected retrieval continues. Without a
+configured workspace, investigate available packages directly; do not request
+or create one merely to start.
+
+A knowledge package may be workspace build output (usually `dist/`), a global
+installation, or an equivalent host-provided directory. Locate it from available
+configuration or installation metadata rather than assuming a fixed path.
+Select packages relevant to the question. Follow their bundled query Skill when
+present; otherwise search readable indexes and pages. Missing Skills or build
+inventories do not block retrieval or justify rebuilding. If a needed package is
+missing, use the host's configured, authorized package retrieval mechanism while
+other reading continues. Only check or prepare tools needed for the next actual
+operation; installation failure does not block independent local retrieval.
+
+For gaps or latest-content questions, also search approved knowledge when a workspace is available:
+use `knowledge/structure.yaml` and relevant `knowledge/` paths, trying business
+terms, symbols and synonyms, then read matching sections in context. Delivered
+content may lag approved knowledge; they are not independent corroboration.
+Candidates and temporary reports are not approved pages. A search miss does not
+prove a capability is absent. Do not build merely to answer a query; a separately
+authorized build must follow its own workflow without advancing unrelated work.
+
+When package or approved knowledge leaves a gap, directly trace relevant sources
+without asking whether to deepen the query. Use available document, code-search
+or extraction tools within the authorized scope, recording source identity and
+version. Prepare sources while continuing other reading.
+One failed source blocks only dependent claims. Answer when evidence is
+sufficient, without completing unnecessary preparation.
+
+## Trace and retrieve only relevant sources
+
+Without a workspace, use explicit source references in the package, its metadata
+or user configuration to identify relevant documents or repository paths and
+commits. Read or retrieve those sources directly within scope; the workspace
+registry is not a mandatory intermediate step. If the source identity or version
+cannot be established, retain package-grounded findings and qualify attribution;
+do not invent a repository or equate current source with the package's baseline.
+
+When a workspace and `context-build-inventory.json` are available, map a delivered page's
+`dist_path` through `approved_knowledge.files` to its `approved_path`, relative
+to the workspace's `knowledge/` root. Follow the approved page's associations in
+`knowledge/structure.yaml` and `sources/*/index.yaml`. Without a reliable mapping,
+continue package retrieval and follow explicit source references where available.
+Do not guess originals from similar filenames or claim attribution without
+checking the referenced material.
+
+Use the repository and recorded commit identified by the package or workspace
+as the source baseline.
+Reuse existing checkouts only after checking remote, commit, module coverage
+and local changes; do not reset them or change their sparse configuration.
+Missing code goes into a reusable query-owned path such as
+`.tmp/context-inspect/<host>/<repository-path>/<commit>/`, separate from user
+checkouts and production-managed sources. Use safe, credential-free path
+components and the full commit. Verify identity before reuse; never overwrite
+a mismatched directory. Deduplicate recovery and use one writer per checkout;
+that writer may append sparse paths without resetting existing files.
+
+Default to lightweight retrieval and sparse checkout:
+
+- Use shallow history (`--depth=1`) and deferred contents (`--filter=blob:none`)
+  where supported, with a complete partial-clone setup and named promisor remote.
+  Configure the sparse scope before checkout and verify the resulting commit.
+- Start from known module paths. If unclear, inspect
+  `git ls-tree -r --name-only <commit>` for candidates, then read code to confirm
+  their relevance. Expand along imports, calls and service routes as needed;
+  deepen history only when needed. A sparse search miss is not a whole-repository miss.
+- Read ready modules while other recovery proceeds. Allow sufficient command
+  time (for example 300 seconds or more), but investigate confirmed stalls
+  without waiting for timeout; silence alone is not a stall. If unsupported or
+  unsuccessful, try caches, commit-specific file retrieval or bounded shallow
+  retrieval; use a full clone only when necessary. Do not retry blindly or
+  silently substitute the default branch for an unavailable recorded commit.
+
+Query retrieval never runs `context source restore`, `task prepare` or production
+capture/recovery actions. Production recovery gates do not block this independent
+inspection. Preserve unavailable-evidence gaps rather than changing production
+state to get past them.
+
+Compare relevant baseline files with current code when accessible, including
+relevant local changes. Use actual diffs to assess impact; current code is not a
+substitute for the baseline. Mention a missing comparison only when it limits
+the answer. For documents, notes and sessions, read saved bodies and necessary
+attachments; fetch missing accessible material within scope. A summary is not a
+full transcript, an unread link is not evidence, and current remote content does
+not prove a historical snapshot.
+
+## Answer with evidence and hand off updates
+
+Answer the user's question directly, keeping conditions that change the conclusion
+beside it. For complex questions, explain the mechanism that determines the result,
+not just the verdict and source links. Explain its practical meaning before using
+a short code excerpt or concrete rule when that helps the reader verify or act.
+Keep decisive evidence beside the claim it supports; separate supplementary facts
+from the proof. State where a local rule applies rather than generalizing it to
+the whole system, and do not infer presentation or behavior from data retrieval
+alone without checking the controlling logic.
+
+Adapt depth and structure to the question: keep simple answers short; use short
+headings and, where supported, separators between major semantic sections in
+longer answers. Do not impose a fixed outline, separate every paragraph, repeat
+the conclusion, or remove necessary explanation just to shorten the answer.
+Keep conditions affecting the answer prominent and supplementary reading secondary.
+Distinguish implementation,
+declared contracts, test assertions, runtime observations and inferences. Perform
+bounded non-destructive validation only when useful; inspect its effects first
+and do not run unrelated scripts, builds or tests.
+
+Link material actually read: source files at the inspected commit, knowledge
+website articles and original documents. If no reliable clickable link exists,
+give checkable local paths, symbols and short supporting excerpts with the
+limitation. Do not dump internal reasoning, runtime identifiers or routine
+version comparisons. Explain only differences affecting the answer; hashes may
+appear in source URLs without requiring a separate version audit in the prose.
+
+For website links, use `context-site-map.json` from the selected package or
+sibling website output. Match `pages[].package_path` or `approved_path`, and
+resolve `site_path` against `site_url` without prepending `base` again. Cite only
+matched pages, deduplicate links and do not invent anchors. If mapping is absent
+or invalid, retain local citations. Do not build, publish or probe remote sites
+just to format citations; a local map is not proof of the current online content.
+
+Suggest a knowledge update only with supporting evidence: identify the affected
+page or gap, proposed change and bounded source scope. Check neighboring content
+before proposing a new page. Only after user acceptance, hand the evidence and
+scope to the installed `context` production Skill in the selected workspace and
+its fresh Route. If no target workspace is known, resolve it at that handoff,
+not as a prerequisite to answering. Do not edit approved knowledge, clear state
+or reuse an earlier revision. If that entry
+is unavailable, provide the handoff and state that no update has started.

package/plugins/cursor/skills/context-inspect-search/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: true

package/plugins/skills/context-inspect-search/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: context-inspect-search
-description: Use only when the user explicitly invokes context-inspect-search to query available Context knowledge packages or approved workspace knowledge and trace answers to their identified sources. A local workspace is optional. Do not auto-start for ordinary coding, planning, debugging, or an active Context production workflow.
-disable-model-invocation: true
+description: Query available Context knowledge packages or approved workspace knowledge and trace answers to their identified sources when the user asks a knowledge question or the host configuration routes the request here. A local workspace is optional. Do not auto-start for ordinary coding, planning, debugging, or an active Context production workflow.
 ---
 
 # Context Inspect Search
@@ -26,14 +25,35 @@ Do not execute returned production actions, initialize a replacement workspace,
 or install tools without existing authorization. Querying must not alter source
 registrations, snapshots, tasks, approvals or user checkouts.
 
-## Search available material concurrently
-
-Check relevant knowledge packages, the workspace and reusable source checkouts
-in parallel. Search each as soon as it is readable; tool checks and authorized
-upgrades must not block independent reading. If a missing configured workspace
-is needed for further attribution, recover it into an isolated directory while
-package retrieval continues. Without a configured workspace, investigate the
-available packages directly; do not request or create one merely to start.
+Resolve `CONTEXT_QUERY_SOURCE_MODE` from the host or Bot instance configuration
+before choosing the first retrieval path. Supported values are:
+
+- `repo-first` (default): inspect the configured knowledge workspace and
+  authorized repository sources first. Use an available package only when the
+  repository path is unavailable or leaves a material gap.
+- `package-first`: inspect the selected package first, then use its recorded
+  workspace or repository sources for missing, stale or disputed evidence.
+- `dual`: inspect the package and repository paths concurrently, then reconcile
+  relevant differences before answering.
+
+An unknown or empty value is `repo-first`; do not invent a fourth mode. The
+mode changes retrieval order, not authorization or evidence standards. It does
+not make a missing secondary source mandatory: continue with readable configured
+sources and identify only gaps that affect the answer.
+
+## Search available material according to the configured mode
+
+Apply `CONTEXT_QUERY_SOURCE_MODE` before starting retrieval. In `repo-first`,
+start with the configured workspace and reusable source checkouts; do not fetch
+or install a package merely to begin the query. In `package-first`, start with
+the selected readable package. In `dual`, start both paths concurrently. Search
+each selected path as soon as it is readable; tool checks and authorized
+upgrades must not block independent reading. If a configured primary path is
+missing, continue with the readable fallback instead of stopping. If a missing
+configured workspace is needed for further attribution, recover it into an
+isolated directory while other selected retrieval continues. Without a
+configured workspace, investigate available packages directly; do not request
+or create one merely to start.
 
 A knowledge package may be workspace build output (usually `dist/`), a global
 installation, or an equivalent host-provided directory. Locate it from available
@@ -119,7 +139,21 @@ not prove a historical snapshot.
 
 ## Answer with evidence and hand off updates
 
-Lead with the conclusion and a concise evidence chain. Distinguish implementation,
+Answer the user's question directly, keeping conditions that change the conclusion
+beside it. For complex questions, explain the mechanism that determines the result,
+not just the verdict and source links. Explain its practical meaning before using
+a short code excerpt or concrete rule when that helps the reader verify or act.
+Keep decisive evidence beside the claim it supports; separate supplementary facts
+from the proof. State where a local rule applies rather than generalizing it to
+the whole system, and do not infer presentation or behavior from data retrieval
+alone without checking the controlling logic.
+
+Adapt depth and structure to the question: keep simple answers short; use short
+headings and, where supported, separators between major semantic sections in
+longer answers. Do not impose a fixed outline, separate every paragraph, repeat
+the conclusion, or remove necessary explanation just to shorten the answer.
+Keep conditions affecting the answer prominent and supplementary reading secondary.
+Distinguish implementation,
 declared contracts, test assertions, runtime observations and inferences. Perform
 bounded non-destructive validation only when useful; inspect its effects first
 and do not run unrelated scripts, builds or tests.

package/plugins/skills/context-inspect-search/agents/openai.yaml

@@ -1,2 +1,2 @@
 policy:
-  allow_implicit_invocation: false
+  allow_implicit_invocation: true

package/providers/context/graphs/indexer.yaml

@@ -36,6 +36,10 @@ nodes:
     kind: action
     reasonCode: route.production.planning-required
     action: actions/work-production-stage.yaml
+    resources:
+      recommended:
+        - resources/procedures/document-code-investigation.md
+        - resources/procedures/repository-source-recovery.md
     satisfiedBy:
       - path: production.planning_complete
         equals: true

package/providers/context/manifest.json

@@ -2,14 +2,14 @@
   "schema": "agent-graph.bundle.v1",
   "provider": {
     "id": "c4a/context",
-    "version": "0.7.25"
+    "version": "0.7.29"
   },
   "providerManifest": "provider.yaml",
   "graphs": [
     {
       "id": "indexer",
       "path": "graphs/indexer.yaml",
-      "digest": "sha256:4992b548a9d19c6d7fd25a5dc0ae6b78a4a494ce39d37633144d389362f21122"
+      "digest": "sha256:d52242180fbe1afea09946bb223a698f7e0637f81d619d9245acb74732f2409e"
     },
     {
       "id": "workspace",
@@ -290,6 +290,11 @@
       "path": "resources/procedures/document-capture.md",
       "digest": "sha256:9d0d1b9187bbe540a4afffb366cd549385dbf61bfaffa96ae51de848b2dd5460"
     },
+    {
+      "id": "procedure.document-code-investigation",
+      "path": "resources/procedures/document-code-investigation.md",
+      "digest": "sha256:eff8e54b9e1c1139c5df82a0685a365bce902dfb4a19c17e380967ee1c1762f5"
+    },
     {
       "id": "procedure.homogeneous-source-review",
       "path": "resources/procedures/homogeneous-source-review.md",
@@ -343,7 +348,7 @@
     {
       "id": "procedure.repository-source-recovery",
       "path": "resources/procedures/repository-source-recovery.md",
-      "digest": "sha256:024f6e2947ef421b9a5f5e138c9af65a054d676a7f484dbf80b43a620ee2c95d"
+      "digest": "sha256:20a8112df985a20481e914a564c64c231218c73c1630d74cd46d72987e54f714"
     },
     {
       "id": "procedure.runtime-event-delivery",
@@ -562,7 +567,7 @@
     },
     {
       "path": "graphs/indexer.yaml",
-      "digest": "sha256:4992b548a9d19c6d7fd25a5dc0ae6b78a4a494ce39d37633144d389362f21122"
+      "digest": "sha256:d52242180fbe1afea09946bb223a698f7e0637f81d619d9245acb74732f2409e"
     },
     {
       "path": "graphs/workspace.yaml",
@@ -570,7 +575,7 @@
     },
     {
       "path": "provider.yaml",
-      "digest": "sha256:205a4786448c8825b10469fc7eda3b5e9e67caa7a0df528d14709c9c88f985bd"
+      "digest": "sha256:0a21f82483186c4fe1f6f450923d0d336300274fb95e2c7ee3569700ba922372"
     },
     {
       "path": "resources/contracts/indexer-provider-guide.yaml",
@@ -692,6 +697,10 @@
       "path": "resources/procedures/document-capture.md",
       "digest": "sha256:9d0d1b9187bbe540a4afffb366cd549385dbf61bfaffa96ae51de848b2dd5460"
     },
+    {
+      "path": "resources/procedures/document-code-investigation.md",
+      "digest": "sha256:eff8e54b9e1c1139c5df82a0685a365bce902dfb4a19c17e380967ee1c1762f5"
+    },
     {
       "path": "resources/procedures/homogeneous-source-review.md",
       "digest": "sha256:e9746b45351f3c58f1eca90f786fa5ddef06b19024f4ba5539a0c21e0a1508da"
@@ -734,7 +743,7 @@
     },
     {
       "path": "resources/procedures/repository-source-recovery.md",
-      "digest": "sha256:024f6e2947ef421b9a5f5e138c9af65a054d676a7f484dbf80b43a620ee2c95d"
+      "digest": "sha256:20a8112df985a20481e914a564c64c231218c73c1630d74cd46d72987e54f714"
     },
     {
       "path": "resources/procedures/runtime-event-delivery.md",
@@ -862,12 +871,12 @@
     },
     {
       "path": "skills/work-production-stage/SKILL.md",
-      "digest": "sha256:b7aa28c032e00f93f67d3c9dc3589cf1513451456f589262e22ad7f73d265de7"
+      "digest": "sha256:676289693df57b5887f104d751dd9c8cc73fb1c903e4df7088f110ef6147388a"
     }
   ],
   "graphDependencies": {
     "indexer": [],
     "workspace": []
   },
-  "digest": "sha256:1632415b812eb5fe95240d1e959d1f598ed060a9b923ba9dfa5dc5d88d02cfce"
+  "digest": "sha256:3e0f9fc6f81571381dced3a8d02b20624022183e924c7b99c16430c8924d624d"
 }

package/providers/context/provider.yaml

@@ -1,6 +1,6 @@
 schema: agent-graph.provider.v1
 id: c4a/context
-version: 0.7.25
+version: 0.7.29
 name: Context workflow
 description: Internal work contract for Context knowledge workspaces.
 graphs:

package/providers/context/resources/procedures/document-code-investigation.md

@@ -0,0 +1,45 @@
+---
+id: procedure.document-code-investigation
+kind: procedure
+mediaType: text/markdown
+---
+
+# Assess code needs during document investigation
+
+Register the requested document sources before preparing their article plan.
+Continue authorized document capture even when unrelated registered repositories
+are unavailable. Existing workspace coverage does not select the current task's
+code dependencies.
+
+After reading outlines, representative bodies and related approved articles,
+group the reader topics and assess whether code investigation is needed before
+submitting the plan and work-start report. Large collections can be investigated
+in batches while capture continues. If the expected production plan exceeds 30
+article tasks, explicitly perform this assessment before bulk writing. This is
+Agent guidance, not a CLI validation threshold. Wiki nodes, documents and article
+tasks are different counts; more than 30 document nodes calls for early batched
+investigation, not an assumption of 30 articles or automatic repository recovery.
+
+Code evidence is useful when the reader task requires implementation behavior,
+call chains, interface constraints or debugging entry points, or when incomplete
+or conflicting documents require checking code. Explicit file, symbol or API
+references strengthen that assessment. A repository link or service name alone
+does not establish a dependency. Keep document-supported topics independent.
+
+Use existing plan briefs or report prose to explain which reader questions need
+which registered modules and why; no separate assessment receipt, score or
+required schema field is needed. If code is needed, inspect its availability with
+`context source recovery-plan <registered-name> --format json`. Follow
+[repository source recovery](repository-source-recovery.md), reusing applicable
+authorization and local checkouts. Prefer the smallest sufficient registered
+module scope. Expand to a shared physical checkout or whole repository when
+cross-module calls, common dependencies or uncertain boundaries require it;
+do not substitute a different remote or pinned commit.
+
+If recovery is unavailable, continue independent document tasks. Keep questions
+requiring unread code pending, or narrow the article to supported document
+claims and explain its limits. Do not present inferred implementation as verified
+code, delete configured sources, or clear a stage to bypass unavailable evidence.
+After recovery, follow its returned preparation command and current task handles;
+retain accepted work instead of restarting the task. Reassess code needs when
+later reading exposes a dependency that the initial sample did not show.

package/providers/context/resources/procedures/repository-source-recovery.md

@@ -17,7 +17,9 @@ remote and pinned commit, so one physical checkout can restore every module in
 that group. Do not create one clone per module. Groups already marked `ready`
 need no decision; when every group is ready, the plan has no recovery action.
 
-For each missing physical checkout, ask the user to choose one option:
+For each missing physical checkout, reuse an applicable choice and authorization
+already supplied in the current task. If the recovery choice is unresolved, ask
+the user to choose one option:
 
 1. provide an existing local Git checkout;
 2. name a bounded directory that the Agent may scan, then choose one of the
@@ -43,3 +45,8 @@ Repository sources are ready only when every selected module resolves to the
 registered remote and pinned commit, every registered subpath exists, no local
 path was overwritten, Context materialization succeeds, and the selected recovery
 plan reports them ready.
+
+Recovery failure does not stop unrelated document capture or independent article
+tasks. Preserve pending code-dependent questions and follow the returned recovery
+diagnostic. After a successful restore, follow `next_action` to refresh affected
+production material; keep accepted articles and use the newly returned handles.

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

@@ -19,6 +19,10 @@ where needed to decide reader topics, source grouping and writing batches.
 Indexer guidance discovers a skeleton, not a mandatory deep parse or a ledger
 of every symbol. Declare relevant available skills and record planned uses;
 do not collect skill hashes, versions or article ownership credentials.
+After reading representative documents and grouping reader topics, apply
+[document and code investigation guidance](../../resources/procedures/document-code-investigation.md)
+before submitting the article plan. Revisit it when new implementation questions
+appear during writing. This assessment adds no approval gate or required field.
 Submit the plan before presenting the work-start report. Planning does not
 authorize writing or approve the report.