Merge pull request #17 from thinksyncs/feat/product-v1

feat(production): add deployable Direct-Agent profile

Author: thinksyncs

.github/workflows/main.yaml

@@ -114,13 +114,20 @@ jobs:
           GOTOOLCHAIN=go1.26.0+auto go test \
             ./pkg/atls/... \
             ./pkg/clients/... \
-            ./pkg/agtp/...
+            ./pkg/agtp/... \
+            ./pkg/production
 
       - name: Run Direct-Agent security red-team tests
         run: |
           GOTOOLCHAIN=go1.26.0+auto go test -v -race -count=1 \
             ./pkg/atls/identitypolicy \
-            ./pkg/clients
+            ./pkg/clients \
+            ./pkg/production
+
+      - name: Run protected-change consumer integration
+        run: |
+          GOTOOLCHAIN=go1.26.0+auto go test -v -race -count=1 \
+            ./examples/protected-change-consumer
 
       - name: Run v1 and draft-06 v2 A2A negative integration
         run: |

.github/workflows/security-red-team.yaml

@@ -14,8 +14,12 @@ on:
       - "pkg/agtp/**"
       - "pkg/atls/**"
       - "pkg/clients/**"
+      - "pkg/production/**"
       - "examples/a2a-multiprocess/**"
+      - "examples/protected-change-consumer/**"
       - "docs/draft06-a2a-profile.md"
+      - "docs/API_COMPATIBILITY.md"
+      - "docs/production-deployment-profile.md"
       - "docs/security-red-team-tests.md"
       - "docs/live-red-team-report.md"
   push:
@@ -30,8 +34,12 @@ on:
       - "pkg/agtp/**"
       - "pkg/atls/**"
       - "pkg/clients/**"
+      - "pkg/production/**"
       - "examples/a2a-multiprocess/**"
+      - "examples/protected-change-consumer/**"
       - "docs/draft06-a2a-profile.md"
+      - "docs/API_COMPATIBILITY.md"
+      - "docs/production-deployment-profile.md"
       - "docs/security-red-team-tests.md"
       - "docs/live-red-team-report.md"
 
@@ -59,4 +67,6 @@ jobs:
             ./pkg/atls/identitypolicy \
             ./pkg/atls/sbaipv2 \
             ./pkg/clients \
+            ./pkg/production \
+            ./examples/protected-change-consumer \
             ./examples/a2a-multiprocess

CHANGELOG.md

@@ -0,0 +1,17 @@
+# Changelog
+
+## v1.0.0
+
+- Add the supported Direct-Agent v1 production composition.
+- Add role-separated trust and revocation snapshots that fail closed on source
+  errors.
+- Add signed attestation-result appraisal with exact binder, policy,
+  measurement, freshness, and verifier-key checks.
+- Add a TLS-only Redis/Valkey SETNX replay adapter with bounded operations.
+- Add the protected-change HTTPS consumer and positive/negative E2E tests.
+- Define the supported API and compatibility policy.
+
+The v1.0.0 release covers the verifier-side Direct-Agent v1 core and the
+documented protected-change deployment profile. It does not make the
+experimental draft-06 v2, gateway runtime, inherited Cocos runtime, or
+hardware evidence acquisition part of the supported product API.

Makefile

@@ -1,6 +1,7 @@
 BUILD_DIR = build
 SERVICES = manager agent cli attestation-service log-forwarder computation-runner egress-proxy ingress-proxy
-DIRECT_AGENT_CORE_PKGS = ./pkg/atls/... ./pkg/clients/... ./pkg/agtp/...
+DIRECT_AGENT_CORE_PKGS = ./pkg/atls/... ./pkg/clients/... ./pkg/agtp/... ./pkg/production
+PRODUCTION_CONSUMER_PKGS = ./examples/protected-change-consumer
 CGO_ENABLED ?= 0
 GOARCH ?= amd64
 VERSION ?= $(shell git describe --abbrev=0 --tags --always)
@@ -70,7 +71,7 @@ build-igvm:
 product-security-gate:
 	go mod verify
 	GOTOOLCHAIN=go1.26.0+auto go test $(DIRECT_AGENT_CORE_PKGS)
-	GOTOOLCHAIN=go1.26.0+auto go test -v -race -count=1 ./pkg/atls/identitypolicy ./pkg/clients
+	GOTOOLCHAIN=go1.26.0+auto go test -v -race -count=1 ./pkg/atls/identitypolicy ./pkg/clients ./pkg/production $(PRODUCTION_CONSUMER_PKGS)
 	$(MAKE) fuzz-smoke
 	$(GOVULNCHECK) ./...
 

PUBLICATION_TODO.md

@@ -88,6 +88,30 @@ Do not describe this repository as implementing every binding profile from the
 draft. Product claims should say that it implements an experimental
 Direct-Agent binding profile based on the core acceptance rules.
 
