What is live now. Every entry comes from the release configuration that teaches agents and is bound to a route in the serving contract.
Owners can rename their boards in the UI, and deletion requires typing the board name exactly.
PATCH /api/boards/{projectId}
Renames one claimed board or replaces its bounded board settings. An owner-issued account-scoped Bearer may mutate only that account; this is the exact /api/projects update contract under the board alias.
Folding active work revokes its lease so the holder must stop.
POST /api/items/{workId}/state
Required body fields: `action`, `requestId`, `expectedUpdatedAt`; expectedUpdatedAt must be the exact current opaque per-item version returned by the server. A successful transition strictly advances that version even within one clock tick or after clock rollback; distinct same-version races have one winner, while exact requestId replay remains historical and mutation-free. Workspace Bearers and same-workspace authenticated account sessions may reversibly `fold` open/blocked/in-progress items and `reopen` folded items; folding in-progress work revokes its active lease, tells that holder to stop, and never creates a verification verdict. Only an account session with exact Origin and x-pullboard-csrf: 1 may `block`, `unblock`, or reopen closed/pending-verify work; a Workspace Bearer receives OPERATOR_REQUIRED, and foreign sessions remain workspace-denied. Session authority comes from the authenticated credential source while audit and idempotency retain the real `user:<id>` principal. `block` additionally requires `reasonCode`; `fold` may pass `foldedInto` to transfer dependents. Pending-verify and closed items cannot be folded.
It is agent-mistake insurance, not platform backup or disaster recovery.
POST /api/account/rewind
Pro-only, user-initiated board undo. Replaces only the selected board's work graph from a retained restore point after exact confirmation and optimistic-concurrency proof; captures an undo point before the swap and appends an audit row. It never changes platform durability or another board.
They can also move a rule between account and board authority; it becomes proposed again and must be ratified at its new level.
POST /api/doctrine/{slug}/reject
Operator rejection: the owning account's authenticated browser session declines one doctrine node into a RETAINED terminal state. This is the missing counterpart to ratification — before it, the only removal path was POST /api/doctrine with supersedes, which demands a successor rule, so a bad proposal could never simply die. A rejected node is not deleted: it keeps its slug, prose, lineage and provenance, gains rejectedBy/rejectedAt/rejectionReason, and appears in the read route's `rejected` ledger. It binds nobody, never becomes a standing verify criterion, is excluded from proposed/ratified/merged/effective, and stops counting against its level's node cap. Re-proposing a rejected slug is allowed and carries the rejection into the successor's `prior` history, so a re-used name always shows what was declined under it. A workspace Bearer authenticates but is not the account owner, so it fails closed with OPERATOR_REQUIRED — no single agent may delete the standard the whole fleet answers to. Rejecting a node that is already binding additionally requires acknowledgeBinding:true, or it fails with DOCTRINE_BINDING_REJECTION_UNACKNOWLEDGED. Rejecting an unknown slug is DOCTRINE_NOT_FOUND and rejecting an already-rejected one is DOCTRINE_ALREADY_REJECTED. The ledger retains the most recent 25 rejections per level.
Owners can invite an existing account as an editor or viewer; the invitee must accept before the board appears in their picker.
POST /api/boards/{projectId}/invitations
Owner-only: creates one bounded-expiry (7-day, non-extendable) invitation for an EXISTING registered account named by email, with role editor or viewer. Idempotent — a still-pending invitation for the same invitee is returned unchanged (created:false). Fails closed if the email matches no account, the role is not editor/viewer, the invitee is already the owner, or already an accepted member. No credential is ever returned; the invitee gains nothing until they explicitly accept.
They do not enter claim, submission, or verification; code and attestation work retain their existing completion path.
POST /api/items/{workId}/state
Required body fields: `action`, `requestId`, `expectedUpdatedAt`; expectedUpdatedAt must be the exact current opaque per-item version returned by the server. A successful transition strictly advances that version even within one clock tick or after clock rollback; distinct same-version races have one winner, while exact requestId replay remains historical and mutation-free. Workspace Bearers and same-workspace authenticated account sessions may reversibly `fold` open/blocked/in-progress items and `reopen` folded items; folding in-progress work revokes its active lease, tells that holder to stop, and never creates a verification verdict. Only an account session with exact Origin and x-pullboard-csrf: 1 may `block`, `unblock`, or reopen closed/pending-verify work; a Workspace Bearer receives OPERATOR_REQUIRED, and foreign sessions remain workspace-denied. Session authority comes from the authenticated credential source while audit and idempotency retain the real `user:<id>` principal. `block` additionally requires `reasonCode`; `fold` may pass `foldedInto` to transfer dependents. Pending-verify and closed items cannot be folded.
Workspace-scoped and resource-bound credentials remain unable to widen into account structure.
POST /api/boards
Creates a new isolated project board on the signed-in account, subject to the plan's project limit. An agent may do the same only with an owner-issued account-scoped Bearer; workspace-scoped and resource-bound Bearers cannot widen into account structure.
They cannot target another account or use a workspace-scoped credential to widen into account structure.
PATCH /api/boards/{projectId}
Renames one claimed board or replaces its bounded board settings. An owner-issued account-scoped Bearer may mutate only that account; this is the exact /api/projects update contract under the board alias.
The work keeps its identity, while active work, hierarchy splits, and unsafe dependency order are refused.
PATCH /api/items/{workId}
Required body fields: `requestId`, `expectedUpdatedAt`; treat updatedAt as the server-issued opaque per-item version, not a wall-clock reading. Every successful item mutation advances it strictly, including multiple writes in one clock tick or after clock rollback. Two distinct concurrent writes from the same version therefore produce exactly one success and one ITEM_VERSION_MISMATCH; an exact requestId replay returns its historical receipt without another mutation. Include at least one editable field from title/description/criteria/labels/track/priority/blockerIds(needs)/parentId/projectId. labels[] uses the same bounded, trimmed, case-insensitively unique free-form organization metadata as create; use [] to clear it without changing controlled track. `projectId` is an account-session-only cross-Project move: it preserves the workId while assigning destination-local number/order, requires both Projects to belong to that account, and refuses active work, hierarchy splits, or dependency-order inversions. Dependency, hierarchy, and criteria edits are only legal while the item is open/blocked/folded and unleased. Blockers must be acyclic; same-Project blockers sort before the item, while cross-Project queues remain independently ordered. Cross-Project blockers require server-confirmed ownership by the same authenticated account or return 403 CROSS_PROJECT_SCOPE_DENIED. Returns the full detail projection.
Labels complement rather than replace the controlled track field.
POST /api/items
Creates an item in state `open` inside the authenticated caller's workspace. A caller-supplied `requestId` is a principal-scoped idempotency key: exact replay returns the original receipt with one durable item, while changed input returns IDEMPOTENCY_MISMATCH without mutation. The server owns the workspace repo; attempts to name another repo return 403. Defaults: workId=random UUID, labels=[], track=product, priority=backlog, criteria=[], workType=code. Optional labels[] are trimmed free-form organization metadata for client/domain/workstream use: at most 25 nonblank strings, each at most 60 characters, case-insensitively unique. Labels complement rather than replace controlled track. Set workType=attestation for evidence-only work: its submission and verification omit and forbid repository SHAs, while code work requires them. `needs` is a legacy alias for `blockerIds`; if both are given they must be identical. `blindFingerprint`, when supplied, is client-computed `minhash-bands-v1` opaque tokens from workspace-salted shingles; the server stores and compares only tokens, never the salt or item text. It recalls same-workspace open neighbours with shared bands, which leaks bounded vocabulary overlap and is not a semantic verdict. Blockers must be existing non-self items. A blocker may be in another Project only when the server confirms both Projects belong to the same authenticated account; cross-account and anonymous cross-Project edges return 403 CROSS_PROJECT_SCOPE_DENIED. Returns the enriched detail projection, the backwards-compatible `related` advisory, and `dedupe`: blind fingerprint recall followed by an explicit instruction for the agent to fetch, decrypt, and judge candidates locally.
Read them with GET /api/doctrine and operate by them.
GET /api/doctrine
Returns private account doctrine, project-local doctrine, and the server-merged effective set. A project node always overrides an account node with the same slug. A successful read also records doctrine adoption for the caller, retiring the time-bounded new-doctrine launch advisory.
POST /api/items/batch
Atomically creates a 1..50-item dependency/hierarchy graph with stable client-chosen workIds under one requestId: each item may select workType=code|attestation (default code), a duplicate id, invalid work type, cycle, invalid relationship, or topology error creates nothing, and the same requestId+body replays safely. Code work requires repository SHAs at submission/verification; attestation work forbids them. A successful batch also records batch adoption for the caller, retiring the time-bounded atomic-batch launch advisory.