Closes the findings of a third independent review of the tool boundary and
builds the pending-action package of the actions design on top.
Guarantees:
- A pending action is confirmed or cancelled once, by exactly one request,
on one server or several: the decision is an insert under a unique key
(new table assistant_pending_action_claim). Whatever fails after the claim
ends in FAILED or EXECUTED with a tool-call row, never in RUNNING.
- A tool cannot be run around the tool-call service from code outside the
assistant's packages: execute, log and withdraw are package-private; a
tool call request, a confirmed tool call and a tool context have no public
constructor and are made only with the service's permit; the runtime has
no public getter for the tool registry, the UI API gateway or its tool
families. A host's own ToolFamily and AssistantTool compile unchanged.
- A signed-in person is one person: a session with no HTTP request is made a
person only when the authentication module resolves the session's own id
to the user the session names. The turn engine no longer makes a person.
- Only the credential a request's session was resolved from is forwarded to
the UI API.
- A tool call that was cut short leaves no proposal anybody could confirm.
- The policy a tool call runs under is read fresh on every call.
- The hard budget is read on every call with one aggregate query per budget.
- The input kept in the tool-call log is redacted with the administrator's
custom patterns too.
Pending actions (design package A3):
- update_record and delete_record read the record as the person when they
propose; the card shows each field before and after (a delete: what the
record holds), after the exposure rules of get_record.
- What was approved is what is written: the proposal keeps a version of the
record (a digest, never values); a confirmed update or delete reads the
record again and refuses when it changed, is gone or cannot be read.
- actionKind (record_create, record_update, record_delete, or the proposing
tool's name), GET /assistant/actions (the person's own list), and
approvalRetentionDays is now read by the retention process.
- UI API extension assistant 1.9.0 (additive).
Schema: three columns and two indexes on assistant_pending_action, and the
table assistant_pending_action_claim (docs/schema-postgres.sql, UPGRADE.md).
ChatToolSetTest and ToolCallChecksTest pass unchanged.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
james.maesandClaude Fable 5.2