+## Supported v1 Product Surface
+
+Release `v1.0.0` fixes the supported surface and compatibility rules in
+`docs/API_COMPATIBILITY.md`. The supported product API is the Direct-Agent v1
+subset of `pkg/clients` and `pkg/atls/identitypolicy`, composed through
+`pkg/production`. Draft-06-inspired v2, `pkg/agtp`, gateway runtime, inherited
+Cocos runtime services, and hardware evidence acquisition remain experimental
+or outside the supported API.
+
+The concrete `protected-change-v1` deployment profile is recorded in
+`docs/production-deployment-profile.md`. It includes:
+
+- separate Manager, Agent, and attestation-verifier Ed25519 key roles;
+- fresh trust and revocation snapshots with fail-closed source errors;
+- a signed attestation result bound to the accepted TLS session, exact action,
+  verifier nonce, appraisal policy, and measurement;
+- a TLS 1.3 Redis/Valkey `SET NX PX` replay adapter with bounded operations;
+- a concrete non-Split-Knowledge HTTPS consumer; and
+- positive and negative unit, replay-race, and E2E integration tests.
+
+The profile authenticates signed appraisal results. Hardware-specific evidence
+acquisition and appraisal remain deployment responsibilities and are not
+implied by the default GitHub-hosted test environment.
+
 ## Inherited Runtime Risk Classification
 
 These items come from inherited Cocos runtime code paths. Profile text does not

README.md

@@ -13,6 +13,13 @@ The primary failure class is context diversion: accepting cryptographically
 valid material for a different service, tenant, Agent, task, delegation, or
 authority boundary than the verifier intended.
 
+Release `v1.0.0` defines a supported verifier product surface for the
+Direct-Agent v1 profile. It adds one complete deployment composition covering
+role-separated trust keys, revocation, signed attestation results, TLS-protected
+distributed replay, and a concrete protected-change consumer. See
+[`docs/API_COMPATIBILITY.md`](docs/API_COMPATIBILITY.md) and
+[`docs/production-deployment-profile.md`](docs/production-deployment-profile.md).
+
 ## Acceptance Contract
 
 The verifier evaluates one ordered contract:
@@ -38,10 +45,17 @@ CWT/COSE, and gateway-route policy experiments.
   v2 profile for the multiprocess A2A demonstration.
 - `docs/live-red-team-report.md`: current live-style red-team evidence and
   evaluation boundaries.
+- `docs/API_COMPATIBILITY.md`: supported v1 API and compatibility policy.
+- `docs/production-deployment-profile.md`: fixed production choices for trust,
+  revocation, attestation, distributed replay, and exact action binding.
 - `formal/`: ProVerif and TLA+ models, recorded results, and
   model-to-implementation traceability.
 - `pkg/clients`, `pkg/atls`, and `pkg/atls/identitypolicy`: Direct-Agent
   acceptance implementation.
+- `pkg/production`: supported fail-closed composition and Redis/Valkey replay
+  adapter.
+- `examples/protected-change-consumer`: independent HTTPS application consumer
+  and E2E negative tests; it is not Split-Knowledge.
 - `PUBLICATION_TODO.md`: publication blockers, inherited runtime risk
   classification, module identity choice, and CI/red-team checkpoint status.
 
@@ -87,7 +101,7 @@ acceptance path.
 
 ## Evaluation Evidence
 
-The current v0.4 evidence covers:
+The release evidence covers:
 
 - focused local checks and unit-level coverage;
 - positive and negative profile vectors;
@@ -99,6 +113,12 @@ The current v0.4 evidence covers:
   for compact JWT/JWS parsing, and deterministic acceptance invariants;
 - route-assertion policy tests and a local HTTP route-assertion harness for the
   documented gateway boundary.
+- a production composition with current trust/revocation snapshots, signed
+  attestation-result policy, and TLS-only Redis/Valkey SETNX replay;
+- an independent protected-change HTTPS consumer that rejects a changed
+  action, wrong TLS session, replay, revoked grant, attestation mismatch, and
+  replay-store outage; and
+- a 20-client TLS replay-store race that requires exactly one SETNX winner.
 
 For accepted TLS sessions, the AGTP observed-identity path derives
 `tls_exporter_sha256` from the accepted `tls.ConnectionState`. Fixed exporter
