Runtime map (what actually runs)

Supplied-session authenticated assessment

The non-default supplied-session-review scanner/CLI feature adds no work by itself and remains outside release-bundle. Explicit --profile web-review, a strict local policy, and exactly one matching credential source select one context-isolated authenticated child inside the existing assessment. V1 security.supplied-session-policy/v1 accepts one authorization-header value from environment, regular file or stdin. V2 security.supplied-session-policy/v2 accepts a bounded explicit cookie TSV file through --session-cookie-file. V3 security.supplied-session-policy/v3 accepts one bounded username/password TSV through --session-login-file and establishes its cookie session using one explicitly configured form. The target must use HTTPS; numeric-loopback HTTP is accepted only for owned development fixtures, and Secure cookies still require HTTPS.

V1/V2 perform one structured startup health GET, then at most four explicitly listed bodyless, operator-selected same-application GETs, each followed by another health checkpoint. V3 performs one anonymous exact-login-page GET, requires one exact eligible form and hidden CSRF input, and permits at most one no-retry/no-redirect form POST to that same URL. It begins with no session cookie; only policy-declared host-only session cookies from that response can establish the jar, and the independent startup JSON health predicate is the sole success oracle. V3 selects at most three resources so login GET + POST + startup health + resource/checkpoint pairs still fit the unchanged nine-request ceiling. Application-defined GET handling and the explicit login POST can have server-side effects, so the operator must authorize the selected sequence. The no-proxy client, evidence and reuse state are private to the operator-declared principal/ context. Redirects and retries are disabled. Policy response/body/time ceilings narrow the shared parent authority. Session loss stops later credentialed work without automatic renewal or anonymous fallback. V2 preserves declared host/domain/path/Secure/expiry, HttpOnly and SameSite facts while intersecting protocol applicability with the narrower application authority. V3 permits only declared host-only, HttpOnly, Strict/Lax session-cookie shapes. Neither mode emulates browser CSRF behavior nor enables the HTTP client's automatic cookie jar. A selected or unusable post-login response-cookie update stops later work; outside V3's initial establishment, no response update is applied.

The completed report may contain one strict security.supplied-session-audit/v1, V2 security.supplied-session-audit/v2, or V3 security.supplied-session-audit/v3 with opaque references and reconciled checkpoint/resource accounting. V2 adds only aggregate declared-cookie metadata and value-free update counts. V3 adds value-free page/CSRF/submission/cookie outcomes, bounded attempt/cookie/byte counts, and its pre-authentication epoch zero to authenticated epoch one lifecycle. It emits no vulnerability item and does not claim continuous authentication between checkpoints, principal authentication, server authorization, exploit execution or impact validation. Browser import, form discovery, credential guessing, automatic renewal, OAuth and MFA bypass are not part of this slice. The separately explicit WordPress composition accepts only V1/V2/V3 and sends no credential to WordPress metadata or fingerprint requests. V3 uses the versioned form-login collection policy; V4–V7 remain refused before secret acquisition. This does not add native wp-login.php compatibility, authenticated-page fingerprint or private-URL crawl authority, or a new request allowance.

V4 security.supplied-session-policy/v4 is an explicit exception to the legacy no-renewal behavior: a ready host-only, HttpOnly, nonpersistent Strict/Lax cookie session may perform one scheduled bodyless same-application POST after a healthy resource boundary. Applying the exact replacement set advances the epoch before an immediate new-epoch health GET. Subsequent resources require that check; a failure never resumes the old jar, retries, replays a resource or falls back. Two or three resources plus renewal fit the unchanged nine-request/five-health- checkpoint ceilings. The new security.supplied-session-audit/v4 and strict feature-independent reader preserve epoch-bound receipt, accounting and offline comparison semantics; historical v1–v3 bytes remain unchanged. WordPress and WebSocket session consumers reject v4 before credential/output acquisition.

V5 security.supplied-session-policy/v5 adds only imported external public-code S256 credential acquisition. Explicit --session-oauth-code-file supplies a bounded secret transaction, never a browser/profile search. A sealed exact IdP descriptor permits one token POST in a separate no-proxy/no-cookie/no-retry pool under the SAME parent/session accounting; there is no IdP discovery or callback. Complete uncoded JSON is privately reduced before general observation, and a read-back committed context-bound acquisition receipt is required before Bearer startup health/resources. The exact schedule is 2 + 2 * N, N <= 3, within the unchanged nine-request session ceiling; smaller parent/body/time bounds win. The imported front-channel/S256 context remains an operator assertion. State, nonce, OIDC identity, token signature and remote PKCE enforcement are not established; a token response does not replace the target health oracle. V5 audit and strict feature-independent readers retain null unevaluated facts, opaque references and actual admitted/completed/committed counts, not token/code bytes or public unkeyed secret/body hashes. WordPress/WebSocket V5 composition, refresh and interactive OAuth/OIDC login are unsupported. The feature and curated bundle composition do not change. See the complete V5 limitations in docs/internals/supplied-session-review.md.

V7 is a separate client-initiated public S256/state transaction, selected only by --session-oauth-authorization-output and strict V7 policy. The CLI owns a create-only private handoff file; runtime receives a bounded writer, not a path. An exact fixed numeric-loopback form-post listener is minted once by the same assessment authority. Its reception lease and raw ingress consume the same parent ledger but remain separate from outgoing session HTTP counts. The authorization wait is capped at 30s; callback qualification starts the unchanged at-most-10s session window without resetting the parent deadline. A successfully committed callback receipt is revalidated before the single IdP exchange and in the subsequent credential-acquisition receipt chain. Saved V7 data is display only. Reports distinguish state/issuer binding from OIDC nonce/identity/signature validation, which remain unperformed. No automatic user-agent opening, IdP discovery, refresh or WordPress/WebSocket composition is selected. Historical V5/V6 admission, digests, schemas and broker once bits retain their meanings.

V6 additionally selects one scheduled opaque-Bearer refresh after the first committed resource and healthy boundary. Its separate sealed purpose requires the same assessment's exact committed code/resource/health evidence; a new read-back renewal receipt plus immediate epoch-2 health qualifies later work. Exactly two resources use eight shared requests, four health checkpoints and one IdP pool. The immutable parent/policy deadline is never reset by a new access lifetime. Refresh values stay guarded and leave no public secret-derived digest; one local replacement-value inequality does not establish server revocation or replay detection. V5 remains refresh-discarding. V6 audit/readers and contextual Compare preserve original resource epochs without installed-version, OIDC or signature authority. WordPress/WebSocket composition is initially unsupported; there is no new flag, feature or curated-bundle promotion.

OpenAPI surface review

The non-default openapi-review scanner/CLI feature adds no work by itself. With explicit --openapi-review --profile web-review, one native action may select one exact-origin JSON document and dispatch a bodyless GET candidate plus an exact replay through the shared broker. The complete optional child costs at most two requests and one logical active verification. Only replayed OpenAPI 3.0/3.1 JSON may produce the Informational / KnowledgeOnly api.openapi-contract-observed@1 item. YAML and Swagger 2.0 create no runtime item, and described operations are not executed.

Explicit --secret-exposure-review may compose with OpenAPI and its optional REST child, but not the selected OpenAPI-plus-SSRF-OAST combination. The separately planned GET candidate/replay are not passive detector inputs. Full semantic replay equality stays private; exact committed value-free lineage replaces public response/catalogue digests, the existing audit keeps semantic_digest: null, and the item uses a coarse assessment-subject identity. That identity does not establish cross-run document equality. The privacy guard adds no request or allowance, and option-off behavior is unchanged.

REST read-only review

The non-default rest-review scanner/CLI feature adds no work by itself. It requires explicit --profile web-review --openapi-review --rest-review and a complete replay-stable OpenAPI catalog committed by the same assessment. It selects at most one anonymous, bodyless, exact-origin GET with zero required inputs. One candidate plus one replay consumes exactly two requests and one logical active verification through the existing broker and budget.

Only replay-stable successful JSON evidence equivalent in Status, Fields, and value-sensitive Resources may produce api.rest-readonly-surface-observed@1, capped at Informational / KnowledgeOnly. No parameter or request body is materialized, no credential, cookie, redirect, retry, or write method is used, and the selected operation is not chained into SQL, SSTI, XSS, authorization, SSRF, or upload review.

Explicit secret-exposure composition retains full value-sensitive REST replay equality privately. Its separately planned GETs are not passive detector inputs. Exact committed receipt/write/lineage checks replace public body/view digests and catalogue-derived operation/target identities; the selected REST audit omits selected_operation_identity and uses a coarse subject item, not cross-run resource equality. Historical option-off contracts remain strict. This adds no REST request or budget and does not change the two-request/ one-active allowance or operation selector.

Passive response secret-exposure review

The non-default secret-exposure-review scanner/CLI feature adds no work by itself and remains outside release-bundle. Explicit --profile web-review --secret-exposure-review attaches one shared, assessment-owned observer to the ordinary anonymous response transaction. Its value-free records become report authority only after the validated commit. It does not add a request, widen the generic subject plan, promote HEAD to GET, start a provider client, or create a second assessment. Every observed body, including an evaluated zero-match, uses value-free lineage instead of a public whole-body digest and is not projected into generic or WordPress body- derived evidence; the audit counts that privacy suppression. Native active-review control/candidate bodies are never detector inputs. While this option is selected, their ordinary public body digest is replaced with value-free, receipt-bound lineage; the native semantic evidence and request plan remain unchanged.

