@c4a/context-cli 0.7.8 → 0.7.9

package/providers/context/skills/configure-indexer-providers/references/guides/indexer-provider-and-customization.md

@@ -10,6 +10,35 @@ Context is registry-only by default. The durable selection lives in
 resolved transport paths and runtime staging directories are not selection
 authority. A Provider-only project does not create `src/indexer/`.
 
+
+## Large sources and planning depth
+
+Use directory/manifests, route or service registration and representative code to
+select Providers and plan reader subjects. Do not run a complete symbol index
+just to decide the initial article menu. Application/service file-inventory
+batches describe reading scope; they are not business module boundaries or a
+requirement to publish one article per directory. Inspect the supplied source
+access and converge related batches into reader subjects. A file with no supplied
+symbol facts has not been deeply parsed; this is not evidence that it has no APIs.
+Accepted application batches acquire parser facts before Author. Existing
+request-material remains the next action for implementation outside the initial
+reading scope. Public-contract-led profiles, including component libraries,
+retain their contract preparation because those facts define their reader targets.
+
+A read scope is an authorization ceiling. Each Indexer should own its actual
+module, with other sources as supporting evidence only when needed. Mixed
+frameworks require per-module Provider choices; do not disable a relevant
+extension to avoid fixing an oversized source boundary. Framework facts are
+still prepared at Author after the selected code has been parsed. For large
+IDL sources, first follow the selected applications' concrete protocol references
+and required includes; an entire protocol monorepo is not a default target.
+
+Parser progress is on stderr; stdout remains the command's JSON result. Report
+actual phase, source and available counts without estimating a percentage from
+elapsed time. A preparation-cache hit only reuses parser work, not proof of
+completed articles. After interruption use the current Route; do not clear state
+or increase memory automatically to retry the same oversized scope.
+
 ## Selection flow
 
 Follow `workflow.current` from `context status --format json` or `context run`.
@@ -31,8 +60,9 @@ configuration or semantic input boundary; it does not make those decisions.
    installed-Skill inventory, discovery report, or discovery-only confirmation
    is required. Use the supplied exact identity and cli-bundled distribution
    for shipped Providers, even when their Skills are also visible to the Host.
-   For a relevant external Skill, read only its exact Host-exposed frontmatter
-   and sibling `context-indexer.yaml` needed for selection. Do not guess versions
+   For a relevant external Skill, read its exact Host-exposed `SKILL.md`
+   and sibling `context-indexer.yaml`, then only the linked framework references
+   needed to evaluate observed module signals. Do not guess versions
    or scan `.claude`, `.codex`, `.agents` or arbitrary user directories. Different
    versions remain distinct; discovery order is not selection precedence.
 3. Submit the semantic `indexers` and any relevant non-CLI `host_visible_skills`
@@ -57,6 +87,31 @@ For CLI-bundled instruction Providers, these fields record the original
 selection; they are not a requirement to reinstall old bytes when resuming.
 The current CLI supplies its installed Provider's guidance automatically.
 
+### Select technology profiles per module
+
+A registered repository is a source boundary, not a single technology profile.
+Different modules may need different primary profiles and extension layers. Use
+the current selection contract's supported module and target/read scopes; never
+assign one module's stack to the entire repository merely because it was
+registered as one source.
+
+An observed framework dependency, configuration, entry or adapter signal is a
+reason to load the relevant Provider Skill and its applicable reference during
+selection. Reading this guidance is not activation or permission to execute the
+Provider. Follow its evidence rules to verify the signal within authorized source
+material, then bind the applicable profile only to the supported modules. A name
+alone may justify investigation without proving a framework is active.
+
+If boundaries are still unclear, identify the relevant modules and inspect their
+configuration and entries in the existing selection flow. Do not reject a
+relevant Provider solely because the repository contains mixed stacks, or defer
+investigation until generic authoring happens to report a capability gap. Record
+unresolved evidence and the concrete next inspection when it cannot yet be
+obtained. Keep unrelated modules on their appropriate primary profiles; multiple
+compatible, proven extensions may support one module without becoming duplicate
+primary owners. These are Agent selection responsibilities, not CLI semantic
+checks or new review gates.
+
 ## Resuming after a tool update
 
 Continue with the current Route and its supplied source material. Agents do not
