# Data, reliability and operations

Document: SPEC-006. Revision: 0.7. Date: 2026-10-21. Lifecycle: Partially approved under delegated decision D-024; V1 resolution sections are active, later scope remains Draft. Supersedes: none.

This document proposes behaviour supporting the confirmed messaging, whiteboard, federation, serverless, and independent-hosting requirements. Retention durations, capacity, operating budget, and enterprise controls remain OPEN.

## Logical-server records and hidden channel history (D-227/D-228)

[SPEC-028](028-developer-api.md) adds durable logical-server/channel/membership records without changing shared account IDs or message tables. The first stored logical server or non-visible message advances the marker to schema 10; successor servers support both 9 and 10, and predecessor servers refuse 10. Root and logical messages share existing retention/storage quotas. Bounded history pages advance across controls omitted from default presentation; opt-in API reads preserve membership intervals and original expiry. Current authorization is required before command-result replay.

## Conversation extension — 2026-10-19

D-068 adds persistent conversation replies under [SPEC-013](013-conversations.md). Signed reply references survive ordinary history/recovery delivery while preserving retention and membership intervals. An unavailable original never grants permission to fetch older text.

## Durable and transient state

D-088 selects retained text for the new temporary-group type after its voice session ends: configurable duration, default four hours, maximum one year. [SPEC-018](018-direct-conversations.md) defines the D-090-approved per-message expiry, read-only closed history and versioned device/recovery-copy extension implemented in alpha.11. This is a scoped exception to the ordinary seven-day horizon; channel/DM retention is unchanged.

| Data | Proposed treatment |
| --- | --- |
| Accounts, memberships, permissions, room settings | Durable authoritative records with revisions |
| Membership intervals and permission evidence | Ordered admission/removal positions and authenticated historical authorisation sufficient for permitted replay; revocations must survive the supported recovery procedure |
| Messages and edits/deletion events | Durable within declared retention policy; encrypted payloads stay opaque in E2EE conversations |
| Attachments and whiteboard snapshots | Access-controlled object storage with retention and reference tracking |
| Voice attendance and presence | Expiring state with reconnect reconciliation |
| Typing and live cursor movements | Transient; do not replay stale activity after reconnect |
| Live media | Forwarded; recording requires a separately approved feature and visible policy |
| Administrative audit events | Durable, access-controlled records with a defined retention policy |
| Federation delivery jobs | Durable retryable work with deduplication, expiry and terminal failure |

Never rely on a worker process staying alive or on process-local memory as the only copy of accepted durable state. After suspension or restart, reconstruct state and resume delivery. Idle persistent rooms need not retain active media resources.

## People sidebar data (D-071)

SPEC-014 owns saved-contact records and the client-local recent-person limits. Contacts persist until removal; they are private account metadata, not message content or an E2EE guarantee against the home operator. Recent entries remain in protected per-account client storage and are not copied by device linking/recovery.

## Messaging delivery

Proposed semantics: at-least-once transport delivery with stable event/request IDs and idempotent effects. Do not promise exactly-once network delivery. A host acknowledges acceptance only after the required durable commit.

An accepted mutation durably records its state change, result identity and required delivery/propagation work as one recoverable operation. Recovery discovers every committed but incomplete effect. A transactional outbox is a candidate, not a selected storage dependency; a design spanning transaction boundaries must specify equivalent recovery states. External adapter calls use stable operation identities and reconcile ambiguous outcomes. An API timeout is not evidence of rollback; a caller must be able to retrieve an operation's authorised result or retry it safely.

Bind each idempotency identity to the authenticated actor, resource scope and canonical request fingerprint. Reuse with changed content is a conflict. Retrying an accepted operation returns its permitted existing result without reapplying the effect; revocation may restrict result disclosure but cannot erase idempotency protection. Admission of genuinely new operations rechecks current authority. Define a bounded command-validity protocol or durable uniqueness/tombstone scheme before implementation. Result-cache expiry alone must never turn an old request into a new command. If the result is unavailable outside the valid retry period, return an explicit expired/unknown-result outcome without repeating the mutation. The authority and binding of command timestamps/validity must prevent a replay extending that interval.

