Skip to content

Mandate 0.1.0

Choose a tag to compare

@b10x-bot b10x-bot released this 18 Sep 23:07
874a74f

The first tagged release of Mandate: the state of main after three implementation waves of the ten-wave forecast, with a changelog that backfills the batches that led here as pre-releases (v0.1.0-alpha.1 … v0.1.0-alpha.4).

What runs

Capability Crate
mandate.authorization.Check decided over the graph and policy ports: context binding, one graph read and one policy read folded through deny precedence with the requested authority scope and the applicable ceilings, challenges assembled; nothing a port cannot answer becomes an allow mandate-authz
Federation: connection registration, explicit linking, first-login provisioning, authentication, and the non-consuming AuthorizePublicClient validation (S256 challenge form decided by decoding, registered client, exact redirect, tenant-bound target, session, constant-time state and nonce) mandate-federation
Session security generations, snapshots and refresh that denies a stale epoch mandate-identity
Tenancy and resource topology folds with a compile-time persisted-value boundary mandate-model
Graph and policy ports over doubles; a revision-bound read that denies a revoked grant at every floor mandate-graph, mandate-policy
The 74 accepted canonical types with a machine-checked inventory mandate-types, mandate-token, mandate-proto
mandate pkce-challenge: the S256 challenge for a verifier read from stdin, never echoed bins/mandate
A contract of 72 events, 59 commands, 110 types and 36 entities, regenerated and byte-compared; every fold input declared on an event systems/mandate, generated/
A gate that reads its own document deliverables (cargo xtask documents) xtask/

Validation: task check on the wave-3 head: exit 0, 109 test targets, 611 tests passed, 0 failed; dependency boundaries, 59 command obligations, 50 contract scenarios with source-hash verification, deterministic ESS regeneration, cargo deny, planning-store validation, and the document step all green. Twenty-four adversary passes across the three waves; every finding has a recorded outcome on its story.

Not in this release

  • No served route: every binary still refuses serve.
  • No real signature or JWKS verifier: the port ships with a fixture double (story:signing-and-verification).
  • No durable event-log adapter: the kit is wired, every fold is in-memory.
  • No credential issuance or authorization-code redemption at STS (story:credential-profiles, story:oauth-integration).
  • Fourteen entities have no creation event yet and cannot be rebuilt from the log (story:declared-writers).
  • The customer login flow does not run end to end yet; see docs/architecture/federated-login.md for the design and the road.

Pull requests in this release

  • #4 — the ten-wave plan and the integration-batch delivery rule (v0.1.0-alpha.1)
  • #5 — wave 1: canonical types, runtime decision dossier (v0.1.0-alpha.2)
  • #6 — wave 2: session epochs, tenancy topology, federation linking, graph and policy ports (v0.1.0-alpha.3)
  • #7 — wave 3: Check decisions, public-client validation, fold-ready events, the document gate (v0.1.0-alpha.4)
  • #8 — the changelog

Full details: CHANGELOG.md.