feat(process): the assistant runs a process the signed-in person may run, confirmed on a card; four review findings closed

Conversation 0 Commits 2 Files Changed 41

+6901 -48

2 Commits

Author	SHA1	Message	Date
james.maesandClaude Fable 5.2	a9ebe64883	fix(process): only a reviewed process runs; a person confirms what they were shown; an independent review of the process tools closed maven / build (push) Successful in 7m48s Details build / maven (push) Successful in 7m48s Details After an independent review of the process tools. Each change is described by the guarantee it gives. - Only a reviewed process runs, decided when the application runs. A host registers the processes it reviewed for the assistant in AssistantQBitConfig (withReviewedProcesses, or withReviewedProcessesResource for a file on its classpath). With no list, only a table's own bulk edit and bulk delete are runnable: they act on records of a table the person may already change through the assistant. With a list: exactly the listed processes and those two, each still subject to every never-runnable rule, to an administrator's narrowing row and to the person's own permission. RunnableProcessReview stays as the way a host notices drift in its build, and now also fails when the reviewed file is not the registered list. - An input is only a field a screen asks a person for. A screen's field whose name the process keeps for its own working is never an input (ProcessControlNames: the inputs of the process's backend steps, and a fixed set this QBit owns, checked by a test against the QQQ version it builds with). The person is told the field cannot be set through the assistant; the process stays runnable for its other fields. - A person confirms what they were shown. A run stops at every later screen that has something to show (a form, values to read, a text, a list of records), and going on is a second card that shows it. Only a screen with nothing to show is passed. The screen a run starts at is on the first card. - A run is over exactly the records its card counted. A filter is resolved when the run is proposed, to at most 500 primary keys (more is refused, for the person to narrow); the confirmed run is sent those keys and does not start when one of them is gone. - A process that may run as a durable job is created waiting, or not run: where the application does not offer the operation that creates a job, the run is refused. - Text of the application reaches a model only inside the data envelope every tool result uses: a process's messages, what a screen shows, the application's message for a refusal or a failure. That holds for a result, for a card's lines, for the summary a later request keeps of a process step, for what a later request is told became of a confirmed run, and for the thread's own message about it (ToolLabels.forModel, MessageParts.modelText). - A card goes on only with the run as it stood when the card was made: a run counts a version up at every step and stop, and an older card of the same run is refused. One expectation of ChatToolSetTest changes: the scenario everythingAsAnotherPerson no longer holds the four process tools. That host registered no reviewed list, and its person may run processes of another QBit and change no table, so the assistant runs no process for them. ToolCallChecksTest is unchanged. No new tool. AssistantStore is still the only code that calls data actions. README, UPGRADE.md, CHANGELOG.md, CLAUDE.md and section 4.5 of docs/actions-and-mcp.md say the same. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-12 17:51:29 -06:00
james.maesandClaude Fable 5.2	7b4a2b9353	feat(process): the assistant runs a process the signed-in person may run, confirmed on a card; fix: four review findings maven / build (push) Failing after 12m50s Details build / maven (push) Failing after 12m50s Details Process tools (package A4 of docs/actions-and-mcp.md), in tools/process: list_processes, describe_process, run_process and get_run_status. - The list and the description come from the person's own metadata, asked as them: a process they may not run is never listed or described, and is refused by name in the words used for a process that does not exist. - run_process only proposes. Inputs are checked against the fields the process's screens declare before a card exists (unknown input, wrong type, missing required; no value is made up). The card (pending action kind process_run) shows the process, every input, the records and the steps that stop for the person. - The confirmed run is the person's: it runs through the UI API with the confirming request's session, and a run whose records are no longer the ones the card counted does not start. - A process eligible to run as a durable job is created as one and never started by the assistant; any other runs through its own init and step operations until it ends or needs the person (a review, a required field with no value), where going on takes a new card. - A confirmed run never holds its pending action RUNNING: the action ends when the run was started, and get_run_status reports where it stands. - What is never runnable through the assistant is decided in one place (ProcessRunnability): denied to the assistant channel, the assistant's own, data access not READ_WRITE, hidden, offered by no screen, on a table the assistant may not change, or with a screen it cannot present. Review findings, by the guarantee each gives: - A host notices each process that becomes runnable through the assistant: RunnableProcessReview fails the host's build when the runnable list differs from its committed file. - An administrator is warned before the data-access migration opens a table they left read-only: UPGRADE.md has a query with the migration's own predicate, tested against the changeset. - No tool says confirmation can be turned off (the cached request prefix changes once). - No model is called without a spending limit in force: the routing classifier asks for its own model. The administrator's Test connection is the one documented exemption. Also: a scheduled task is offered run_process only with its write approval; a test that a confirmed update into a record-security key the person lacks is refused by the application and changes nothing; UI API extension assistant 1.10.0 (additive). Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-12 15:04:09 -06:00

Author

SHA1

Message

Date

james.maesandClaude Fable 5.2

a9ebe64883

fix(process): only a reviewed process runs; a person confirms what they were shown; an independent review of the process tools closed

maven / build (push) Successful in 7m48s

Details

build / maven (push) Successful in 7m48s

Details

After an independent review of the process tools. Each change is described
by the guarantee it gives.

- Only a reviewed process runs, decided when the application runs. A host
  registers the processes it reviewed for the assistant in
  AssistantQBitConfig (withReviewedProcesses, or
  withReviewedProcessesResource for a file on its classpath). With no list,
  only a table's own bulk edit and bulk delete are runnable: they act on
  records of a table the person may already change through the assistant.
  With a list: exactly the listed processes and those two, each still
  subject to every never-runnable rule, to an administrator's narrowing row
  and to the person's own permission. RunnableProcessReview stays as the
  way a host notices drift in its build, and now also fails when the
  reviewed file is not the registered list.
- An input is only a field a screen asks a person for. A screen's field
  whose name the process keeps for its own working is never an input
  (ProcessControlNames: the inputs of the process's backend steps, and a
  fixed set this QBit owns, checked by a test against the QQQ version it
  builds with). The person is told the field cannot be set through the
  assistant; the process stays runnable for its other fields.
- A person confirms what they were shown. A run stops at every later screen
  that has something to show (a form, values to read, a text, a list of
  records), and going on is a second card that shows it. Only a screen with
  nothing to show is passed. The screen a run starts at is on the first
  card.
- A run is over exactly the records its card counted. A filter is resolved
  when the run is proposed, to at most 500 primary keys (more is refused,
  for the person to narrow); the confirmed run is sent those keys and does
  not start when one of them is gone.
- A process that may run as a durable job is created waiting, or not run:
  where the application does not offer the operation that creates a job,
  the run is refused.
- Text of the application reaches a model only inside the data envelope
  every tool result uses: a process's messages, what a screen shows, the
  application's message for a refusal or a failure. That holds for a
  result, for a card's lines, for the summary a later request keeps of a
  process step, for what a later request is told became of a confirmed run,
  and for the thread's own message about it (ToolLabels.forModel,
  MessageParts.modelText).
- A card goes on only with the run as it stood when the card was made: a
  run counts a version up at every step and stop, and an older card of the
  same run is refused.

One expectation of ChatToolSetTest changes: the scenario
everythingAsAnotherPerson no longer holds the four process tools. That host
registered no reviewed list, and its person may run processes of another
QBit and change no table, so the assistant runs no process for them.
ToolCallChecksTest is unchanged. No new tool. AssistantStore is still the
only code that calls data actions.

README, UPGRADE.md, CHANGELOG.md, CLAUDE.md and section 4.5 of
docs/actions-and-mcp.md say the same.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

2026-11-12 17:51:29 -06:00

james.maesandClaude Fable 5.2

7b4a2b9353

feat(process): the assistant runs a process the signed-in person may run, confirmed on a card; fix: four review findings

maven / build (push) Failing after 12m50s

Details

build / maven (push) Failing after 12m50s

Details

Process tools (package A4 of docs/actions-and-mcp.md), in tools/process:
list_processes, describe_process, run_process and get_run_status.

- The list and the description come from the person's own metadata, asked
  as them: a process they may not run is never listed or described, and is
  refused by name in the words used for a process that does not exist.
- run_process only proposes. Inputs are checked against the fields the
  process's screens declare before a card exists (unknown input, wrong
  type, missing required; no value is made up). The card (pending action
  kind process_run) shows the process, every input, the records and the
  steps that stop for the person.
- The confirmed run is the person's: it runs through the UI API with the
  confirming request's session, and a run whose records are no longer the
  ones the card counted does not start.
- A process eligible to run as a durable job is created as one and never
  started by the assistant; any other runs through its own init and step
  operations until it ends or needs the person (a review, a required field
  with no value), where going on takes a new card.
- A confirmed run never holds its pending action RUNNING: the action ends
  when the run was started, and get_run_status reports where it stands.
- What is never runnable through the assistant is decided in one place
  (ProcessRunnability): denied to the assistant channel, the assistant's
  own, data access not READ_WRITE, hidden, offered by no screen, on a table
  the assistant may not change, or with a screen it cannot present.

Review findings, by the guarantee each gives:
- A host notices each process that becomes runnable through the assistant:
  RunnableProcessReview fails the host's build when the runnable list
  differs from its committed file.
- An administrator is warned before the data-access migration opens a
  table they left read-only: UPGRADE.md has a query with the migration's
  own predicate, tested against the changeset.
- No tool says confirmation can be turned off (the cached request prefix
  changes once).
- No model is called without a spending limit in force: the routing
  classifier asks for its own model. The administrator's Test connection
  is the one documented exemption.

Also: a scheduled task is offered run_process only with its write
approval; a test that a confirmed update into a record-security key the
person lacks is refused by the application and changes nothing; UI API
extension assistant 1.10.0 (additive).

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

2026-11-12 15:04:09 -06:00

feat(process): the assistant runs a process the signed-in person may run, confirmed on a card; four review findings closed #110