Package A2 of the actions design (docs/actions-and-mcp.md, sections 2 and 3),
with two owner decisions of 2026-11-12, and five findings of an independent
review of the tool boundary, each closed by the guarantee it gives.
Writes follow the person
- The data access of a table or process is declared in versioned code:
AssistantQBitConfig.withDefaultTableAccess / withDefaultProcessAccess (both
READ_WRITE) and a pin per object (withTableAccess, withProcessAccess).
READ_WRITE grants nothing: the assistant may propose what the signed-in
person may do themselves, and every change waits for their confirmation.
- An administrator's assistant_data_access row can only narrow (READ, NONE).
It never raises a code default, a pin or a table kept from AI.
- Every assistant_* table and every process of the QBit is NONE by a pin in
code that no row and no host pin lifts.
- The write tools are offered to a person who may create, edit or delete
records of some table (asked of the UI API as that person, once per offer,
within the tool-call time limit; no answer means no write tool). GET /config
features.writes is that answer for the person.
- Settings that cannot be read, and were never read, allow nothing.
- The table action "Add rows for every table" is retired. The changeset
assistant-data-access-follow-user removes the unedited READ rows it wrote,
and no other row.
No answer without a spending limit
- A person for whom no spending limit is in force (BudgetService.limitInForce)
is refused: the turn before anything is stored, every model call, every tool
call, every embedding request, a scheduled turn. Restoring a limit restores
service on the next request.
Review findings
- A pending action is never marked expired over its outcome: expiry is a
decision made through the same claim as confirming and cancelling.
- No action stays RUNNING for ever: retention ends one left running for more
than an hour as FAILED ("outcome unknown, check the record"), with a log row.
- A person is the session the authentication module resolved, not the object
passed in: a hand-made permission gives nothing, a revoked one is gone.
- The assistant's own reads get their context from the tool-call service, for
a person it checked; there is no public way to make a tool context from a
session id, a gateway and a policy.
- The published test-jar holds the testing package only.
- AssistantStore's decision methods are final.
See CHANGELOG.md and UPGRADE.md (what a host must apply before deploying).
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The design this branch builds package A2 of. It is merged here so that the
sentences of the design that the code and the owner's decisions of 2026-11-12
have overtaken can be corrected in the same change.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The write-mode switch is not on develop but exists as an open draft
pull request (#21). Say so, and say what happens to it if the owner
confirms that every write is confirmed.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Draft design and work plan for owner review. Nothing is implemented here.
- Writes follow the person's permissions by default: data access defaults
declared in code, an administrator can only restrict, every write is
confirmed on a card that shows the values before and after.
- New tools: run a process the person may run, create and edit saved
reports and saved analyses, schedule delivery by email.
- An MCP endpoint that serves the same tool registry as chat: read-only
first, then writes as proposals approved in the application.
- Test strategy, repositories and release order, risks, decisions for the
owner, and work packages that can be built in parallel.
docs/DESIGN.md gets a pointer under "Next phases".
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
james.maesandClaude Fable 5.2