Scanner

Optional controlled XML external-entity review

The non-default xml-external-entity-review feature adds one explicitly authorized child to the existing WebAssessmentRuntime. It requires --profile web-review, --xml-external-entity-review, one strict local policy, all three stateful-work acknowledgements, and exactly one provider administrator-token source through environment, file, or stdin. The policy binds one exact application-contained disposable HTTPS endpoint and one distinct self-hosted HTTPS provider; it does not discover endpoints or accept caller XML.

The runtime generates one inert control plus candidate and replay XML documents, uses at most three anonymous POSTs and one logical active verification, and charges provider registration/allocation/polling/cleanup to the same parent authority. Only two distinct fresh post-dispatch callback events with a quiet control, complete cleanup, and reconciled accounting can produce a NeedsReview / KnowledgeOnly item. This does not establish confirmed XXE, parser identity, file read, internal access, data exfiltration, exploitability, or impact. The feature is mutually exclusive with ssrf-oast-review and remains outside release-bundle. See Controlled XML external-entity review.

Optional SSRF OAST query review

The non-default ssrf-oast-review feature adds one explicitly enabled child to the existing WebAssessmentRuntime. It requires explicit --profile web-review, --ssrf-oast-review, a strict security.ssrf-oast-review-policy/v1 file selected by --ssrf-oast-policy, and exactly one provider administrator-token source through environment, file, or stdin. The policy binds the CLI target's exact origin, one different HTTPS provider origin, explicit external-interaction acknowledgement, and bounded polling/lifetime limits. No provider is selected or deployed automatically.

V1 selects at most one exact query-parameter occurrence whose observed value is an absolute HTTP(S) URL, or one eligible optional url/uri query parameter from a complete same-run OpenAPI catalog. It never guesses from a name or materializes an example/default. The target plan is exactly one inert .invalid control plus candidate and replay. Execution is bounded to at most three anonymous bodyless GETs and at most one logical active verification; a completed positive path uses all three target legs and the single active verification. Candidate and replay use distinct provider callbacks and both must yield fresh, correctly correlated HTTP events before ssrf.oast-repeated-outbound-interaction@1 may be projected as NeedsReview / KnowledgeOnly with no severity. One-sided callbacks, timing, status codes, provider noise, and business-impact inference are insufficient. See SSRF OAST query review.

Optional OpenAPI surface review

The non-default openapi-review feature adds one explicit --openapi-review option to web-review. It selects at most one exact-origin JSON document, using the fixed /openapi.json fallback only because the operator opted in. The candidate and exact replay are anonymous bodyless GETs through the existing broker and together consume at most two requests and one logical active verification. Only replayed bounded OpenAPI 3.0/3.1 JSON can project api.openapi-contract-observed@1 as Informational / KnowledgeOnly. YAML is unsupported in V1, Swagger 2.0 remains metadata-only, redirects are not followed, and declared operations are never executed.

Optional REST read-only review

The non-default rest-review feature adds one explicitly enabled child to the same WebAssessmentRuntime. It requires explicit --profile web-review and same-run --openapi-review --rest-review; missing OpenAPI opt-in is rejected before network I/O. Only a complete OpenAPI candidate/replay pair with the same semantic digest can supply the catalog. V1 selects at most one anonymous, bodyless, exact-origin GET with no required path, query, header, or cookie input and no auth, request body, cross-origin, or templated-server requirement.

The selected operation receives exactly one candidate and one replay request through the parent broker and budget, consuming one logical active verification. Stable successful JSON evidence must agree in Status, Fields, and value-sensitive Resources. At most one api.rest-readonly-surface-observed@1 item is emitted as Informational / KnowledgeOnly. The review materializes no parameters, executes no writes, uses no credentials or cookies, and does not chain the route into SQL, SSTI, XSS, authorization, SSRF, or upload review. See REST read-only review.

Optional WordPress evidence review

The non-default wordpress-review feature adds one explicitly enabled, transport-free interpretation to the same WebAssessmentRuntime. It requires --profile web-review --wordpress-review; optional --wordpress-context FILE and --wordpress-advisories FILE inputs are opened, bounded, and validated by the CLI before secrets or network construction. The runtime receives typed values, not filesystem authority.

