adaptive-multi-protocol-gateway/docs/fixture-manifests.md

Fixture Manifests

Status: draft | Updated 2026-07-07 | Applies to: AMPG and AMPB compatibility checks

AMPG writes deterministic fixture manifests so AMPB can verify that generated site variants route to the expected browser transport and profile.

Output

ampg build writes one manifest per site:

<site.outputs.root>/ampg-fixture-manifest.json

The manifest contains public route expectations only:

• site id, domain, and canonical URL.
• enabled protocol fixtures.
• protocol renderer and relative output path.
• route URL for AMPB checks.
• expected AMPB transport, profile, and transport-profile isolation.
• declared interaction tier, identity adapter, payment adapter, realtime flag, and public exposure flag.
• optional route-group metadata for configured public route policies.

It must not contain private host inventory, hidden-service keys, tunnel keys, credentials, or deployment notes.

The isolation check is a browser-facing result, not a daemon-management instruction. AMPG declares which transport profile must consume the route; AMPB independently decides whether to adopt or start the local transport needed to reach it.

Commands

python3 -m ampg --config examples/wownero.gateway.toml build
python3 -m ampg --config examples/wownero.gateway.toml manifest
python3 -m ampg --config examples/wownero.gateway.toml addresses list
python3 -m ampg --config examples/wownero.gateway.toml deploy apply --stage addresses --dry-run --profile mobile-i2p
python3 -m ampg --config examples/wownero.gateway.toml addresses capture --profile mobile-i2p
python3 -m ampg --config examples/wownero.gateway.toml preview manifest
python3 -m ampg --config examples/wownero.gateway.toml health-plan
python3 -m ampg --config examples/wownero.gateway.toml health-plan --mode preview
python3 -m ampg --config examples/wownero.gateway.toml deploy apply --stage health --dry-run --profile mobile-i2p

build emits the manifest after writing protocol outputs. manifest rewrites only the manifest and does not rebuild protocol outputs.

preview manifest writes:

<site.outputs.root>/ampg-preview-fixture-manifest.json

Preview manifests point fixture URLs at loopback HTTP servers for generated output roots. They preserve the intended published URL and transport checks under each fixture's published metadata. Use preview manifests to verify generated output with AMPB before real Tor, I2P, Gemini, or other transport daemons are installed or adopted.

health-plan consumes the same fixture contract. Published mode prints checks for real transport URLs. Preview mode prints loopback checks against generated preview URLs. deploy apply --stage health runs the published checks after transport addresses are configured or captured.

Address Status

Some transports may not have final public addresses when a fixture is generated. In those cases AMPG uses route-valid placeholders such as http://wownero.onion/ so AMPB can still verify transport selection without contacting the network.

When a managed or adopted daemon writes an actual address, run deploy apply --stage addresses --dry-run before recording it. Captured addresses are stored under gateway.state_dir and replace placeholders in fixture manifests and published health plans. Operators can then run deploy apply --stage health --dry-run to review the exact transport checks before live verification. Operators can also use addresses capture for a direct write or addresses set to store an address manually.

Interaction Policy

Fixture interaction policy defaults to:

{
  "tier": "static",
  "identity": "none",
  "payments": "none",
  "realtime": false,
  "public_allowed": true
}

Protocol-level options can declare the base fixture policy that AMPB should check.

When [[site.interactions.route]] entries are configured, AMPG emits additional fixtures for public route groups. Routes with tier = "internal", public_allowed = false, or a match covered by deny_routes are not emitted.

Routes imported from site.interactions.route_manifest are treated the same way as inline TOML routes.

AMPG also omits route fixtures whose interaction tier exceeds the protocol target's max_tier. When max_tier is not configured, AMPG uses the transport capability defaults from the generated interaction capability matrix.