Admission requires one complete status-200 ordinary GET with no explicit request headers, no redirect, no Content-Encoding, consistent retained byte and Content-Length evidence, a supported textual media type, valid UTF-8, and a successful evidence commit. The fixed V1 catalogue recognizes only structurally plausible private-key blocks, nearby paired AWS access-key-ID and secret-access-key assignments, Stripe live secret/restricted-key shapes, and explicit Bearer authorization assignments. It retains detector classes and bounded counts only—never matched values, fragments, reversible encodings, or public secret hashes. Supplied-session response bodies are not selected.

The observer accepts at most 128 KiB per response and reserves at most 4 MiB of admitted detector-work bytes across an assessment before UTF-8 and detector parsing. Invalid UTF-8 and detector-limit refusals still consume that private allowance; the public interpreted_byte_count counts only successfully evaluated bodies. It also allows at most 1,024 response outcomes, 64 occurrences per response, and 32 retained subject/class observations. The existing smaller assessment bounds still win. Committed response outcomes and retained/omitted counts feed the same final item set and the optional strict security.passive-secret-exposure-audit/v1. A retained detector class may produce only an Informational / KnowledgeOnly item. Source authentication, secret validity, provider acceptance, exploit execution, and impact validation are not established or performed. See Passive response secret-exposure review.

Existing-connection TLS observation

The non-default tls-observation scanner/CLI feature adds no work by itself and remains outside release-bundle. Explicit --profile web-review --tls-observation enables TLS metadata exposure on the same assessment-owned Reqwest clients and reduces metadata only from successful responses they already obtain. It does not add a subject, request, connection, handshake, retry or redirect.

The current response seam exposes at most one peer leaf certificate as complete DER. The shared collector immediately bounds, parses and reduces it; neither the DER bytes nor readable subject/SAN names enter evidence or reports. At most 16 unique leaves retain a complete-DER SHA-256/length, validity/observation times, bounded SAN-class counts, time status, successful transport-validation scope and response occurrence count. Plain HTTP, missing metadata, malformed or oversized leaves and retention exhaustion remain distinct accounting outcomes.

Reqwest does not expose negotiated protocol, cipher suite, ALPN, the full peer chain, connection identity/reuse, handshake kind or resumption here. These stay not_exposed_by_backend; revocation/OCSP/CT/AIA remains not_checked. Matching leaf bytes cannot prove socket reuse, and one successful connection is not an active TLS support matrix. The source is scoped to the assessment's exact-origin authority rather than a request purpose or principal. Validity classification uses a local system clock whose accuracy is not independently verified. The strict optional security.tls-observation-audit/v1 produces no finding or active verification. See Existing-connection TLS observation.

Active TLS negotiation review

The non-default tls-negotiation-review scanner/CLI feature remains outside all aggregates and release-bundle. Explicit --profile web-review --tls-negotiation-review accepts one credential-free DNS HTTPS target and mints one single-use child from the existing assessment authority. The child shares the parent request/active-verification, response-byte, cancellation and deadline accounting.

The fixed execution order is TLS 1.3 then TLS 1.2, using Rustls' default ring provider and ordinary configured certificate and hostname validation. At most one connection is in flight. The child sends only TLS handshake and close-notify bytes: no HTTP/application bytes, credential, client certificate, early data or ALPN offer. It disables resumption and performs no retry, redirect, proxy operation or alternate-address fallback. A single bounded DNS resolution chooses one deterministic address. Three additional matrix rows—TLS 1.1, TLS 1.0 and legacy cipher suites—perform no network work and remain not_tested_client_backend_unsupported.

The strict optional security.tls-negotiation-review-audit/v1 records only the closed matrix, dispatch/outcome classes, actually negotiated protocol/cipher on successful cells, validation state and raw TLS byte accounting. It contains no target hostname or address and produces no finding. Offline Verify and Compare understand the audit without compiling the producer feature. See Active TLS negotiation review.

Isolated HTTP parser-boundary laboratory

S15B is not a scanner mode. A private termivar-scanner module exists only under exact cfg(test) beneath the scanning-gated web_runtime module; it has no Cargo product feature, CLI selection, runtime input, report writer, saved reader, capability record or package member. The exact native test owns both ends of a numeric-loopback front-end/back-end topology and runs four fixed, sequential, one-message cases: one Content-Length agreement, two intentionally different Content-Length/Transfer-Encoding boundary interpretations and one incomplete timeout control. The fixtures contain no second request and the laboratory has no cache, response-interception, authorization or application-effect oracle.

One test-owned RequestAccountingBroker admits each case at the active stage before any listener or connection is created. The fixed matrix accounts four logical requests and 328 admitted input bytes. Separate wire counters record 328 front-end plus 266 back-end request bytes, zero response bytes, four front-end connections and three back-end connections. The timeout control never dispatches to the back end, and a fifth case is rejected at the total-request limit before bind/connect. Only case identity, parser identity, exclusive boundary offsets, connection and byte counts, outcome, and limitations may be printed; raw request bytes are not evidence output.

The exact release-profile test runs on Linux, Windows, Intel macOS and Apple Silicon through the existing runtime-smoke matrix. Its maximum maturity is LAB_QUALIFIED_ONLY: a measured boundary disagreement proves only the behavior of the owned parsers and fixed fixture. It does not establish HTTP request smuggling, a vulnerable target, exploitability, cache poisoning, response interception, access-control effect or live-target support. See Isolated HTTP parser-boundary laboratory.

Local JWT policy review

The non-default jwt-policy-review scanner/CLI feature remains outside default and release-bundle. Explicit --profile web-review, --jwt-policy FILE, --jwt-public-jwk FILE, and exactly one of --jwt-token-env ENV_VAR, --jwt-token-file FILE, or --jwt-token-stdin select one local transport-free evaluation. The policy plus the closed public-JWK structure and canonical 32-byte x/y coordinates are validated before the selected token source is read. Curve membership and signature validity are decided only during local ES256 verification; failure remains unauthenticated with local_signature_status=invalid. Token bytes stay outside argv. Without the separately compiled target-acceptance feature and explicit target policy, they are never forwarded to the assessment target.

The V1 policy requires a bounded non-secret operator policy_revision plus explicit intended typ, issuer, and audience bindings. All three checks are mandatory; a policy cannot deselect one and still belong to this contract. The revision must change with private policy semantics, while a reported SHA-256 of the exact public key point detects changed supplied key bytes without authenticating their source.

The closed V1 profile accepts only a bounded compact ES256 JWS and one strict local EC/P-256/ES256 public JWK. Structural admission does not establish P-256 curve membership before verification. Duplicate JSON keys, unsupported algorithms, JWE, nested or compressed JOSE, critical/unencoded-payload extensions, private key material, embedded keys, jku, and x5u fail closed. The JWT evaluator performs zero target requests and no remote-key retrieval. Unless the separate target-acceptance feature is selected, it performs no token replay; the surrounding scan retains its ordinary authorized web requests.

The value-free security.jwt-policy-review-audit/v1 keeps parsing, local claim/time policy consistency, ES256 verification against the supplied key, and target acceptance as distinct states. Target acceptance remains not_performed when the separate target option is absent. Local signature verification does not authenticate the issuer or source, establish server acceptance or authorization, or perform exploit/impact validation. See Local JWT policy review.

Bounded JWT target acceptance

The separate non-default jwt-target-acceptance-review feature depends on the local review but remains outside default and release-bundle. After the local evaluator establishes supported parsing, policy consistency and ES256 signature validity, explicit --jwt-target-acceptance-policy FILE may authorize one exact same-origin, application-contained, query-free JSON GET resource and one private top-level boolean marker. The policy cannot select a key endpoint or expand target authority.

The child runs six ordered candidate/replay roles: valid token, anonymous control and invalid-signature control, then the same three roles as replays. Only the two invalid-signature roles are active, and each requires its same-stage valid marker plus absent anonymous marker before dispatch. Each leg gets a fresh ambient-proxy-free connection pool. Redirects, retries, cookies, ambient credentials and write methods are absent; request, active, byte, deadline, cancellation and evidence accounting remain owned by the parent assessment.

The local retained/interpreted limits are 64 KiB per response and 256 KiB for the six-leg child. The broker still charges every delivered transport chunk, so the audit reports exact charged bytes separately; those bytes can exceed the retained bytes by a final chunk overrun. Only complete committed JSON-compatible status-200, 401 or 403 responses with a strict top-level boolean marker are classified. Token bytes, the marker name, raw URL, body and Authorization value are absent from the value-free audit. A stable marker under an invalid-signature control is a target-acceptance relationship only. It does not authenticate the issuer, prove an authorization bypass, validate impact or emit a Confirmed finding.

Versioned control-reference mapping

The non-default control-reference-mapping scanner/CLI feature remains outside default, release-bundle, and the published alpha.2 archives. Explicit --profile web-review --control-reference-mapping runs one bounded local post-composition pass over completed typed assessment items. It neither changes the assessment plan nor schedules a target request, provider request, source retrieval, action, or active verification.

