Deep Capture compatibility

Published baseline: v0.10.2.

Rust integrations can drive the same behavior through fragcap::deep_capture. The public API supports side-effect-free preflight, exact-plan authorization, checked lifecycle methods, narrow proxy, trust, launch, Capture, and storage adapters, typed events, and one authoritative terminal report. Controlled adapters require no capture driver, elevation, game account, remote service, or trust-store change.

Deep Capture does not promise that every encrypted flow becomes readable. It does not bypass certificate pinning, downgrade TLS, extract keys from a target process, or silently change system-wide proxy settings. Packet truth remains available through Capture even when application inspection is unavailable.

See Output formats and session bundles for the current native artifact authority, sensitivity, omission, correlation, retention, and cleanup contract. The native bundle includes versioned application and cleanup streams, packet-to-application correlation, a bounded HAR projection, and a manifest that declares finalization, completeness, loss, sensitivity, and omissions for every expected artifact.

Traffic support

All supported routes preserve IPv4 or IPv6 family from authorization through listener ownership, routing, lifecycle, artifacts, and cleanup. The default is IPv4; IPv6 selection is explicit and never uses a wildcard listener.

In compatibility facts, full means the proxy observed the required supported semantics for that exact target, launch case, route, address family, protocol, backend, and product version. It does not mean every body byte, WebSocket frame, or custom payload was retained. Bounded retention and explicit omission or truncation remain authoritative. A TLS key log is an analyzer aid produced by the proxy side of the session. It is not a key extracted from the selected process.

Local target matrix

Compatibility depends on the launch path and local evidence. fragcap therefore does not publish a guessed title list. Inspect the facts stored for one selected target instead:

fragcap targets show sample-target

With evidence, the detail view adds one line per stored fact:

compatibility:
  proxy-routing = reached-client | launch=steam-protocol-cold | source=observed-run | freshness=current
  inspectability = metadata-only | source=stale-observation | freshness=stale

Without evidence, it says:

compatibility:  unknown (no stored evidence)

Repeated or conflicting rows remain visible. fragcap does not collapse them into a single compatible or incompatible verdict because two launch cases, target versions, or proxy backends can produce different results.

Evidence and freshness

targets show is read-only. It does not launch software, start a proxy, change certificate trust, contact a catalog, or refresh facts. A later explicit and authorized Deep Capture measurement can add newer evidence. Existing launch-specific rows remain available as context rather than being silently rewritten.

Calibrating an unknown target

Start with the guided front door:

fragcap calibrate sample-target
fragcap calibrate --id 42 --protocol https

Stored resolution takes precedence. On a clean miss, an exact installed Steam application identifier or case-insensitive display name can produce a separately confirmed registration plan. Eligible absent Steam executable metadata and ambiguous stored non-Steam client declarations have distinct setup and candidate-selection plans. A content-derived --candidate identity selects one current candidate, never a list position. Registration, setup, and each later session require separate fresh authorization; a choice is not consent to traffic inspection.

The workflow proposes reachability first when applicable routing evidence is missing. Fresh eligible final-client observations can propose concrete protocols, but requested --protocol values are only measurement intent. Each workflow runs reachability at most once and each concrete protocol at most once, with at most fourteen durable attempt ordinals. A failure, limitation, decline, partial result, interruption, target change, or repeated case checkpoints coverage and stops later effects instead of pretending success.

Resume from the same effective local store using the workflow identity printed by the command:

fragcap calibrate --resume 17 --local-db C:\Users\you\local.db
fragcap calibrate --resume 17 --pause-for login --local-db C:\Users\you\local.db

The workflow stores an immutable target snapshot and exact-case intent. Resume rebuilds process inventory, fact applicability, proposal, recovery, bundle, plan, and confirmation authority; it never reuses an old plan or response. An in-flight record first becomes an effect-free interruption pause. Login, EULA, update, anti-cheat, gameplay, shutdown, and interruption pauses record operator work, not compatibility proof. Advanced fresh workflows can assert the inferred cold launch case, choose IPv4 or IPv6, and select child-environment routing; other routing strategies remain pre-effect refusals. Resume cannot change those dimensions or the candidate.

Ordinary eligibility uses the latest exact applicable routing row for target/version, launch case, route, loopback family, selected measurement, native backend/version, and fragcap version. A historical current display label, imported fact, protocol fact, launcher observation, or another workflow cannot substitute for that decision. See the CLI reference for full options.

Advanced single-phase measurements

Compatibility calibration is the supported, explicit path from unknown local evidence toward ordinary Deep Capture eligibility. It keeps the ordinary safety gate intact and measures one declared launch case in two separate runs.

First close the selected target and, for a Steam launch, close Steam. Calibration requires a cold target and cannot use the ordinary Deep Capture warm close-and-retry option. Managed direct, cold Steam platform, and declared publisher-launcher chains are supported. Then measure scoped proxy reachability without changing certificate trust. This example uses the Steam launch case:

fragcap deep-capture sample-target --launch --calibrate reachability --calibration-protocol routing --launch-case steam-protocol-cold

For an eligible stored direct target, use --launch-case direct-exe-cold instead. Warm Steam and direct-executable targets are refused before side effects.

fragcap displays the exact target and launch authority, phase, loopback and routing policy, process-local CA identity when trust is needed, bundle and sensitive artifacts, finite deadlines, possible fact writes, cleanup obligations, refusal boundaries, and versioned plan identifier before asking once for confirmation. A shorter --wait or --duration becomes the displayed calibration bound; longer values are capped at the calibration maximum. Shutdown and cleanup enforce the displayed bounds too. JSON and prompt-free automation require --authorize-stdin; the caller reads the plan event and returns its exact identifier plus one LF in the same process.

Review the new rows with fragcap targets show sample-target. If current evidence for the same launch case says proxy-routing = reached-client, a separate TLS phase can measure CA acceptance and inspectability:

fragcap deep-capture sample-target --launch --calibrate tls --calibration-protocol https --launch-case steam-protocol-cold

Use the same exact cold launch case in both phases.

Routing and environment propagation remain separate facts. Reaching the final client does not prove how the launcher propagated proxy configuration, and fragcap records proxy-propagation = confirmed only when a separate non-invasive observation supports it. CA acceptance requires full HTTPS semantics correlated to the final client, so launcher traffic cannot establish the target's trust behavior. Silence remains inconclusive. A phase outcome such as proxy not reached, metadata only, or unsupported protocol is recorded in the local bundle and is not converted into an aggregate compatible or incompatible target verdict.

Publishing compatibility evidence

Public documentation and committed fixtures use placeholders such as sample-target and sample.exe. Do not publish local title names, account identifiers, access tokens, filesystem paths, private endpoints, host identifiers, or unreviewed free-form notes collected during compatibility work.