@prefig/upact 0.1.1 → 0.1.2

package/CHANGELOG.md

@@ -4,6 +4,46 @@ All notable changes to this project are documented here. Format follows [Keep a
 
 ---
 
+## [Unreleased]
+
+### Removed
+
+- `CONTRIBUTING.md`, `GOVERNANCE.md`, `ROADMAP.md`. Load-bearing content folded into `README.md` (maintenance posture, commit conventions including the `Co-Authored-By:` exclusion) and `SPEC.md` (working-group definition self-contained in §11; authorship note self-contained at the top). Decision lineage lives in `git log` and the `SPEC.md` §12 register. The Decision 12 deployment-shape table moved to `docs/adapter-shapes.md`. The repo's earlier institutional shape exceeded what a single-maintainer experiment in v0.x earns.
+
+### Changed
+
+- `SPEC.md`: stripped audit-framing references in §4, §5.1, §11, §12, §13 prose, leaving the substantive content intact. The footer no longer points at deleted documents.
+- `package.json` `files` array: drops the deleted documents from the published package.
+
+---
+
+## [0.1.2] — 2026-05-04
+
+Documentation-only release in this package. The substantive change is a new external adapter (`@prefig/upact-mastodon`) shipped separately.
+
+### Added
+
+- ROADMAP Decision 12 (closed): multi-instance fediverse exception to Path B. The default adapter strategy (Path B / OIDC + Authentik) is incompatible with substrates whose UX requires per-login instance flexibility; `@prefig/upact-mastodon` is the first direct adapter shipped under this exception.
+- `SPEC.md §13` non-normative entry for `@prefig/upact-mastodon`.
+- `docs/adapter-shapes.md`: Mastodon column added to the comparison table; Mastodon-specifics section documents the per-login instance discovery + dynamic OAuth client registration pattern; F2 (per-user-session binding) is now empirically observed in two shipped adapters rather than predicted.
+- `docs/cross-adapter-findings.md`: H1 confirmation note for F1/F2/F3/F6/G1 (originally Mastodon-as-analysis findings; now empirically supported by the shipped adapter).
+- `README.md`: `@prefig/upact-mastodon` row added to the Adapters table.
+
+### Changed
+
+- ROADMAP line 13 (adapter strategy): nuanced from blanket "Path B for all OIDC-shaped substrates" to "Path B for stable per-deployment instance configuration; direct adapters for per-login instance flexibility per Decision 12."
+
+### Unchanged (explicit non-changes)
+
+- No changes to `SPEC.md §1` through `§12` (normative spec text).
+- No changes to `src/types.ts`, `src/runtime.ts`, `src/errors.ts`, `src/index.ts`, or any test under `tests/`.
+- No changes to the capability vocabulary (still `'email' | 'recovery'`).
+- No changes to MUST clauses in §7.
+
+The runtime kernel is unchanged from v0.1.1.
+
+---
+
 ## [0.1.1] — 2026-05-01
 
 Additive spec amendments: lifecycle and provenance on `Upactor`. Ships `@prefig/upact-oidc` as the third reference adapter.

package/CONFORMANCE.md

@@ -27,6 +27,8 @@ Copy this template into your adapter package as `CONFORMANCE.md` and fill in eac
 
 For each capability listed, name the concrete consumer (the application code that gates on it).
 
+Note: authorization roles (admin, moderator, operator) MUST NOT appear here. They are out of scope for the port (§3.1).
+
 ## AuthError mapping table
 
 | Substrate error | AuthErrorCode |
@@ -66,7 +68,7 @@ This adapter passes a sixteen-vector reflection test (`tests/back-channel.test.t
 
 ## Substrate
 
-Supabase Auth — a managed PostgreSQL-backed identity service. `auth.users` is the substrate user record. Enforcement-camp substrate: the Supabase `User` object exposes email, phone, JWT claims, `app_metadata`, and `user_metadata`; the adapter strips all of these except what is needed to populate the three `Upactor` fields.
+Supabase Auth: a managed PostgreSQL-backed identity service. `auth.users` is the substrate user record. Enforcement-camp substrate: the Supabase `User` object exposes email, phone, JWT claims, `app_metadata`, and `user_metadata`; the adapter strips all of these except what is needed to populate the three `Upactor` fields.
 
 ## Threat model
 
@@ -74,8 +76,8 @@ Casual coordination. Supabase Auth is a centralised service operated by Supabase
 
 ## Capabilities self-declared
 
-`['email', 'recovery']` — for users with a confirmed email address (non-empty `user.email`).
-`[]` — for users without a confirmed email address.
+`['email', 'recovery']`: for users with a confirmed email address (non-empty `user.email`).
+`[]`: for users without a confirmed email address.
 
 Concrete consumer: dyad M1 UI gates on `capabilities.has('email')` to show or hide email-related settings. `recovery` is bundled with `email` because the same email address that identifies the user is the recovery channel; they are not independently affords.
 
@@ -107,7 +109,7 @@ None.
 
 ## Identifier derivation
 
-`Upactor.id` is set directly from `user.id` — the Supabase Auth UUID. Supabase UUIDs are opaque random identifiers (`gen_random_uuid()`); they are not derivable from user-supplied identifiers (email, phone). No hashing is applied. The raw UUID is not email-shaped and carries no information about the user visible at the application layer.
+`Upactor.id` is set directly from `user.id` (the Supabase Auth UUID). Supabase UUIDs are opaque random identifiers (`gen_random_uuid()`); they are not derivable from user-supplied identifiers (email, phone). No hashing is applied. The raw UUID is not email-shaped and carries no information about the user visible at the application layer.
 
 ---
 
@@ -121,7 +123,7 @@ None.
 
 ## Substrate
 
-SimpleX Chat daemon — a local IPC process exposing a JSON command API. Pre-conforming substrate: the SimpleX local profile carries `localDisplayName`, `agentUserId` (UUID), and a handful of status flags. There is no central directory; profiles are application-scoped and anonymous. The adapter is thin — mostly type translation.
+SimpleX Chat daemon: a local IPC process exposing a JSON command API. Pre-conforming substrate: the SimpleX local profile carries `localDisplayName`, `agentUserId` (UUID), and a handful of status flags. There is no central directory; profiles are application-scoped and anonymous. The adapter is thin: mostly type translation.
 
 ## Threat model
 
@@ -129,9 +131,9 @@ Anonymous / pseudonymous coordination. The SimpleX substrate has no central dire
 
 ## Capabilities self-declared
 
-`[]` — no capabilities declared for v0.1.
+`[]`: no capabilities declared for v0.1.
 
-The SimpleX substrate affords messaging (`sendMessage`, `receiveMessage`) and peer-to-peer matching. Neither is surfaced through the upact port at v0.1: no shipped consumer gates on a `messaging` or `p2p_matching` capability check. Per the minimum-viable discipline (CONTRIBUTING.md), capabilities land when a concrete consumer surfaces them.
+The SimpleX substrate affords messaging (`sendMessage`, `receiveMessage`) and peer-to-peer matching. Neither is surfaced through the upact port at v0.1: no shipped consumer gates on a `messaging` or `p2p_matching` capability check. Capabilities land when a shipped consumer needs them, per `SPEC.md` §5.2.
 
 ## AuthError mapping table
 
@@ -159,4 +161,4 @@ None.
 
 ## Identifier derivation
 
-`Upactor.id` is derived from `user.agentUserId` (a UUID string) via `SHA-256(agentUserId).slice(0, 32)` — the first 32 hex characters of the SHA-256 digest. The derivation is deterministic per `agentUserId` (stable across sessions for the same profile) and not reversible from the application layer. The hash is implemented with the Web Crypto API (`crypto.subtle.digest`).
+`Upactor.id` is derived from `user.agentUserId` (a UUID string) via `SHA-256(agentUserId).slice(0, 32)`: the first 32 hex characters of the SHA-256 digest. The derivation is deterministic per `agentUserId` (stable across sessions for the same profile) and not reversible from the application layer. The hash is implemented with the Web Crypto API (`crypto.subtle.digest`).

package/README.md

@@ -6,22 +6,34 @@ A typed architectural contract between a social application and any identity pro
 
 upact is named for the Ulysses pact that adopters make when building privacy-first social technologies that are architecturally hostile to extractive practices.
 
-upact is a minimum-disclosure anti-corruption layer between your application and any supported identity-management substrate. The privacy minima at the port (no email, no phone, no IP, opaque sessions, enumerated capabilities) are commitments the application can no longer violate. The architectural cost of breaking the contract later is what makes the commitment durable: an application built on upact cannot quietly pivot to surveillance-driven, data-retention-driven, or third-party-sharing-shaped revenue without tearing up its foundations.
+upact is a minimum-disclosure anti-corruption layer between your application and any supported identity-management substrate. The privacy minima at the port (no email, no phone, no IP, opaque sessions, enumerated capabilities) are commitments the application can no longer violate *through the upact-shaped path*. An application built on upact cannot quietly pivot the identity layer toward surveillance, retention, or third-party data-sharing without visible architectural change.
 
-The constraint also shapes design. When the application cannot know a user's email, you build features that don't need it. This provides friction against reflexes inherited from an extraction- and retention-shaped social media ecosystem. That friction matters especially with LLM-assisted development, where those patterns are efficiently automated by tools trained on that ecosystem.
+The port does not block pivots reachable through direct substrate-library import. Those remain visible to code review only. See §7.5 below and `SECURITY.md` for the limit.
+
+The constraint also shapes design. When the application cannot know a user's email, you build features that don't need it. This provides friction against reflexes inherited from an extraction- and retention-shaped social media ecosystem.
 
 upact is not a replacement for OIDC clients (`auth.js`, `lucia`, `openid-client`), identity-broker IDPs (Authentik, Keycloak, ZITADEL), or identity protocols (DIDs, Verifiable Credentials). It is the typed-contract layer that sits on top of these substrates and provides a contract on what the application is permitted to know and what it has bound itself out of knowing.
 
 ## Why upact
 
-The values commitment is what motivates platforms to consider adopting upact. These benefits accrue to every adopter who honours the contract, regardless of whether the values posture is what brought them in:
+These benefits accrue to every application using upact, regardless of motivation:
 
 - **Design discipline.** Structural limits on what you can know force design principles and features that don't depend on data you shouldn't have.
 - **A small, well-defined identity surface.** The `Upactor` type has three fields. Substrate-shaped User types typically have >=30.
-- **Reduced surface for accidental privacy violations.** If application code can't read `email`, it can't accidentally include it in logs, metrics, error reports, SSR-rendered HTML, or analytics events. The architectural constraint doubles as a debugging-and-monitoring privacy guarantee.
+- **Privacy guarantees at call sites that use the port.** Code that uses `currentUpactor` cannot accidentally include email in logs, metrics, error reports, SSR-rendered HTML, or analytics events. Code that calls the substrate directly remains a code-review concern; treating substrate-library imports as a marked, audited boundary (e.g. only allowed in the substrate seam, forbidden in service code) extends the guarantee to the rest of the application.
 - **Audited opacity primitives.** Sessions cannot be unwrapped via `JSON.stringify`, `structuredClone`, `util.inspect`, or other inspection vectors. The runtime kernel is centrally tested across sixteen vectors; every conforming adapter inherits the guarantee.
-- **Swap substrates without re-architecting.** The port carries your privacy posture. Switch from Supabase Auth to an OIDC-brokered provider and your application code is unchanged.
-- **A pre-written audit artefact.** When a third party (legal, compliance, regulator, partner) asks "what does your application know about users?", the conformance statement is the answer.
+- **Swap identity providers without re-architecting the identity layer.** The port carries your privacy posture across providers. Switch from Supabase Auth to an OIDC-brokered provider, and the application's identity-shaped call sites are unchanged. Substrate concerns outside identity (data access, RLS, jobs, admin tooling) remain substrate-coupled by design; upact does not abstract data access.
+- **A ready answer for compliance, legal, and regulator questions about user data.** When a third party asks "what does your application know about users?", the conformance statement documents what the adapter returns. It narrows but does not replace an application-level audit, since application code remains free to import substrate libraries directly per §7.5.
+
+## Limits: what upact does not prevent
+
+upact closes the identity boundary architecturally. Application-level misuse of the substrate is not closed:
+
+- An application that ignores the port and calls the substrate library directly (e.g. `supabase.auth.getUser()`) gets back whatever the substrate exposes, including email and other fields the port would have stripped. upact's binding holds only for code that consumes `Upactor` values from the port.
+- The application's freedom to import substrate libraries is preserved (§7.5). That coupling is transparent (visible in `package.json` and reviewable in code), but the port does not block it.
+- Authorization (admin, moderator, operator) is out of scope (§3.1). upact does not provide a permissions model.
+
+The discipline that makes the binding stick: treat substrate-library imports as a marked, audited boundary, only allowed in the substrate seam (the adapter, the auth callback handler), forbidden in service code. A future v0.2 conformance test suite will mechanise this; today it is convention. See `SECURITY.md` for the full scope.
 
 ## Usage
 
@@ -29,7 +41,7 @@ The values commitment is what motivates platforms to consider adopting upact. Th
 import type { IdentityPort } from '@prefig/upact';
 import { SubstrateUnavailableError } from '@prefig/upact';
 
-// authenticate returns Session | AuthError — discriminate on 'code':
+// authenticate returns Session | AuthError; discriminate on 'code':
 const result = await port.authenticate({ kind: 'password', email, password });
 if ('code' in result) {
   switch (result.code) {
@@ -51,7 +63,7 @@ try {
 }
 ```
 
-`authenticate` communicates auth failures as return values (`AuthError`) — it never throws for wrong passwords or rate limits. `currentUpactor` and `issueRenewal` throw `SubstrateUnavailableError` for substrate outages — they never return error values. The asymmetry is deliberate: auth failures are expected control-flow; substrate outages are exceptional conditions.
+`authenticate` communicates auth failures as return values (`AuthError`); it never throws for wrong passwords or rate limits. `currentUpactor` and `issueRenewal` throw `SubstrateUnavailableError` for substrate outages; they never return error values. The asymmetry is deliberate: auth failures are expected control-flow; substrate outages are exceptional conditions.
 
 ## Adapters
 
@@ -60,38 +72,46 @@ try {
 | `@prefig/upact-supabase` | Supabase Auth | Enforcement | v0.1.0 shipped |
 | `@prefig/upact-simplex` | SimpleX Chat daemon | Pre-conforming | v0.1.0 shipped |
 | `@prefig/upact-oidc` | Any OIDC-compliant IDP (Dex, Authentik, Keycloak, ZITADEL) | Enforcement | v0.1.0 shipped |
+| `@prefig/upact-mastodon` | Mastodon REST API (any user-chosen instance) | Enforcement | v0.1.0 shipped |
+| `@prefig/upact-ember` | ember (temporary scope membership renewed in presence) | Pre-conforming | v0.1.0 shipped; first `renewable: 'represence'` adapter |
+| `@prefig/upact-eudi` | EUDI wallet (OpenID4VP 1.0 / HAIP verifier, SD-JWT VC German PID) | Enforcement | v0.1.0 shipped; declared attribute list (CIR (EU) 2025/848) enforced at construction |
 
 ## Adopters
 
 | Application | Substrate | Notes |
 |---|---|---|
-| [dyad.berlin](https://dyad.berlin) | `@prefig/upact-supabase` | First adopter; M1 integration in progress |
+| [dyad.berlin](https://dyad.berlin) | `@prefig/upact-supabase` | Reference adopter; database layer substrate-agnostic, application routes return `Upactor` |
 
 If your application uses upact, open a PR to add it here.
 
 ## In this repo
 
-- `SPEC.md` — normative specification, v0.1.
-- `src/types.ts` — reference TypeScript types (`Upactor`, `IdentityPort`, `AuthError`, `Capability`, `Session`).
-- `src/runtime.ts` — small runtime kernel. Exports `createSession`, the canonical factory that produces opaque `Session` values per SPEC.md §7.4. Adapter authors should use it rather than maintain their own opaque-wrapper class; the opacity guarantee is centralised here, audited once.
-- `docs/adapter-shapes.md` — type-only sketches of the v0.1 shipped adapters (Supabase, SimpleX, OIDC).
-- `docs/cross-adapter-findings.md` — cross-substrate observations that shaped the spec.
-- `examples/sveltekit-supabase/` — minimal SvelteKit + Supabase integration showing the three key wiring points: hook, type augmentation, and capability-gated page load.
-- `CONTRIBUTING.md` — the five-test contributor audit, AI-Involvement trailer convention.
-- `GOVERNANCE.md` — v0.x maintainer posture and v1.0 working-group target.
-- `CONFORMANCE.md` — conformance statement template with filled-in examples for both v0.1 adapters.
-- `CHANGELOG.md` — per-version change record.
-- `ROADMAP.md` — open and closed decisions.
+- `SPEC.md`: normative specification, v0.1.
+- `src/types.ts`: reference TypeScript types (`Upactor`, `IdentityPort`, `AuthError`, `Capability`, `Session`).
+- `src/runtime.ts`: small runtime kernel. Exports `createSession`, the canonical factory that produces opaque `Session` values per SPEC.md §7.4. Adapter authors should use it rather than maintain their own opaque-wrapper class; the opacity guarantee is centralised here, audited once.
+- `docs/adapter-shapes.md`: type-only sketches of the v0.1 shipped adapters (Supabase, SimpleX, OIDC, Mastodon).
+- `docs/cross-adapter-findings.md`: cross-substrate observations that shaped the spec.
+- `examples/sveltekit-supabase/`: minimal SvelteKit + Supabase integration showing the three key wiring points: hook, type augmentation, and capability-gated page load.
+- `CONFORMANCE.md`: conformance statement template with filled-in examples for both v0.1 adapters.
+- `CHANGELOG.md`: per-version change record.
 
 ## Status
 
-v0.1.1. Three reference adapters shipped. Breaking changes between v0.x revisions are permitted; v1.0 marks the first stable version.
+v0.1.2. Four reference adapters shipped (OIDC added in 0.1.1, Mastodon added in 0.1.2). Breaking changes between v0.x revisions are permitted; v1.0 marks the first stable version.
+
+upact is maintained by a group of maintainers. Issues welcome at [github.com/prefig/upact/issues](https://github.com/prefig/upact/issues). At v1.0 the core capability vocabulary (§5.1) and MUST clauses (§7) move to a working group of ≥3 conforming-adapter authors (see `SPEC.md` §11).
+
+## Commit conventions
+
+Commits with substantive AI involvement carry an `AI-Involvement: <tier>` trailer recording the character of involvement (`autonomous` / `authored` / `collaborative` / `assisted` / `commit-message-only`), so readers can calibrate the provenance of normative content. The convention is most important on `SPEC.md`, `src/types.ts`, and capability-vocabulary changes.
+
+upact does not use `Co-Authored-By:` for AI authorship. `Co-Authored-By:` claims human co-authorship; `AI-Involvement` records the character of involvement instead.
 
 ## Licence
 
 Dual-licensed:
 
-- **`SPEC.md`, `docs/`, this README, and other prose** — CC BY 4.0 (see `LICENSE`).
-- **`src/` (TypeScript types and runtime kernel)** — Apache-2.0 (see `LICENSE-CODE`).
+- **`SPEC.md`, `docs/`, this README, and other prose**: CC BY 4.0 (see `LICENSE`).
+- **`src/` (TypeScript types and runtime kernel)**: Apache-2.0 (see `LICENSE-CODE`).
 
 Each `src/*.ts` file carries an `SPDX-License-Identifier: Apache-2.0` header. The split follows TC39 / SPDX precedent: spec text is intellectual property meant to be cited and forked under CC; runtime code is software under a conventional permissive licence with a patent grant.

package/SECURITY.md

@@ -30,4 +30,4 @@ The following are **out of scope**:
 
 ## Conformance and security
 
-A conforming adapter's security posture is described in its `CONFORMANCE.md`. Applications that need stronger threat-model guarantees (e.g. adversarial-context coordination) SHOULD choose a substrate whose threat model matches — see `SPEC.md §10`.
+A conforming adapter's security posture is described in its `CONFORMANCE.md`. Applications that need stronger threat-model guarantees (e.g. adversarial-context coordination) SHOULD choose a substrate whose threat model matches; see `SPEC.md §10`.

package/SPEC.md

@@ -4,7 +4,7 @@
 **Status:** Working draft. Public release. Breaking changes between v0.x revisions are permitted; v1.0 marks the first stable version.
 **License:** CC BY 4.0
 
-> **A note on authorship.** v0.1 of this specification was AI-co-authored under the project's `AI-Involvement` trailer convention (see `CONTRIBUTING.md`). The transparency posture is preserved as disclosure rather than authorship-purity. Every commit touching normative content carries the trailer; readers can audit the contribution lineage in `git log`. Future revisions may include a maintainer-only re-authoring pass; for now the disclosure trail is the binding mechanism.
+> **A note on authorship.** v0.1 of this specification was AI-co-authored. Commits touching normative content carry an `AI-Involvement: <tier>` trailer recording the character of involvement (`autonomous` / `authored` / `collaborative` / `assisted` / `commit-message-only`). The contribution lineage is auditable in `git log`. Future revisions may include a maintainer-only re-authoring pass.
 
 ---
 
@@ -47,6 +47,20 @@ An **application** conforms to this specification when it:
 
 Conformance is to a specific version of the spec.
 
+**Application-side conformance is currently a discipline, not a test.** The provider has a sixteen-vector reflection test for §7.5 conformance; the application side has no equivalent automated check. A future v0.2 release SHOULD ship application-side static checks (lint rules forbidding substrate-library imports outside the substrate seam, or equivalent) to mechanise this bar.
+
+### §3.1 Scope: user-tier identity
+
+This specification governs user-facing identity — the relationship between an authenticated person and the application. It does not govern:
+
+- Application-internal authorization (admin, moderator, operator capabilities)
+- System-to-system credentials
+- Any identity concern that is not a direct person–application relationship
+
+**Authorization is out of scope.** The privacy minima of §7 describe what the application may know about a user; they do not describe what an operator may know about, or do to, the system. How an application implements operator/administrative tooling is its own concern — whether through a substrate-native capability claim, an application-layer role, a separate authentication plane on a different surface, a command-line tool, or no operator surface at all.
+
+`Upactor` attributes and capabilities MUST NOT be used to model authorization roles. The capability vocabulary in §5 governs what user-facing features the application may use (e.g. sending an email to a user); it does not govern what privileged operations a particular caller is permitted to perform.
+
 ## §4. Upactor
 
 A `Upactor` is a value of the following shape:
@@ -66,7 +80,7 @@ interface IdentityLifecycle {
 }
 ```
 
-Five fields, three of which are optional. The shape is intentionally minimal per the contributor audit (CONTRIBUTING.md). `lifecycle` and `provenance` were deferred from the initial draft and brought back by the OIDC adapter (Phase C, v0.1.1) — concrete consumer need surfaces them. See §12 for the remaining deferred-decisions register.
+Five fields, three of which are optional. `lifecycle` and `provenance` were deferred from the initial draft and brought back by the OIDC adapter (Phase C, v0.1.1) when it concretely needed them. See §12 for the remaining deferred-decisions register.
 
 ### §4.1 `id`
 
@@ -109,7 +123,7 @@ Capabilities are self-described provider features. The application uses capabili
 | `email` | The provider can deliver email to this identity. |
 | `recovery` | The provider supports identity recovery flows. |
 
-**The vocabulary is intentionally minimal.** The audit (see CONTRIBUTING.md) found these two are the capabilities that have shipped consumers — the Supabase reference adapter declares them; dyad's UI gating consumes them for password-reset and invitation flows. Capabilities present in earlier drafts (`messaging`, `p2p_matching`, `presence_renewal`, `threshold_attestation`, `push`, `webauthn`) were not declared by any shipped consumer in this version and were deferred. Adapter authors do not pre-emptively expand the vocabulary; new capabilities land via §5.2 extension when concrete consumers surface.
+**The vocabulary is intentionally minimal.** These two capabilities have shipped consumers: the Supabase reference adapter declares them; dyad's UI gates on them for password-reset and invitation flows. New capabilities land via §5.2 extension when shipped adapters need them.
 
 This minimum-viable discipline is itself part of the binding mechanism. A capability vocabulary that grew speculatively would dilute the contract: applications would gate on capabilities that no substrate genuinely supports, providers would declare capabilities to look feature-rich, and the whole signal would erode. Keeping the vocabulary small and concrete-need-driven keeps the binding genuine.
 
@@ -185,6 +199,8 @@ interface AuthError {
 
 Providers MUST return one of these codes; substrate-specific detail goes in `message`. Applications branch on `code` for substrate-portable error handling. Adapter packages document their per-substrate mapping (which substrate errors map to which code) in their conformance statement (§10).
 
+Adapters may emit a subset of the vocabulary. Codes that distinguish identity-existence from credential-validity (notably `identity_unavailable`) are reserved for substrates that surface that distinction; the v0.1 reference adapters do not — Supabase conflates "no such user" with "wrong password" as credential-stuffing resistance, OIDC surfaces failures as token errors. Application code can branch on the full vocabulary; some branches will be unreachable for some adapters.
+
 ## §7. Privacy minima (normative MUST NOT clauses)
 
 These clauses are normative. A conforming provider MUST observe them.
@@ -273,11 +289,11 @@ This specification is versioned. v0.1 is the first public draft. Breaking change
 
 Capabilities present in §5.1 are normative for v0.1. Capabilities outside §5.1 are advisory and follow registry conventions to be specified in v0.2. The registry MAY accept new capabilities on demonstrated implementation by at least two independent providers AND demonstrated consumption by at least one application.
 
-Governance posture: v0.x decisions are made by the maintainer. By v1.0, decisions about the core capability vocabulary (§5.1) and MUST clauses (§7) move to a working group of ≥3 conforming-adapter authors. See `GOVERNANCE.md`.
+Governance posture: v0.x decisions are made by the upact maintainer group on rough consensus. At v1.0, decisions about the core capability vocabulary (§5.1) and MUST clauses (§7) move to a working group of ≥3 conforming-adapter authors. A *conforming-adapter author* is an organisation or individual who maintains a published `@prefig/upact-*` package that passes the sixteen-vector reflection test, has shipped a `CONFORMANCE.md` against a specific spec version, and has actively maintained the adapter (a PR or release in the last twelve months). Capability-vocabulary additions and MUST-clause changes after v1.0 require a working-group decision plus implementation by ≥2 independent conforming adapters and consumption by ≥1 shipped application; MUST-clause changes additionally require a migration period during which the old behaviour remains valid.
 
 ## §12. Deferred decisions (the register)
 
-The audit (CONTRIBUTING.md) trimmed v0.1 to the minimum-viable surface that shipped consumers concretely need. Items below are deferred — not abandoned, just held until a concrete consumer surfaces or a shipped adapter forces the question.
+v0.1 was scoped to what shipped adapters need. Items below were proposed but did not ship in v0.1 because no adapter required them yet. They reactivate when a shipped adapter forces the question.
 
 | Decision | Substance | Why deferred from v0.1 |
 |---|---|---|
@@ -291,7 +307,7 @@ The audit (CONTRIBUTING.md) trimmed v0.1 to the minimum-viable surface that ship
 | ~~**G1 — OIDC scope discipline**~~ | **Closed v0.1.1.** `@prefig/upact-oidc` ships `validateScopes` runtime guard and documents the scope allow-list in its conformance statement. | Phase C adapter ships with runtime enforcement. |
 | **Convene + Reticulum substrate sketches in `docs/adapter-shapes.md`** | Speculative entries removed | No shipped adapter, no concrete consumer. Sketches return alongside their adapter. |
 
-The audit checklist in CONTRIBUTING.md names the five tests every Decision passes (concrete-need / minimum-viable / substrate-agnosticism / binding-integrity / disclosure). Future contributors apply the same checklist; this register records the exit conditions for each deferred Decision.
+A Decision exits §12 when a shipped adapter has a concrete need for it (substrate-agnosticism: the change makes sense across at least one enforcement-camp and one pre-conforming substrate), the change preserves the §7 MUST NOTs (binding-integrity), and the spec amendments propagate to the §9 conformance template, the §10 security considerations, and this register where applicable (disclosure).
 
 ## §13. Non-normative appendix — provider sketches
 
@@ -301,14 +317,18 @@ Brief sketches of providers shipped or deferred against this port.
 
 - **`@prefig/upact-supabase`** — Supabase Auth substrate. Capabilities: `email`, `recovery` for users with email; `recovery` only for those without. Identity stable for the account lifetime; renewable via password reset. The port hides email, password, magic-links, JWT claims, `app_metadata`, `user_metadata` from the application; `capabilities.has('email')` gates email-bound features.
 
-- **`@prefig/upact-simplex`** — SimpleX Chat substrate (anonymous unidirectional queues, no central directory). Capabilities: `[]` (no `email`, no `recovery`; substrate affordances for messaging and p2p-matching are real but documented in the adapter README rather than declared as capabilities — see §5 / CONTRIBUTING.md audit). Identity stable per loaded profile; renewable by re-loading the profile. No email, no recovery, no central user database.
+- **`@prefig/upact-simplex`** — SimpleX Chat substrate (anonymous unidirectional queues, no central directory). Capabilities: `[]` (no `email`, no `recovery`; substrate affordances for messaging and p2p-matching are real but documented in the adapter README rather than declared as capabilities, since no shipped consumer gates on them). Identity stable per loaded profile; renewable by re-loading the profile. No email, no recovery, no central user database.
 
 **Shipped at v0.1.1:**
 
 - **`@prefig/upact-oidc`** — generic OIDC client adapter delegating substrate-specific machinery to a substrate-side IDP (Authentik, Keycloak, ZITADEL, Dex). One adapter, many configured IDPs; substrate-specific machinery in IDP realm config rather than in adapter code. Adding a substrate (Mastodon-via-broker, GitHub-via-broker, etc.) becomes operational rather than code-level. Ships `lifecycle` (JWT `exp` → `expires_at`, `renewable: 'reauth'`), `provenance` (`substrate: 'oidc'`, `instance: issuer`), and runtime scope enforcement (`validateScopes`). 75 unit tests + 11 Dex integration tests.
 
+**Shipped at v0.1.2:**
+
+- **`@prefig/upact-mastodon`** — direct Mastodon REST API adapter (per-login instance discovery, dynamic OAuth client registration, no token expiry). Substrate is "any Mastodon-API-compatible server"; Mastodon proper validated, forks (Pleroma, Akkoma, GoToSocial) MAY work via API compatibility but are not validated at v0.1.0. Capabilities: `[]`. Lifecycle: `expires_at: undefined`, `renewable: 'reauth'` (Mastodon access tokens never auto-expire per F6). Provenance: `{ substrate: 'mastodon', instance: <origin> }`. Identifier derivation: `sha256(actor.url)[:32]` per F3. Exists alongside `@prefig/upact-oidc` rather than replacing it: deployments with a fixed instance keep Path B (OIDC + Authentik); deployments wanting fediverse-flexibility (any user-chosen instance) use this package. See `docs/adapter-shapes.md` for the deployment-shape table.
+
 The application code does not change across these. The deployment chooses the provider; the port carries the rest.
 
 ---
 
-*Document version: 0.1.1. Audit-trimmed and AI-co-authored under disclosure 2026-05-01. See `ROADMAP.md` for the full decision lineage and `CONTRIBUTING.md` for the audit discipline.*
+*Document version: 0.1.2. AI-co-authored under disclosure (see authorship note above). Decision lineage is in `git log` and the §12 register.*

package/dist/index.d.ts

@@ -8,7 +8,7 @@
  * subpath — see SPEC.md §7.4 and `docs/adapter-shapes.md`.
  */
 export type { Capability, IdentityLifecycle, Upactor, UserIdentity, // deprecated alias for v0.1.x compat; removed in v0.2
-Session, AuthError, AuthErrorCode, IdentityPort, } from './types.js';
+PresentationRequest, Presentation, Session, AuthError, AuthErrorCode, IdentityPort, } from './types.js';
 export { createSession } from './runtime.js';
 export { SubstrateUnavailableError } from './errors.js';
 //# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AACA;;;;;;;;GAQG;AAEH,YAAY,EACX,UAAU,EACV,iBAAiB,EACjB,OAAO,EACP,YAAY,EAAE,sDAAsD;AACpE,OAAO,EACP,SAAS,EACT,aAAa,EACb,YAAY,GACZ,MAAM,YAAY,CAAC;AAEpB,OAAO,EAAE,aAAa,EAAE,MAAM,cAAc,CAAC;AAC7C,OAAO,EAAE,yBAAyB,EAAE,MAAM,aAAa,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AACA;;;;;;;;GAQG;AAEH,YAAY,EACX,UAAU,EACV,iBAAiB,EACjB,OAAO,EACP,YAAY,EAAE,sDAAsD;AACpE,mBAAmB,EACnB,YAAY,EACZ,OAAO,EACP,SAAS,EACT,aAAa,EACb,YAAY,GACZ,MAAM,YAAY,CAAC;AAEpB,OAAO,EAAE,aAAa,EAAE,MAAM,cAAc,CAAC;AAC7C,OAAO,EAAE,yBAAyB,EAAE,MAAM,aAAa,CAAC"}

package/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,sCAAsC;AACtC;;;;;;;;GAQG;AAaH,OAAO,EAAE,aAAa,EAAE,MAAM,cAAc,CAAC;AAC7C,OAAO,EAAE,yBAAyB,EAAE,MAAM,aAAa,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,sCAAsC;AACtC;;;;;;;;GAQG;AAeH,OAAO,EAAE,aAAa,EAAE,MAAM,cAAc,CAAC;AAC7C,OAAO,EAAE,yBAAyB,EAAE,MAAM,aAAa,CAAC"}

package/dist/types.d.ts

@@ -72,6 +72,41 @@ export interface Upactor {
  * @deprecated Use `Upactor` instead.
  */
 export type UserIdentity = Upactor;
+/**
+ * A presentation request a relying party issues to a keyring/wallet, asking the
+ * holder to present membership. Substrate-agnostic, and named to map onto an
+ * OpenID4VP authorization request so a Digital Credentials API adapter is a
+ * mechanical shim rather than a redesign:
+ *   nonce    -> `nonce`              (replay binding)
+ *   audience -> `client_id`          (who the presentation is for)
+ *   scopes   -> `dcql_query` / `presentation_definition` constraint
+ * The wire encoding is the substrate's; this is the shape an app reasons about.
+ */
+export interface PresentationRequest {
+    /** Single-use challenge the verifier issued; the presentation must echo it. */
+    nonce: Uint8Array | string;
+    /** The verifier this presentation is for (its origin). Binds against relay. */
+    audience: string;
+    /** Optional restriction to specific scopes; omitted means "whatever you hold". */
+    scopes?: string[];
+}
+/**
+ * A verifiable presentation supplied as authentication (or renewal) evidence,
+ * the response to a {@link PresentationRequest}. The envelope is
+ * substrate-agnostic; `vpToken` is the substrate's opaque presentation token,
+ * named to map onto an OpenID4VP `vp_token` response so the DC-API path stays a
+ * shim. An adapter verifies `vpToken` against the scope root(s) it trusts and
+ * returns an {@link Upactor} carrying a `represence` lifecycle. See the
+ * @prefig/upact-ember README for the concrete field mapping.
+ */
+export interface Presentation {
+    /** Echoes the request nonce. */
+    nonce: Uint8Array | string;
+    /** The audience the holder addressed the presentation to, if any. */
+    audience?: string;
+    /** Substrate-specific verifiable presentation token (maps to `vp_token`). */
+    vpToken: Uint8Array;
+}
 /**
  * A provider-shaped credential exchange result. Opaque to the application.
  * The only valid use is to pass it back to the port (e.g. for invalidate).

package/dist/types.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":"AACA;;;;;GAKG;AAEH;;;;;;;;;;;;GAYG;AACH,MAAM,MAAM,UAAU,GAAG,OAAO,GAAG,UAAU,CAAC;AAE9C;;;;GAIG;AACH,MAAM,WAAW,iBAAiB;IACjC,0EAA0E;IAC1E,UAAU,CAAC,EAAE,IAAI,CAAC;IAClB;;;;;OAKG;IACH,SAAS,EAAE,QAAQ,GAAG,YAAY,GAAG,OAAO,CAAC;CAC7C;AAED;;;;;;;GAOG;AACH,MAAM,WAAW,OAAO;IACvB,kFAAkF;IAClF,EAAE,EAAE,MAAM,CAAC;IACX,wEAAwE;IACxE,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,YAAY,EAAE,WAAW,CAAC,UAAU,CAAC,CAAC;IACtC;;;;OAIG;IACH,SAAS,CAAC,EAAE,iBAAiB,CAAC;IAC9B;;;;;OAKG;IACH,UAAU,CAAC,EAAE;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CACtD;AAED;;;;;GAKG;AACH,MAAM,MAAM,YAAY,GAAG,OAAO,CAAC;AAEnC;;;;GAIG;AACH,MAAM,WAAW,OAAO;IACvB,QAAQ,CAAC,OAAO,EAAE,OAAO,MAAM,CAAC;CAChC;AAED;;;;;GAKG;AACH,MAAM,MAAM,aAAa,GACtB,oBAAoB,GACpB,qBAAqB,GACrB,uBAAuB,GACvB,sBAAsB,GACtB,cAAc,GACd,aAAa,CAAC;AAEjB,MAAM,WAAW,SAAS;IACzB,IAAI,EAAE,aAAa,CAAC;IACpB,OAAO,EAAE,MAAM,CAAC;CAChB;AAED;;;GAGG;AACH,MAAM,WAAW,YAAY;IAC5B,YAAY,CAAC,UAAU,EAAE,OAAO,GAAG,OAAO,CAAC,OAAO,GAAG,SAAS,CAAC,CAAC;IAChE,cAAc,CAAC,OAAO,EAAE,OAAO,GAAG,OAAO,CAAC,OAAO,GAAG,IAAI,CAAC,CAAC;IAC1D,UAAU,CAAC,OAAO,EAAE,OAAO,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAC5C,YAAY,CACX,QAAQ,EAAE,OAAO,EACjB,QAAQ,EAAE,OAAO,GACf,OAAO,CAAC,OAAO,GAAG,IAAI,CAAC,CAAC;CAC3B"}
+{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":"AACA;;;;;GAKG;AAEH;;;;;;;;;;;;GAYG;AACH,MAAM,MAAM,UAAU,GAAG,OAAO,GAAG,UAAU,CAAC;AAE9C;;;;GAIG;AACH,MAAM,WAAW,iBAAiB;IACjC,0EAA0E;IAC1E,UAAU,CAAC,EAAE,IAAI,CAAC;IAClB;;;;;OAKG;IACH,SAAS,EAAE,QAAQ,GAAG,YAAY,GAAG,OAAO,CAAC;CAC7C;AAED;;;;;;;GAOG;AACH,MAAM,WAAW,OAAO;IACvB,kFAAkF;IAClF,EAAE,EAAE,MAAM,CAAC;IACX,wEAAwE;IACxE,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,YAAY,EAAE,WAAW,CAAC,UAAU,CAAC,CAAC;IACtC;;;;OAIG;IACH,SAAS,CAAC,EAAE,iBAAiB,CAAC;IAC9B;;;;;OAKG;IACH,UAAU,CAAC,EAAE;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CACtD;AAED;;;;;GAKG;AACH,MAAM,MAAM,YAAY,GAAG,OAAO,CAAC;AAEnC;;;;;;;;;GASG;AACH,MAAM,WAAW,mBAAmB;IACnC,+EAA+E;IAC/E,KAAK,EAAE,UAAU,GAAG,MAAM,CAAC;IAC3B,+EAA+E;IAC/E,QAAQ,EAAE,MAAM,CAAC;IACjB,kFAAkF;IAClF,MAAM,CAAC,EAAE,MAAM,EAAE,CAAC;CAClB;AAED;;;;;;;;GAQG;AACH,MAAM,WAAW,YAAY;IAC5B,gCAAgC;IAChC,KAAK,EAAE,UAAU,GAAG,MAAM,CAAC;IAC3B,qEAAqE;IACrE,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,6EAA6E;IAC7E,OAAO,EAAE,UAAU,CAAC;CACpB;AAED;;;;GAIG;AACH,MAAM,WAAW,OAAO;IACvB,QAAQ,CAAC,OAAO,EAAE,OAAO,MAAM,CAAC;CAChC;AAED;;;;;GAKG;AACH,MAAM,MAAM,aAAa,GACtB,oBAAoB,GACpB,qBAAqB,GACrB,uBAAuB,GACvB,sBAAsB,GACtB,cAAc,GACd,aAAa,CAAC;AAEjB,MAAM,WAAW,SAAS;IACzB,IAAI,EAAE,aAAa,CAAC;IACpB,OAAO,EAAE,MAAM,CAAC;CAChB;AAED;;;GAGG;AACH,MAAM,WAAW,YAAY;IAC5B,YAAY,CAAC,UAAU,EAAE,OAAO,GAAG,OAAO,CAAC,OAAO,GAAG,SAAS,CAAC,CAAC;IAChE,cAAc,CAAC,OAAO,EAAE,OAAO,GAAG,OAAO,CAAC,OAAO,GAAG,IAAI,CAAC,CAAC;IAC1D,UAAU,CAAC,OAAO,EAAE,OAAO,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAC5C,YAAY,CACX,QAAQ,EAAE,OAAO,EACjB,QAAQ,EAAE,OAAO,GACf,OAAO,CAAC,OAAO,GAAG,IAAI,CAAC,CAAC;CAC3B"}

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@prefig/upact",
-	"version": "0.1.1",
+	"version": "0.1.2",
 	"description": "upact — identity port: a typed architectural contract between a social application and any identity provider, with privacy minima as the translation rule.",
 	"license": "(CC-BY-4.0 AND Apache-2.0)",
 	"type": "module",
@@ -21,10 +21,7 @@
 		"LICENSE",
 		"LICENSE-CODE",
 		"SPEC.md",
-		"ROADMAP.md",
 		"CHANGELOG.md",
-		"CONTRIBUTING.md",
-		"GOVERNANCE.md",
 		"CONFORMANCE.md",
 		"SECURITY.md"
 	],

package/CONTRIBUTING.md

@@ -1,87 +0,0 @@
-# Contributing to upact
-
-## How the spec grows
-
-upact operates on **inverse kinematics**: the spec grows from concrete consumer need, not from speculative design. A change to `SPEC.md`, `src/types.ts`, or the capability vocabulary begins with an adapter author or application developer who needs something the current spec does not provide — not the other way around.
-
-Before proposing a spec change, run the five-test audit below. All five tests apply; a change that fails any one does not land.
-
-### The five-test audit
-
-**1. Concrete-need.** Does a shipped or actively-in-development adapter *require* this change to function correctly? "Would be useful for" is not sufficient. Name the adapter and the specific operation that fails without the change.
-
-**2. Minimum-viable.** Is this the smallest change to the spec (types, MUST clauses, capability vocabulary) that satisfies the concrete need? If a narrower change would work, make that one instead.
-
-**3. Substrate-agnosticism.** Does the change make sense for at least two structurally different substrates — one enforcement-camp, one pre-conforming (see `docs/adapter-shapes.md`)? A change that only works for one substrate shape is a substrate-specific extension, not a spec change.
-
-**4. Binding-integrity.** Does the change preserve the self-binding contract? Spec changes MUST NOT:
-  - Expose additional substrate fields through the port (email, phone, IP, substrate-internal handles)
-  - Add OPTIONAL fields to `Upactor` whose presence reveals substrate-type information to the application
-  - Weaken the Session opacity guarantee (§7.4)
-  - Weaken the adapter back-channel closure requirement (§7.5)
-
-**5. Disclosure.** Does the change require documentation of a new disclosure obligation for conforming adapters — in the conformance statement (§9), the security considerations (§10), or the deferred-decisions register (§12)?
-
-### Worked example: adding `lifecycle`
-
-When `lifecycle: { expires_at?: number; renewable: ... }` was first proposed for `Upactor`, the audit looked like this:
-
-- **Concrete-need:** OIDC adapter needs `jwt.exp` for cookie renewal decisions. Named consumer: dyad M2 SvelteKit layout, `+layout.server.ts` session check. — *passes.*
-- **Minimum-viable:** Could the adapter just re-call `issueRenewal` instead? Yes, for dyad M2. The field is pre-emptive. — *fails.*
-- **Result:** Deferred to §12 (D-SPEC-4). Returns when the OIDC adapter concretely needs it.
-
-### Worked example: SimpleX `messaging` capability
-
-When `messaging` was proposed as a capability for `@prefig/upact-simplex`:
-
-- **Concrete-need:** SimpleX affords messaging. No current dyad UI gates on `capabilities.has('messaging')`. No shipped consumer. — *fails.*
-- **Result:** `@prefig/upact-simplex` ships with `capabilities = []`. Capability lands when a consumer surfaces.
-
-## Adapter conformance
-
-New adapters MUST pass the five-test audit for any spec amendment their design requires. Adapters that work within the existing spec need not run the audit — the spec is already there.
-
-All adapters MUST:
-
-1. Ship a `CONFORMANCE.md` (template in this repo) declaring the spec version, substrate, threat model, capability self-declaration, and `AuthError` mapping table.
-2. Ship a sixteen-vector reflection test (see `@prefig/upact-supabase/tests/back-channel.test.ts`) asserting that no sentinel substrate token leaks through the adapter instance.
-3. Use `createSession` from `@prefig/upact` for Session construction, or pass an equivalent sixteen-vector test suite.
-
-## AI-Involvement trailers
-
-upact acknowledges LLM contributions to normative content under an `AI-Involvement` trailer on git commits. The trailer records the character of AI involvement so readers can calibrate the provenance of what they are reading.
-
-```
-AI-Involvement: <tier>
-```
-
-Five tiers:
-
-| Tier | When to use |
-|---|---|
-| `autonomous` | AI generated the full commit with no human review of content (rare; avoid for normative paths) |
-| `authored` | AI wrote the primary content; human reviewed and accepted with minor edits |
-| `collaborative` | Human and AI contributed substantial portions; hard to separate authorship |
-| `assisted` | Human wrote the primary content; AI provided suggestions or structured material the human evaluated |
-| `commit-message-only` | AI wrote only the commit message; content is human-authored |
-
-The trailer is advisory, not mechanical. Its purpose is honest attribution, not compliance theatre. Use the tier that most accurately describes the commit.
-
-Normative paths (`SPEC.md`, `src/types.ts`, capability vocabulary) that carry `autonomous` or `authored` tiers are permitted at v0.1. This posture is revisited before v1.0.
-
-## Spec versioning and stability
-
-- v0.x: breaking changes between minor versions are permitted. The maintainer (Theodore Evans) makes decisions.
-- v1.0: first stable version. Decisions about the core capability vocabulary (§5.1) and MUST clauses (§7) move to a working group of ≥3 conforming-adapter authors. See `GOVERNANCE.md`.
-
-## What goes in the deferred-decisions register
-
-`SPEC.md §12` is the register of features that passed the concrete-need test *eventually* — meaning a concrete need exists in principle — but failed minimum-viable or substrate-agnosticism, or whose consumer is not yet shipped. Items enter the register with a brief rationale; they reactivate when the consumer surfaces or a shipped adapter forces the question.
-
-Do not treat §12 entries as a backlog. They are a deliberate holding pattern, not a roadmap.
-
-## Submissions
-
-- Open an issue before a PR for anything that touches `SPEC.md` or `src/types.ts`.
-- Adapter packages are independent repos under the `@prefig/` namespace; open issues on the relevant adapter repo.
-- Discussion happens in issues. Normative decisions land in commits. The commit message carries the decision; the issue carries the context.

package/GOVERNANCE.md

@@ -1,34 +0,0 @@
-# Governance
-
-## v0.x (current)
-
-Theodore Evans is the maintainer. Decisions about the spec, capability vocabulary, and normative content are made by the maintainer, informed by adapter authors and application developers through issues and PRs.
-
-The inverse-kinematics principle (see `CONTRIBUTING.md`) is the primary constraint on spec growth. The maintainer applies it consistently; so should anyone making a case for a change.
-
-Decisions are recorded in commits to `SPEC.md` and `ROADMAP.md`, not in issue threads. Issue threads carry context; the commit is the decision.
-
-## v1.0 (target)
-
-Decisions about the core capability vocabulary (§5.1) and MUST clauses (§7) move to a working group of ≥3 conforming-adapter authors at v1.0. A *conforming-adapter author* is an organisation or individual who:
-
-- Maintains a published `@prefig/upact-*` package that passes the sixteen-vector reflection test,
-- has shipped a `CONFORMANCE.md` against a specific version of the spec, and
-- is actively maintaining the adapter (a PR or release in the last twelve months).
-
-The working group operates on rough consensus. When rough consensus is absent, the maintainer retains casting vote.
-
-Additions to the capability vocabulary after v1.0 require a working group decision AND demonstration of:
-
-1. Implementation by ≥2 independent conforming adapters, and
-2. Consumption by ≥1 shipped application.
-
-Changes to MUST clauses require the same bar plus a migration period during which the old behaviour remains valid.
-
-## Forks
-
-upact is dual-licensed (CC BY 4.0 / Apache-2.0; see `LICENSE` and `LICENSE-CODE`). Forks are permitted; they are asked to rename the package to avoid registry confusion. Forked packages that claim upact conformance MUST reference the specific version of the spec they conform to in their `CONFORMANCE.md`.
-
-## Conflicts
-
-Disputes about spec interpretation go to the issue tracker. The maintainer resolves them by issuing a normative clarification (a commit to `SPEC.md`). Disputes about governance itself go to the working group at v1.0; before v1.0, they go to the maintainer.

package/ROADMAP.md

@@ -1,107 +0,0 @@
-# upact roadmap
-
-Last updated: 2026-05-01 (rev. 7 — v0.1.1 shipped: lifecycle + provenance, Phase C OIDC adapter, Dex integration tests).
-
-Open work for the v0.2 release window. Closed items are retained for institutional record.
-
-## Posture (load-bearing for everything below)
-
-upact is a self-binding contract for values-aligned platform builders. The privacy minima at the port — no email, no phone, no IP, opaque sessions, enumerated capabilities — are commitments the application has structurally given up the ability to violate. The architectural cost of later breaking the contract is what makes the commitment durable.
-
-upact is not a replacement for OIDC clients (`auth.js`, `lucia`, `openid-client`), identity-broker IDPs (Authentik, Keycloak, ZITADEL), or identity protocols (DIDs, Verifiable Credentials). It is the typed-contract layer above them.
-
-**Adapter strategy (Path B).** Enforcement-camp substrates with OIDC-shaped auth (Supabase, Mastodon, Auth0, etc.) consume upact via `@prefig/upact-oidc`, which delegates substrate-specific machinery to a substrate-side IDP (Authentik, ZITADEL, etc.). Pre-conforming substrates (SimpleX, Reticulum) use direct adapters. This split is reflected in `docs/adapter-shapes.md`.
-
-## Open
-
-### Decision 3 — `issueRenewal` semantics normative
-
-**Posture.** Supabase adapter renews the cookie holder (substrate-holder semantics); SimpleX adapter compares the freshly-read agentUserId against the prior `Upactor.id` and refuses renewal on mismatch (identity-bound semantics). Option A (identity-bound) is recommended per planning conversation — it is the more honest posture for a substrate where id stability is part of the contract.
-
-**Status.** Deferred in `SPEC.md §12` (D3) until divergence between adapters becomes a concrete consumer issue. The §6.4 wording remains advisory.
-
-### Decision 6 — `provenance` field on `Upactor`
-
-`provenance: { substrate: string; instance?: string }` for cross-substrate disambiguation. Shipped with the OIDC adapter (Phase C); concrete consumer: cross-IDP discrimination in multi-IDP deployments. Open question: whether Supabase and SimpleX adapters should also populate provenance for parity.
-
-### Decision 7 — `continuation` field on `Upactor`
-
-`continuation: { prior_id: string; kind: 'rotation' | 'migration' | 'rekey' | 'reauth' }` for substrate-known identifier transitions. No shipped substrate currently emits transitions through the port. Reactivated when AP `Move`, SimpleX rotation, or similar arrives with a shipped adapter.
-
-### Decision 8 — `watch` on `IdentityPort`
-
-`IdentityPort.watch(context): AsyncIterable<Upactor | null>`. Push-shaped substrates need an adapter first; the streaming-primitive choice (AsyncIterable vs Observable vs callback) deferred until a concrete push substrate ships.
-
-### v0.2 conformance test suite
-
-**Posture.** A published conformance test suite (referenced in `SPEC.md §9` as "TBD") that adapter authors run to claim conformance mechanically. Currently only the sixteen-vector reflection test is standardised; the rest of the conformance bar is prose.
-
-**Status.** Targeted for v0.2. Funding (OSA) would accelerate this.
-
-## Closed
-
-### v0.1.1 (2026-05-01)
-
-**Shipped.** OIDC adapter (Phase C), lifecycle + provenance spec amendments, Dex integration test suite.
-
----
-
-### Phase C: `@prefig/upact-oidc` adapter
-
-**Closed 2026-05-01.** Third reference adapter shipped: enforcement-camp, OIDC-shaped. `createOidcAdapter(config, cookies)` factory — closure-captured cookie jar, no enumerable substrate state. PKCE (S256) + authorization-code flow, signed-cookie state and session management, transparent refresh on expiry, HMAC-SHA256 signed cookies. Scope policy enforces `email`/`phone`/`address`/`groups` exclusion at construction time. 75 unit tests + 11 Dex integration tests. Permanent Dex dev rig at `upact-oidc-poc/`.
-
-### Decision 9 (close) — `issueRenewal` normatively OPTIONAL
-
-**Closed 2026-05-01.** See above; moved from Open.
-
-### `lifecycle` + `provenance` on `Upactor` (v0.1.1 spec amendment)
-
-**Closed 2026-05-01.** Optional `lifecycle?: IdentityLifecycle` and `provenance?: { substrate: string; instance?: string }` added to `Upactor`. `IdentityLifecycle = { expires_at?: Date; renewable: 'reauth' | 'represence' | 'never' }`. Purely additive — existing adapters continue to work without populating these fields. The OIDC adapter populates both. Normative text in `SPEC.md §4.4` and `§4.5`.
-
----
-
-### v0.1.0 (2026-05-01)
-
-**Shipped.** First public draft of spec and runtime. All items below were completed as part of the v0.1.0 release window.
-
----
-
-### `Upactor` rename across the codebase
-
-**Closed 2026-05-01.** `UserIdentity` → `Upactor` throughout: `SPEC.md`, `src/types.ts`, `src/index.ts`, both adapter packages (`src/adapter.ts`, `src/identity-mapper.ts`, tests). Deprecated alias `UserIdentity = Upactor` retained for v0.1.x compatibility; removed at v0.2. Method `currentIdentity` → `currentUpactor` on the port.
-
-### Decision 4 — `AuthErrorCode` vocabulary normative in `§6.5`
-
-**Closed 2026-05-01.** Six-member normative union: `credential_invalid`, `credential_rejected`, `substrate_unavailable`, `identity_unavailable`, `rate_limited`, `auth_failed`. Both reference adapters declare their mapping table in `CONFORMANCE.md`. Applications branch on `code` for substrate-portable error handling.
-
-### Decision 11 — Adapter package back-channel closure (conformance bar)
-
-**Closed 2026-05-01.** Normative text added to `SPEC.md §7.5`: conforming adapters MUST hold substrate state in closure scope (factory pattern) or `#private` fields, not on enumerable instance properties. `(adapter as any).client` MUST return `undefined`. Both reference adapters (upact-supabase, upact-simplex) retrofitted to factory-only; `SupabaseUpactAdapter` and `SimpleXUpactAdapter` class forms removed. Both ship sixteen-vector back-channel reflection tests at `tests/back-channel.test.ts`.
-
-### `AI-Involvement` trailer convention
-
-**Closed 2026-05-01.** Five-tier vocabulary documented in `CONTRIBUTING.md` and `ROADMAP.md`. Adopted across the prefig org for subsequent commits. Existing commits pre-convention carry no trailer; the convention start point is the v0.1.0 release.
-
-### v0.1 SPEC authorship policy (relaxed)
-
-**Closed 2026-05-01.** The earlier commitment to a hand-rewritten normative spec before public push was relaxed for v0.1. `SPEC.md`, `src/types.ts`, and the runtime kernel ship with `AI-Involvement: authored` or `collaborative` trailer disclosure. The transparency posture (disclosure replaces authorship-purity as the binding mechanism) is consistent with the project's own values.
-
-### SPEC §6.2 amendment — `currentUpactor` throw permission
-
-**Closed 2026-05-01.** Adapters MAY throw `SubstrateUnavailableError` (from `@prefig/upact`) when the substrate is unreachable, distinct from returning `null` when the user is not authenticated. Normative text in `SPEC.md §6.2`.
-
-### Decision 2 — `currentIdentity` throw-vs-null contract
-
-**Closed 2026-05-01 (option C).** Typed `SubstrateUnavailableError` for substrate-down, `null` for logged-out. Both distinctions needed for quality UX without substrate coupling.
-
-### Decision 10 — Multi-step authentication flows at the port
-
-**Closed 2026-05-01.** IDP delegation (Path B) resolves multi-step auth without growing the port. The OAuth dance happens at a substrate-side IDP; the upact adapter consumes terminal OIDC tokens. The port stays one-shot.
-
-### Decision 1 — `OpaqueSubstrateSession._unwrap()` escape hatch
-
-**Closed 2026-05-01.** Lifted into `@prefig/upact` as `createSession` + `_unwrapSession`. Both reference adapters use `createSession`. Sixteen-vector opacity suite centrally maintained in `tests/runtime.test.ts`.
-
-### Decision 5 — Naming the central primitive
-
-**Closed 2026-05-01.** `UserIdentity` → `Upactor`. Draws on the UML Actor lineage; coined word in the upact namespace; no external collisions; brand cohesion. Lower-case bare word — `Upactor`, not `UpActor`.