The built-in finite catalogue is termivar.reviewed-control-references revision 2026-09-20.1. Its optional audit is security.control-reference-mapping-audit/v1 under policy termivar.control-reference-mapping/v1. V1 embeds attributed OWASP Top 10:2025 IDs and exact title references plus original Termivar rationale. PCI DSS 4.0.1 and ISO/IEC 27001:2022+Amd 1:2024 are bibliographic rights_deferred sources; they contribute no embedded control mapping. KVKK Law No. 6698 Article 12 and Guide No. 72 (April 2025) are relevant technical context only, with applicability unestablished.

Mapping is an additive relationship audit. It cannot change an item's severity, disposition, identity, evidence, remediation or claim authority. It is not a score, pass/fail result, certification, legal advice or compliance determination, and an absent item is not control fulfilment. Catalogue/source changes are methodology changes in Compare. Verify checks saved bytes and schema consistency, not catalogue truth, source authenticity, applicability or control fulfilment. See Versioned control-reference mapping.

Cert Spotter CT reconnaissance provider

The non-default recon-ct-provider scanner/CLI feature remains outside default, the seven-member release-bundle, and the published alpha.2 archives. Explicit --profile web-review --recon-certspotter-policy FILE selects one strict security.recon-certspotter-policy/v1 file. Both provider_use_authorized and privacy_disclosure_acknowledged must be true.

The production policy token names only the fixed live-endpoint mode at https://api.certspotter.com/v1/issuances; it does not establish provider approval, account entitlement, or general production entitlement. The required provider_use_authorized acknowledgement records the operator's decision that the query fits the provider-documented limited unauthenticated personal/evaluation-use basis, hourly quota, and current terms. The only alternate route is an explicit operator-owned numeric-loopback fixture. The child uses the shared parent request, byte, deadline, and cancellation authority. Only complete supported page bodies enter hypothesis parsing. Every dispatched attempt and terminal outcome, including throttling, unsupported responses, and transport failure, remains bounded accounting in the runtime audit and final report. It dispatches at most two sequential pages, retains/interprets at most 256 KiB per page and 512 KiB total, retains at most 256 names, and performs no retries or polling. V1 supplies no credentials. Redirects and ambient proxies are disabled.

Returned CT names stay source-qualified hypotheses and never become scan subjects, broker permits, scan authority, ownership or authentication evidence, assessment items, or findings. Release-candidate acceptance does not receive a production query/authorization input and therefore records live service status NOT_RUN_NO_INPUT. See Cert Spotter CT reconnaissance provider.

Local reconnaissance snapshot import

The non-default recon-snapshot-import scanner/CLI feature remains outside default and release-bundle. Explicit --profile web-review --recon-snapshot FILE opens one hardened regular local file and strictly parses the bounded security.recon-snapshot/v1 document before output reservation, credential acquisition, or runtime construction.

The typed snapshot bypasses WebAssessmentRuntime planning and transport. Only after ordinary composition completes is it attached as an optional security.recon-snapshot-import-audit/v1 section. Imported CT names, historical DNS associations, banner product hints and reputation labels stay linked to their unverified source declarations. They create no subjects, knowledge authority, broker permits, assessment items/findings, requests, or verification claims. See Local reconnaissance snapshot import.

WordPress evidence review

The non-default wordpress-review scanner/CLI feature adds no work by itself. With explicit --profile web-review --wordpress-review, the existing root observer interprets supported structured generator metadata and canonical exact-origin WordPress asset-path hints from the complete HTML response that the assessment already obtained. Optional context and advisory files are strictly acquired by the CLI before runtime construction; the runtime receives bounded typed declarations and no path or file handle.

There is no separate WordPress scanner, provider, budget, queue, or finalizer. Enabling only the review adds zero target/provider requests and zero active verifications. One technology.wordpress-surface-observed@1 Informational / KnowledgeOnly item may describe supported root-response hints.

The additional --wordpress-discovery opt-in reuses the same assessment broker, budget, evidence lifecycle, and deadline for at most twelve anonymous, bodyless, same-origin metadata GET attempts. Without a page scope, candidates still come only from committed root evidence. Explicit --wordpress-page-scope observed may additionally interpret at most three eligible anonymous complete HTML GET responses already committed by the ordinary assessment; it dispatches no page request, while accepted component hints may nominate metadata requests inside the same twelve-attempt allowance. It does not use credentials, follow redirects, retry, seed general crawling, or add an active verification. A separate technology.wordpress-metadata-source-response-observed@1 informational observation may retain references to committed REST-index, theme-stylesheet, or plugin-readme response outcomes, including cases where usable metadata was not present. Plugin Stable tags remain distribution hints, not installed versions.

When both review features are compiled, the additional --wordpress-supplied-session flag requires the supplied-session policy and credential plus the explicit WordPress review/discovery composition. This consumer admits only V1/V2/V3; V3 uses the existing private --session-login-file, while V4–V7 remain refused before secret acquisition. Only a complete selected resource response whose following health checkpoint and S01 resource evidence committed can contribute component hints. The frozen entry application/layout remains authoritative. Public metadata is fetched anonymously through the existing WordPress broker and shared twelve-attempt allowance; the session credential is never forwarded. Authenticated-page asset fingerprinting is deliberately not selected in this first integration. Its separate audit keeps policy/application/principal/mechanism/epoch identity and health-qualified page coverage, so a principal or session-loss difference is not presented as plugin removal or remediation.

The discovery schema remains security.wordpress-discovery-audit/v4, with the same field shape. Ready V1/V2 retain collection policy termivar.wordpress-supplied-session-metadata-discovery/v1, mode committed_supplied_session_resources and epoch one. V3 uses collection policy termivar.wordpress-supplied-session-metadata-discovery/v2 and mode form_login_supplied_session_resources. Its nested epoch is the actual final established-session epoch, zero until acquisition and healthy startup complete. Cookie acquisition alone does not advance it. Epoch zero requires zero dispatched resources, no committed/interpreted activity and only empty not_established / not_evaluated page rows without supporting component evidence. S01's undispatched planned resource rows remain epoch one. Wrong-principal startup failure retains epoch zero; health loss after successful startup retains epoch one. Neither qualifies an uncommitted page. The separate owned V3-conforming fixture does not establish native wp-login.php compatibility, fresh session creation or session-fixation prevention. No budgets, flags or feature selection change.

Version ranges, prerequisites, catalogue coverage, discovery limits, and uncertainty are kept in the same final report audit. They do not authenticate a live installation, prove advisory applicability, execute an exploit, or validate impact. The feature remains outside default. The current untagged alpha.3 release-bundle compiles this Preview, but it still adds no work without explicit CLI selection; published alpha.2 archives predate all WordPress producer and audit support.

This page describes the executable truth of the current main-line source, not aspirations. A compiled module is not necessarily part of a product runtime. This unreleased development source line uses package version 0.10.0-alpha.3; the published v0.10.0-alpha.2 prerelease does not include later main changes. Neither line is production-ready.

The historical audit and its final dispositions are kept separately in the runtime-truth remediation closure.

Termivar has one default scan runtime, one separately compiled historical runner, and optional host/adapter surfaces. A capability in one surface does not silently participate in another.

The separate, non-published termivar-exploit workspace crate remains outside all product runtimes. Its default Preview surface owns bounded venom.exploit-manifest/v1 metadata, deterministic catalog selection, applicability/risk declarations, authorization requirements, and lifecycle vocabulary. Its non-default orchestration feature adds an explicit host library for deterministic planning, host-minted non-deserializable grants, sealed source-linked implementation bindings, narrow step permits, validated receipts, impact/cleanup accounting, and venom.exploit-run/v1 reports. Only a wholly in-memory termivar-canary integration fixture exercises that surface. There is no production target, network, process, browser, filesystem, or external-callback adapter; no scanner/CLI/API/proxy dependency edge; and no route from an AssessmentItem to an exploit. Repository pack validation is an explicit xtask operation and does not participate in termivar scan.

The historical scanner salvage ledger is repository evidence, not runtime authority. The explicit xtask scanner-salvage check reads only the strict ledger, generated report, and local Git objects for the deleted 38-file tree. Only the historical detector's byte-pattern component is now marked Restored by the separate termivar-artifact domain. The historical request/response fixture component is restored only as the sanitized repository conformance corpus; synthetic vulnerabilities remain rejected. Bounded GraphQL review and the independently rebuilt OpenAPI contract/replay subset now cover two parts of the historical protocol taxonomy without restoring it wholesale; REST operation execution, gRPC, SOAP, and fabricated unconditional API tests remain outside this runtime. Its unsafe mmap adapter, fabricated request-path finding logic, and unsupported optimization claims remain rejected.

The separate post-workspace WAF/evasion salvage ledger records a later 13-file, 39-component source epoch around the WAF/evasion quarantine commit. The xtask waf-evasion-salvage check reads only that strict ledger, its generated report, and local Git objects. It maps historical fingerprinting to the existing observation-only defense domain and neutral encoding to the existing payload-strategy boundary where applicable. It does not restore waf.rs, retired adaptive modules, a generic evasion dispatcher, or their request paths. Only the classified HTML token-case and inter-token whitespace concepts are marked restored by the separately reviewed, feature-gated normalization-resilience runtime. Every rejected blind, request-shape, framing, rate-limit, and misleading-claim component remains rejected; ledger status itself never authorizes execution or raises claim authority.