The room host supplies ordering within its authoritative stream; there is no global federation order. Define concurrent edits, deletions, membership changes, and policy changes relative to that stream. Sender timestamps are presentation data, not authority to reorder permissions.

On reconnect, use a bounded resume cursor. If the cursor has expired, resynchronise a snapshot plus permitted history. Clients display pending, accepted, failed, and retried messages distinctly. Queueing while offline is proposed; recheck destination membership, policy and encryption epoch before admitting queued content as a new event. Re-encrypt or reject stale-epoch unsent content under SPEC-003. Never silently generate a new operation identity after an ambiguous send outcome; reconcile the original first.

Direct-message routing must work while a recipient device is offline, subject to an explicit expiry/retention policy. Ciphertext can be queued at a home domain; device fan-out and acknowledgements need a selected protocol. Revoked devices must not receive new keys merely because an old delivery job exists.

## History, deletion and attachments

CONFIRMED D-016/D-023: first-time members see text from admission onward. After a member leaves or is removed and is later admitted again, the host permits fetching retained messages from their earlier membership periods plus the current period, excluding every absence. Represent each period by committed admission and removal positions in the room host's authoritative stream; use an exclusive removal boundary. Sender timestamps cannot move content across those boundaries. A reconnect that preserves persistent membership does not open a new period.

Proposed retrieval rule: current room membership and current read permission are required for new host retrieval. Leaving/removal stops new host delivery; already downloaded copies are not erased. On re-admission, historical eligibility is the union of recorded membership intervals, still subject to retention, redaction and current rights. These are fixed V1 access-bundle semantics rather than independently configurable history controls. Identity reassignment must not transfer another account's membership periods.

Apply eligibility to pagination, resume, search, snapshots and exports. A message's creation position and any content-bearing revision delivered to the member must both fall in eligible periods. A later edit cannot expose a message created before first admission or during an absence; do not substitute an ineligible latest revision into an otherwise eligible message. Where supported, reconstruct the last eligible revision or omit unavailable content. Redaction/deletion may suppress otherwise eligible content without disclosing new plaintext from an absence. Edits/deletion, search and exports remain later scope, but their implementations must preserve these boundaries.

Encrypted history additionally requires retained keys for the permitted periods. Re-admission supplies future group membership, not keys for the absence. D-022 accepts unrecoverable older encrypted history in V1 after loss of the only device/keys; ciphertext eligibility does not override that limitation. Any later recovery/transfer contract must preserve interval boundaries. An authorised member can deliberately copy or quote content into a new message; history access control does not prevent participant disclosure.

Recommended deletion semantics: remove/redact content from the host's active views and propagate a deletion event to conforming replicas/caches. State that recipients, exports, backups, and foreign operators may retain earlier copies. Retention policy cannot guarantee erasure from devices beyond the operator's control.

Use bounded upload sizes, quotas, content-type validation, private URLs, and expiring access. For E2EE attachments, encrypt bytes and private metadata before upload; content keys remain in the encrypted conversation. Previews, filenames, and thumbnails must not leak through an otherwise encrypted attachment flow. Server malware scanning cannot inspect encrypted bytes; clients still need safe handling.

Search in server-readable rooms is scoped to the requesting user's current history rights. Encrypted search is performed on authorised client data unless a separately reviewed mechanism is adopted. Do not upload plaintext indexes as an implementation shortcut.

## Collaborative whiteboards

Whiteboards are required for meetings. Proposed first feature set: freehand strokes, text, basic shapes, selection/move/delete, participant cursors, and export. Images, templates, infinite canvas, and presentation slides are scope questions.

A board belongs to a room and inherits its access/security mode. Separate view, draw, edit-others, clear, and export permissions. Concurrent changes need a specified convergence algorithm, stable operation IDs, bounded operations, snapshots, and replay after disconnect. CRDT and host-ordered operations are candidates, not selected implementations.

For E2EE boards, encrypt operations and snapshots client-side. The server can enforce admission, sender permissions, message sizes, and rates from authenticated outer metadata; it cannot safely inspect opaque object ownership or validate the decrypted board itself. Clients must validate decrypted operations against authenticated actors and the relevant permission state. Resolve malicious-object edits, authorisation races, snapshot trust, and recovery before implementation.

