---
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.