Skip to content
TrustPlane

Acceptance gate

How do you know your local TrustPlane Auth runtime actually behaves correctly — that valid proofs pass, tampered requests fail, and replays are denied? One command answers that. This page explains what the acceptance gate runs and what a green result proves: the canonical definition of “v0.1 is healthy.”

Run the gate

Section titled “Run the gate”
Terminal window
make v01-acceptance

This is deterministic and local-only. It uses no Docker, Helm, cloud deploy, release automation, publish automation, or wiki sync. A green run means the local TrustPlane Auth contract is ready for review.

What it actually runs

Section titled “What it actually runs”

The gate (scripts/v01-acceptance.sh) chains four things:

flowchart TD
  G["make v01-acceptance"] --> C["transcript-v1 conformance<br/>(Go / JS / Python identical output)"]
  G --> B["targeted broker tests<br/>(software signer, key-binding,<br/>adapter pass-through, abuse, replay)"]
  G --> M["targeted CLI tests<br/>(sign headers accepted, tamper deny,<br/>up flow, bundle policy failures)"]
  G --> H["targeted middleware tests<br/>(route key-binding, freshness,<br/>replay-not-consumed-on-policy-deny,<br/>tamper deny)"]
  G --> P["provider-gateway/run.sh<br/>(full end-to-end)"]

Concretely, it executes:

  1. sh scripts/transcript-v1-conformance.sh — cross-language transcript equality.
  2. Targeted go test ./internal/broker — software-signer issue, insufficient_key_binding, transcript digest match, broker-issued headers passing and being rejected for abuse and duplicate replay through the adapter.
  3. Targeted go test ./cmd/trustplane-cli — sign headers accepted by the transcript-v1 adapter, tamper deny, rejecting a stronger key-binding than provided, the up flow verifying through the adapter, and bundle-policy failure denials.
  4. Targeted go test ./pkg/middleware/http — route key-binding policy, bundle freshness failing before the verifier, realtime freshness window, policy denial not consuming replay, and transcript tamper/corruption denials.
  5. ./examples/provider-gateway/run.sh — the full broker → adapter → upstream walkthrough.

What “passing” proves

Section titled “What “passing” proves”
Behavior Verified by
A valid proof-bound request is accepted broker + provider-gateway
Wrong route is denied CLI + middleware
Duplicate replay is denied (jti_replay) broker
Stale bundle fails closed middleware
Insufficient key binding is denied broker + middleware
Tampered request binding is denied CLI + middleware
Policy denial does not burn the jti middleware
Cross-language transcript output is identical conformance

Run the fuller reviewer checklist

Section titled “Run the fuller reviewer checklist”

Before any later tag/deploy, the repo’s reviewer checklist runs:

Terminal window
make boundaries
scripts/check-boundaries.sh
make transcript-conformance
make v01-acceptance
go test ./internal/... ./pkg/... ./spec ./cmd/... ./examples/...
make test
scripts/public-release-scan.sh
git diff --check

A durability note

Section titled “A durability note”

The v01-acceptance gate exists and passes, but at the time of writing it is run manually — the CI workflow runs make test and make boundaries but not make v01-acceptance or make transcript-conformance. Wiring those two into CI is the recommended way to keep v0.1 from silently regressing on a future PR.

Next steps

Section titled “Next steps”
  • Quickstart — the local flow the gate exercises.
  • Versioning — what the v0.1 boundary includes and excludes.