The host supplies authenticated authorisation evidence tied to actor, resource, permitted action/constraints, operation identity and relevant host position or policy revision. Clients verify that evidence and the shared decrypted-object rules; they do not independently choose server-role precedence. Evaluate historical operations against the evidence valid at their accepted position, not today's role assignment. Missing/invalid evidence cannot be treated as permission. Define evidence retention and verification, permission-change ordering, snapshot provenance and convergence before choosing the board algorithm. Evidence must not require exposing the encrypted object content to the server. SPEC-008 owns evidence issuance; SPEC-005 consumes the shared validation contract.

Removing a participant stops future delivery and key access; it does not remove their exported board. Board persistence after a meeting and whether history is available to late joiners remain open.

## Operator independence

Publish deployment instructions covering DNS/TLS, domain discovery, first-admin bootstrap, secrets, storage, media, backups, upgrades, recovery, and federation troubleshooting. Provide documented configuration and protocol conformance tests alongside source.

Proposed portability gate: demonstrate the same clients and federation behaviour against the Cloudflare reference deployment and one independent alternative deployment. Demonstrate managed and self-hosted media. The second control platform, hosting formats, and exact release gate need approval.

Backups include metadata, objects, configuration, and server signing identity as appropriate, with protected secrets and restore procedures. A restore must not silently resurrect revoked sessions or publish stale membership. Operator backups do not include user plaintext encryption keys unless the user deliberately stores an encrypted recovery backup.

Proposed recovery contract: distinguish process/invocation restart from disaster restore. Restart preserves acknowledged durable state; disaster recovery states an approved recovery-point objective (permitted data-loss window) and recovery-time objective. An older snapshot alone is not evidence of current membership, device trust or revocations.

Before restored authority serves requests, invalidate pre-restore sessions and active media grants using an authority-generation change or equivalent mechanism that cannot itself roll back with the snapshot. Reconcile revocations and membership intervals against a durable source outside the supported rollback window. Rotating authentication credentials alone does not repair stale membership. If current authority cannot be established, keep affected accounts/rooms closed until an explicit recovery procedure establishes valid membership, trust and encryption epochs. Ensure an old deployment cannot remain a competing authority. The generation fencing, revocation source, retention and recovery procedure remain OPEN and must be selected before backup/restore conformance is claimed.

Keep accepted content recovery and authority recovery distinct: the declared data-loss window does not authorise restoring removed participants. Recovery tests must include post-snapshot revocations, existing media paths and unavailable recovery journals, not only a fresh backup of unchanged state.

## Reliability and cost

Publish capacity limits per room/domain/media provider. Enforce quotas on storage, uploads, concurrent streams, fan-out, federation retries, and API calls. Define overload and partial-failure behaviour; reject new expensive work before disrupting established voice where feasible.

Separate media usage from control-service/storage costs. Estimate budget from participant-hours, forwarded media bytes, region/egress, attachment retention, and connection activity. Do not imply “serverless” means free or no ongoing resource consumption.

Measure voice delay, jitter, loss, media establishment, reconnects, permission revocation, message acceptance, federation queues, and resource spend. Proposed telemetry excludes private content and is documented with retention and access rules. Local diagnostics must make redaction reviewable before sharing.

If the control service loses authority while media continues, the active forwarding lease in SPEC-003 bounds continuation. On expiry, the media service stops the affected forwarding even if its connection was admitted earlier. Renewal rechecks current authoritative policy; admission-token expiry alone is insufficient. SPEC-008 defines enforcement outcomes. Select this hard interval separately from the normal-operation latency percentile, balancing bounded unauthorised continuation against transient-outage tolerance.

## Moderation and enterprise scope

Proposed baseline: block/report users, refuse unsolicited direct requests, remove/ban participants, invite expiry, rate limits, and operator domain allow/deny policy. A federation protocol accepts foreign identities, not their trustworthiness.

