Skip to content

feat(boatstack): actor-typed next steps — turns end only at the operator frontier - #234

Merged
bigboateng merged 1 commit into
mainfrom
feat/actor-typed-next
Jul 28, 2026
Merged

feat(boatstack): actor-typed next steps — turns end only at the operator frontier#234
bigboateng merged 1 commit into
mainfrom
feat/actor-typed-next

Conversation

@bigboateng

Copy link
Copy Markdown
Contributor

Problem

The response contract renders one ### Next step, but nothing types who performs it. When the step is the coding agent's own work ("amend and reactivate the plan, then implement and run the test"), the turn still ends — so the operator gets handed the agent's to-do list and has to re-prompt ("ok is it done?", "what's next") just to return control. The operator frontier already exists implicitly in the run coordinator (pause for a, a material product answer, o/u), but next mode and the contract don't carry it.

Control law: turn-ends-only-at-the-operator-frontier

Every prescribed next step is typed by actor:

  • Operator-owned — exactly the steps owing operator knowledge or authority: approval (a), publish (o/u), cleanup (c/k), a feature choice, a source-plan path, correction facts (--message/--source-stage/--classification), --mutation, --preview-fingerprint.
  • Agent-owned — everything else, including steps whose owed inputs are evidence the agent produces by doing the work (--status --evidence, the review protocol). Owing evidence never crosses the frontier.
  • None — terminal states.

A working response may end only at the operator frontier. The read-only next status query is the one exception (a status question must not mutate): an agent-owned step renders as a one-key delegation — "This step is mine to do. Reply g and I will do it now, then continue to your next decision." — so the operator's next action is always a single key, even when the work is the agent's. Liveness guard: a prescription repeated without progress is a stall and hands the turn to the operator. Fail-closed: anything unclassifiable is operator-owned, i.e. today's prescribe-and-stop.

Changes

  • flow_control.go: NextActor type, operatorOwedFlags (knowledge/authority vs work-derivable evidence), classifyNextActor, FlowNext.Actor (next_actor in flow next --json), actor line in FormatFlowNext.
  • next_response.go: agent-owned prescribed steps carry the delegation marker + g reply.
  • references/workflow.md: new The operator frontier subsection in the response contract; next table row names the g delegation.
  • export.go: the boatstack-next instruction carries the frontier rule (delegation reply, continue-until-operator loop, no-progress stall guard) while staying strictly read-only per invocation.
  • next_actor_conformance_test.go: per-stage classification through real resolution, fail-closed boundary cases, render-marker parity, exported-instruction bypass guarantee.
  • Release note + test_product_loop.py export assertions.

Verification

  • go test ./... green (full lab suite, 110s).
  • python -m unittest discover -s tests green (23 tests).
  • release_notes.py preflight PASS.

…tor frontier

Every prescribed next step is typed by who performs it (next_actor:
agent/operator/none). Operator steps are exactly those owing operator
knowledge or authority; evidence the agent produces by doing the work
never crosses the frontier. The renderer marks agent-owned steps
("This step is mine to do") and offers the one-key delegation reply g,
so a read-only status query stays side-effect free while the operator's
next action is always known. Working responses may no longer end by
describing the agent's own pending work; a repeated prescription
without progress is a stall and hands the turn to the operator.
Fail-closed: unclassifiable steps stay operator-owned.

control-law: turn-ends-only-at-the-operator-frontier

Disclosure-Reviewed: reviewed — public-safe only, private facet kept out of this commit
@bigboateng
bigboateng merged commit ebc2162 into main Jul 28, 2026
12 checks passed
@bigboateng
bigboateng deleted the feat/actor-typed-next branch July 28, 2026 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant