@openvtc/trust-tasks 0.26.15 → 0.26.17

package/CHANGELOG.md

@@ -11,6 +11,110 @@ 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.26.17 — 2026-10-18
+
+
+### Added
+
+- **vtc/rooms/memberships**: List — every surface shows a member the same rooms, and finishes an acceptance any other began (#813)
+
+A member reaches their community from several surfaces (member portal via
+  the wallet, a terminal client, a phone). Each could see only the offers
+  open now or accepted within the repeat window, so a room taken up in one
+  was missing from the others after it; and an acceptance one surface began
+  could be finished by no other, because every other minted a different
+  KeyPackage and was answered alreadyAccepted.
+
+  - vtc/rooms/memberships/list 0.1 (new): the community's own record of the
+    caller's admissions to rooms it owns — offered, admitted or removed — for
+    as long as it keeps the record, with no credentials. repeatAcceptUntil
+    says while the Welcome is kept. Defines how a surface combines it with
+    rooms/keys/list (custody) so every surface derives the same state, and
+    forbids a surface keeping its own record of acceptance.
+  - rooms/keys/key-package 0.2: returns the outstanding KeyPackage for the
+    same room, member and invitation (alreadyMinted: true, original
+    expiresAt) instead of minting another; invitation and expiresAt
+    required. Mint, accept and Welcome now each answer a repeat with their
+    first answer.
+  - rooms/keys/act 0.5: adds vtc/rooms/memberships/list/0.1 to the table
+    beside the offer types (act 0.4, #810), on their terms, as "the
+    community types"; widens the type pattern to vtc/rooms/memberships/;
+    KeyPackages from key-package 0.1 or 0.2. A new version, not an edit to
+    0.4: the closed table admits a type 0.4 refuses.
+  - vtc/_shared/0.1/community-room: RoomMembership.
+  - vtc/rooms/offers/list 0.2, offers/accept 0.1: informative cross-links.
+
+  Bindings regenerated (Rust, TS, Go, Dart); additive modules only.
+
+## 0.26.16 — 2026-10-17
+
+
+### Added
+
+- **vtc/community/theme**: Show and update — a community's own stylesheet for its console and member portal (#811)
+
+* feat(vtc/community/theme): show and update — a community's own stylesheet for its console and member portal
+
+  A community could set an accent colour and a logo (vtc/community/branding),
+  and nothing else about how its pages look. Administrators want to restyle
+  their console and member portal at run time, without the operator-only
+  admin_ui directory mode.
+
+  vtc/community/theme/update/0.1 (new, draft):
+  - An administrator replaces one stylesheet; the empty string removes it.
+    Proof and issuedAt REQUIRED; audited by digest, never by text.
+  - `dryRun: true` checks and answers with what would be stored, storing
+    nothing, so a client can preview a theme exactly as stored.
+  - The theme profile (P1-P8): design tokens on :root (light/dark), plus a
+    small set of cosmetic properties on ordinary elements — colours,
+    gradients, bounded borders/radius, font family/weight. No url()/@import/
+    @font-face (a theme loads nothing), no !important, no escapes or `<`, and
+    nothing that can move, size, hide, overlay or add content.
+    `outsideProfile` names the line, column and profile item broken.
+  - maxDocumentBytes 48 KiB both ways, for a 32 KiB stylesheet.
+
+  vtc/community/theme/show/0.1 (new, draft):
+  - Proof OPTIONAL and answerable to an unidentified caller: sign-in pages
+    draw the theme before the visitor holds any identity.
+  - Client requirements: re-check the profile before applying; render every
+    surface where a person decides, approves, consents, signs or is warned
+    in structural isolation from the theme; mark that a custom theme is on.
+
+  Why no second-administrator consent: the profile and the isolation
+  together mean a theme cannot change what another administrator is asked
+  to approve, so it stays an ordinary configuration write.
+
+  Bindings regenerated (Rust, TS, Go, Dart).
+
+
+
+### Specifications
+
+- **rooms/keys**: Act 0.4 — a member lists their offers at vtc/rooms/offers/list 0.2, and sees what each room is for (#810)
+
+rooms/keys/act/0.3's closed table admits vtc/rooms/offers/list/0.1 but not
+  vtc/rooms/offers/list/0.2 (#805), which shows each offered room's current
+  label and description (never its tags). A key holder conforming to act 0.3
+  refuses a 0.2 listing with typeNotActable, so a surface that reads offers
+  through act — pnm, the browser wallet — cannot use 0.2, and a member never
+  sees a room's description before accepting.
+
+  act 0.4:
+  - The table's offers/list row lists vtc/rooms/offers/list/0.1 and
+    vtc/rooms/offers/list/0.2 on the same terms: no presentation inserted,
+    issuer REQUIRED and the DID the offer is addressed to (Producer item 2),
+    resolved without a room credential (Recipient item 2b, which now names
+    list/0.2 too).
+  - New "What changed from 0.3" note; a request example completing a
+    list/0.2 as the member.
+  - Schemas otherwise identical to 0.3 (the type pattern already admits
+    vtc/rooms/offers/); no error code added. vtc/rooms/offers/accept has only
+    0.1, so nothing changes for it.
+
+  vtc/rooms/offers/list/0.2, in place: its "Signing as the member" paragraph
+  pointed at act "0.3 or later", which does not list it; it now points at
+  act 0.4. Prose only; its wire is unchanged (SPEC §5.2 editorial, as #797).
+
 ## 0.26.15 — 2026-10-17
 
 

package/dist/_shared/components.d.ts

@@ -8134,6 +8134,41 @@ export interface RoomMember {
     admittedAt?: string;
     removedAt?: string;
 }
+/**
+ * What vtc/rooms/memberships/list/0.1 returns: one room the community owns, and where the caller's admission to it stands in the community's own record. Unlike `OfferV2` it carries no credentials — those are collected with vtc/rooms/offers/list while an offer is open — and it is listed in every state, for as long as the community keeps the record, not only while an accept can be repeated. `label` and `description` are the room's as they stand when the record is read.
+ */
+export interface RoomMembership {
+    roomId: string;
+    /**
+     * The room's host: this community.
+     */
+    host: string;
+    label: RoomLabel;
+    /**
+     * Absent when the room has none.
+     */
+    description?: RoomDescription;
+    visibility: Visibility;
+    actions: MemberActions;
+    /**
+     * When the member's authority credential expires.
+     */
+    validUntil: string;
+    state: MemberState;
+    offeredAt: string;
+    /**
+     * When the community recorded the admission. Present when `state` is `admitted`, and kept when it becomes `removed`.
+     */
+    admittedAt?: string;
+    /**
+     * Present exactly when `state` is `removed`.
+     */
+    removedAt?: string;
+    /**
+     * On an `attributed` or `private` room in state `admitted`: until when the community keeps the Welcome, so that a repeated vtc/rooms/offers/accept carrying the same KeyPackage is answered with it. Absent on an `open` room, in any other state, and once the community no longer keeps it. A surface finding the member admitted but the room absent from its key holder's rooms/keys/list finishes the acceptance before this time, and asks an administrator to re-admit the member after it.
+     */
+    repeatAcceptUntil?: string;
+}
 /**
  * What a room says about itself to its own members: a name and, optionally, a description, short tags and an emoji, so that a member's wallet, portal or CLI can show what each room is rather than a DID.
  *