Feature-enabled development builds also accept the documented saved WP-CLI plugin/theme inventories and core-version file. An operator may explicitly declare --wordpress-advisories-format wordfence-v3-production for an already saved Production-format export. That path reads local bytes only: it neither obtains an API key nor contacts Wordfence, and unresolved source comparison semantics remain indeterminate instead of falling back to a Termivar comparator.

V1 reuses only the complete root HTML already obtained by the assessment. It recognizes supported generator metadata and canonical same-origin WordPress core/plugin/theme asset paths, adds no request or active verification, and does not fetch an asset or advisory. Public declarations, structural hints, and operator assertions retain distinct source/confidence semantics. Advisory range and prerequisite decisions remain an optional audit; they do not authenticate an installation, execute an exploit, validate impact, or mint a vulnerability finding. Supported root-response hints may project one technology.wordpress-surface-observed@1 item as Informational / KnowledgeOnly. See WordPress evidence review.

termivar-scanner contains the default deterministic evidence/reasoning/runtime stack plus feature-gated historical scan contracts, optional analysis modules, plugins, events, persistence models, and bounded report rendering.

Default deterministic runtime

Default builds expose one termivar scan product with three deliberately distinct selection states:

• With no --profile, StandardWebDecisionRuntime keeps the conservative single-resource behavior, text/--explain output, and the existing decision-scan/v1 JSON contract.
• --profile baseline explicitly selects the strict venom.scan-profile/v1 single-resource contract and emits the additive web-assessment/v1 profile audit.
• --profile web-review composes the same single-resource primitive inside a bounded exact-origin assessment. Deterministic discovery, semantic extraction, defense observation/shadow planning, passive header/cookie review, and the closed native differential catalog share one runtime-owned RuntimeBudget, request-accounting broker, cancellation authority, and exact-origin policy. Redirects remain disabled.

The exact-origin runtime uses stable bounded discovery and retains canonical subjects, form actions/methods, form-control names, candidate query-parameter names, and typed provenance. It does not retain form values or cookie values, and a discovered resource is knowledge rather than a vulnerability result. Cross-origin references are rejected rather than becoming new authority.

Passive review observes HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and value-free cookie metadata. These capabilities project only Informational AssessmentItem values. The product claim ladder permits an observation to become Informational, a matched differential to become NeedsReview, and only a verifier-authorized, case-correlated transition under a confirming claim policy to become Confirmed.

Native low-risk review is enabled only by web-review and runs on the authorized starting resource inside the same StandardWebDecisionRuntime session used for its bootstrap. It uses matched CORS control/candidate requests and, only for a recognized navigation parameter already named by the starting URL, a matched redirect/reflection query pair. The supplied query value is discarded. At most one deterministic discovered parameter is also reviewed by two independent matched SQL quote-balance pairs. The mutation contains no operator, comment, statement separator, function, or delay syntax. An item requires the same candidate-specific status-class and normalized body-structure difference in both pairs; text and latency are not signals. Native actions do not suppress otherwise eligible standard actions. The same bounded selection composes one initial versioned SSTI brace-arithmetic family. Two independently derived expressions must produce their distinct exact expected results while their controls do not. Literal reflection, a result already present in control, generic errors, unrelated changes, or inconsistent replay are insufficient. This structural signal is at most NeedsReview and does not execute commands. A reflected Origin without the complete credential policy or without two successful-status legs is insufficient. Redirect review accepts only 301/302/303/307/308, and redirects are not followed. A separate matched reflection pair sends one bounded scanner-owned inert marker and parses a supported text/html candidate once with html5ever. Comment, ordinary text, and ordinary attribute placement are Informational; URI-bearing, style, inline-handler, script-element, and embedded-HTML attribute placement are at most NeedsReview. A bounded single-pass source analyzer supplies exact double-, single-, or unquoted ordinary/URI/event-handler attribute anchors and cross-checks them with the DOM; ambiguity, incompleteness, or disagreement fails closed. The typed context and quote mode select at most one non-executing V1 family across the assessment. HTML-text requires its exact inert node. Attribute families require exact inert boundary and tail attributes on the anchored HTML host and sink, absent from control.

For a unique marker in a supported inline classic or module script, one bounded, non-evaluating JavaScript source pass is cross-checked with the html5ever script context and exact script host. Single-quoted strings, double-quoted strings, and template-literal text have executable V1 families. Expression/code, template-expression, line-comment, block-comment, and regex contexts remain metadata-only. A positive script result requires both exact scanner-owned inert block-comment tokens to be recognized as JavaScript comment tokens outside the original string or template text, in the expected order on the same script host, and absent from the control. Raw substrings, encoded syntax, and same-context reflection are insufficient.

