@openvtc/trust-tasks 0.20.1 → 0.20.3

package/CHANGELOG.md

@@ -11,6 +11,116 @@ The package versions over **its own API** — what a consumer compiles against
 not over `SPEC.md`. Below 1.0 a breaking change bumps the leading non-zero
 component.
 
+## 0.20.3 — 2026-09-23
+
+
+### Added
+
+- **git-ns**: Add the git namespaces specification family (#621)
+
+* feat(git-ns): add the git namespaces specification family
+
+  A VTC can say today that a DID may sign commits for an org or a repo, and
+  nothing else about git: who owns a repository, who may create one, who may
+  merge and who may grant commit rights all live on the forge, and drift from
+  the VTC as soon as someone clicks a button. git-ns makes the VTC the source of
+  truth for all of it. Rights are per resource, not per role; the Trust Registry
+  is the published projection verifiers read, and the forge is the enforced one.
+
+  Five rights, spelled as the TRQP actions the VTC publishes them under:
+  git.ns.admin, git.repo.create, git.repo.own, git.repo.maintain and
+  git.commit.sign. Resources are forge-qualified and lowercase
+  (github.com/acme/widgets, codeberg.org/acme), so a right never crosses forges
+  and a community can host where it likes.
+
+  Member- and admin-facing tasks, addressed to the VTC:
+
+  - git-ns/namespace/bind, git-ns/namespace/unbind
+  - git-ns/repo/create, git-ns/repo/adopt, git-ns/repo/transfer,
+    git-ns/repo/archive
+  - git-ns/right/grant, git-ns/right/revoke
+  - git-ns/view
+  - git-ns/account/link, git-ns/account/link-status
+
+  git-ns/right/grant carries the family's rights model: implied rights, the
+  grant-authority table, and six fixed rules a VTC enforces in its own code
+  before policy runs, which policy can narrow and never loosen: scope
+  containment, no escalation, the last-owner invariant, a last-admin invariant,
+  the members-only floor for namespace rights, and policy-may-only-narrow. Each
+  refusal has its own error code, declared once at the family level (git-ns:*).
+
+  VTC <-> bridge tasks, for the per-community service that holds the forge
+  credentials and the forge adapters:
+
+  - git-ns/bridge/job — seven convergent, forge-neutral job kinds
+  - git-ns/bridge/result — exactly one per job, per-step outcomes
+  - git-ns/bridge/event — nine forge-neutral event types plus drift
+
+  Shared shapes (resources, namespaces, RepoSummary, RightRecord, drift) live in
+  git-ns/_shared/0.1.
+
+  Bindings regenerated for Rust, TypeScript, Go and Dart; conformance checks
+  agree. trust-tasks-rs gains a git-ns feature, in all-specs.
+
+## 0.20.2 — 2026-09-23
+
+
+### Added
+
+- **vtc/vetting/vetters/event-mode**: The exception to the constant drip (#620)
+
+A vetter's ordinary rate is a few tokens a tick, whether or not they have
+  vetted anyone. That is the right rate for ordinary weeks and the wrong one for
+  a conference desk, and the answer is deliberately not a bigger drip under the
+  same key: it is a separate token label for a named event, with its own rate,
+  its own expiry, and a group of vetters large enough that a spend under it still
+  hides one.
+
+  This task carries the vetter's half of that, which is only ever a request. The
+  approval is an act by someone else, through the community's own administrative
+  surface, and the specification says why there is no Trust Task for it: a task
+  the vetter could send is a task a vetter could be made to send.
+
+  The response says where the request stands, and carries a group *count* rather
+  than a group. Who else is at the event is the anonymity set, so the number is
+  the most a member may be told — enough to tell "nobody has approved it" from
+  "not enough people have asked", which are the two reasons a request waits.
+
+- **vetting/attestation**: The four tasks hidden-vetter admission needs (#618)
+
+* feat(vetting/attestation): the four tasks hidden-vetter admission needs
+
+  A community can hide which of its vetters vetted an applicant: the vetter
+  attests under a blind class credential, the applicant proves that k distinct
+  holders of one attested it, and the community counts the proof with the rule
+  it already counts named statements with. What was missing was the wire.
+
+  Four specifications, and the split between them is the design:
+
+  - vtc/vetting/vetters/pcs-root — a vetter enrols for a class label. The
+    community checks its own records (a live vetter grant, no credential under
+    this label yet, the identifier it was bound to) and signs a commitment it
+    cannot open. Being named happens here, once per label, and nowhere else on
+    the path.
+  - vtc/vetting/vetters/pcs-tokens — the vetter draws its tick of attestation
+    tokens, unconditionally and at a published rate. A draw that tracked demand
+    would report activity, which is what the exchange exists to hide; the quota
+    is the community's to enforce, never the asker's restraint.
+  - vetting/attestation — vetter to applicant, carrying the facts of the session
+    and no issuer. The delivering identity is deliberately NOT what makes it
+    count, and a consumer is told not to record it beside the attestation: that
+    would recreate, in the applicant's own store, the link the exchange removes.
+  - vtc/vetting/pcs-challenge — the applicant asks the community for the
+    single-use nonce its proof must bind. Without it a proof verifies as often
+    as it is submitted, and the second submission counts as readily as the first.
+
+  vetting/attestation declares identifierScope: any. Nothing in it needs a
+  reusable identifier — the community never sees the document, and the applicant
+  only needs the identifier the session was held under — so a pair that runs the
+  whole vetting exchange pairwise loses nothing.
+
+  Bindings regenerated for all four languages; conformance checks agree.
+
 ## 0.20.1 — 2026-09-23
 
 

package/dist/_shared/components.d.ts

@@ -128,6 +128,10 @@ export type DeviceAttestation_DeviceV0_1 = WebAuthnAttestation_DeviceV0_1 | Appl
  * Producer-supplied attestation at registration time, verifiable by the maintainer against the platform's attestation infrastructure. Tagged union over the discriminator `kind`.
  */
 export type DeviceAttestation_DeviceV0_2 = WebAuthnAttestation_DeviceV0_2 | AppleAppAttest_DeviceV0_2 | PlayIntegrity_DeviceV0_2 | Tpm_DeviceV0_2 | NitroEnclave_DeviceV0_2 | NoAttestation_DeviceV0_2;
+/**
+ * A DID, compared by exact string equality.
+ */
+export type Did = string;
 /**
  * A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.
  *
@@ -193,6 +197,14 @@ export type FaceReach = {
  * **Superseded by `WorldColour`** — the same set, under the name the rest of the family now uses. Retained because `persona/facet/*` is retired in favour of `persona/world/*`, and a retired specification's schema is frozen, so the definition it references has to stay. New work references `WorldColour`. A colour **name**, resolved by each consumer against its own palette — never a hex value or any other literal. Two reasons, and both are about the consumer rather than the holder. A literal cannot be legible in a terminal, in a light theme and in a dark one at once, so a stored `#8B0000` is a colour that is wrong somewhere and the holder has no way to know where. And a consumer that reserves colours to mean something — an error, a warning, an irreversible act — must be able to keep a holder's decorative choice out of that channel; it cannot do that with an arbitrary value, and it can do it trivially with a closed set it maps itself. The eight members are chosen to be distinguishable from one another and deliberately carry no status connotation: none is named for success, warning or danger.
  */
 export type FacetColour = "slate" | "indigo" | "teal" | "moss" | "sand" | "clay" | "rose" | "plum";
+/**
+ * The lowercased DNS host of a forge: `github.com`, a GitHub Enterprise Server host, `codeberg.org`, or a self-hosted Forgejo instance such as `git.example.org`. No scheme, no port, no path. The host is a segment of every resource, so a right never crosses forges.
+ */
+export type ForgeHost = string;
+/**
+ * An identifier the forge itself assigns — a repository id, a user or organisation id — carried as a string so a forge whose ids are not numbers needs no new version. GitHub and Forgejo ids are decimal integers written as strings (`"812736451"`). Unlike a name, it survives renames and transfers, which is why rights and bindings are keyed by it.
+ */
+export type ForgeId = string;
 /**
  * The highest version among the records `DataCommitment` covers. `0` for a room that holds none.
  *
@@ -241,6 +253,10 @@ export type LanguageTag = string;
  * Scopes one application's records within a context, so several tools can share a context without colliding — `openvtc`, `cnm`, an agent runtime. The maintainer MUST NOT interpret the value; it is an opaque partition name. Namespaces are first-come and unreserved, so an application SHOULD pick a stable, specific one: a future per-namespace ACL would grant on this exact string, which makes renaming a namespace a migration rather than an edit.
  */
 export type Namespace = string;
+/**
+ * The VTC's opaque identifier for a namespace, assigned when it is bound. Stable for the life of the binding; never reused for another binding.
+ */
+export type NamespaceId = string;
 /**
  * A region or city name as the vetter writes it. Compared case-insensitively and otherwise exactly.
  */
@@ -409,10 +425,26 @@ export type RecordType = "authorization" | "recognition";
  * Absent means *not decided by the holder* and resolves from the claim-type registry, which defaults `payment.*` and `gov.*` to `stepUp`.
  */
 export type ReleaseRequirement = "consent" | "stepUp";
+/**
+ * A forge-qualified resource naming exactly one repository: `<forge-host>/<owner>/<repo>`, lowercase.
+ */
+export type RepoResource = string;
+/**
+ * Repository visibility on the forge.
+ */
+export type RepoVisibility = "public" | "private";
+/**
+ * A forge-qualified resource: `<forge-host>/<owner>` for a namespace, or `<forge-host>/<owner>/<repo>` for one repository, all lowercase — `github.com/acme`, `github.com/acme/widgets`, `codeberg.org/acme`. The forge is never implied: `acme/widgets` alone is not a resource. Containment is by whole segment: `github.com/acme` contains `github.com/acme/widgets` and does not contain `github.com/acme-labs/x` or `codeberg.org/acme/widgets`.
+ */
+export type Resource = string;
 /**
  * Whether a room keeps its history readable across a membership change, fixed at creation and immutable thereafter — like `Visibility`, and for the same reason: the rungs of an epoch key chain either exist for an epoch or they do not, and no later change of mind can seal key material that was never sealed or unseal what was already severed. `chained`: each advance produces an `EpochLink`, so every member reads the room's whole retained history however long they have been in it — what a **library** wants, at the cost of post-compromise security for record content, since a compromised current key then reaches every retained epoch. `fromJoin`: no rungs are produced, so a member reads only from the epoch their group state is at — what a **stream** wants, and what a room under a strict forward-secrecy obligation wants, at the cost that a joining member finds an empty-looking room and nobody can reread a record once their group state has moved past the epoch it was sealed under. Absent means `chained`; see the prose on why the absent case is the readable one.
  */
 export type RetentionPolicy = "chained" | "fromJoin";
+/**
+ * One of the five git rights. Each string is also the TRQP `action` the VTC publishes the right under in its Trust Registry, so it is carried verbatim. `git.ns.admin` and `git.repo.create` apply to a namespace resource; `git.repo.own` and `git.repo.maintain` to a repository resource; `git.commit.sign` to either.
+ */
+export type Right = "git.ns.admin" | "git.repo.create" | "git.repo.own" | "git.repo.maintain" | "git.commit.sign";
 /**
  * How a consent prompt reaches the approver: `wake` pushes to the approver's device for a DID-signed decision; `bridge-relay` renders it through an enrolled bridge (e.g. a numbered card in the operator's messaging app) for a bridge-attested decision.
  */
@@ -457,6 +489,10 @@ export type SecretKind_VaultV0_1 = "password" | "passkey" | "oauth-tokens" | "di
  * - `custom` — arbitrary structured fields; release-time consumer responsible for interpretation.
  */
 export type SecretKind_VaultV0_2 = "password" | "passkey" | "oauthTokens" | "didSelfIssued" | "didcommPeer" | "bearerToken" | "sshKey" | "custom";
+/**
+ * One lowercased owner or repository name. Forges compare these case-insensitively, so the wire form is always lowercase and a producer lowercases before sending. A leading `.` is refused, which rules out `.` and `..`.
+ */
+export type Segment = string;
 /**
  * How carefully a value is shown TO ITS OWN HOLDER. `high` means a consumer masks it by default, reveals it one attribute at a time on a deliberate act, and — the half that is not cosmetic — omits it from a listing that did not ask for sensitive values.
  *
@@ -1245,6 +1281,27 @@ export interface BackupEnvelope {
      */
     ciphertext: string;
 }
+/**
+ * Whether each step that turns commit trust on for a repository is in place, as last reported. A step that this forge's plan does not need reads `true`.
+ */
+export interface Bootstrap {
+    /**
+     * The verify-trust check runs on the repository's pull requests — from a workflow committed to it, or, where the forge supports it, required on it from the namespace's own bridge-managed workflow repository at a pinned commit.
+     */
+    workflow: boolean;
+    /**
+     * The exempt platform keyring for forge-signed merge commits is committed, or the forge's plan does not need one.
+     */
+    keyring: boolean;
+    /**
+     * The repository names the Trust Registry and this VTC as its trust anchors.
+     */
+    variables: boolean;
+    /**
+     * The forge refuses to merge into the default branch unless the verify-trust check passes, with no bypass, and a pull request cannot change what that check runs: an organisation-required workflow, code-owner review of workflow files, or protected workflow paths, as the forge allows.
+     */
+    requiredCheck: boolean;
+}
 /**
  * The self-description of a pluggable community capability: the Trust Task families it serves, the trust-registry vocabulary it reads and writes, the roles that may operate it, the membership lifecycle hooks it consumes, and the external adapters that act on its decisions. The manifest is what governance approves, what discovery advertises, and what a management UX renders.
  */
@@ -2237,6 +2294,28 @@ export interface DrainEntry {
     drainsUntil: string;
     ext?: Ext;
 }
+/**
+ * One difference between the forge's observed state and the VTC's projection of a repository.
+ */
+export interface DriftItem {
+    /**
+     * `roleAdded` — someone holds a forge role the projection does not give them. `roleRemoved` — a projected role is missing. `roleChanged` — a projected role is present at another level. `requiredCheckMissing` — the verify-trust check is no longer required. `protectionWeakened` — branch protection or a ruleset is weaker than the projection in another way (force-push allowed, bypass actors added). `bootstrapMissing` — a bootstrap file or variable is gone.
+     */
+    type: "roleAdded" | "roleRemoved" | "roleChanged" | "requiredCheckMissing" | "protectionWeakened" | "bootstrapMissing";
+    resource: RepoResource;
+    /**
+     * Whose role differs, for the three role types.
+     */
+    account?: ForgeAccount;
+    /**
+     * What the forge shows, in the forge's own vocabulary (a role name such as `maintain`, a setting name). Absent when nothing is there.
+     */
+    observed?: string;
+    /**
+     * What the projection calls for, in the forge's own vocabulary. Absent when the projection calls for nothing.
+     */
+    expected?: string;
+}
 /**
  * One consequence of executing the pending task, authored by the executor that is about to run it. An effect is produced by dry-running the real handler against the executor's own prior state — never by the requester, and never by re-implementing the handler's semantics elsewhere. A consent surface renders ONLY effects it received under the executor's signature.
  */
@@ -2395,6 +2474,40 @@ export interface Exposure {
 export interface Ext {
     [k: string]: unknown | undefined;
 }
+/**
+ * A person's account on one forge. `id` is authoritative; `login` is for display only, because logins can be renamed and re-registered.
+ */
+export interface ForgeAccount {
+    forge: ForgeHost;
+    id: ForgeId;
+    /**
+     * The account's current login, as the forge reported it when last seen. Display only.
+     */
+    login: string;
+}
+/**
+ * The VTC's binding to one owner on one forge.
+ */
+export interface GitNamespace {
+    id: NamespaceId;
+    forge: ForgeHost;
+    /**
+     * The organisation or user on the forge, lowercased.
+     */
+    owner: Segment;
+    /**
+     * Whether the owner is an organisation or a personal account, as the forge reports it. Present once known: a bridge-mode namespace learns it when binding completes, and a manual-mode namespace MAY never learn it.
+     */
+    kind?: "organization" | "user";
+    /**
+     * `bridge` — a bridge service acts on the forge for this namespace (creates repositories, projects roles, reports drift). `manual` — no automation; people with forge access carry out the steps the VTC names, and the VTC governs the rights alone.
+     */
+    mode: "bridge" | "manual";
+    /**
+     * `pending` — binding has started and the forge-side proof has not arrived yet. `bound` — the VTC governs rights under this namespace.
+     */
+    state: "pending" | "bound";
+}
 /**
  * OpenPGP-style ASCII-armored HPKE bundle — the existing OpenVTC sealed-transfer wire form (X25519-HKDF-SHA256 KEM + ChaCha20-Poly1305 AEAD, framed in armor with Bundle-Id / Digest-Algo headers and a CRC24 checksum). Producer assertion (`did-signed` / `attested` / `pinned-only`) is the integrity / authenticity anchor.
  *
@@ -3652,6 +3765,27 @@ export interface RejectedKey {
      */
     reason: string;
 }
+/**
+ * One repository as the VTC records it.
+ */
+export interface RepoSummary {
+    resource: RepoResource;
+    /**
+     * The forge's repository id. Absent until the forge has confirmed the repository exists (a `pendingCreate` repository, or one adopted in bridge mode before the first inspection).
+     */
+    forgeId?: ForgeId;
+    visibility: RepoVisibility;
+    /**
+     * `pendingCreate` — the name is reserved and the repository is not yet confirmed on the forge. `active` — managed. `archived` — archived through git-ns/repo/archive; commit rights on it are revoked. `detached` — no longer governed: its namespace was unbound, or it moved outside the namespace. `orphaned` — its last owner left the community and ownership passed to the namespace admins, who have not yet named a new owner. `unmanaged` — it exists on the forge inside a bound namespace but was never created or adopted through the VTC.
+     */
+    state: "pendingCreate" | "active" | "archived" | "detached" | "orphaned" | "unmanaged";
+    /**
+     * The DIDs holding `git.repo.own` on this repository by an explicit grant. Empty only for an `unmanaged` repository, and for an `orphaned` one whose ownership rests with the namespace admins by implication.
+     */
+    owners: Did[];
+    bootstrap: Bootstrap;
+    sync: Sync;
+}
 /**
  * One held credential a deferred query asked for, and the claims of it that would be disclosed.
  */
@@ -3727,6 +3861,30 @@ export interface RevocationReceipt {
      */
     revokedAt: string;
 }
+/**
+ * One recorded right. Implied rights (§4.2 of the rights model: `own` implies `maintain` implies `commit.sign` on the same resource; `ns.admin` implies `repo.create` and `own` across its namespace) are not records and never appear as RightRecords.
+ */
+export interface RightRecord {
+    /**
+     * Who holds the right. For `git.commit.sign` this is the DID whose commit signatures the CI check accepts.
+     */
+    subject: Did;
+    right: Right;
+    resource: Resource;
+    /**
+     * The actor whose task caused the right: the granter, the creator of a repository (for its first `own`), the adopting admin, the transferring owner, or the binding admin (for the first `git.ns.admin`). The VTC's own DID for a right it derives from its configuration.
+     */
+    grantedBy: Did;
+    grantedAt: string;
+    /**
+     * When the right lapses. Absent: no expiry.
+     */
+    expiresAt?: string;
+    /**
+     * The granter's free-text reason. Disclosed only to holders of `git.repo.own` on the resource and of `git.ns.admin` over it.
+     */
+    reason?: string;
+}
 /**
  * The outcome of a rollback. Distinct from ServiceMutationResult because a rollback can legitimately publish nothing: if the previous state already equals the current one there is no change to write, and `kind: "noOp"` says so with `logEntryVersionId` absent. Treating that as a failure would be wrong — the requested state holds — and treating it as an ordinary success would report a log entry that does not exist.
  */
@@ -4026,6 +4184,23 @@ export interface StreamDescriptor {
     expectedSizeBytes: ExpectedSizeBytes;
     expiresAt: ExpiresAt;
 }
+/**
+ * How the forge compares with the VTC's projection for one repository.
+ */
+export interface Sync {
+    /**
+     * `inSync` — the last comparison found no drift. `drift` — it found some, listed in `drift`. `pending` — a change has been sent to the forge and not yet confirmed. `unchecked` — nothing compares this repository (a manual-mode namespace).
+     */
+    state: "inSync" | "drift" | "pending" | "unchecked";
+    /**
+     * When the forge was last compared. Absent if never.
+     */
+    checkedAt?: string;
+    /**
+     * Outstanding drift. Empty unless `state` is `drift`.
+     */
+    drift: DriftItem[];
+}
 /**
  * An access token (typically short-lived JWT) paired with an optional refresh token (typically long-lived opaque string). The shapes follow OAuth 2.0 (RFC 6749 §5.1) conventions but are not coupled to any particular OAuth profile.
  */