Corporate deployment may need SSO, provisioning, retention, export, legal hold, managed clients, and regional data controls. These are not implied by the initial corporate-use goal. Server-readable rooms can support operator processing if specified; mandatory E2EE direct communication must not gain hidden escrow to satisfy an enterprise integration.

Recording/transcription are unapproved candidates. If introduced, define who can initiate them, visible participant status, endpoint access, retention, and applicable consent policy. The product cannot prevent participants using external recording tools.

## Linked history and recovery data (D-059/D-060; SPEC-011)

D-044 requests the same readable history where feasible; D-045 requires recovery using a separate secret. Apply history entitlement to the account across all approved devices. Adding a device is not a new room admission and cannot widen the account's membership intervals. Preserve current-membership checks and the union of eligible admission periods, excluding absences, for transfer, backup retrieval and restore as well as ordinary history pages. Already downloaded content cannot be recalled.

For future messages, encrypt to every approved text recipient, including offline devices, under the approved successor profile. Fetch retained ciphertext independently when a device reconnects. For older messages, transfer only history a trusted device can actually decrypt, using an authenticated end-to-end channel addressed to the approved destination. The current V1 client has no durable transcript archive; do not assume an offline device has a complete local copy. V1 ciphertext addressed only to a lost private key remains unrecoverable.

Preserve original host ordering, message identity, sender/device and membership evidence; resume interrupted transfers without duplicate chat entries. New messages may arrive while history transfers, so completion needs an authenticated coverage boundary and explicit gaps. A legacy decrypted transcript re-encrypted by another device has that device's transfer attestation, not a new proof of the original sender's plaintext. Do not mislabel it as directly verified under the original ciphertext signature. SPEC-011 defines the successor envelope/history proof format under Q-42/Q-44.

Keep an encrypted recovery copy independent of all endpoint disks. It must contain enough authenticated content/key material to restore covered history with the user's recovery secret, not merely a list of ciphertext IDs. Show last successful coverage, gaps, storage/transfer failure and recovery readiness. Retain the current seven-day message horizon from host acceptance; copying a message must not reset its expiry. A longer account archive is a separate policy choice, not implied by shared history. SPEC-011 fixes retention/quota and copies readable eligible old messages on explicit setup/link or repeat-copy; future messages include the approved recovery recipient. Completion reports copied/unavailable counts for that run, not a durable complete-history or zero-loss guarantee. Purging hosted material cannot delete a copy the user already downloaded.

Partition hosted recovery/transfer data so the service can enforce room, membership-position and expiry checks before disclosing ciphertext. An opaque account-wide archive that can only be downloaded in full cannot establish that guarantee; SPEC-011 binds each separately stored copy to its original room, position, message and expiry. Do not claim that encrypted storage alone enforces history eligibility.

Content recovery does not restore server authority from a database snapshot. Resolve against current membership, permissions, device roster and recovery generation; never resurrect revoked devices or obsolete grants from a backup. The separate stale-server-restore contract and A-30 remain applicable to operator backup/restore.

## Lobby access state migration (D-052)

Persist optional boolean `roomAccess` on the existing account record, scoped to the single V1 lobby. This is operational permission state, not configuration. New ordinary accounts start false; bootstrap owner starts true. For records predating this extension, omission resolves to the existing `admitted` flag; explicit false is never replaced by that fallback. A voluntary leave materializes the effective grant before clearing membership, preserving legacy members' ability to return. Disabled accounts cannot use a grant. Existing membership intervals, ciphertext, account/device IDs and sessions are unchanged.

Grant/revoke, target invitation invalidation, membership intervals, voice removal and command outcomes share the existing SQLite transaction. Grant alone opens no interval. Legacy room-token redemption also records access. Removal and rejoin retain the exclusive absence boundaries under D-023. No bulk rewrite, database reset or namespace migration is needed.

## Configuration

D-058/P-027 selects a fixed test-profile ceiling of **100 persistent rooms per domain, including the existing lobby**. It is not an operator setting or an automatic allocation of 100 media relays. Enforce the ceiling transactionally; a retry of accepted creation does not consume another slot. Existing per-room member/retention limits and the deployment-wide media ceiling remain.