Selection is deterministic and metadata-first, so later catalog growth does not blindly multiply requests, payload materialization, or source/DOM parses. One selected family uses one child bootstrap plus one control and one candidate: three requests total. Exact candidate-specific structural control is still only NeedsReview. No JavaScript is evaluated and no browser execution or XSS confirmation is performed. Credentialed candidate-specific CORS, an exact candidate-specific external redirect, and repeatable SQL/SSTI structural relationships are also at most NeedsReview. Every native action is KnowledgeOnly, and no native assessment capability can produce a Confirmed item.

XSS structural family	Context	Source mode	Executable?	Required evidence	Request cost	Maximum
HTML text boundary	HTML text	N/A	Yes	Exact candidate-specific inert HTML node, absent from control	3 including child bootstrap	NeedsReview
Ordinary attribute boundary	Ordinary attribute	Double, single, unquoted	Yes	Exact source/DOM anchor plus exact inert boundary and tail attributes on the host/sink	3 including child bootstrap	NeedsReview
URI attribute boundary	URI-bearing attribute	Double, single, unquoted	Yes	Same exact anchored host/sink attribute evidence; no executable URI scheme	3 including child bootstrap	NeedsReview
Event-handler attribute boundary	Inline handler attribute	Double, single, unquoted	Yes	Same exact anchored host/sink attribute evidence; event is never triggered	3 including child bootstrap	NeedsReview
JavaScript single-quoted string boundary	Supported inline classic/module script	Single-quoted string text	Yes	Exact ordered boundary/tail block-comment tokens outside the string on the exact script host; clean control	3 including child bootstrap	NeedsReview
JavaScript double-quoted string boundary	Supported inline classic/module script	Double-quoted string text	Yes	Exact ordered boundary/tail block-comment tokens outside the string on the exact script host; clean control	3 including child bootstrap	NeedsReview
JavaScript template-literal boundary	Supported inline classic/module script	Template-literal text	Yes	Exact ordered boundary/tail block-comment tokens outside template text on the exact script host; clean control	3 including child bootstrap	NeedsReview
JavaScript expression structures	Supported inline classic/module script	Expression/code or template expression	No, metadata-only	No narrow executable-slot evidence contract in V1	0	None
JavaScript comment structures	Supported inline classic/module script	Line or block comment	No, metadata-only	No active structural family in V1	0	None
JavaScript regex structure	Supported inline classic/module script	Regex literal or character class	No, metadata-only	Slash/grammar-sensitive contexts remain fail-closed	0	None
An explicitly non-HTML response makes reflection review not applicable. A
truncated body, invalid UTF-8, or exhausted DOM/occurrence ceiling instead makes
the selected differential review typed incomplete; it is never reported as an
empty successful assessment.

Optional normalization-resilience review

Normalization resilience is excluded from the default scanner and CLI feature sets. It requires the non-default normalization-resilience feature plus the explicit --normalization-resilience flag on --profile web-review; the flag is rejected for baseline and with no profile. It does not alter venom.scan-profile/v1 or decision-scan/v1.

The review consumes one complete committed XSS parent pair only when the control is not blocking and the canonical candidate creates a new candidate-specific defensive engagement. Standing blocks, rate limiting, timeouts, truncation, ambiguity, canonical semantic success, and fingerprint evidence alone are ineligible. A strong/probable fingerprint may annotate or tie-break compatible metadata; it never authorizes a request or a claim.

V1 selects at most one transform with chain depth one:

Transform	Availability	Parent family
xss.html-token-case@1	Executable	HTML text boundary
xss.html-inter-token-tab@1	Executable	Ordinary, URI, or event-handler attribute boundary
query.percent-decode-depth-one@1	Metadata only	No V1 request obligation
query.percent-decode-depth-two@1	Metadata only	No V1 request obligation

The typed serializers change only scanner-owned HTML token names or one scanner-owned horizontal separator. They do not mutate arbitrary payload text, identity values, target-controlled values, parameter names, event names, URI schemes, or JavaScript. The committed parent control/canonical pair is not resent. One selected child uses one bootstrap request, one transformed candidate, and one distinct transformed replay: exactly three child requests and one active verification through the same exact-origin, redirect-disabled broker and RuntimeBudget.

Both transformed legs must avoid the canonical candidate's defensive block and reach the parent's exact existing inert DOM semantic verifier. A status change without those semantics is not enough; a missing or mismatched replay produces no item. The resulting defensive-normalization-gap capability is at most NeedsReview and always KnowledgeOnly. It is not WAF-bypass confirmation, XSS execution, or a product-specific bypass result. See Normalization-resilience review.

An explicit root authorization context adds one anonymous/authorized JSON visibility pair without creating another scanner engine or authority. Library hosts pass WebAssessmentRootAuthorizationContext; the CLI accepts the complete header value only via --auth-env, --auth-file, or --auth-stdin. There is no raw credential argument. The option requires web-review at the exact origin root and HTTPS; numeric-IP loopback HTTP is reserved for local fixtures. A file source must be a regular, non-symlink file. Standard-input loading waits for EOF and is intentionally controlled by the invoking host. Profile, target, transport, and obvious report-output failures are resolved before credential material is read. Both active legs use the same assessment broker, budget, cancellation token, deadline, and redirect-disabled policy. Equal visibility produces no item. A complete difference is projected as one atomic comparison evidence reference and at most NeedsReview; it is not decomposed into fake control/candidate evidence and does not prove an authorization vulnerability. Incomplete collection stops later discovery and makes the run typed incomplete. The compiled web-review default reserves ten active-verification slots: seven for the initial native review pass, one for the assessment-wide context-selected XSS structural family, and two for this optional pair; any lower host-selected ceiling still fails closed.

Optional resource authorization review

Resource authorization review requires the non-default scanner/CLI authorization-review feature, explicit --profile web-review, one --authorization-review-policy file, and exactly one primary and one peer credential source. Each role accepts an environment, regular-file, or stdin source through the existing bounded secret loader; no raw credential-value argument exists, and two stdin sources or a concurrent root authorization review are rejected before network I/O.

The strict security.authorization-review-policy/v1 contract selects one exact-origin bodyless GET JSON resource and at least one non-root RFC 6901 path under the sole executable primary-only expectation. The capability is one native action inside WebAssessmentRuntime, not a second scanner. It uses the parent exact-origin authority, redirect-disabled broker, RuntimeBudget, cancellation, deadline, evidence registry, completeness lifecycle, and final report for four ordered requests: primary candidate, peer candidate, primary replay, and peer replay. The four legs consume one logical active verification. That lease is charged when the primary replay begins; the peer replay is passive-accounted inside the same active decision phase.

Each credentialed leg uses a fresh broker-owned connection pool with ambient proxies disabled. This prevents proxy state or connection reuse from joining the two operator-declared principals while preserving the parent exact-origin authority, request/byte accounting, cancellation and evidence lifecycle.

Positive evidence requires stable successful primary and peer replays plus equivalence in Status, Fields, and value-sensitive Resources for both cross-principal rounds. Status or field shape alone is insufficient. A denied, different, unstable, missing-path, malformed, truncated, redirected, rate-limited, or defensively challenged response produces no positive item and no claim that access control is secure. At most one authorization.resource-cross-principal-equivalence@1 item may be projected, with NeedsReview disposition and KnowledgeOnly authority. The review never mutates or enumerates identifiers, sends a write method, carries cookies, or confirms IDOR, BOLA, or authorization bypass. See Authorization differential review.

Stable item identity preserves authorized-root@1 for the exact origin root and assigns eligible discovered exact-origin subjects a deterministic opaque discovered-resource@1 identity. Its digest preimage uses only the stable scope, method, canonical resource structure, and sorted unique query names; query values and readable path material are never public identity metadata. A non-root starting target remains typed incompleteness unless explicit WordPress metadata discovery supplies the versioned, validated application reference. The assessment item still uses the stable origin-root identity.

Defense enforcement remains off unless --enforce-defense is supplied with web-review. Observation and shadow planning are always non-authoritative; enabled enforcement can only narrow or suppress existing authorized work. It cannot add an action, expand exact-origin authority or budgets, or increase intensity.

Optional versioned control-reference mapping

The non-default control-reference-mapping feature and explicit --profile web-review --control-reference-mapping select a bounded local pass over completed typed assessment items. The mapper is not a scanner phase and does not schedule target/provider requests, retrieve source material, change the plan or add active verification. Its additive security.control-reference-mapping-audit/v1 records finite-catalogue source metadata, item-to-reference relationships, mapped/unmapped/omitted accounting, and explicit zero external activity.

The built-in termivar.reviewed-control-references revision 2026-09-20.1 contains attributed OWASP Top 10:2025 IDs/exact title references and original Termivar rationales. PCI DSS 4.0.1 and ISO/IEC 27001:2022+Amd 1:2024 remain bibliographic rights_deferred records with no embedded control mappings. KVKK Law No. 6698 Article 12 and Guide No. 72 (April 2025) are relevant technical context with applicability unestablished. This capability is deliberately separate from the older experimental compliance scaffold below.

Relationships never mutate item identity, severity, disposition, remediation, evidence or claim authority. They are not scores, pass/fail, certification, legal advice or compliance determinations; an absent item does not establish control fulfilment. See Versioned control-reference mapping.

Optional local reconnaissance snapshot import

The non-default recon-snapshot-import feature and explicit --profile web-review --recon-snapshot FILE select one strict local security.recon-snapshot/v1 document. The file is fully bounded and validated before output reservation, credential reads, or runtime construction. Its source-qualified hypotheses are attached only after the ordinary assessment completes, so they cannot create subjects, broker permits, target/provider requests, assessment items, findings, or scan authorization.

The audit preserves exact input byte identity separately from unverified source metadata and reports its 1 MiB input, 1,024-source, 1,024-record, 4,096-source- association and 4 MiB prepared-index bounds. See Local reconnaissance snapshot import.

Internal domain facades

The scanner's responsibility-dense domains are split behind their existing root source facades. plugin, decision_loop, decision_runner, http_evidence, knowledge, rules, planner, and api_observation remain public modules; lua_engine and distributed remain private modules with reviewed crate-root re-exports. Private child modules own narrower model, policy, registry, execution, receipt, storage, query, VM, and coordination responsibilities. This organization does not add a scanner engine or change any capability semantics.

cargo xtask architecture binds the reviewed child-module inventory, keeps authority-defining symbols in their facade, rejects responsibility moving back into the facade or across siblings, and checks allowed cross-domain imports. Lifecycle remains unchanged: the deterministic assessment and plugin API 0.2 surfaces are Preview, ScannerSdk is a Legacy facade, and Lua/distributed host surfaces are Experimental.

Historical ordered pipeline

The ordered runner, scanner SDK, context, and phases require the non-default legacy-scanner feature. The CLI exposes them only as legacy-scan, and only after --acknowledge-legacy-heuristics. It registers reconnaissance, crawling, parameter discovery, SQL-behavior observation, reflection observation, template-arithmetic observation, an inert-by-default file-canary/XXE phase, and an inert-by-default OOB delivery phase; DirectoryFuzzer requires the additional --legacy-directory-fuzz opt-in.

This is currently a mixed-authority pipeline:

• Crawler, optional directory discovery, and parameter discovery (phases two through four) share a context-owned exact-origin, redirect-disabled broker. DiscoveryLimits configures finite crawl-depth, page, request, per-request-timeout, wall-time, cumulative-body, and per-response-body ceilings across those phases.
• The crawler uses deterministic breadth-first traversal and an HTML5 parser only for complete text/html bodies no larger than 64 KiB. Its typed forms retain action, method, and named parser-tree-descendant controls. POST and dialog forms are recorded, never requested as GET.
• Directory discovery compares candidates to two stable randomized nonexistent-path controls in the same parent namespace and with the same trailing-slash and extension shape. Parameter discovery requires a reproducible four-leg differential: baseline, randomized unknown parameter, candidate, and identical replay. Both produce INFO observations, not vulnerability conclusions.
• Discovery endpoints, visits, and forms are staged and committed atomically; a failed or budget-exhausted batch does not publish partial state.
• Phases five through nine share a second context-owned exact-origin broker. VerificationLimits configures its finite request, per-request-timeout, wall-time, cumulative-body, and per-response-body ceilings. Requests are bodyless, redirects and retries are disabled, and broker accounting uses the Active stage. The default shared request ceiling is 96; phase-local ceilings (20/18/16/16/16) prevent one built-in phase from consuming the full envelope. This is a separate migration authority, not the standard runtime's RuntimeBudget.
• Reproduced SQL diagnostics and robust timing differentials, exact replayed template arithmetic, and an SDK host's explicitly configured benign local-file canary may project only verifier-owned, knowledge-only NeedsReview. Exact nonce reflection remains Unknown because there is no browser-execution verifier. The default phase-eight path dispatches neither LFI nor XXE probes; an OOB string does not enable XXE. Phase nine is inert by default, and explicit OOB delivery records a nonce-bearing request receipt, not callback evidence. No cloud-metadata or sensitive-file destination is a default probe.
• Reconnaissance and host-defined custom phases can still use the raw legacy client outside both bounded authorities and RuntimeBudget. Consequently the complete ordered run is reported as Unmetered even though built-in phases two through nine have scoped limits.