@@ -110,18 +165,19 @@ indexers:
     providers:
       - id: community
         role: primary
-        skill: "<catalog.skill>"
-        version: "<catalog.version>"
-        integrity: "<catalog.integrity>"
-        distribution:
-          kind: cli-bundled
-          locator: "<catalog.distribution.locator>"
+        catalog_skill: "<catalog.skill>"
 ```
 
 - Choose `component-library` only if it matches the reader task and appears in
   the selected catalog entry's `capabilities.profiles`. For captured documents,
   notes or conversation summaries, select a profile from the corresponding
-  compatible Provider. Copy the actual catalog identity.
+  compatible Provider. `catalog_skill` selects exactly one bundled entry from the
+  current Action catalog. The CLI fills its version, integrity and distribution
+  after checking the Route revision; a changed catalog invalidates that revision.
+  Do not combine this reference with identity overrides. Full identities remain
+  available for explicitly pinned entries and external Providers, which retain
+  their resolution and authorization requirements. The persisted registry always
+  contains complete identities, never `catalog_skill` references.
 - Bind each selected requirement and all required coverage domains it owns;
   the single-domain template is not permission to drop other required domains.
   `owned_scope` names the target being described. `read_scope` may also include
@@ -347,17 +403,16 @@ Existing `reader_goals` remain valid when it is absent. Context passes this
 requirement through Partition, Author, and Review; it does not classify free
 text against a fixed vocabulary.
 
-After representative reading and necessary scope discussion, substantial new work
-can preserve the decisions in `.tmp/work-start-report.md` before Partition.
-The current workflow supplies `procedure.work-start-report` and
-`template.work-start-report`: a readable report with its existing requirement
-reference, use scenarios, scope choices, proposed classifications, first delivery
-and actual execution settings. Lightweight edits keep a short summary. The report
-is scratch context, not a published Artifact, a new approval or a condition for
-advancing the workflow. On its first presentation, invite the user to read and
-correct it and pause for that response, including in managed mode, unless they
-explicitly waived this reading opportunity. Reuse the response and report when
-continuing the same task; do not add a per-batch pause or report-status field.
+For the first production task in a new workspace, the source-boundary Route
+requires `.tmp/work-start-report.md` before source registration. The current
+workflow supplies `procedure.work-start-report` and `template.work-start-report`:
+a readable report covering readers, purpose, source families, language, settings,
+delivery outputs, first delivery and proposed organization. The Agent reads the
+brief and representative authorized material with Host tools, presents the report
+and resolves its missing choices before registration or capture. The CLI only
+checks the Route payload references a real non-empty report and records its digest;
+it does not judge prose or infer semantic decisions. Reuse and update the report
+with actual Provider choices before Partition rather than adding a per-batch report.
 
 Partition may select `artifact_intent` and `template_id` from the current
 Provider catalog, along with `reader_task`, `outline`, `priority`, and

package/providers/context/skills/configure-indexer-providers/references/reference/indexer-provider-protocol.md

@@ -47,6 +47,25 @@ Writing style, chapter drift and ordinary Provider version differences remain
 guidance. Changed source/approval identities invalidate an in-flight supporting
 projection; they are not semantic content judgments.
 
+## Current CLI Author batches
+
+Use the current Route's task keys and supplied scaffold. Within a CLI batch,
+`group_key` may be omitted: preview and completion inherit it from the selected
+current task. An explicitly different group is rejected. Standalone SDK semantic
+results still require `group_key`. Intent and eligible policy use the existing
+page-plan defaults; changing a page's purpose is not a metadata repair.
+
+The inventory reading joins exact member/fact identities to parser names, kinds
+and explicit `propsType` values. These are navigation references, not proof that
+a symbol is public or a member has been covered. Keep semantic dispositions and
+source evidence explicit.
+
+On a stale revision, the CLI exposes a current Route snapshot and current tasks,
+plus accepted identities available from the current main ledger and its Composers.
+Task keys are local to each Route. Compare stable workset/request identities,
+read the new Route and do not replay accepted work. Missing historical records
+are not evidence that old work is unaccepted.
+
 ## Resources and execution
 
 A Provider may contain a controlled program, profile-bound instructions,

package/providers/context/skills/record-workspace-version/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: record-workspace-version
+description: Record the completed Context knowledge iteration when the workspace Route selects this action.
+---
+
+Run `context version inspect --format json`. Read the changed formal files and
+the current conversation to write a concise reader-facing changelog. The CLI
+checks real changes and an increasing SemVer; you decide the wording and impact.
+Do not summarize temporary execution progress as knowledge changes.
+
+This action is selected at completed-scope delivery, after Review, Close and
+package configuration/template approval, before the final package build.
+Record one version for the completed scope, then follow the returned workspace
+Route to build outputs with that version. A failed build alone does not require
+another version; retry through the Route using the recorded version. Do not
+record a version for each intermediate batch or worker result.
+
+Keep each version's details within 1500 visible characters total, including
+punctuation across title, changes, trigger descriptions and actor display name;
+exclude protocol keys, version and date. Before submitting, compress longer
+entries by merging related changes and removing repeated execution narration.
+Retain the main changes, impact and actual triggers. Do not truncate text blindly
+or split one iteration into extra versions to evade the limit.
+
+Use the returned digest in `context version record --input <file> --format json`.
+Input fields: `expected_digest`, `version`, `title`, `changes` (nonempty list),
+`triggers` (nonempty list of `{kind, description}`), and optional
+`actor: {name, kind}`. Trigger kinds are initial, note, sessions, mr, module,
+document, navigation, repair, dist, other. Describe what actually triggered the
+iteration, not merely the CLI command. Never include raw private transcripts,
+credentials, local absolute paths or private account IDs in public history.
+
+Increment minor for added modules/material that expands knowledge coverage;
+increment patch for repairs, existing-module updates, navigation or persistent
+work-status changes. Major increases require an explicit user instruction.
+Start at 0.1.0 unless the workspace already has a higher version or the user
+specifies one. One completed scope receives one version, not one per worker.
+
+Use a Lark user's display name only when explicitly known from the conversation
+(`kind: lark`); otherwise omit actor and let the CLI use Git user.name. Do not
+look up accounts just for attribution. No identity is preferable to guessing.
+Only the coordinator records the version. Consume the returned `workflow.current`
+directly; refresh status only when the response has no Route or configuration changed.
+In managed mode resume `context run --managed --until blocked-or-complete --format json`
+for mechanical execution. Recording a
+version does not authorize a commit, tag, upload or deployment.

package/providers/context/skills/recover-workspace/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: context-recover-workspace
+description: Recover a stuck existing Context task through the independent diagnostic and scoped recovery commands. Internal entry selected by Context recovery intent; usable even when normal Graph evaluation fails.
+---
+
+# Recover a Context workspace
+
+Read [the recovery procedure](../../resources/procedures/task-recovery.md).
+Start with `context task recover --format json` in the intended existing workspace,
+without a historical workflow revision. This read-only inspection does not invoke
+normal status, source parsing, project entry execution or Graph evaluation.
+Use the reported operations and current digests, preserving approved work.
+
+If no safe operation succeeds, use [the issue template](../../resources/templates/recovery-issue.md)
+to write a sanitized `issue/YYYY-MM-DD-short-description.md` in the workspace.

package/providers/context/skills/run-indexer-agent-step/SKILL.md

@@ -9,11 +9,27 @@ metadata:
 
 # Run one bounded Indexer Agent batch
 
-Read the current Route action input and every required Resource marked `read-required`.
+Before dependent bulk work, follow
+[the shared homogeneous-source review](../../resources/procedures/homogeneous-source-review.md).
+Reuse explicit group decisions; when a newly observed group needs user choice,
+present its concrete scope and pause before parsing or submitting dependent work.
+
+
+Read the current Route action input and required shared instructions. Every
+Resource marked `read-required` must be read by the Agent responsible for that
+work; delegation does not waive reading or permit fabricated receipts.
 For `stage: approved-revision`, follow `procedure.approved-revision`: read the
 supplied approved page and return the revised Markdown using that action's schema.
 The batch instructions below apply to Partition, Author, and Composer worksets.
 
+For Partition and Author, follow the current Route's
+`procedure.parallel-agent-batch` before reading task material. When the Host and
+current permissions allow delegation, use 2–4 read-only workers for independent
+tasks; otherwise complete them in this Agent. The coordinator owns all Context
+commands and file writes. This is execution within the selected batch, not a new
+lifecycle or permission to overlap stages. Use `template.indexer-agent-worker`
+for each assignment and the procedure's bounded fallback on worker failure.
+
 Use the readable `resolved-indexer-instructions` and each task's
 `authorized-indexer-workset-view/task-NNN`, including its goals, constraints and source material.
 Each task has its own reading file. Read its referenced shared files once;
@@ -32,15 +48,21 @@ evidence.
 Return exactly one `results[]` entry for every task in the current batch, in task-key order. Each
 entry carries its `task_key` and the existing stage-specific semantic Result. A single-task batch
 still uses the same array shape. Prepare distinct results together and submit the batch once;
-do not turn it into a separate CLI round trip for each page. Copy dynamic authority values only from the Route input or that
+do not turn it into a separate CLI round trip for each page. Author group_key may be omitted to inherit the group selected by this current task_key; an explicit different group is rejected. The CLI preview and completion apply the same inheritance. Inventory facts in the reading map exact members to parser names/kinds and usable references; they do not decide coverage. Copy dynamic authority values only from the Route input or that
 task's authorized View.
 
-At the start of Partition, preserve the settled purpose/scope decisions in the
-work-start report when this substantial task warrants one and the earlier setup
-did not already cover it. The current Route exposes `procedure.work-start-report`
+At the start of Partition, preserve new settled purpose/scope findings in the
+existing work-start report when the earlier setup did not already cover them.
+The current Route exposes `procedure.work-start-report`
 and `template.work-start-report` for that handoff, including the scratch write
 boundary. Reuse an applicable report on continuation; do not recreate it for each
-workset. Report text is context, not evidence or authority. Author follows the
+workset. When planning tasks first become countable, ensure the report's task and
+module breakdown has been shown before bulk planning; for more than 50 planning
+tasks, wait for the required first report feedback before continuing. This
+threshold wait occurs once per continuing production task; later recounts or
+revisions reshow the report without repeating that wait unless a new unresolved
+user choice requires it. Follow the procedure's feedback rules. Unchanged
+continuations reuse the prior handoff. Report text is context, not evidence or authority. Author follows the
 accepted page plan and does not reread these resources or rewrite the report
 unless a material task decision changes.
 
@@ -182,6 +204,13 @@ If `next` is null and `next_preparation` reports failure, the committed outcomes
 are still saved: run its recovery command, not the previous submission. A stage's
 `progress.stop=complete` does not mean Review, close or package build is finished.
 
+For Indexer files that need no read receipt, reuse a fully read resource in this
+conversation only when its source/Provider identity and content digest are unchanged
+and its contents remain available. A new revision alone does not require rereading
+those files. Always read the new Route and task-specific changes; after context loss
+or truncated output, read the missing content. Never invent a receipt or mark an
+unread file as read.
+
 ## Reader purpose and saved page plans
 
 Use the bound requirement's `purpose` and open `reader_goals` throughout planning,
@@ -268,9 +297,10 @@ number of currently prepared tasks. Revisions can overlap delivered pages;
 do not add wave tasks to delivered pages to invent a page total.
 
 Use two bold progress lines. The first combines `overall` and a clearly labelled
-`wave` supplement; the second uses `slice`. For example, with matching CLI values:
-**[总体进度：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
-**[当前分片：补充内容检查 0/8 项]**
+`wave` supplement; the second describes the current action, using `slice` counts
+when available. Internal wave/slice names need not appear in user-facing text. For example, with matching CLI values:
+**[总体进展：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
+**[当前进展：补充内容检查 0/8 项]**
 
 A completion receipt's `submitted_slice` describes the slice just submitted;
 `progress.scopes.slice` can already describe the next Route. Use the former when
@@ -278,8 +308,12 @@ reporting submission success and the latter when announcing the next slice.
 Never combine their numerators and denominators. A null slice means no active
 Agent task slice, not that the workflow is complete. During Review/build, state
 the returned Route action briefly rather than inventing a slice ratio.
-If progress is unavailable after task cleanup, say the counters are unavailable;
-do not turn the last wave into the overall scope or report delivery as zero.
+Before counters exist or after task cleanup, describe the known stage and current
+action instead of repeatedly saying counters are unavailable. For example:
+**[总体进展：正在准备知识工作区]**
+**[当前进展：已读取启动清单，正在整理仓库与文档范围]**
+During review or packaging, name that action rather than a nonexistent slice.
+Do not turn the last wave into the overall scope or report delivery as zero.
 Continue authorized work after an update; only the agreed delivery stop or an
 actual unresolved blocker permits stopping. This format governs progress, not
 answers, review findings or necessary questions.
@@ -383,3 +417,20 @@ Use the selected Provider diagram instructions and the article guidance to choos
 ### Existing visual sources
 
 For Author/Review involving source images or tables, consume the selected Provider `references/visual-source-processing.md`. Read current workspace AGENTS.md and `context.convertVisuals`; explicit user instructions override defaults. Use authorized `visual_resources` and sections[].visuals; reuse accepted unchanged results. Capability absence or unsuitable content retains originals without a new gate. Never edit source snapshots or delete assets yourself.
+
+### Knowledge-map placement during structure review
+
+Structure approval includes `knowledge_map`. Read the preview's `knowledge_map_coverage`
+and `article_targets`. Add article entries beneath the agreed category nodes,
+with `target.artifact_ref` and an optional `section_key`; categories alone do not
+place articles. Preserve prior-wave entries. An unchanged knowledge-map revision does
+not imply the new articles are covered. Resolve the CLI's missing/invalid target
+list before resubmitting approval; classification remains your responsibility.
+Report article delivery and navigation coverage separately.
+
+For new and revised pages, decide placements against the user's current knowledge
+map: retain, add, move or create a category when the reader purpose warrants it.
+Preserve unrelated entries and stable article identities. The coordinator owns
+map edits; workers may suggest placements but never write the map. Recheck new
+article bindings each wave, even when the map itself has not changed. Website
+navigation and LLMS consume this same accepted map.

package/providers/context/skills/run-indexer-lifecycle/SKILL.md

@@ -9,6 +9,12 @@ metadata:
 
 # Run The Indexer Lifecycle
 
+Before dependent bulk work, follow
+[the shared homogeneous-source review](../../resources/procedures/homogeneous-source-review.md).
+Reuse explicit group decisions; when a newly observed group needs user choice,
+present its concrete scope and pause before parsing or submitting dependent work.
+
+
 This Action continues the sole registry-and-Provider indexing route. Use the
 current Indexer subroute for semantic partitioning, structure review, authoring,
 composition, layout, Candidate compilation, and repair. Existing approved
@@ -79,16 +85,14 @@ or delete existing knowledge to implement a proposed scope reduction.
 Read authorized captured sources before raising material gaps; only unresolved
 core questions requiring new sources or human knowledge need another question.
 
-After those decisions, use the Route's `procedure.work-start-report` and
-`template.work-start-report` Resources for substantial new work or material
-choices worth preserving. Write the readable report at `.tmp/work-start-report.md`
-before semantic planning, using the existing requirement reference and actual
-settings. Lightweight work keeps a short conversational summary. This is a scratch
-document written with the Host file tool, not another Gate or Action payload;
-follow the procedure's first-report reading invitation and conversational pause,
-including in managed mode unless the user explicitly waived that pause. Then
-continue the same Route; do not add a report approval state or polling loop.
-Reuse it on continuation rather than generating a report for every batch.
+The first production task in a new workspace already has a work-start report from
+the source-boundary Gate. Reuse and update that report with the confirmed
+requirements, actual Provider choices and later task inventory before semantic
+planning. Do not replace it or create another report per Indexer or batch. For an
+existing workspace task that legitimately had no first-task report, follow the
+Route's `procedure.work-start-report` and `template.work-start-report` when the
+task is substantial or preserves material choices. The source-boundary Gate owns
+the initial user feedback; do not add a second report approval state here.
 
 When the current subroute is a Gate, follow `gate.resolution_action` rather
 than looking for a top-level `action`. Read its Skill and output schema, use its
@@ -203,9 +207,10 @@ number of currently prepared tasks. Revisions can overlap delivered pages;
 do not add wave tasks to delivered pages to invent a page total.
 
 Use two bold progress lines. The first combines `overall` and a clearly labelled
-`wave` supplement; the second uses `slice`. For example, with matching CLI values:
-**[总体进度：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
-**[当前分片：补充内容检查 0/8 项]**
+`wave` supplement; the second describes the current action, using `slice` counts
+when available. Internal wave/slice names need not appear in user-facing text. For example, with matching CLI values:
+**[总体进展：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
+**[当前进展：补充内容检查 0/8 项]**
 
 A completion receipt's `submitted_slice` describes the slice just submitted;
 `progress.scopes.slice` can already describe the next Route. Use the former when
@@ -213,8 +218,12 @@ reporting submission success and the latter when announcing the next slice.
 Never combine their numerators and denominators. A null slice means no active
 Agent task slice, not that the workflow is complete. During Review/build, state
 the returned Route action briefly rather than inventing a slice ratio.
-If progress is unavailable after task cleanup, say the counters are unavailable;
-do not turn the last wave into the overall scope or report delivery as zero.
+Before counters exist or after task cleanup, describe the known stage and current
+action instead of repeatedly saying counters are unavailable. For example:
+**[总体进展：正在准备知识工作区]**
+**[当前进展：已读取启动清单，正在整理仓库与文档范围]**
+During review or packaging, name that action rather than a nonexistent slice.
+Do not turn the last wave into the overall scope or report delivery as zero.
 Continue authorized work after an update; only the agreed delivery stop or an
 actual unresolved blocker permits stopping. This format governs progress, not
 answers, review findings or necessary questions.

package/providers/context/skills/run-indexer-post-author-composer/SKILL.md

@@ -71,6 +71,13 @@ completion from outstanding user requests; Composer task names are not a revisio
 queue. If the Graph is complete, return to the Context entry to handle any
 remaining authorized requests rather than declaring a missing Review/build.
 
+For Indexer files that need no read receipt, reuse a fully read resource in this
+conversation only when its source/Provider identity and content digest are unchanged
+and its contents remain available. A new revision alone does not require rereading
+those files. Always read the new Route and task-specific changes; after context loss
+or truncated output, read the missing content. Never invent a receipt or mark an
+unread file as read.
+
 ## User-facing progress
 
 Use CLI `progress.scopes` (or `indexerProgress.scopes` in status) as the
@@ -93,9 +100,10 @@ number of currently prepared tasks. Revisions can overlap delivered pages;
 do not add wave tasks to delivered pages to invent a page total.
 
 Use two bold progress lines. The first combines `overall` and a clearly labelled
-`wave` supplement; the second uses `slice`. For example, with matching CLI values:
-**[总体进度：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
-**[当前分片：补充内容检查 0/8 项]**
+`wave` supplement; the second describes the current action, using `slice` counts
+when available. Internal wave/slice names need not appear in user-facing text. For example, with matching CLI values:
+**[总体进展：已交付 33 页，总页数待确定；规划完成 50/122 项；本轮写作完成 30/30 项]**
+**[当前进展：补充内容检查 0/8 项]**
 
 A completion receipt's `submitted_slice` describes the slice just submitted;
 `progress.scopes.slice` can already describe the next Route. Use the former when
@@ -103,8 +111,12 @@ reporting submission success and the latter when announcing the next slice.
 Never combine their numerators and denominators. A null slice means no active
 Agent task slice, not that the workflow is complete. During Review/build, state
 the returned Route action briefly rather than inventing a slice ratio.
-If progress is unavailable after task cleanup, say the counters are unavailable;
-do not turn the last wave into the overall scope or report delivery as zero.
+Before counters exist or after task cleanup, describe the known stage and current
+action instead of repeatedly saying counters are unavailable. For example:
+**[总体进展：正在准备知识工作区]**
+**[当前进展：已读取启动清单，正在整理仓库与文档范围]**
+During review or packaging, name that action rather than a nonexistent slice.
+Do not turn the last wave into the overall scope or report delivery as zero.
 Continue authorized work after an update; only the agreed delivery stop or an
 actual unresolved blocker permits stopping. This format governs progress, not
 answers, review findings or necessary questions.