The versioned migration retains `lobby` as its ID and preserves accounts, sessions, explicit access denials, membership intervals, positions, message IDs and ciphertext. New rooms use server-generated UUIDs. Domain account/role/device state is distinct from room access/history/moderation state. Migration commits atomically, is repeatable without duplication and fails closed on unsupported schema versions. No owner reset or production-account recreation is part of this work; SPEC-012 defines the schema/wire amendment.

The logical keys below are PROPOSED inventory for the future code. Most operational values remain OPEN because no production capacity, retention, or budget decision has been accepted. `OPEN` never means unlimited, zero, disabled, or a valid executable value. Retention/limit changes need defined validation and propagation before implementation.

| Property | Scope and type | Default and status | Behaviour |
| --- | --- | --- | --- |
| `retention.messages_seconds`, `retention.attachments_seconds`, `retention.whiteboards_seconds` | Domain/room policy; positive integer seconds | OPEN — not selected | Finite active-content retention; omission has no implicit unlimited meaning. Any later indefinite-retention option needs a distinct typed representation and approval. |
| `retention.audit_seconds`, `retention.backups_seconds`, `retention.telemetry_seconds` | Operator; positive integer seconds | OPEN — not selected | Separate finite lifetimes; required authority/uniqueness records cannot expire solely because content retention does. |
| `delivery.direct_queue_expiry_seconds` | Domain; positive seconds | OPEN — not selected | Maximum offline ciphertext queue lifetime; expiry produces a defined status. |
| `delivery.retry_max_attempts`, `delivery.retry_initial_delay_ms`, `delivery.retry_max_delay_ms` | Worker/job policy; positive count and milliseconds | OPEN — not selected | Bounded retry/backoff; jitter, terminal failure, and dead-letter rules must be specified. |
| `delivery.result_cache_seconds` | Domain; positive integer seconds | OPEN — not selected | Retains retrievable operation results; expiry cannot remove required uniqueness/tombstones or make an old command new. Replaces draft deduplication-window setting. |
| `delivery.command_validity_seconds` | Protocol-constrained domain policy; positive integer seconds | OPEN — not selected | Bound for admitting/retrying commands if the selected validity protocol uses one; authority, binding and durable uniqueness must be defined together. Remove this property if the selected protocol fixes validity instead. |
| `history.resume_cursor_lifetime_seconds` | Domain; positive integer seconds | OPEN — not selected | Resume-token lifetime; expiry causes authorised resynchronisation, not a changed history entitlement. |
| `presence.lease_seconds`, `activity.typing_expiry_seconds`, `activity.cursor_expiry_seconds` | Domain/client; positive seconds | OPEN — not selected | Expire attendance and transient activity so stale state is not replayed indefinitely. |
| `messages.max_bytes`, `attachments.max_bytes` | Domain/room; positive byte counts | OPEN — not selected | Reject oversized content before committing work; encrypted envelope overhead requires definition. |
| `storage.quota_bytes`, `federation.queue_max_events`, `api.rate_limits` | Operator/account/domain scopes; byte/count/rate limits | OPEN — not selected | Resource bounds and their rejection behaviour; rate units/scopes must be made explicit. |
| `attachments.allowed_types`, `attachments.access_url_lifetime_seconds` | Domain/room; type policy and positive seconds | OPEN — not selected | Safe content handling and time-bounded access; ciphertext cannot be content-scanned by the host. |
| `whiteboard.max_operation_bytes`, `whiteboard.max_objects`, `whiteboard.snapshot_interval_operations` | Room/profile; positive byte/count limits | OPEN — not selected | Bounds operation validation, state size, and snapshot frequency. |
| `whiteboard.persist_after_meeting` | Meeting/room; boolean | OPEN — not selected | Determines whether meeting-end cleanup retains board state. |
| `messages.read_receipts_enabled`, `messages.typing_indicators_enabled` | Account/room; booleans | OPEN — not selected | Privacy-sensitive messaging signals; scope/precedence still open. |
| `invitations.account_expiry_seconds`, `invitations.room_expiry_seconds` | Issuing authority; positive integer seconds | OPEN — not selected | Distinct account-creation and room-admission invitations with purpose-bound tokens; neither is interchangeable or indefinitely valid by omission. |
| `direct.unsolicited_request_policy` | Account/domain; approved admission policy | OPEN — not selected | Determines unsolicited direct-contact handling; cannot disable mandatory direct E2EE. |
| `backup.schedule`, `backup.destination_ref` | Operator; schedule and protected storage reference | OPEN — not selected | Defines backup cadence/target without embedding credentials. |
| `backup.recovery_point_objective_seconds`, `backup.recovery_time_objective_seconds` | Operator; nonnegative content-loss target and positive restore-time target, integer seconds | OPEN — not selected | Targets must match a demonstrated recovery design; zero content loss cannot be assumed. Neither permits restoring stale authority. |
| `telemetry.export_enabled`, `telemetry.destination_ref` | Operator; boolean and endpoint reference | OPEN — not selected | Controls diagnostics export; excludes private content regardless of enablement. |
| `budget.monthly_limit`, `budget.alert_thresholds` | Operator; monetary amount/currency and thresholds | OPEN — not selected | Alerts/caps require an approved cost model and a defined response to crossing the limit. |