@@ -205,6 +225,14 @@ Product security gate:
 make product-security-gate
 ```
 
+Focused production profile and consumer integration:
+
+```sh
+go test -race -count=1 \
+  ./pkg/production \
+  ./examples/protected-change-consumer
+```
+
 ## Security Reporting
 
 Report suspected vulnerabilities through GitHub private vulnerability reporting
@@ -240,16 +268,17 @@ upstream notices. See `ATTRIBUTION.md`.
 - Gateway-routed runtime wiring is outside the current Direct-Agent
   implementation. Wallets can provide presentation or signing functions, but
   are not trust roots or sources of verifier-local expected policy.
-- The v0.4 evaluation is evidence for the tested fail-closed verifier behavior,
+- The release evaluation is evidence for the tested fail-closed verifier behavior,
   not a formal proof or validation of every deployment. Broader application
   0-RTT behavior, production gRPC pooling, runtime gateway wiring, longer
   fuzz/property campaigns, and hardware-backed confidential-VM attestation
   replay remain outside the recorded evaluation.
 - The ProVerif model uses symbolic cryptography and does not prove TLS, X.509,
   JWT parsing, certificate handling, or equivalence with compiled Go code. The
-  TLA+ result is bounded evidence for a generic target state machine; the
-  current Go tree does not implement its complete durable snapshot, revocation,
-  lease, audit-outbox, or logical-time contract.
+  TLA+ result is bounded evidence for a generic target state machine. The
+  production profile implements trust/revocation snapshots, signed attestation
+  results, and shared replay commits, but not the model's complete lease,
+  audit-outbox, application outcome, or logical-time contract.
 - `pkg/atls` and `pkg/agtp` are legacy compatibility names and do not define the
   protocol trust model. Cocos is implementation provenance rather than the
   normative scope of the profile.

docs/API_COMPATIBILITY.md

@@ -0,0 +1,66 @@
+# Supported API and compatibility policy
+
+This policy applies beginning with release `v1.0.0`.
+
+## Supported surface
+
+The supported Go API is:
+
+- `pkg/production`: production composition, signed attestation-result policy,
+  accepted TLS binding derivation, and TLS-protected Redis/Valkey SETNX replay
+  adapter;
+- `pkg/clients`: Direct-Agent v1 JWT verification through
+  `JWTVerifyOptions`, `VerifyIdentityGrantJWT`, `VerifySessionBindingJWT`, and
+  `VerifySessionIdentityJWT`; and
+- `pkg/atls/identitypolicy`: Direct-Agent v1 policy, binding, and replay
+  interfaces used by the supported production composition.
+
+The supported wire profile is Direct-Agent profile version `1` with
+`sbaip.identity-grant` and `sbaip.session-binding` token types. The fixed
+production exporter label is `Attestation`; application context and a
+verifier-issued nonce are combined by `production.BindingFromTLS`.
+
+The following remain experimental or outside the supported product API:
+
+- draft-06-inspired v2 entrypoints and types;
+- `pkg/agtp`, gateway-route, cache, and diversion-policy adapters;
+- the inherited Manager, Agent, CVM, HAL, proxy, and CLI runtime surfaces;
+- examples, test harnesses, formal models, and document structure; and
+- hardware-specific evidence acquisition and appraisal implementations.
+
+An exported Go identifier outside the supported list is not implicitly stable.
+
+## Compatibility rules
+
+Tags follow semantic versioning.
+
+- Patch releases preserve the supported source API and v1 wire shape. A patch
+  may reject input that was previously accepted when the input is invalid,
+  ambiguous, insecure, or outside the documented profile.
+- Minor releases may add optional APIs or fields. Existing supported calls and
+  valid v1 messages continue to work without source changes.
+- Breaking supported API or wire changes require a new major version and a new
+  versioned verification entrypoint. They are not introduced by silently
+  changing v1 parsing or binding behavior.
+- Stable APIs deprecated during v1 remain available through the v1 major line
+  unless retaining them creates a concrete security vulnerability. Any
+  security exception is documented in the release notes and security advisory.
+- The supported build baseline for v1.0 is Go 1.26.x. A later toolchain floor
+  is announced in release notes before it becomes the default-branch minimum.
+
+Only the latest v1 minor release receives routine fixes. The immediately prior
+minor receives critical security fixes for 90 days after the newer minor is
+released. Release artifacts and their source commit remain available after the
+support window.
+
+## Deployment compatibility
+
+Production deployments must keep Manager, Agent, and attestation-verifier key
+roles separate. Key rotation is compatible when old and new key IDs overlap in
+the locally accepted trust snapshot for the intended migration window.
+Disabling a key ID or revoking a token ID intentionally causes requests that
+depend on it to fail.
+
+Replay storage is compatible with Redis or Valkey servers that implement
+`SET key value NX PX ttl` over TLS. Store unavailability is an authentication
+failure; there is no in-memory fallback in the production profile.

docs/SSOT.md

@@ -1271,10 +1271,16 @@ The implemented production profile covers:
 - local QUIC/TLS early-data authentication gating coverage for pre-binding
   rejection.
 
-Deployment still chooses trusted keys, expected policy values, revocation data,
-and distributed replay storage. Those sources can be Manager configuration,
-Agent metadata, computation state, an authorization policy engine, or a
-fail-closed registry integration. They must not be raw peer-controlled metadata.
+`pkg/production` composes the Direct-Agent v1 checks with role-separated trust
+and revocation snapshots, signed attestation-result appraisal, and a
+TLS-protected Redis/Valkey SETNX adapter. The concrete supported choices and
+consumer boundary are fixed in `docs/production-deployment-profile.md`.
+
+Each deployment still supplies its own trusted keys, expected policy values,
+revocation data, Redis/Valkey service, and attestation verifier output. Those
+sources can be Manager configuration, Agent metadata, computation state, an
+authorization policy engine, or a fail-closed registry integration. They must
+not be raw peer-controlled metadata.
 
 ## 26. Evaluation boundary