@c4a/context-cli 0.6.19 → 0.7.1

package/providers/context/schemas/indexer-selection-proposal-validation.schema.json

@@ -0,0 +1,23 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.indexer.selection-proposal-validation/v1",
+  "type": "object",
+  "required": [
+    "protocol",
+    "proposal",
+    "static_report",
+    "outcome",
+    "next_provider_requests",
+    "resolution_requests",
+    "validation_digest"
+  ],
+  "properties": {
+    "protocol": { "const": "context.indexer.selection-proposal-validation/v1" },
+    "proposal": { "type": "object" },
+    "static_report": { "type": "object" },
+    "outcome": { "const": "provider-resolution-required" },
+    "next_provider_requests": { "type": "array", "items": { "type": "object" } },
+    "resolution_requests": { "type": "array", "items": { "type": "object" } },
+    "validation_digest": { "type": "string", "pattern": "^sha256:[a-f0-9]{64}$" }
+  }
+}

package/providers/context/schemas/indexer-subject-reidentification-input.schema.json

@@ -0,0 +1,37 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.indexer.subject-reidentification-input/v1",
+  "oneOf": [
+    {
+      "type": "object",
+      "required": ["protocol", "project_ref", "old_schema", "new_schema", "approved_subjects", "proposed_mappings"],
+      "properties": {
+        "protocol": { "const": "context.indexer.subject-key-validation-input/v1" },
+        "project_ref": { "type": "string", "minLength": 1 },
+        "old_schema": { "type": "object" },
+        "new_schema": { "type": "object" },
+        "approved_subjects": { "type": "array", "items": { "type": "object" } },
+        "proposed_mappings": { "type": "array", "items": { "type": "object" } },
+        "report": { "type": "object" },
+        "authorization": { "type": "object" }
+      },
+      "additionalProperties": false
+    },
+    {
+      "type": "object",
+      "required": ["protocol", "project_ref", "old_schema", "new_schema", "approved_subjects", "proposed_mappings", "report", "authorized_by", "authorized_at"],
+      "properties": {
+        "protocol": { "const": "context.indexer.subject-reidentification-confirmation-input/v1" },
+        "project_ref": { "type": "string", "minLength": 1 },
+        "old_schema": { "type": "object" },
+        "new_schema": { "type": "object" },
+        "approved_subjects": { "type": "array", "items": { "type": "object" } },
+        "proposed_mappings": { "type": "array", "items": { "type": "object" } },
+        "report": { "type": "object" },
+        "authorized_by": { "type": "string", "minLength": 1 },
+        "authorized_at": { "type": "string", "format": "date-time" }
+      },
+      "additionalProperties": false
+    }
+  ]
+}

package/providers/context/schemas/indexer-subject-reidentification-output.schema.json

@@ -0,0 +1,31 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.indexer.subject-reidentification-output/v1",
+  "type": "object",
+  "required": ["protocol", "report", "graph_outcome"],
+  "properties": {
+    "protocol": {
+      "enum": [
+        "context.indexer.subject-key-validation-result/v1",
+        "context.indexer.subject-reidentification-confirmation-result/v1"
+      ]
+    },
+    "report": { "type": "object" },
+    "authorization": { "type": "object" },
+    "authorization_digest": {
+      "oneOf": [
+        { "type": "string", "pattern": "^sha256:[a-f0-9]{64}$" },
+        { "type": "null" }
+      ]
+    },
+    "outcome": {
+      "enum": [
+        "subject-key-schema-current",
+        "index-subject-reidentification-required",
+        "index-subject-reidentification-invalid"
+      ]
+    },
+    "graph_outcome": { "enum": ["completed", "blocked", "failed"] }
+  },
+  "additionalProperties": false
+}

package/providers/context/skills/configure-indexer-providers/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: context-configure-indexer-providers
+description: Build one path-free Context Indexer Provider selection from current requirements and visible Indexer Skills; use during the provider-selection Graph route, not for executing Providers or changing requirements.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: indexer
+  agent-graph.entry: provider-selection
+---
+
+# Configure Indexer Providers
+
+Read
+`node_modules/@c4a/context/docs/guides/indexer-provider-and-customization.md`
+for the registry-only default, Provider-layer rules, conflict handling and
+completion conditions. This Action is the entry for
+`indexer-provider-required`; when an exact distribution is unavailable, follow
+the guide's `indexer-provider-unavailable` handling instead of substituting a
+different version or cache.
+
+Report the exact CLI-bundled catalog together with other Indexer entry Skills
+already visible in this conversation. For an exact Skill root already exposed
+by the Host, read only `SKILL.md` frontmatter and the sibling
+`context-indexer.yaml`: the manifest version is authoritative and
+`metadata.context-provider-version` must match it. Do not load Provider guidance
+until selection. Group the same Skill name and exact version into one
+conversation item with all observed source types; an installed copy of the
+same CLI-bundled identity is not another Provider. Preserve distinct source
+observations in `visible_skills`, keep different versions separate, and never
+use source count or discovery order as precedence. Do not scan plugin caches or
+persist this discovery list.
+
+When the Graph enters through `markdown-provider`, first require the completed
+capture report and report the visible `context-markdown-indexer*` Skills before
+building the route input. Treat only the report's exact `source_inputs` as
+current evidence. Do not infer semantic ownership from filenames, titles, or
+headings, and do not persist the discovery list. Capture proves byte/currentness
+only; the selected Markdown Provider remains responsible for semantic indexing.
+
+Produce `context.indexer.provider-route-input/v1` for the current, unchanged
+requirement set. Select portable distribution locators and exact versions and
+integrities. Each required requirement/domain/source/module owner cell needs one
+primary Indexer; overlapping read scope is allowed for enrichers. One Indexer
+may combine a primary layer, supporting profiles, extension layers, and
+composers, but Provider array order is not precedence.
+
+On the first pass set `community_fallback_attempted: false`. If the CLI records
+the route Action as `partial`, retry with the applicable CLI-bundled community
+profile and set it to `true`. If the CLI reports conflicting primary owner cells,
+do not choose one by name order: present the exact conflict and wait for a
+decision. If fallback still leaves an unowned required cell, preserve the exact
+CLI `capability_gap_proof` and record `blocked`; never invent a Provider or
+weaken the requirement. Only the following `propose-indexer-customization`
+Action may use that proof to draft a dependency-free minimal `extend`.
+
+Record the CLI Route Action outcome exactly from `route.graph_outcome`. Only a
+`completed` report may pass its `selection_proposal_input` to
+`validate-indexer-selection-proposal`. Provider resolution and execution remain
+separate Actions.

package/providers/context/skills/prepare-indexer-customization-project/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: prepare-indexer-customization-project
+description: Resolve the exact validated customization selection and stage its CAS-bound project proposal.
+---
+
+# Prepare Indexer customization project
+
+Read
+`node_modules/@c4a/context/docs/guides/indexer-provider-and-customization.md`
+before staging a project proposal. If validation reports an invalid local
+resource or upstream drift, preserve the exact
+`indexer-customization-invalid`/`indexer-customization-upstream-changed`
+diagnostic and return to reconciliation; do not silently drop or overwrite the
+affected override.
+
+Consume only the current `context.indexer.customization-validation-result/v1`.
+
+1. Pass `selection_proposal_input` to `context indexer validate-indexer-selection-proposal`.
+2. Resolve every emitted Provider request through `context indexer resolve-indexer-providers`; never scan a
+   plugin cache or substitute another version. Stage each resolved Bundle with
+   `context indexer stage-indexer-provider-bundle`.
+3. Build `context.indexer.customization-project-preparation-input/v1` with the exact validation digest,
+   static report, resolved/staged Bundle inputs, and current CLI operator/profile contracts. Run
+   `context indexer prepare-indexer-customization-project`.
+4. If the result is `program-authorization-required`, stop at the independent program-execution authority.
+   Do not invent the authority receipt and do not apply any source file.
+5. If the result is `project-confirmation-required`, preserve the returned proposal digest and staging
+   validation unchanged for the confirmation/apply route.
+
+Never copy Provider files into the project, widen requirement scope, add dependency intents, or bypass the
+content-addressed customization stage.

package/providers/context/skills/propose-indexer-customization/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: context-propose-indexer-customization
+description: Propose one minimal dependency-free extend customization only after the Context CLI has emitted a final capability-gap proof.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: indexer
+  agent-graph.entry: provider-selection
+---
+
+# Propose Indexer Customization
+
+Read
+`node_modules/@c4a/context/docs/guides/indexer-provider-and-customization.md`
+and follow its six-level ladder. This Action handles the
+`indexer-customization-required` outcome only; it must not reinterpret
+`indexer-customization-invalid` or
+`indexer-customization-upstream-changed` as permission to replace upstream
+resources.
+
+Use this Action only when its exact input is a
+`context.indexer.provider-route-report/v1` whose route outcome is
+`indexer-customization-required` and whose `capability_gap_proof` is present. Copy the
+exact route input and report into `capability_gap`, and copy the proof's
+`gap_digest` into the draft. Close every smaller ladder step in order with its
+CLI/provider evidence digest. Never infer a gap from prose, a Provider manifest,
+or an earlier route attempt.
+
+Propose the smallest `extend` change that can close only the reported owner
+cells and affected scopes. First close Provider-only and config levels with the
+route evidence; then prefer appended instructions, one exact template
+override, and a fixed local program extension in that order. Include only files
+under `src/indexer/<indexer-id>/` and preserve the required Provider origin
+comment. Do not create a `replace` draft, widen source scope, weaken the
+requirement, or add dependency intents.
+
+The output is an untrusted draft for the next CLI validation Action. Do not
+write project source, install dependencies, execute local code, or claim that
+the customization is applied. If no dependency-free `extend` can close the
+exact gap, report the limitation and stop for human/dependency/program
+authorization instead of emitting a conforming-looking draft.

package/providers/context/skills/revise-index-output/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: revise-index-output
+description: Revise one exact Indexer candidate set in response to a recorded runtime profile failure.
+---
+
+# Revise Index Output
+
+Read the current profile audit and its failed metric samples. Change only the bound candidate revision; do not change source scope, requirements, baseline checks, metric thresholds, or provider authority.
+
+Return `context.indexer.profile-revision-record-input/v1` with the new result fingerprint, a concrete list of actions taken, unresolved reasons, and the current ledger digest. A semantically unchanged fingerprint is not a new attempt.
+
+After the third failed attempt, stop revising. The CLI must produce the complete failure report before any override is requested.

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

@@ -0,0 +1,20 @@
+---
+name: context-run-indexer-agent-step
+description: Execute one Context-authorized Indexer workset using only the current Route input and resolved Provider instructions.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: indexer
+  agent-graph.entry: agent-step
+---
+
+# Run one Indexer Agent step
+
+Read the current Route action input and every required Resource marked `read-required`.
+Use only the materialized `resolved-indexer-instructions` content, the supplied workset,
+composition input, and Context-authorized evidence. Do not discover another Skill, read a
+Provider path, widen source scope, run a program, or invent missing evidence.
+
+Return exactly `context.indexer.agent-step-result/v1`. Preserve the supplied input and
+execution request digests, bind the materialized instruction payload digest, and include
+the current Host execution receipt. Context performs the final schema, evidence, owner,
+scope, and workset validation; never report success merely because the prose looks valid.

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

@@ -0,0 +1,36 @@
+---
+name: context-run-indexer-lifecycle
+description: Continue the sole Context registry-and-Provider indexing route; use only when the workspace Graph selects route.indexer.lifecycle-required.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: workspace
+  agent-graph.entry: context
+---
+
+# Run The Indexer Lifecycle
+
+This Action replaces the retired extraction, document-classification, align,
+structure-confirmation, and prose default-plan routes. Do not invoke those
+paths and do not turn existing approved knowledge into an indexing fallback.
+
+Read
+`node_modules/@c4a/context/docs/guides/indexer-provider-and-customization.md`,
+then follow the root `context` Skill's Indexer instructions and the exact
+structured outcomes returned by `context indexer ...`. Start by forming and
+confirming requirements when `src/indexers.yaml` is absent or stale; otherwise
+continue the current registry selection, Provider resolution, execution,
+reconciliation, layout, audit, and Candidate compile subroute. The Indexer
+Graph is the authority for each substep. Never skip directly to compile and
+never synthesize a Provider Result or a default plan.
+
+Stop on the first Host permission, non-delegatable Gate, validation failure, or
+human decision. Once current Candidates have been compiled, return control to
+`context status --format json`; the workspace Graph will select Knowledge
+Review. The Action output is only:
+
+```json
+{
+  "protocol": "context.indexer.lifecycle-continuation/v1",
+  "outcome": "follow-indexer-route"
+}
+```

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

@@ -0,0 +1,21 @@
+---
+name: context-run-indexer-post-author-composer
+description: Execute one CLI-authorized post-author composer request without changing primary facts, identity, scope, or composer selection.
+metadata:
+  agent-graph: path:../../provider.yaml
+  agent-graph.graph: indexer
+  agent-graph.entry: post-author-composer-step
+---
+
+# Run one post-author composer
+
+Read the current Route input and the exact `context.indexer.layer-fragment-request/v1`.
+Use only its bounded `primary_result_view`, selected `composer_ref`, allowed target refs,
+and the resolved instructions supplied by Context. Do not discover another Skill or
+composer, read project files outside the request, change a SubjectKey, create a complete
+primary Result, or widen the target set.
+
+Return exactly `context.indexer.layer-fragment-result/v1`. Preserve the request digest,
+composer ref, and consumed PrimaryResultView digest. Return only zero or more
+`derived-artifact-proposal` fragments for allowed targets. Context performs final schema,
+identity, evidence, policy, layer, and receipt validation before accepting the Result.

package/providers/context/actions/align-next.yaml

@@ -1,6 +0,0 @@
-schema: agent-graph.action.v1
-id: align-next
-runner: host
-effect: write
-handler: context.align.next
-inputSchema: schemas/prose-structure-batch.schema.json

package/providers/context/actions/apply-code-index-guidance.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: apply-code-index-guidance
-runner: host
-effect: write
-handler: context.project.apply-code-index-guidance

package/providers/context/actions/apply-structure-confirmation.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: apply-structure-confirmation
-runner: host
-effect: write
-handler: context.structure.confirm

package/providers/context/actions/compile-next.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: compile-next
-runner: host
-effect: write
-handler: context.compile.next

package/providers/context/actions/configure-code-extraction.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: configure-code-extraction
-runner: host
-effect: write
-handler: context.project.configure-extraction

package/providers/context/actions/configure-prose-lifecycle.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: configure-prose-lifecycle
-runner: host
-effect: write
-handler: context.project.configure-prose

package/providers/context/actions/extract-next.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: extract-next
-runner: host
-effect: write
-handler: context.extract.next

package/providers/context/actions/inspect-code-extraction.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: inspect-code-extraction
-runner: host
-effect: read
-handler: context.extract.inspect-capabilities

package/providers/context/actions/inspect-document-classification.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: inspect-document-classification
-runner: host
-effect: read
-handler: context.document.inspect-classification

package/providers/context/actions/inspect-structure.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: inspect-structure
-runner: host
-effect: read
-handler: context.structure.inspect

package/providers/context/actions/migrate-codeindex.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: migrate-codeindex
-runner: host
-effect: write
-handler: context.code-index.migrate

package/providers/context/actions/optimize-documents.yaml

@@ -1,6 +0,0 @@
-schema: agent-graph.action.v1
-id: optimize-documents
-runner: host
-effect: write
-handler: context.document-optimization.next
-inputSchema: schemas/document-optimization-decisions.schema.json

package/providers/context/actions/preview-extraction-batch.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: preview-extraction-batch
-runner: host
-effect: write
-handler: context.extract.preview-batch

package/providers/context/actions/revise-code-index-audit.yaml

@@ -1,5 +0,0 @@
-schema: agent-graph.action.v1
-id: revise-code-index-audit
-runner: host
-effect: write
-handler: context.project.revise-code-index

package/providers/context/actions/submit-code-index-audit.yaml

@@ -1,6 +0,0 @@
-schema: agent-graph.action.v1
-id: submit-code-index-audit
-runner: host
-effect: write
-handler: context.code-index-audit.submit
-inputSchema: schemas/code-index-audit-decision.schema.json

package/providers/context/resources/dialogue/code-extraction.md

@@ -1,87 +0,0 @@
----
-id: dialogue.code-extraction
-kind: procedure
-mediaType: text/markdown
----
-
-# Code-extraction dialogue
-
-Begin with the Route-selected batch inspection. Classify all modules from that
-evidence before opening any archetype template, inspect source files only for
-unresolved facts, then read every matching Route-recommended type or facet
-template. For all modules in the current batch, state:
-
-- the confirmed repository module;
-- the primary and additional module types, composable facets, evidence paths,
-  stable responsibility, entries, external protocols and important dependencies;
-- the output owner/profile and planned page kinds;
-- which files or generated/derived areas are excluded;
-- whether extraction follows configured/public entries or scans all matched
-  files;
-- whether internal symbols are included; and
-- that the first run or later deltas produce Review candidates rather than
-  approved Markdown.
-
-Also state the inspected manifest signals and the chosen extractor in one
-sentence. Say whether the selected capability covers the module directly or
-whether a project-owned adapter supplies the missing mapping. Do not ask the
-user to choose between parser package names unless two genuinely incompatible
-technical choices remain.
-
-In fully managed mode, write the same fields into one batch report instead of
-asking or narrating them module by module. A typed `material-required` gap and
-the measured scale limit remain observable in both modes; advisory risks do not
-create another confirmation Gate.
-
-If a selected package lacks a standard entry, offer two Context-owned choices:
-configure source-relative API roots, or use scan mode for all declarations in
-the confirmed file scope. Do not ask the user to change source code or package
-metadata to satisfy Context.
-
-`extractTs()` creates one candidate page per selected symbol and assigns a
-source to one index unit. Use it only when that granular shape is the intended
-public reference. For an aggregate module map, registry, protocol index, or
-cross-module flow—or multiple units over one source—use `extractCustom()` and
-declare candidate ownership. If an optional structural extractor is available,
-use it for syntax facts and keep project-specific classification in the project
-callback; do not imply that installing it adds a new CLI phase.
-
-Do not predict page counts from the template examples. Run the route-selected
-batch preview once after the plan is configured. Report discovered, AST-analyzed,
-skipped, symbol, relation, and candidate counts separately, plus resolved
-entries, exported/internal counts, symbol-kind counts, output ownership and the
-proposed knowledge tree.
-Treat those fields as structural scope evidence, not a semantic ranking. Stop
-when the preview crosses the confirmed module boundary or the module
-identity/path shape is wrong.
-
-Also report the unit inventory: eligible/analyzed file and LOC counts,
-discovered/read Markdown, target/exported symbols, stable entry and boundary
-targets, exclusions and parser gaps. After extraction, read every independent
-audit dimension and the exact uncovered identities. Use the CLI-selected
-repair actions and matching templates; do not invent a total score.
-
-Apply the per-index-unit policy exactly: up to 100 pages proceeds; 101–300 pages
-warns and proceeds; more than 300 pages stops even in fully managed mode. Group
-all oversized or capability-gap units into one explanation and one plan-revision
-Gate instead of asking about modules one by one. If the revision changes a
-module's classification, read the newly selected template before editing the
-plan; otherwise reuse the current classification and avoid another
-classification dialogue.
-
-When blocked, propose only legal revisions: narrow `include`, exclude generated
-or mirrored areas, enable `exportedOnly`, change to an aggregate
-`extractCustom()` shape, or register real child sources. Do not split one
-`extractTs()` source into overlapping index units. Report a batch-total page
-advisory as a cost signal, not a new Gate.
-
-In fully managed mode, revise absolute failures automatically and aim for each
-recommended target. After three attempts with the same unit/problem fingerprint,
-stop at the single aggregated guidance Gate and report all failed modules,
-dimensions, attempted actions, and likely missing material together. Ordinary
-mode also makes one batch decision; it does not create one user Gate per module.
-
-For a multi-module round, finish every pending extraction target before opening
-one Review. For an unchanged repeat run, explain that no added, changed, or
-removed symbols need a decision. Mention `extractTs`, `include`, `entries`,
-`mode`, or `exportedOnly` only in technical configuration detail.

package/providers/context/resources/dialogue/document-classification.md

@@ -1,33 +0,0 @@
----
-id: dialogue.document-classification
-kind: procedure
-mediaType: text/markdown
----
-
-# Document-classification dialogue
-
-Do not recommend a collection before reading the collection-neutral evidence
-view and every required source-body resource. Summarize the observed document
-shape, explain one evidence-backed
-recommendation, and describe its package root:
-
-| Collection | Use when the evidence primarily represents | Package root |
-|---|---|---|
-| `business` | business domains, actors, objects, and non-technical domain knowledge | `wikis/` |
-| `product` | requirements, user behavior, user stories, and acceptance intent | `wikis/` |
-| `architecture` | system structure, module design, technical mechanisms, and platform/tooling design | `guides/` |
-| `sop` | procedures, runbooks, operations, maintenance, and troubleshooting steps | `guides/` |
-| `faq` | question-and-answer material intended for issue-oriented retrieval | `guides/` |
-| `standards` | normative rules, constraints, checklists, and quality/compliance requirements | `rules/` |
-| `decision` | explicit alternatives, selected choices, trade-offs, and decision records | `guides/` |
-| `incident` | incident timelines, impact, causes, response, and prevention | `guides/` |
-| `test` | test plans, validation scenarios, matrices, and acceptance cases | `rules/` |
-
-`codeindex` comes from code extraction and `feats` is not a document mainline
-collection. Filenames, URLs, titles, and example collection names are
-insufficient evidence.
-
-Ask the user to confirm exactly one mainline collection for the current source,
-unless session-managed authority resolves this gate. After confirmation,
-declare the complete align, compile, and Review lifecycle for the same source
-and collection, then re-evaluate because other captured targets may remain.

package/providers/context/resources/dialogue/structure-confirmation.md

@@ -1,44 +0,0 @@
----
-id: dialogue.structure-confirmation
-kind: procedure
-mediaType: text/markdown
----
-
-# Structure-confirmation dialogue
-
-Present the staged structure as a proposal, not as approved knowledge. Explain
-that confirmation freezes the current round's:
-
-- knowledge pages and paths;
-- section ownership and source spans;
-- source-backed relationships; and
-- compile order.
-
-The final staged HTML report is the confirmation surface. Open it when the CLI
-returns it, report whether opening succeeded, and provide the file URL/path when
-it did not. Do not confirm from counts alone.
-
-Present these three outcomes in the user's language:
-
-- confirm the current staged structure digest;
-- revise the proposed structure and validate/stage it again; or
-- return to the source boundary when the current evidence scope is wrong.
-
-If staging changed the structure digest, any earlier confirmation no longer
-applies. When `workflow.current.gate.resolution` is `user`, explain the change
-and obtain a new confirmation. When it is `session-authority`, inspect the same
-report and continue without asking again. After resolution, execute only the
-revision-bound command returned by `workflow.current`; never construct or reuse
-a phase-local confirmation command.
-
-Deterministic boundary repairs are internal CLI maintenance and are not
-separate approval rounds. If `workflow.current.gate.resolution` is
-`session-authority`, inspect the final staged report and execute the returned
-resolution command without asking the user again. Otherwise ask for one final
-confirmation of the staged digest. Ask an earlier design question only when
-evidence supports multiple incompatible structures, and say clearly that it is
-not the final confirmation.
-
-One source document may map to one page, but that is still an ordinary
-structure proposal. A multi-source round confirms each source/collection slot;
-do not confuse one slot with completion of the entire document batch.

package/providers/context/resources/dialogue/workflow-mode-after-capture.md

@@ -1,25 +0,0 @@
----
-id: dialogue.workflow-mode-after-capture
-kind: procedure
-mediaType: text/markdown
----
-
-# Workflow mode after source capture
-
-When source capture has completed, ask about execution mode only if the
-conversation still has no explicit choice and no earlier mode question was
-asked. If ordinary review or fully managed operation was already selected,
-continue without a reminder or another confirmation. When a choice is still
-needed, explain in the user's current conversation language that ordinary
-review pauses at review decisions and provides HTML reports for inspection.
-The current product estimate is that ordinary review makes the overall workflow
-about 40% slower, with the exact difference depending on scope and response
-time.
-
-Offer fully managed operation for the rest of the current conversation. Explain
-that it skips delegatable content-review surfaces and is faster, but reduces the
-user's ability to control or adjust intermediate content. It does not bypass
-source boundaries, external permissions, hard validation, evidence checks,
-verification failures, or other non-delegatable safety boundaries. Do not ask
-again after this one-time conversation choice, and never persist it in project
-files.