The scanner conformance corpus is also outside every product runtime. Its 127 sanitized cases, including 23 four-view authorization differentials and 24 raw-free SSRF OAST lifecycle cases, use the internal security-assessment-fixture/v1 schema and are checked by the deterministic xtask scanner-corpus command. Validation and the conformance harness perform no network requests, add no scanner action or executor, and change no report claim. Passing these repository cases demonstrates agreement with checked-in contracts only; it is not an empirical scanner-accuracy measurement.

The OAST correlation foundation is a non-default, transport-free termivar-scanner library surface. It accepts host-minted move-only correlation tokens and already reduced DNS/HTTP events under exact verification-case and bounded polling contracts. It owns no provider adapter, listener, clock, random generator, CLI flag, scanner action, target request, report projection, or SSRF conclusion, so enabling the feature does not add a runtime path.

The native OAST provider is a separate unpublished auxiliary service, not a scanner surface. Its production binary binds only to loopback behind an operator-managed HTTPS reverse proxy. Its fixed protocol creates short-lived sessions, allocates opaque HTTP callback targets, returns bounded raw-free events, and performs explicit cleanup. The non-default native OAST provider authority adds one sealed scanner host-library consumer of its HTTPS client. A host-minted permit binds the exact provider origin, assessment, epoch, fixed operations, parent budget reservation, and request/byte/time ceilings. It feeds reduced HTTP events through the existing OAST correlation state machine. Enabling the adapter by itself still adds no CLI flag, WebAssessmentRuntime action, target request, assessment evidence, report item, release-bundle edge, or SSRF conclusion.

The closed product callers that join this narrowing provider authority to target-side authority are the separately gated SSRF OAST query review and controlled XML external-entity review. The SSRF review binds one structurally eligible query occurrence to one .invalid control and two independent callback mutations. The XML review binds one operator-owned disposable application endpoint to runtime-generated inert control, candidate and replay POST documents. Each uses at most three target requests, one logical active verification and at most twelve fixed provider operations; both fresh callback identities must be observed after their respective dispatches. One-sided or noisy interaction never creates an item. The maximum conclusion is NeedsReview / KnowledgeOnly, never confirmed SSRF/XXE, file access, exfiltration or inferred impact.

The OpenAPI contract catalog is a transport-neutral foundation rather than a product runtime. It accepts only caller-supplied JSON bytes for OpenAPI 3.0/3.1, applies a strict 2 MiB document ceiling plus bounded depth, nodes, members, arrays, strings, paths, and operations, and produces deterministic metadata in memory. It does not locate or fetch a contract, resolve an external reference, contact a declared server, construct or dispatch a request, consume credentials, execute content, write evidence, or create a report, finding, or claim. YAML is future/unsupported; Swagger/OpenAPI 2.0 is metadata-only and produces no operation catalog. Neither label implies parser, network, or execution authority.

termivar-artifact is not part of either scan runtime. Its Preview library scans bounded caller-supplied byte slices or Read streams and emits exact/wildcard match observations with deterministic offsets and completion truth. The non-default CLI artifact-adapter owns the only repository file-access edge: one explicitly selected local regular file, read-only, without recursion, globbing, process acquisition, network I/O, execution, or file writes. No signature observation triggers exploit orchestration or becomes a malware or vulnerability verdict.

Default deterministic scan runtime (Surface B)

termivar scan <target> is the canonical CLI path. With no explicit profile, it composes StandardWebDecisionRuntime with the unchanged conservative single-resource policy and routes every built-in request through its runtime-owned, redirect-disabled, metered broker. termivar decision-scan is a deprecated Clap alias for the same command variant and implementation; it is not a second engine.

termivar scan <target>  (or deprecated decision-scan alias)
  -> StandardWebDecisionRuntime
      -> RuntimeBudget
          -> Evidence
          -> Knowledge and deterministic rules
          -> Planner
          -> Executor registry and metered broker
          -> Passive / active verification
          -> Experience and bounded continuation

termivar scan <target> --profile baseline
  -> the same StandardWebDecisionRuntime primitive
  -> additive web-assessment/v1 profile audit

termivar scan <target> --profile web-review
  -> WebAssessmentRuntime
      -> one RuntimeBudget / request broker / cancellation / exact-origin policy
      -> stable bounded discovery
      -> StandardWebDecisionRuntime subject work under that shared authority
      -> bounded semantic extraction
      -> defense observation and shadow planning
      -> passive header/cookie assessment projection
      -> optional value-free secret-shaped observation inside the response transaction
      -> root-scoped matched CORS and optional redirect review
      -> one bounded root-or-discovered parser-driven reflection-context pair
      -> one DOM reflection parse + bounded attribute/JavaScript source-anchor passes
      -> at most one assessment-wide evidence-capable XSS structural family
      -> optional explicit normalization-resilience child from committed parent evidence
      -> one bounded root-or-discovered SQL structural review with exact replay
      -> one bounded root-or-discovered SSTI arithmetic review with independent replay
      -> optional exact-root anonymous/authorized API visibility pair
      -> optional anonymous GraphQL control/introspection/replay child
      -> optional same-run OpenAPI-constrained REST GET candidate/replay child
      -> optional one-resource primary/peer authorization differential with independent replays
      -> central bounded assessment renderer on complete execution

The no-profile and explicit baseline single-resource policy permits at most 16 total dispatches, 60 seconds of wall time, a 1 MiB cumulative delivered response-body threshold, a per-probe buffered-body limit of 256 KiB inherited from HttpEvidencePolicy, and an 8,192-character text sample. It uses planning budget 100, risk limit 40, and at most eight semantic action cycles. API reasoning and payload binding remain absent unless a library host explicitly opts into their separate APIs.

The strict venom.scan-profile/v1 schema exposes exactly baseline and web-review. Custom profile files, raw transport settings, arbitrary origins, unbounded concurrency, and deep-merge/override semantics are not supported. web-review applies compiled absolute ceilings and checked profile limits for subjects, discovery depth, references per document, URL retention, forms, controls, query-parameter names, total requests, body bytes, wall time, and active verification count. Every limit fails closed.

Origin discovery is deterministic and bounded. It canonicalizes eligible absolute, root-relative, relative, and form-action references, removes fragments and duplicate representations, follows only safe GET/HEAD candidates, and never silently crosses the authorized exact origin. Forms retain action, method, and control names only—not values, credentials, CSRF values, or cookie contents. Discovered subjects and semantic entities are typed knowledge with provenance, not vulnerability findings.

Committed response evidence is projected into bounded semantic entities and defense observations. Defense shadow planning is audit-only. Enforcement is off by default; explicit --enforce-defense can only narrow or suppress already-authorized actions and cannot add actions, increase intensity, or expand scope/budget.

Passive web-review observes HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and value-free cookie metadata. Its closed native differential catalog is composed into the authorized root's existing Standard runtime session, so bootstrap and pair legs share the same broker and global budget without suppressing eligible standard actions. CORS always uses a matched no-Origin/candidate pair and requires successful status classes on both legs. The redirect action exists only when the starting URL supplied a recognized navigation parameter name; its original value is discarded. Only 301/302/303/307/308 are treated as redirect statuses, and redirects are not followed. A distinct two-request reflection pair uses a scanner-owned inert marker and one bounded html5ever parse for supported text/html. Comment, ordinary text, and ordinary attribute placement are Informational; typed URI-bearing, style, inline-handler, script-element, and embedded-HTML attribute placement is at most NeedsReview. Quote mode and JavaScript lexical context are supplied only by their bounded source analyzers and cross-checked with the DOM; CSS context is not inferred. Exact credentialed CORS and candidate-specific redirect relationships are also at most NeedsReview. Every native action is KnowledgeOnly, and no native assessment capability can produce a Confirmed item. For XSS structural selection, one fail-closed linear source pass retains only an exact normalized host/sink and double-, single-, or unquoted mode, then cross-checks that anchor against html5ever. HTML-text evidence requires the exact inert scanner node. Ordinary, URI, and event-handler attribute evidence requires exact inert boundary and tail attributes on that same anchored HTML host/sink and a clean matched control. A separate bounded, non-evaluating pass classifies one unique marker on one supported inline classic/module script host. Single-quoted string, double-quoted string, and template-literal-text families require exact ordered scanner-owned boundary/tail block-comment tokens outside the original string/template context on that same host, with neither token in control. Expression/code, template-expression, line/block-comment, and regex contexts remain metadata-only. Selection precedes payload materialization and admits one family, preserving one child bootstrap plus control/candidate—the three-request ceiling—regardless of catalog size; metadata growth does not add per-family HTML/JavaScript parses or requests. Lexical boundary evidence remains KnowledgeOnly and can project at most NeedsReview; no JavaScript or browser is executed.

The non-default normalization-resilience scanner/CLI feature adds no work by itself. A feature-enabled operator must also pass --normalization-resilience with explicit --profile web-review. The runtime accepts only committed XSS parent evidence where the control is open and the canonical candidate created a new candidate-specific defensive block; a standing block, 429, timeout, truncation, fingerprint alone, or canonical semantic success is ineligible. It selects at most one depth-one typed family: xss.html-token-case@1 for HTML-text or xss.html-inter-token-tab@1 for an ordinary, URI, or event-handler attribute boundary. Percent decode-depth-one/two are metadata-only. Parent requests are not resent; one child bootstrap plus transformed candidate and distinct replay uses exactly three child requests and one active verification through the same broker and budget. Both transformed responses must avoid the canonical block and reproduce the parent's exact inert DOM semantics. A fingerprint is only a compatible-metadata hint, and the resulting defensive normalization gap is NeedsReview / KnowledgeOnly, never a WAF-bypass or XSS confirmation. See Normalization-resilience review.