The CLI emits typed completion state and suppresses phase prose/evidence. Raw compatibility records project only as informational Unknown observations; the allowlisted phase-five, phase-seven, and opt-in phase-eight bridge can instead publish the verifier-scoped NeedsReview outcomes described above. See the runtime map, ADR 0016, and ADR 0018.

Each phase implements:

#[async_trait]
pub trait ScanPhase: Send + Sync {
    fn phase_number(&self) -> u8;
    fn name(&self) -> &'static str;
    async fn execute(&self, ctx: &ScanContext) -> Result<Vec<ScanFinding>>;
}

Reporting host contract

The independent reporting feature exposes a bounded, deterministic renderer for an already constructed RunReport. In its standalone reporting feature closure it still enables only core, performs no I/O, and requires the host to pre-redact target, authorized_origin, step/outcome action_id, and outcome redacted_summary values.

When both scanning and reporting are enabled, the same ReportGenerator also consumes a completed runtime-owned WebAssessmentRunReport plus its validated profile, internally mints the generic run envelope, and renders a typed AssessmentRunReport. The default CLI enables this combination and uses it for completed web-review JSON, CSV, HTML, and Markdown output under the same 16 MiB ceiling. Assessment summaries and opaque references are already redacted before they reach the renderer. The renderer does not create items, upgrade dispositions, synthesize severity/risk, persist files, or acquire verdict authority. See Bounded report rendering, ADR 0021, and ADR 0023.

Endpoint-scale evidence

The endpoint harness exercises the real WebAssessmentRuntime only against a hard-coded 127.0.0.1 fixture. Its fixed workloads cover 100 endpoints, 1,000 endpoints, and 10,000 requests. The last workload is a batch of ten independent 998-subject origin assessments, each with its own broker, budget, cancellation, and deadline; it is not one 10,000-request authority.

Initial controlled evidence for source commit 27321efbbf49cb2adbc72afb699d1b31ea407486 is retained from workflow run 33292247976 as Markdown and validated JSON. These runner-local observations are not an SLA, capacity limit, concurrency result, accepted repeatable baseline, or regression threshold. See Benchmarks for the authority model and reproduction contract.

Experimental host execution contracts

The independent lua feature closes over core, Tokio, and a vendored Lua 5.4 build with no default mlua features. It implements approved-root source snapshot registration and fresh, no-standard-library, text-only VMs with bounded context/output/return/history and cooperative memory, instruction, deadline, cancellation, and concurrency controls. These controls are not process isolation or an OS sandbox; no CLI, scanner phase, or plugin path calls them. See Lua execution.

The distributed feature has an empty raw feature closure and implements bounded ordered task/worker/result state machines with caller-supplied logical time, expected revisions, fenced leases, fixed retry/recovery policy, and deterministic output for a fixed accepted command order. It has no transport, authentication, serialization, persistence, ambient clock, background work, exactly-once, or multi-node contract. See Distributed coordination.

Feature flags