Recording/transcription, legal hold, and SSO/provisioning remain unapproved feature scope; their configuration must be added if selected. They are not implicitly enabled or implemented by omission from this table. Adapter credentials belong to [SPEC-002](002-architecture.md#configuration), media capacity to [SPEC-004](004-media.md#configuration), and security/grant lifetimes to [SPEC-003](003-identity-security.md#configuration).

V1 history interval rules are fixed under D-016/D-023, replacing the draft `history.visibility_policy` setting. Membership intervals, restore authority generations, authorisation evidence and operation outcomes are durable protocol state, not administrator-selectable values. SPEC-009/011/012 define the implemented storage/wire subset; operator backup restoration remains open. Configuration source precedence, per-room override permission, update timing and units for compound limits must be completed under SPEC-000 before those settings are implemented.

### Selected linked-history configuration

SPEC-011 is the fixed protocol inventory for batch/envelope/body size, encrypted share quota and original-message expiry. It replaces the proposed `history.transfer_*` and recovery bundle configuration for this alpha. No indefinite account archive or operator backup restore is added. The account-wide history version counter causes a destination to rescan retained history when a new copy arrives; retries skip already stored copies. Clients display copied and unavailable counts, can repeat a copy, and never extend source retention. Data shares remain in the existing jurisdiction-bound SQLite authority; no new storage service is selected.

### Selected V1 data contract (D-024/D-029)

Use SQLite transactions for account/room state, accepted event position, command result and required relay-revocation work. No accepted mutation depends solely on process memory. External work runs after commit, with stable operation/revision identity and monotonic relay reconciliation. A worker alarm or local timer retries incomplete work after restart. The shared service runs on Workers SQLite-backed Durable Objects and the Node SQLite development adapter; provider differences cannot change the transaction boundary.

Command tickets expire after 300 seconds. Results persist for 86400 seconds; expired ticket verification continues to reject a purged command instead of reapplying it. Message UUID uniqueness persists for the lifetime of the retained message, with ticket expiry preventing replay after result cleanup. A changed canonical payload using an existing ticket or retained message UUID conflicts. Result disclosure rechecks current authority. The client queries/retries the original command after an ambiguous response.

Only current members may retrieve history. Admission/removal positions define the union of eligible periods; removal is exclusive. Pages are filtered before return, with host-position cursors that do not expire or widen entitlement. Retention removes content, never grants earlier access. Sender timestamps cannot change history eligibility. V1 has no edits/deletion, attachments, search, snapshots, exports, typing or read receipts.

| Fixed V1 limit/lifetime | Selected value and behaviour |
| --- | --- |
| Account and room invitation lifetime | 86400 seconds; distinct purpose, explicit recipient binding, 32-byte pseudorandom token derived with a purpose-separated HMAC of the random command UUID and `TOKEN_SECRET`; only its hash is persisted, including in operation results; single-use. |
| Encrypted message retention | 604800 seconds (seven days), measured from host acceptance; expiry applies to retrieval and periodic deletion. |
| Plain-text message size | 4096 UTF-8 bytes checked by clients; server cannot inspect plaintext and separately checks envelope bounds. |
| Encrypted signed message envelope | At most 98304 UTF-8 bytes, at most ten recipient devices, bounded nonce/ciphertext fields. |
| API body | At most 131072 bytes; oversized requests fail before parsing/mutation. |
| History page | At most 50 eligible messages, ordered by host position. |
| Accounts / outstanding invitations | At most 100 accounts and 1000 retained invitation records in this V1 fixture. |
| Retained ciphertext quota | At most 10000 messages and 67108864 bytes (64 MiB) of encrypted envelope data; additional sends fail with `storage_full` until retention frees capacity. |
| Membership periods | At most 500 admission periods per account; further admissions fail explicitly without altering prior history eligibility. |
| Message send rate | Twenty per account per minute, checked before commit. |
| Authenticated API rate | 240 requests per account per minute; voice renewal included. |
| Live attendance expiry (`LIMITS.attendanceMs`) | 15000 ms after admission or the last authorised renewal, fixed positive-integer milliseconds under D-137 (supersedes 5000 ms). Applies to host voice attendance and home-server foreign-call reservations; no persistent membership removal. No per-user/channel/operator override or environment variable. New admissions and successful renewals use the running server's value; deployment does not extend already stored deadlines or revive expired records. |
| Relay work retries | Every 1000 ms until superseded/effective; after the hard bound record failure if enforcement cannot be established and retain deny policy. |
| Administrative audit retention | Seven days; metadata only, with actor/action/target/revision/time; accepted results are retained separately, never plaintext or credentials. |

These are fixed bounded test-profile values, not OPEN runtime values or unlimited settings. The API version must change or a compatible configuration amendment must precede exposing overrides. Audit/result/content expiry does not remove account identities or membership intervals. Cleanup runs periodically and filters reads immediately by expiry. No backup/restore feature, telemetry export, recording, content recovery or paid-service deployment is enabled by this build.

## Testing

D-137: deterministic-clock units cover an eight-second renewal gap without attendance loss, renewal of the same call, expiry exactly at the new attendance boundary, restart persistence, and independent home-server reservation renewal/expiry. Verify that an expired media grant cannot authorize forwarding while attendance survives, that renewed media grants retain the SPEC-003 lifetime, and that expiry leaves persistent membership intact. Existing explicit leave, movement, moderation and Cloudflare generation-deadline regressions must still pass.

For D-052, unit-test old account-record migration, explicit false versus omitted access, retained grants on voluntary leave, absence-period history filtering, atomic invitation invalidation and persistence across restart. See A-38; SPEC-008 owns role enforcement.

Successor history units cover interval filtering before pagination/export/restore; unchanged entitlement on linking; offline recipients; interrupted/resumed transfer; duplicates and conflicting message identity; concurrent live delivery; partial/unavailable keys; quota exhaustion; and expiry measured from original acceptance. Recovery units cover authenticated coverage manifests, corruption, incomplete uploads, failed rotation and rejecting stale authority. Measure total ciphertext growth at the selected device cap; these tests remain planned.

Unit tests for event storage/delivery, lifecycle, quotas, and whiteboard operations should cover:

- Accepted-event acknowledgment occurs after the durable-commit contract succeeds; simulated commit failure never yields a false accepted status.
- Stable IDs and idempotency prevent duplicate effects across retries; duplicate, out-of-order and conflicting updates follow the approved host ordering rules.
- Fake-clock retry, queue expiry, deduplication and presence/cursor expiry boundaries, including a dead-letter result after the final allowed attempt.
- History access before join, after departure/removal, and under changed permissions; cursor expiry causes the specified resynchronisation response rather than history leakage.
- Retention and deletion actions preserve required tombstones/idempotency, expire referenced objects according to policy, and never claim that deleting a host copy erased a remote export.
- Retained-message quota (implemented): usage is the UTF-8 byte length of each stored canonical envelope, for readable and encrypted variants alike; mixed multibyte/encrypted fixtures pass below, exactly at and above 67108864 bytes, with replay before charging, rollback and expiry release (SPEC-008 testing).
- Attachment and event size/type/quota limits at below/exactly/above boundaries; expired or wrong-scope access tokens fail, and encrypted metadata is not accidentally rendered into plaintext server fields.
- Whiteboard operation validation, deduplication, approved concurrency/convergence rules, snapshot replay, malicious object edits, and permission changes relative to operation ordering.
- Backup/restore excludes plaintext user encryption keys, preserves required authority, and does not revive revoked sessions or overwrite newer state without the approved restore procedure.
- Telemetry redaction, budget/overload response, rate limits and resource counters, including invalid configuration and rejected operations that must not incorrectly consume or release quota.
- Crash injection before/after commit, work scheduling and external success; every committed incomplete effect remains discoverable, and ambiguous outcomes reconcile without duplicate mutations.
- Retries before/after result-cache and command-validity expiry, changed-payload key reuse, deletion/tombstone interactions and revoked callers; no old command becomes a new operation through expiry.
- Membership-interval unions, concurrent admission/removal/send, reconnect without re-admission, identity reassignment, absence-period edits, snapshot filtering and loss of historical keys; server retrieval never widens eligibility.
- Historical board authorisation evidence before/after revocation, forged identities/revisions and invalid snapshot provenance; later role changes do not rewrite the interpretation of an accepted operation.
- Restore from a snapshot preceding revocation; rollback-resistant authority fencing, absent recovery journal, stale membership intervals and active pre-restore leases keep unauthorised access closed.

Use an explicit storage-contract fake, deterministic clocks and bounded fixtures. Real database transactions, worker restarts, queue delivery, multi-client convergence, restore drills, and production load are separate integration/operational validation.

## Acceptance criteria

- D-137: host attendance and home-server reservations survive an eight-second renewal gap, retain the same call on successful renewal, and expire at the fixed attendance boundary without a further authorized renewal. Media authority expires independently under SPEC-003, and persistent membership is retained.
- A-38 passes for the D-052 workflow without changing existing owner credentials or sessions.

- In the linked-device successor, A-34 restores exactly the retained, eligible, backed-up messages and reports missing ranges; adding a device or using a recovery key exposes neither pre-admission nor absence-period history, and never resets message expiry. No complete-history claim is made for missing V1 keys.

- Inject a worker restart immediately after durable message acceptance and recover the acknowledged event; replay the same request/federation event and observe one applied effect. See A-15.
- Crash after commit but before effect dispatch, and after external success but before local acknowledgement; reconcile every accepted operation. Retry past the valid retry/result window and observe an explicit outcome without another effect. See A-15.
- Admit, remove and re-admit a member around distinct messages; retrieving retained history yields only messages from eligible membership periods, never the absence, and cursor expiry does not change that result. See A-27.
- Disconnect and reconnect a client both before and after cursor expiry; recover exactly the history its current permissions allow and no stale typing/cursor activity.
- Queue encrypted direct content for an offline recipient and observe delivery before expiry or an explicit expiry/failure result afterwards; revoked devices do not receive future keys.
- Exercise approved retention, deletion, history-access and attachment limits with fixed fixtures; active host views and stored-object lifecycles match the documented policy and make no remote-erasure claim.
- Have multiple clients edit a board concurrently and reconnect after missed events; their authorised states converge, unauthorised edits fail, and an encrypted board remains opaque in host storage. See A-13.
- Take a backup, revoke a member/device, then restore that older backup in isolation. Verify stale credentials, memberships and media paths cannot regain access; unavailable authority recovery keeps the affected scope closed. Record content loss and restore time against the selected objectives. See A-30.
- Exceed each approved quota/rate limit and observe its documented rejection or overload behaviour without accepting unbounded work or exposing private data in diagnostics.
- Follow the deployment/upgrade/recovery instructions on the agreed independent target and run the applicable interoperability cases before marking operator portability complete. See A-03/A-19.

## Bounded voice troubleshooting (D-099)

[SPEC-021](021-voice-diagnostics.md) selects local client export and operator control/media logs for the current implementation. This scope supersedes unselected general telemetry proposals only for those events. It adds no client upload endpoint or database retention category.