The non-default graphql-review scanner/CLI feature also adds no work by itself. A feature-enabled operator must pass --graphql-review with explicit --profile web-review. V1 selects at most one exact-origin endpoint and sends up to three anonymous POST/JSON requests through the shared broker: an aliased __typename control, a bounded schema-root introspection candidate, and a distinct replay. The complete candidate/replay path consumes one active verification; fail-closed earlier outcomes stop without it. The review follows no redirect and does not read credentials. Complete correlated surface and replayed-introspection results are Informational / KnowledgeOnly only. See GraphQL surface review.

The non-default rest-review scanner/CLI feature requires the same invocation to enable openapi-review under explicit web-review; otherwise CLI preflight rejects it without network I/O. The OpenAPI child must first commit candidate and replay with the same private semantic document identity. From that catalog, REST V1 selects at most one anonymous, bodyless, exact-origin GET with no required path, query, header, or cookie inputs, no request body, and no auth or templated server requirement. Candidate and replay cost exactly two requests and one active verification. A surface item requires stable successful JSON Status, Fields, and value-sensitive Resources; it is Informational / KnowledgeOnly only. No described write runs and no parameter, credential, cookie, or downstream vulnerability-family action is created. See REST read-only review.

The non-default secret-exposure-review scanner/CLI feature requires explicit --secret-exposure-review --profile web-review. V1 rejects combinations with WordPress discovery and the selected OpenAPI-plus-SSRF-OAST combination, before target or output work because those separate response paths do not yet share its value-free body-digest boundary. One shared observer stages value-free facts inside the ordinary anonymous GET response transaction; only the committed ledger may consume them. It adds zero requests or active verifications. Explicit GraphQL composition preserves the fixed anonymous POST classification, root-presence and replay-agreement facts with exact committed opaque lineage instead of public whole-body or framed GraphQL response digests. Those POSTs are not detector inputs and add no detector response/match count; GraphQL keeps its existing parent-accounted request and replay allowances. Explicit OpenAPI composition similarly keeps the complete semantic replay comparison private and projects only exact committed value-free lineage, categorical counts and a coarse subject item with a present/null semantic digest. Its separately planned GETs are not detector inputs; its existing two-request/one-active allowance is unchanged. Compiled availability alone does not select either review, and unchanged coarse items do not prove catalogue equality across runs. Explicit REST composition retains the same private value-sensitive Status/Fields/Resources comparison, suppresses public body/view digests and catalogue-derived operation/target identities, omits the existing audit's selected_operation_identity and uses a coarse subject item. Those separately planned GETs are not detector inputs; exact committed lineage and the existing two-request/one-active allowance remain mandatory. The composition adds no REST request or budget, and unchanged coarse items do not prove resource equality across runs. Explicit resource authorization composition preserves all four principal-isolated JSON GET legs and private full Status/Fields/Resources comparison. Selected general leg evidence omits response SHA-256 and body-derived receipt SHA-256; exact committed role/transport lineage, parent writes and stored facts must reconcile before projection. Finalization rechecks canonical assessment privacy selection against the private binding. Its existing public authorization audit retains counts, classified booleans and operator-policy identity; unchanged policy/resource-derived items do not prove cross-run body equality. The four credentialed legs are not anonymous detector inputs and retain the same parent four-request/one-active allowance with no S04-owned request or budget. Admission fails closed for redirects, explicit request headers, credentials, content coding, inconsistent lengths, unsupported media types, invalid UTF-8, truncation, failure, or configured limits. The fixed catalogue projects only value-free Informational / KnowledgeOnly observations; it does not validate a secret or provider, authenticate the source, or establish exploitability or impact. See Passive response secret-exposure review.

At most one deterministic query name across the assessment receives SQL structural review. Two independent matched quote-balance pairs must reproduce both a status-class and normalized body-structure change. Error text and latency are not classification inputs; incomplete or inconsistent replay emits no claim and incomplete collection remains typed incomplete.

The optional authorization-context slice consumes a host-supplied complete header value only after explicit profile/root validation. It builds a separate Standard child runtime with the assessment's existing shared authority, then executes the existing atomic API comparator once. Both legs are active, use separate principal-isolating connection pools, and share total-request, response-byte, active-verification, cancellation, deadline, and exact-origin limits. The compiled default active ceiling is six: four for the closed native catalog and two for this pair. Equivalent visibility emits no item; a complete difference is one opaque atomic evidence reference with maximum disposition NeedsReview. Partial collection or a lower exhausted limit is typed incomplete and cannot be reported as empty success.

The non-default authorization-review scanner/CLI feature adds one optional native action inside this same assessment runtime only when an operator passes a strict policy file and two distinct out-of-band credentials with explicit web-review. It selects exactly one exact-origin bodyless GET JSON resource and dispatches primary candidate, peer candidate, primary replay, and peer replay through fresh ambient-proxy-free connection pools governed by the parent broker's exact-origin policy, budget, cancellation and evidence authority. All four legs are one logical active verification, charged when the primary replay begins; the peer replay is passive-accounted inside the same active decision phase. Credentials, query values, the clear resource handle, and selected JSON scalar values do not enter evidence, item identity, audit, or rendered reports.

Both roles must be independently replay-stable, and both cross-principal rounds must match Status, Fields, and value-sensitive Resources under the exact policy profile before the runtime can emit one authorization.resource-cross-principal-equivalence@1 item. Its maximum is NeedsReview / KnowledgeOnly. Non-equivalence is not a secure-negative claim. There is no identifier mutation or enumeration, write method, cookie, redirect follow, second runtime, detached pass, or independent report. The existing exact-root anonymous/authorized compatibility path remains unchanged.

The stable item-identity authority preserves authorized-root@1 for the exact origin root and registers eligible discovered exact-origin subjects with an opaque discovered-resource@1 digest over canonical structure. The identity contains no query values or readable path material and grants no request authority. Unsafe subjects and ordinary non-root starting targets remain typed incompleteness. The explicit WordPress metadata-discovery path is the bounded exception: its versioned audit carries a validated application reference while the projected item retains the stable origin-root identity.

On the no-profile compatibility path, text summary, --explain, and --format json are renderings of the same typed runtime report. The JSON contract keeps its historical decision-scan/v1 name; the command rename does not reinterpret or fork that wire contract. Runtime outcomes are operational decisions and verifier results, not Surface-B findings or vulnerability verdicts.

Explicit baseline uses web-assessment/v1. A completed web-review uses the central renderer's venom-rendered-assessment/v1 schema in JSON, CSV, HTML, or Markdown; absent --report-format, text maps to Markdown and --format json maps to JSON. Incomplete or started-failed origin work emits a redacted web-assessment/v2 diagnostic audit to stdout, marks assessment items unavailable, exits nonzero, and creates no report artifact. --report-output uses exclusive same-directory temporary creation plus hard-link publication, never overwrites, and fails nonzero where those filesystem semantics are not available; directory-metadata crash durability is best effort.

The deterministic modules are compiled through the scanner crate's default core + scanning features: web_runtime, web_decision, web_reasoning, web_planning, web_execution, web_verification, decision_loop, decision_runner, runtime_budget, http_evidence, planner, rules, knowledge, experience, verification, and adaptive.

Internal responsibility splits do not create additional engines. The root source facades for 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 metadata/context/execution, state/policy/receipt, policy/probe/response, store/write/query, and coordinator/lease responsibilities. The architecture gate pins the reviewed child inventory, facade-resident authority, and allowed cross-domain dependencies so these domains cannot silently collapse back into responsibility-dense root files.

Composition is selection-specific:

• Semantic extraction (semantic) consumes evidence through a bounded library API. It remains absent from no-profile and baseline, but explicit web-review composes it only after evidence has been committed.
• Defense projection / shadow / enforcement (defense) is an explicit library API. StandardWebDecisionRuntime alone does not compose it; WebAssessmentRuntime records observation/shadow planning, with enforcement separately opt-in and monotonic.
• Normalization resilience (normalization-resilience, opt-in) is a separately enabled web-review child that consumes committed defense and XSS parent evidence. It cannot add work from a fingerprint or status alone, selects one typed depth-one HTML transform, and requires candidate/replay semantic proof before a knowledge-only review item.
• GraphQL surface review (graphql-review, opt-in) is a separately enabled anonymous web-review child. It selects one exact-origin endpoint at most, executes the fixed three-request control/candidate/replay protocol, and can produce only informational knowledge observations.
• Passive response secret-exposure review (secret-exposure-review, opt-in) is one shared observer inside the ordinary anonymous GET response transaction. Only committed value-free records may project bounded informational observations from the fixed detector catalogue, and it adds no request.
• Local JWT policy review (jwt-policy-review, opt-in) consumes one explicitly supplied compact token, strict local policy with mandatory intended typ, issuer and audience bindings, and a local ES256 public JWK outside the target transport. It produces only a value-free audit, makes no target/provider request, and keeps parsed, policy-consistent, local-signature-verified and target-accepted states distinct.
• JWT target acceptance review (jwt-target-acceptance-review, opt-in) consumes that established local eligibility and one exact non-secret target policy. Six sequential valid/anonymous/invalid candidate/replay legs use fresh no-proxy pools under the same parent authority; only two invalid controls are active, and the value-free result does not produce a finding or Confirmed claim.
• Versioned control-reference mapping (control-reference-mapping, opt-in) runs only after completed typed assessment items exist. It produces an additive finite-catalogue relationship audit, schedules zero target/provider requests, and cannot increase severity, disposition or claim authority.
• Resource authorization review (authorization-review, opt-in) is one native action in the existing web-review runtime. It compares one exact selected JSON resource across primary/peer candidate and replay views, using four requests and one active verification; its sole positive projection is bounded to NeedsReview / KnowledgeOnly.
• Lua execution (lua, opt-in) is a bounded registry and fresh-VM executor for an explicit library host. It uses cooperative in-process controls, not process isolation, with no CLI, scanner-phase, or plugin caller.
• Distributed coordination (distributed, opt-in) is a bounded, deterministic process-local task/worker/result state machine for an explicit library host. It is not a transport service or multi-node control plane.
• Exploit foundation (termivar-exploit, independent Preview crate) validates host-supplied bounded metadata and repository-owned lab manifests. Its non-default orchestration API requires an exact host-minted grant before a prepared plan can produce step permits. Catalog membership, applicability, maturity, a prepared plan, and implementation presence grant no execution authority. Attempt, trigger, impact, cleanup, and cleanup verification remain distinct facts. Source-linked implementations are cooperative trusted code, not sandboxed code. No stock runtime or CLI consumes this API; the only executor is an in-memory integration-test fixture.

Historical mixed-authority runner (Surface A)

The ordered context, runner, Scanner SDK, and phase modules are absent from the default scanner and CLI feature sets. A host must compile termivar-cli/legacy-scanner, invoke legacy-scan, and pass the required --acknowledge-legacy-heuristics flag:

cargo run -p termivar-cli --locked --features legacy-scanner -- legacy-scan \
  <authorized-target> --acknowledge-legacy-heuristics
    -> ScanContext
        -> ScanRunner
            -> historical phases/*

The phase sequence is:

1. ReconPhase
2. CrawlPhase
3. DirectoryFuzzer — only with the additional --legacy-directory-fuzz opt-in
4. ParameterDiscoverer
5. SqliScanner — bounded SQL-behavior differentials
6. XssScanner — bounded exact-reflection observation
7. SstiScanner — bounded template-arithmetic differential
8. LfiXxeScanner — inert by default; SDK-only benign file-canary opt-in, with XXE dispatch quarantined
9. SsrfScanner — inert by default; SDK-only OOB delivery opt-in records probe receipts without collecting callbacks

The whole ordered run remains Unmetered: phase one and host-defined custom phases can retain the raw legacy reqwest client. The run report therefore cannot derive complete request or body usage even though built-in phases two through nine use scoped bounded transport authorities. Neither authority is the standard runtime's RuntimeBudget.

Phases two through four are one deliberately narrow migration boundary. They share a context-owned passive, exact-origin, redirect-disabled request authority with finite configurable limits for crawl depth, scheduled pages, total requests, per-request timeout, shared wall time, cumulative delivered response-body bytes, and retained bytes per response.

The bounded discovery slice has these semantics:

• Phase two performs deterministic breadth-first traversal, parses only non-truncated text/html bodies no larger than 64 KiB, and commits canonically ordered endpoints, visits, and typed forms atomically. Form ownership covers parser-tree descendants; POST and dialog forms are recorded with named controls but are never flattened into GET requests.
• Optional phase three calibrates two stable randomized nonexistent-path responses for each eligible depth/trailing-slash/extension shape before recording a materially distinct endpoint. Candidates equivalent to the normalized wildcard/soft-404 or redirect controls are suppressed. HTTP 401/403 can remain endpoint observations, not authentication findings.
• Phase four uses baseline, randomized unknown-parameter, candidate, and identical-replay legs. A parameter is recorded only when the candidate is reproducible and differs materially from both controls.
• A transport, cancellation, limit, state-validation, or comparison-batch failure publishes no partial discovery delta.

Discovery records are informational observations. The CLI suppresses raw phase prose/evidence and projects any compatibility records as Unknown; neither successful transport nor a differential is a verifier-backed finding or vulnerability verdict. See ADR 0016.

Phases five through nine form a second migration boundary. They share a distinct context-owned, exact-origin, redirect- and retry-disabled authority with a finite VerificationLimits envelope for total requests, per-request timeout, shared wall time, cumulative delivered response-body bytes, and retained bytes per response. Requests are bodyless and charged at the Active stage inside this authority; they do not consume or reset the passive discovery envelope.

The active slice has these claim semantics:

• Phase five requires a negative baseline, a randomized control, an exact diagnostic replay, or repeated control/test timing samples with alternating order and robust median/MAD thresholds. Accepted SQL-behavior categories can project only knowledge-only NeedsReview.
• Phase six requires reproducible byte-exact reflection of a benign nonce and records response content type and a bounded context classification. A nonce already present in the baseline, a truncated response, an encoded-only value, or inconsistent replay is rejected. With no browser-execution verifier, the public result remains Unknown even for an HTML script or attribute context.
• Phase seven uses randomized arithmetic operands, a syntactically similar non-evaluating control, an exact expected result, and exact replay. An accepted differential can project only knowledge-only NeedsReview; it does not identify a template engine or code execution.
• Phase eight dispatches nothing by default. An SDK host can explicitly provide two independent version-four UUIDs for a benign canary file name and expected contents on an authorized fixture. Baseline and randomized missing-file controls must be negative, and two candidate replays must contain the exact marker before a knowledge-only NeedsReview outcome is eligible. XXE remains inert even when the compatibility OOB string is set.
• Phase nine dispatches nothing by default. An SDK host may configure a validated bare DNS OOB domain; Termivar then delivers a nonce-bearing callback URL only through already observed parameters at the authorized origin and records the target request's status as typed probe evidence. It has no callback collector or verifier, so HTTP 200, 401, or 403 produces no SSRF conclusion. No localhost, cloud-metadata, or other sensitive default payload is compiled into this phase.

Only allowlisted phase-five, phase-seven, and opt-in phase-eight action IDs can cross the context's verifier bridge. Reports must be active, origin-scoped, case-correlated, knowledge-only NeedsReview outcomes backed by evidence in the same KnowledgeBase; raw phase strings never gain that authority. The runner checkpoints this typed ledger per phase and discards the phase's public projection on error, panic, timeout, cancellation, or bounded-transport exhaustion. See ADR 0018.

Optional adapters and platform shell (Surface C)

Default termivar-cli features are empty, so the binary exposes neither api nor proxy unless explicitly compiled:

• api-adapter adds termivar api. The command returns a typed nonzero error because termivar-api::start_api does not bind. The library's router() value contains only GET /health for an application-owned host.
• proxy-adapter adds termivar proxy. It starts the experimental fixed-upstream TCP relay described below.

The following matrix separates build availability from actual execution:

Module / group	Build availability	Execution participation	Default termivar scan	Support status
Deterministic stack (web_runtime, decision_runner, runtime_budget, http_evidence, planner, rules, knowledge, experience, verification, adaptive, web_*, api_evidence, api_observation, api_reasoning)	scanner default (core, scanning)	Surface B; no-profile/baseline use the single-resource primitive, explicit web-review adds the origin orchestrator; API reasoning remains host opt-in	yes, profile-dependent	implemented and tested Preview
semantic	scanner default	host library and explicit web-review post-commit composition	web-review only	implemented and tested Preview
defense	scanner default	host library and explicit web-review observation/shadow; enforcement requires --enforce-defense	web-review only	implemented and tested Preview; cannot add or intensify actions
normalization-resilience review	scanner and CLI opt-in (normalization-resilience) plus explicit runtime flag	one eligible web-review parent may produce one transformed candidate/replay child under the shared broker	no	Preview; max one transform/depth one, three child requests/one active verification, NeedsReview / KnowledgeOnly only
GraphQL surface review	scanner and CLI opt-in (graphql-review) plus explicit runtime flag	one exact-origin endpoint may receive an anonymous __typename control, bounded schema-root candidate, and distinct replay through the shared broker	no	Preview; max one endpoint, three requests/one active verification, Informational / KnowledgeOnly only
REST read-only review	scanner and CLI opt-in (rest-review) plus explicit same-run openapi-review	one replay-stable OpenAPI catalog may select one anonymous, bodyless, exact-origin zero-input GET for candidate plus replay; selected secret-exposure composition retains full private replay equality and committed lineage while withholding public body/view and operation/target identities	no	Preview; max one operation, two requests/one active verification, Informational / KnowledgeOnly only; no chaining; the selected coarse subject item is not cross-run resource equality, and REST GETs are not passive detector inputs
Passive response secret-exposure review	scanner and CLI opt-in (secret-exposure-review) plus explicit --profile web-review --secret-exposure-review	one shared observer evaluates eligible complete ordinary anonymous GET bodies inside the response transaction; only validated committed records reach the audit, and it adds no request, active verification, provider call, or subject	no	Preview, development-only; 128 KiB/response and 4 MiB/assessment admitted detector-work ceilings, 1,024 outcome/64 occurrence/32 retained-observation ceilings, fixed value-free catalogue, Informational / KnowledgeOnly only, supplied-session bodies excluded, and outside release-bundle
Existing-connection TLS observation	scanner and CLI opt-in (tls-observation) plus explicit --profile web-review --tls-observation	existing assessment clients expose TLS information for successful responses already selected by their owning paths; one shared collector immediately reduces bounded leaf DER facts and adds no request, connection, handshake, action or retry	no	Preview, development-only; 64 KiB/leaf, 16 retained unique leaves, 256 bounded SAN entries/leaf, leaf-only Reqwest backend visibility, no active protocol/cipher enumeration, no revocation/OCSP/CT/AIA retrieval, no finding, and outside release-bundle
Active TLS negotiation matrix (S15A)	scanner and CLI opt-in (tls-negotiation-review) plus explicit --profile web-review --tls-negotiation-review and one credential-free DNS HTTPS target	one single-use assessment child resolves once, selects one deterministic address and attempts default-provider TLS 1.3 then TLS 1.2 against the exact target host/SNI/port; it shares parent accounting/cancellation/deadline and sends no HTTP/application bytes or credentials	no	Experimental, development-only; one in-flight connection, two network cells, 5 s/cell and 10 s total ceilings, 128 KiB ingress/64 KiB egress per cell and 256 KiB/128 KiB aggregate ceilings. TLS 1.1, TLS 1.0 and legacy cipher rows are client-backend-not-tested. A failed cell is not server non-support, the matrix is not complete enumeration, and the feature is outside every aggregate and release-bundle
Isolated HTTP parser-boundary laboratory (S15B)	private scanner test only: exact cfg(test) child of the cfg(feature = "scanning") web_runtime module; no product feature or runtime selection	four fixed harmless single-message byte fixtures run sequentially through owned numeric-loopback front/back parsers under one test-owned active-stage accounting broker; no second request or application response is sent	no	LAB_QUALIFIED_ONLY; 4 cases, 328 admitted/front-end and 266 separately counted back-end request bytes, zero response bytes, 4 front/3 back connections, one timeout without back dispatch, and a fifth-case pre-network refusal. No CLI, report, capability, package, live-target authority, request-smuggling conclusion, vulnerability, exploitability or impact
Local JWT policy review	scanner and CLI opt-in (jwt-policy-review) plus explicit local policy with a non-secret revision and mandatory intended typ, issuer and audience bindings, local public JWK and one env/file/stdin token source	after local preflight/output reservation and before the target scan, one bounded transport-free evaluator parses the compact JWS, applies the local claim/time policy and verifies ES256 against the supplied P-256 public key; the local evaluator adds no target request and retrieves no remote key. Without the separate target-acceptance option it never forwards/replays the token, and only the value-free local audit is attached during final composition after the ordinary assessment completes	no	Preview, development-only; only compact ES256 JWS and strict local public JWK are supported, all three identity-context checks are mandatory, methodology compares the declared policy revision and exact public-key-byte identifier, parsed/policy/signature/target states are distinct, no finding is added, and the feature is outside release-bundle
JWT target acceptance review	scanner and CLI opt-in (jwt-target-acceptance-review, which includes jwt-policy-review) plus the complete local JWT selection and explicit --jwt-target-acceptance-policy FILE	after local eligibility, one strict policy authorizes one exact-origin application-contained JSON GET; six ordered valid/anonymous/invalid candidate/replay legs run sequentially through fresh no-proxy pools under the shared parent broker, with the two invalid legs admitted only after their same-stage passive controls	no	Preview, development-only; at most six requests/two active requests, 64 KiB retained/interpreted per response and 256 KiB total, exact charged bytes retained separately, complete committed JSON-compatible 200/401/403 boolean-marker classification only, value-free audit, no finding/Confirmed claim, and outside release-bundle
Versioned control-reference mapping	scanner and CLI opt-in (control-reference-mapping) plus explicit --profile web-review --control-reference-mapping	after ordinary composition completes, maps completed typed items to the built-in versioned finite catalogue; adds zero target/provider requests or source retrievals and does not mutate item authority	no	Preview, development-only; OWASP Top 10:2025 mappings plus bibliographic/technical-context source records, no score/pass/fail/certification/legal conclusion, Compare methodology-only for catalogue/source changes, Verify integrity/schema only, and outside release-bundle
Cert Spotter CT reconnaissance provider	scanner and CLI opt-in (recon-ct-provider) plus explicit --profile web-review --recon-certspotter-policy FILE and both policy acknowledgements	the production token selects only the fixed live endpoint, or an owned numeric-loopback fixture; the child shares parent request/byte/deadline/cancellation authority, and complete responses enter bounded runtime audit/composition while names remain inert source-qualified hypotheses	no	Preview, development-only; unauthenticated use is limited to the provider-documented personal/evaluation basis, hourly quota and current terms, and acknowledgement does not prove provider approval or account/general-production entitlement; at most two sequential pages, 256 KiB/page, 512 KiB total and 256 retained names; no retries, polling or V1 credentials; never scan authority/ownership/authentication/findings; live service acceptance NOT_RUN_NO_INPUT; outside release-bundle
Local reconnaissance snapshot import	scanner and CLI opt-in (recon-snapshot-import) plus explicit --profile web-review --recon-snapshot FILE	validates one bounded hardened local JSON input before output/secret/network work, then attaches source-qualified hypotheses only after ordinary composition; it never enters planner/broker/runtime authority	no	Preview, development-only; 1 MiB input, 1,024 sources, 1,024 records, 4,096 source associations and 4 MiB prepared index; zero target/provider requests, no source authentication/asset truth/scan authorization, and outside release-bundle
Bounded WebSocket protocol review (S11)	scanner and CLI opt-in (websocket-review) plus explicit --profile web-review --websocket-review-policy FILE and all three operator acknowledgements; optional --websocket-supplied-session additionally requires supplied-session-review, one V1 Authorization-header policy and exactly one protected resource	the default remains one isolated anonymous RFC 6455 HTTP/1.1 Upgrade child; the explicit combined path instead runs startup health, protected-resource staging, one credentialed WebSocket exchange and terminal health under the declared application/principal/epoch, with both health checkpoints required for context/resource qualification	no	Preview, development-only; one connection, 64 KiB aggregate application payload per direction, ten seconds or the smaller parent deadline, numeric-loopback-only ws and otherwise validated wss; no discovery/retry/reconnect/redirect/compression/proxy/cookie/arbitrary credential forwarding/HTTP2 CONNECT; without the explicit flag no credential or session context reaches WebSocket review; V2/V3 session policies and simultaneous WordPress session consumption are rejected before secret/output acquisition; session health does not prove continuous authentication, raw socket versus complete application bytes remain distinct, physical continuation-frame count is unavailable, no item or security claim, and outside release-bundle
WordPress evidence review and metadata discovery	scanner and CLI opt-in (wordpress-review), compiled by the current untagged alpha.3 release-bundle, plus optional bounded local context/catalogue; the session consumer additionally requires supplied-session-review, policy V1/V2/V3 and --wordpress-supplied-session	review-only interprets complete exact-root HTML and supplied declarations with zero added requests; explicit --wordpress-discovery may issue at most twelve anonymous, bodyless, same-origin metadata GET attempts through the same broker/budget; optional observed page scope reuses up to three eligible committed anonymous secondary-page responses without fetching pages; the V1/V2/V3 session consumer may nominate public metadata only from health-qualified committed resource HTML and never forwards credentials or selects authenticated-page fingerprints; V3 selects the form-login collection policy /v2 with actual final epoch zero or one, while historical V1/V2 keep policy /v1 and epoch one; V4–V7 are refused before secret acquisition	no	Preview, development-only; absent from the default build and published alpha.2 archives; zero active verifications, at most one root-surface item plus one distinct metadata-source response-outcome item; advisory decisions are audit-only and no exploit/impact validation occurs
Native OAST provider authority	explicit library host plus non-default oast-native-provider	fixed register/allocate/poll/cleanup requests to one host-authorized self-hosted HTTPS provider, charged to a narrowing parent-budget reservation	no	Preview; no CLI, target action/request, report/finding, release-bundle entry, or SSRF conclusion
SSRF OAST query review	scanner and CLI opt-in (ssrf-oast-review) plus explicit policy and out-of-band provider administrator token	one exact query occurrence may receive a .invalid control and two independent HTTPS callback mutations through the existing target broker and narrowing provider authority	no	Preview; exactly three target GETs, at most twelve provider requests, one active verification, and one NeedsReview / KnowledgeOnly item only after both callbacks; no confirmed SSRF or impact
Controlled XML external-entity review	scanner and CLI opt-in (xml-external-entity-review) plus one strict endpoint/provider policy, all three acknowledgements and one out-of-band provider administrator token	one exact application-contained disposable endpoint receives a generated inert control, candidate and replay as anonymous application/xml POSTs; distinct provider callbacks are correlated through the same parent-owned target/provider authorities	no	Preview, development-only; at most three target POSTs, at most twelve provider operations and one active verification; a complete repeated differential can produce only NeedsReview / KnowledgeOnly, never confirmed XXE, parser identity, file read, internal access, exfiltration or impact; mutually exclusive with SSRF OAST review and outside release-bundle. The closed xml-external-entity-owned-https-test-profile compile feature adds no CLI surface or product authority and exists only for fixed-owned-identity native HTTPS acceptance with ordinary certificate-chain and hostname validation
Harmless template-evaluation semantics review (S14)	scanner and CLI opt-in (template-evaluation-review) plus explicit --profile web-review --template-evaluation-review	one eligible query parameter already present on the explicit root joins two independently seeded control/candidate pairs to the same root native-review runtime, reusing its bootstrap, exact-origin broker, parent budget, cancellation and evidence commit; the only candidate operation is a Jinja-compatible uppercase filter over scanner-owned lowercase ASCII	no	Experimental, development-only; at most four additional requests and two active legs, with at most one NeedsReview / KnowledgeOnly item. Positive evidence establishes only repeatable compatibility with the named benign expression semantics; engine identity, vulnerability, operating-system execution, file access, outbound interaction and impact remain unestablished or not performed. Literal/escaped, unsupported, replay-mismatch and incomplete outcomes remain item-free. Outside default, release-bundle and published alpha.2 archives
Resource authorization review	scanner and CLI opt-in (authorization-review) plus explicit policy and two out-of-band credentials	one exact-origin JSON resource receives primary/peer candidate and independent replay legs through fresh ambient-proxy-free pools governed by the assessment's shared broker authority/accounting	no	Preview; max one resource, four requests/one active verification, one NeedsReview / KnowledgeOnly item at most
Supplied-session authenticated assessment	scanner and CLI opt-in (supplied-session-review) plus explicit V1 authorization-header, V2 supplied-cookie, V3 bounded-form-login, or V4 scheduled-cookie-renewal policy and one matching out-of-band credential source	one context-isolated no-proxy child performs structured health checkpoints and bounded same-application collection for one operator-declared principal; V1/V2 use bodyless GETs, while V3 performs one anonymous exact-login-page GET and at most one explicit no-retry form POST before the independent startup-health oracle; V2 applies declared cookie scope only inside the operator application, V3 admits only policy-declared host-only session cookies, and later selected/unusable updates stop; only V4 explicitly schedules one bounded bodyless renewal POST and new-epoch health within unchanged limits	no	Preview, development-only; maximum nine session requests, V3 maximum three resources, no browser import/form discovery/credential guessing/OAuth/MFA bypass, WordPress composition rejects V4–V7 and WebSocket composition remains V1-only, no vulnerability item, and excluded from release-bundle
oast correlation foundation	scanner library opt-in (oast-correlation)	host-owned, transport-free registration and caller-driven poll state only; no provider transport dependency or runtime caller	no	Preview library contract; host-minted move-only tokens, exact case binding, bounded DNS/HTTP event receipts, replay suppression, and no target probe or vulnerability claim
termivar-oast native provider	independent unpublished workspace crate; separate non-default server and client features	optional self-hosted loopback auxiliary service plus exact-origin HTTPS client for the fixed management protocol and raw-free HTTP callback mailbox	no	Preview infrastructure; one sealed scanner host-library adapter uses the client under narrowing authority; no public provider, target authority, scanner action, report projection, Interactsh compatibility, or release-bundle inclusion
phases/*, legacy_discovery, runner, context, sdk	opt-in (legacy-scanner)	Surface A; phases 2–4 use bounded passive discovery, phases 5–9 use separate bounded active verification, and phase-one/custom raw I/O remains possible	no	Legacy runtime / ScannerSdk facade; whole-run accounting remains Unmetered
advanced_detection, anomaly	opt-in (detection)	no repository product caller; validated/catalogued caller records plus text matching only	no	Experimental; no deviation computation, response classification, or finding production
api, api_gateway, auth, cache, config, config_loader, metrics, post_exploitation, persistence, realtime, dashboard	opt-in (platform-models)	no repository product caller	no	Experimental records, catalogs, and in-memory utilities; no API/auth/persistence/realtime execution path, and caller-owned collections are not uniformly capacity-bounded
reporting	opt-in at scanner boundary; enabled by normal CLI dependency	standalone host RunReport rendering and, with scanning, typed completed-assessment composition/rendering	completed explicit web-review only	Preview bounded renderer; no I/O, persistence, risk synthesis, or verdict invention; see the reporting guide
ml	opt-in (ml)	external-model records only; no repository computation or execution	no	Experimental data-model scaffold
distributed	opt-in (distributed)	explicit host-owned process-local coordinator/result APIs; no repository product/runtime caller	no	implemented and tested Experimental; bounded ordered state, explicit logical time/revisions, leases, retry/recovery, and fixed-command-order determinism; no transport, authentication, serialization, persistence, background work, exactly-once, or multi-node service
monitoring	opt-in (monitoring)	no default path	no	Experimental / scaffold
compliance	opt-in (compliance)	no default path	no	Experimental / scaffold
threat_intelligence	opt-in (threat-intel)	no default path	no	Experimental / scaffold
plugin	opt-in (plugins)	host-owned; PluginDecisionExecutor can forward registry observations when a host supplies the execution request	no	source-level extension Preview; no stock detector plugins or dynamic loading
lua_engine	opt-in (lua)	explicit host-owned approved-root registry/executor; no repository product/runtime caller	no	implemented and tested Experimental; fresh text-only no-standard-library Lua 5.4 VMs with cooperative per-execution/registry limits, not process isolation
termivar-api / termivar api	CLI opt-in (api-adapter)	command fails closed; router is host-owned	no	unsupported listener
termivar-proxy / termivar proxy	CLI opt-in (proxy-adapter)	explicit adapter	no	Experimental fixed-upstream TCP relay
Deployment (Compose / Helm / Terraform / Kubernetes)	absent	none	no	unsupported; see the deployment blueprint

The default scanner crate feature closure is exactly core plus scanning. The normal CLI dependency additionally enables reporting for the explicit completed web-review path; this does not alter no-profile execution or its wire contract. The stock untagged alpha.3 release-bundle capability inventory now reports 25 known feature identities: the marker plus seven compiled members and seventeen excluded features. The eight compiled identities remain release-bundle, artifact-adapter, normalization-resilience, graphql-review, openapi-review, rest-review, authorization-review, and wordpress-review. The seventeen excluded identities are api-adapter, control-reference-mapping, jwt-policy-review, jwt-target-acceptance-review, legacy-scanner, proxy-adapter, recon-ct-provider, recon-snapshot-import, secret-exposure-review, ssrf-oast-review, supplied-session-review, template-evaluation-review, tls-negotiation-review, tls-observation, websocket-review, xml-external-entity-owned-https-test-profile, and xml-external-entity-review. default remains empty; this inventory is build truth, not runtime activation or publication status. LuaEngineConfig is a small shared support type reachable through either platform-models or lua; the broader config module remains platform-only. The raw lua closure is exactly core, optional mlua, and optional Tokio; mlua disables defaults and enables only vendored Lua 5.4. The raw distributed closure is empty. event_bus and logging are historical legacy-scanner host utilities. The architecture gate checks private opt-in module declarations, exact root facades and dependency closures, production API/source fingerprints, and authority constraints, and prevents a broad default feature from silently restoring either host surface.

The proxy is a TCP relay, not a MITM proxy

With proxy-adapter, termivar proxy --addr <LISTEN> --upstream <UPSTREAM> starts termivar-proxy::FixedUpstreamTcpRelay. Both socket addresses are explicit; there is no implicit destination. The handler accepts a client TCP connection, opens the configured upstream connection, and copies bytes in both directions. It does not parse CONNECT, terminate TLS, generate/present certificates, or inspect/modify HTTP.

Not implemented

The following must not be described as shipped product behavior: a Relation Engine, Planes, a Knowledge Graph, a Machine Scanner, a generic or product-specific WAF-bypass engine, a bound API listener, a supported/configurable MITM proxy, a Lua process-isolation service, a distributed transport/control plane, or cloud deployment. The knowledge module is an evidence/hypothesis store, not a knowledge graph.

How to reproduce the inventory

The feature and module inventory comes from crates/termivar-scanner/Cargo.toml, crates/termivar-scanner/src/lib.rs, crates/termivar-cli/Cargo.toml, and crates/termivar-cli/src/main.rs. Numeric module counts are intentionally omitted because they drift; generate any count against a named commit with an explicit command.

Runtime validation has deliberately narrower evidence boundaries than this inventory. Rust 1.88.0 smoke jobs exercise loopback CLI/path/scope contracts on Ubuntu, Windows, and macOS, but do not certify those platforms or duplicate the all-features matrix. The compat/current-head/ workspace uses one dedicated lockfile and separate package tests for default core, deterministic assessment/reporting, the Legacy ScannerSdk facade, and plugin API 0.2 against the same checkout; they are not cross-version compatibility or external-adoption evidence.

The loopback-only endpoint harness has one initial controlled record for source commit 27321efbbf49cb2adbc72afb699d1b31ea407486 from workflow run 33292247976: Markdown and JSON. It exercises 100 endpoints, 1,000 endpoints, and a 10,000-request batch using the real WebAssessmentRuntime. The batch is ten independent origin authorities, not one global assessment. This evidence is not an SLA, an accepted repeatable baseline, or a regression threshold.