Feature	Purpose	Maturity
core	Transport-neutral evidence, knowledge, planning, and verification contracts	Preview
scanning	Deterministic evidence, reasoning, planning, execution, verification, and bounded runtime	Preview
normalization-resilience	Non-default, explicit web-review normalization child for one typed HTML transform with candidate/replay semantic proof; maximum NeedsReview / KnowledgeOnly	Preview
rest-review	Non-default, explicit web-review REST child requiring same-run openapi-review; maximum one anonymous bodyless exact-origin zero-input GET, two requests/one active verification, Informational / KnowledgeOnly only	Preview
authorization-review	Non-default, explicit web-review four-view comparison of one operator-selected exact-origin JSON resource; maximum NeedsReview / KnowledgeOnly	Preview
supplied-session-review	Non-default, explicit web-review collection for one operator-declared principal using strict V1 authorization-header, V2 supplied-cookie, V3 bounded-form-login, or V4 scheduled-cookie-renewal policy. V3 performs one anonymous exact-login-page GET and at most one explicit no-retry/no-redirect form POST, requires one exact hidden CSRF input, admits only declared host-only session cookies, and uses the independent startup JSON health predicate as the sole success oracle. All modes keep bounded checkpoints and fail-closed later cookie-update handling; V4 adds one explicitly scheduled exact-app bodyless renewal POST and new-epoch health inside the existing nine-request/five-checkpoint limits; there is no form discovery, credential guessing, retry-on-loss renewal, OAuth, MFA bypass or vulnerability claim	Preview
secret-exposure-review	Non-default, explicit passive review of complete committed anonymous ordinary response bodies using a fixed bounded high-specificity detector catalogue; value-free Informational / KnowledgeOnly observations only, no provider validation or extra request	Preview
xml-external-entity-review	Non-default, explicit controlled XML POST review for one disposable application-contained endpoint and separately authorized provider; maximum three target POSTs, one active verification and NeedsReview / KnowledgeOnly, with no confirmed XXE, parser identity, file read, exfiltration or impact claim	Preview
legacy-scanner	Historical ordered runner, context, phases, and Scanner SDK; separate bounded discovery and active-verification slices within an otherwise unmetered run	Legacy
platform-models	Unwired API/auth/dashboard/persistence/post-exploitation/realtime library models	Experimental
reporting	Bounded generic RunReport renderer; with scanning, also the central typed assessment renderer used by completed CLI web-review runs. No renderer-owned I/O, persistence, or verdict generation	Preview
detection	Signal-definition validation, caller-scored technique catalogs, neutral deviation records, and text matching; no scoring or classification	Experimental
plugins	Evidence-only native plugin registry; no stock detector plugins	Preview
lua	Implemented bounded host-library Lua execution; cooperative in-process controls, no process isolation or repository product/runtime caller	Experimental
distributed	Implemented deterministic bounded in-process coordination; no transport, persistence, or multi-node runtime	Experimental
ml	Serializable external-model records; no learning, clustering, classification, or execution	Experimental
monitoring	Caller-supplied performance records and comparisons; no telemetry collector	Experimental
control-reference-mapping	Non-default development-only local mapping of completed typed assessment items to one built-in finite versioned reference catalogue; zero target/provider requests, no item-authority change, no score/pass/fail/certification/legal/compliance conclusion	Preview
recon-snapshot-import	Non-default development-only strict import of one explicit bounded local reconnaissance snapshot; source-qualified hypotheses only, zero target/provider requests, no target/item/finding/authorization creation	Preview
compliance	Caller-supplied audit/catalog records; no compliance determination	Experimental
threat-intel	Caller-supplied feed/rule records and catalogs; no correlation or alert engine	Experimental
full / research	Historical all-opt-in compatibility aggregates; not supported product tiers	Experimental
enterprise	Historical aggregate excluding threat-intel; not an enterprise package	Experimental

The scanner crate's default build enables exactly core and scanning. Detection, the historical runner, platform models, the bounded report renderer, host execution surfaces, and the other feature-flagged modules listed above require explicit opt-in at that crate boundary. The CLI's normal dependency selects scanning + reporting so an explicit completed web-review can use the central assessment renderer; omitting --profile still preserves the old runtime and wire behavior. CI compiles these feature groups independently, and the architecture gate binds their private module declarations, exact root facades, dependency closures, and authority constraints to the expected Cargo features. See the runtime map.

Adding a phase

1. Implement ScanPhase in src/phases/.
2. Keep CLI types out of the implementation. A built-in phase must use its assigned context-owned transport authority; an external custom phase that uses the compatibility client keeps the whole run explicitly Unmetered.
3. Return internal compatibility records; do not render or claim findings in the phase. The typed SDK boundary projects raw records only as unresolved observations. New verifier-backed projections require an explicit, allowlisted case and claim policy rather than a severity string.
4. Cover network failures, cancellation, and false-positive boundaries.
5. Register the phase in the composition root only after its ordering is explicit.

Safety

Phases can send traffic that affects a target. Use bounded concurrency, timeouts, and conservative defaults. Tests that require external targets must use controlled fixtures and must not run against public services.