21 Commits

Include renames

Author	SHA1	Message	Date
dongarandClaude Opus 5.5	848bd9f122	Redeliver an interrupted review comment, and close the issue on completion ... Fixes counterexamples 6 and 7 from specs/orchestrator.qnt, the last two. 6. A crash while the executor answered a review comment lost it: its cursor is saved before the work (at most once), and a restart in PR_OPEN resumed quietly. Now pr.reviewing marks the comment until the executor returns (every way it returns, but not a crash), and boot resumes the watch just before it, with a notice. The mark stays until it is answered, so a second crash cannot lose it either. 7. 'project complete' left the plan issue open. It now closes it with a note, after IDLE is saved, as abandon does (shared helper). The model marks and redelivers, and closes the issue; scenarios 6 and 7 now expect their properties to hold. A mutant without redelivery fails scenario 6. All eight properties held together over 300,000 traces. No xfail reproductions remain. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 20:30:14 +00:00
dongarandClaude Opus 5.5	8bd1ac0fa2	Adopt an already-published PR instead of publishing again ... Fixes counterexample 5 from specs/orchestrator.qnt. A crash after the PR was opened but before PR_OPEN was recorded left the agent in EXECUTING; the restart question's 'continue' and 'start' then published again, Gitea refused a second PR, and there was no way back to PR_OPEN. On the live run the executor model happened to notice the existing work; recovery must not depend on that. - Boot (A3 step 4): in EXECUTING, if Gitea shows the milestone's PR open, adopt it, watch it from the start, and resume in PR_OPEN with a notice. Gitea unreachable or the PR closed: the restart question, as before. - MilestonePublisher.publish is idempotent: after pushing, an open PR for the branch is adopted (and so updated) rather than a second one opened. This also covers a PR opened whose response was lost. - The model adopts too, gains the lost-response outcome, and now counts PRs opened per milestone (one_pr_per_milestone was a flag the fixed model could never set). A mutant without adoption fails the new scenario; the properties held over 200,000 traces each. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 19:58:19 +00:00
dongarandClaude Opus 5.5	97863c1939	Bind approvals and feedback to the revision they were about ... Fixes counterexamples 1-4 from specs/orchestrator.qnt: a repeated 'approve', 'approve rev-1' meant for the architecture, approving on both channels, and 'approve' plus an afterthought all landed on the next plan, one the operator had not seen. - Revisions are numbered across the work item (A4 already required monotonic tags; the code numbered per gate), so rev-N names one plan. - Each reply is stamped on arrival with the revision that was up: in Matrix the one whose approval request had been sent (a plain value the transport thread reads, restored on boot), in Gitea the latest plan comment older than the reply (board.posts). - Gate.evaluate applies a reply that names no revision only if its stamp is the current revision. Otherwise an approval is not applied and feedback rejects nothing (it is still in the transcript), and the agent says which revision is up. 'approve rev-N' binds by its number. - Spec A4 states both rules. The model applies them; scenarios 1-4 now expect the properties to hold, and both held over 200,000 random traces and Apalache's exhaustive check to depth 8. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 19:13:20 +00:00
dongarandClaude Opus 5.5	6afd0cc914	Match approvals and commands regardless of case and trailing punctuation ... A phone keyboard's "Approve" did not match the approval pattern, so it counted as rejection feedback and threw the plan away; "Stop" did not reach the cancel flag; other capitalised commands got a hint instead of acting. gates.command_form() is how a message reads as a command: case, surrounding whitespace, inner runs of whitespace and a trailing '.' or '!' do not matter. The approval gate and every command match in the orchestrator (stop, status, abandon, use, start milestone, next milestone, project complete, the restart choices) use it. Only matching changes: the project name in 'use <name>' keeps its case, and feedback and answers are recorded and passed on as written. A stale revision is still refused, and approval still needs the whole message to be the command. Closes #64. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 17:57:34 +00:00
dongarandClaude Opus 5.5	d68e3b3a83	Add the abandon command ... A4 already names abandon as one of the ways out of a halt (continue, re-plan, or abandon) and 0.2 closes a work item as completed or abandoned, but no command did it: from a gate or a question the only way to drop a task was to edit the state database. - 'abandon' ends the task from any waiting state and returns to IDLE. The move is made durable first; then the plan issue and any open milestone PR are closed with a note (branches kept), and any unresolved intent is aborted so boot reconciliation does not gate on work dropped on purpose. A Gitea failure is reported, not fatal. - Like 'status' it is a command in every state, never read as an answer or feedback. While work runs, 'stop' comes first, as before. - The restart / stranded question and the PR_OPEN hints mention it. - Spec: B1 gains the abandon edge and B2 the command. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 17:43:43 +00:00
dongarandClaude Opus 5.5	3b6aae92c5	Keep Gitea threads watched across restarts and interruptions ... - Record a comment cursor per thread (board.last_comment, the field that already existed unused; pr.last_comment), advanced durably when a comment is taken up. CommentPoller.resume_after() skips comments at or below it, so re-attaching needs no request and cannot replay. - Boot re-attaches the plan watch at an open gate and the review watch in PR_OPEN from their cursors, catching up on comments posted while the agent was down (#59). Data saved without a cursor skips what is there, so an old approval cannot approve the current revision. - A restart in PR_OPEN resumes with a notice instead of the restart question (#58). A stored restart question for PR_OPEN returns to it on either reply instead of re-planning the milestone. - A stopped or failed review response gets its own pending kind; the reply returns to PR_OPEN and resumes the watch from the cursor, so comments that arrived meanwhile are delivered. It used to return to milestone sign-off, where starting the milestone would open a second PR. - Comments ignored because of the state leave the cursor alone, so they are delivered once the agent is back where they apply. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 17:33:41 +00:00
dongarandClaude Opus 5.5	92e5452161	Never leave the agent stranded in a working state ... The first live run found four dead ends one at a time: states where no operator message could move the agent. Most had one shape: work ended, by an exception or by a path that never transitioned, and left the agent in PLANNING_* or EXECUTING, where every message is answered "busy". The worker only prints an exception, so that would keep happening. - Every job the orchestrator runs for an operator message or a Gitea comment now goes through _settled(). If the job leaves a working state behind, whatever the reason, the agent moves to AWAIT_INPUT with the continue / re-plan choice a restart offers, and says why. An exception in a waiting state is reported and the state kept, since its commands still lead on. - A sign-off state whose gate record is missing asks to plan again instead of crashing on every reply. - The stub configurations (no executor, no publisher) complete the milestone and wait in PR_OPEN instead of resting in EXECUTING. test_no_stranding.py drives a whole two-milestone project with a fault injected at each planner, executor and publisher call, and asserts after every message that the agent is not in a working state and that the project still reaches 'project complete'. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 16:39:20 +00:00
dongarandClaude Opus 5.5	f97e459bc7	Publish work the executor committed itself, and gate when there is none ... On the first live run the executor committed its milestone itself, as its plan asked. The publisher only published a commit it made, found a clean tree, reported "no changes to publish", and left the agent in EXECUTING, where every message is answered "busy". - publish(): with nothing left to commit, publish anyway when the branch has commits origin/<base> lacks; report no changes only when it has none. - push_followup(): same for review fixes, comparing HEAD with what the remote branch holds (ls-remote; pushes go by URL, so there is no tracking ref). - Nothing to publish now gates to AWAIT_INPUT, and the reply returns to the still-approved milestone plan. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 16:17:41 +00:00
dongarandClaude Opus 5.5	b0c5f48be4	Handle leading mentions in Matrix messages ... Clients put the addressee's name in front of a message that mentions it ("Nisse Dev Testing: re-plan"), and the transport passed that text on whole, so no command matched: the live run's re-plan was asked again, and an addressed 'approve' would have counted as rejection feedback. - A leading mention of the agent (an HTML pill, its user ID, or its display name followed by ':') is removed before commands are matched. The display name is learnt from the agent's own member event. - A message whose leading mention is someone else is skipped: in a shared room it is addressed to another agent or person. - Only the start counts; a mention later in the text is left alone. - The transcript records the message as sent (InboundMessage.original). The sender is unaffected: it still comes from the event's homeserver-set sender field, never from the text. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-29 15:59:27 +00:00
dongarandClaude Opus 5.5	e5450e3e77	Keep a pending question across restarts, and make the restart question answerable ... A restart in AWAIT_INPUT replaced the saved pending item with a generic "continue or re-plan?" whose answer nothing handled: the reply cleared it and left the agent in AWAIT_INPUT with nothing to resume, where 'use' was refused too. The first live run hit this after a planning failure and could not be moved by any message. - Waiting on the operator is a committed state (A3 step 8): on boot, ask the saved question again instead of replacing it. _await_input keeps the prompt with the pending item for this. - The restart question (A3 step 7) records the state it interrupted, and 'continue' / 're-plan' now do what they offer: re-run the interrupted planning turn, or return an interrupted milestone to its approved plan. Any other reply asks again rather than being swallowed. - With nothing pending, 'use <project>' starts over, as the reply already advised. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-29 15:03:37 +00:00
dongarandClaude Opus 5.5	abb7fa0216	Add the operator kill switch, stop (A4) ... `stop` could not have worked by adding the command alone. Planning turns, milestones and review responses ran synchronously on the thread that delivered the message, so the Matrix sync loop read nothing until the work finished. The state store was also opened on the main thread and used from the transport and poller threads, which SQLite refuses with its default same-thread check; the in-memory test transport never showed it. A single worker thread now runs every handler and owns the store: - The worker opens the store, so the same-thread check stays on and fails loudly if anything touches the store from elsewhere - Matrix messages are handed to the worker; pollers hand over and wait, so their cursor never passes an unhandled comment - A message that arrives during long work gets an immediate "busy; say 'stop' to halt" reply and is recorded, not applied later in a state the operator was not answering - Tests keep running inline through InlineWorker, which defers a job submitted from inside another as the real worker would queue it `stop` sets a shared Cancel flag straight from the transport's thread. The executor and delegation loops check it before each model call and between tool calls; the planner checks it before each turn. Calls left unrun get a result saying so, so the transcript still renders. A stopped delegation is discarded like a failed one. The orchestrator moves to AWAIT_INPUT and asks why the work was stopped. The reply is recorded for the model, and a stopped planning turn resumes with it as the answer. `stop` with nothing running says so and changes nothing; at a gate it is no longer taken as rejection feedback. Closes #40 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-23 22:47:29 +00:00
dongarandClaude Opus 5	e38adf40ca	Discover a model's vendor from LiteLLM instead of its name ... Route selection sniffed model names: anything starting "claude-" or "anthropic/" took the vendor-native passthrough, everything else took the normalized route. That works only while an alias names its vendor. A semantic role alias like "remote-architecture" is meant to point at Anthropic today and somewhere else tomorrow, and the name says nothing either way -- so it would have taken the normalized route regardless of what was behind it, silently losing the fidelity A13 wants for delegations. LiteLLM already knows the answer. /model/info reports each alias's backing model, provider, and declared tool support, so the agent asks at startup and routes on the provider it discovers. That keeps vendor knowledge where A5 already put it -- in the proxy -- rather than duplicating it as name patterns here. There is deliberately no name-based fallback: PASSTHROUGH_PREFIXES and has_native_adapter are gone, and select_client now requires a catalog. A second heuristic could only ever disagree with the proxy. An unknown model raises instead of guessing a route. Misconfiguration is therefore loud and early. build_agent validates every role against the catalog before it clones anything, naming all the bad ones at once. Discovery is per key -- /model/info returns only what the presented token may use -- so the same check catches a role pointed at a real model this key cannot reach. An unreachable proxy is reported separately, since an outage and a typo call for different responses from the operator. Two things now get recorded rather than inferred: the resolved model is pinned alongside the role mapping at task start, for the reason A11 already pins roles, and DelegationStarted carries backing_model so A16 eval history is not averaged across whatever an alias happened to point at. A model LiteLLM declares tool-less warns at startup rather than refusing; A15 expects weak local models to be accommodated, and they are observed driving tool loops anyway. Verified live: all four aliases the production key can see route correctly through discovery, and each chosen route works. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-23 01:47:58 +00:00
dongarandClaude Opus 5	2fb25b8195	Add the composition root and a runnable entry point ... Nothing had ever assembled the agent. main.py was still the hello-world placeholder from the scaffold, and no code outside the test suite constructed an Orchestrator — which is how two fully built, fully tested components came to be reachable from nothing: the delegation harness, and the Gitea comment poller. Unit tests that construct a component directly cannot catch that; only assembly can. - config.py validates every variable before anything is built and names all of them at once, rather than failing at first use twenty minutes into a milestone on the call that mattered. Whitespace-only counts as missing, since a token of spaces passes a truthiness check and fails at the first request instead - agent.py builds the whole graph and owns startup and shutdown order: reconcile before accepting commands, and on stop, stop watching, then stop talking, then close the store last - The Gitea account is read via whoami rather than configured: it names the identity every permission is evaluated against, and proves the token works before anything depends on it - Poller lifecycle is now a state-machine concern: watch the plan issue while a gate stands, the PR while it is open, and stop on leaving. The orchestrator owns when to watch; an injected factory owns how to build one - The executor reports each turn, because it runs synchronously inside the transport callback: without it the agent is silent for a whole milestone and a working run looks exactly like a hung one - main.py loads .env, builds, and shuts down cleanly on SIGINT/SIGTERM The entry-point tests changed shape: nisse-dev no longer greets, it refuses to start unconfigured and says everything that is missing. Both tests now run with a deliberately empty environment and a .env path that does not exist, because the working directory's .env holds live credentials and a test must never be one cwd away from starting a real agent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-08 22:26:26 +00:00
dongarandClaude Opus 5	ce436262f4	Wire delegation to A12's trigger, and implement A3's resume rule ... Two gaps found by auditing spec against code, the second created by 7b landing the harness without its boot-time half. **The harness was not connected to anything.** Only a live test constructed a Delegation; A12's failure-count trigger still gated to the human, which A13 describes as the fallback rather than the path. Consecutive command failures now hand the sub-task to the delegate, with the failures in the brief so it need not rediscover what the local model learned the hard way. A usable handback lets the local loop carry on; anything else escalates, because a cap breach leaves a half-edited tree. **A3 step 5 was unimplemented.** A crash mid-delegation failed safe — boot gated on "restarted mid-EXECUTING" — but always gated, even on the clean cut the spec says should resume, and left the branch orphaned because _abandon only runs while the process lives. - A delegation now records an intent before the branch exists, and settles it whichever way the delegation ends; an aborted delegation is a finished one, and leaving it pending would make the next boot believe work was still in flight - delegation_verdict implements the clean-cut test as an observable check, never model self-assessment: settled if a completion follows the start, absent if the branch was never created, gate on a tool_call with no recorded result, resume otherwise - recover() sweeps at boot, announcing a resume with a notice rather than a question, since a clean cut needs no decision from the operator, and leaving an unclean one pending so the generic sweep gates on it - resume() continues the same delegation rather than starting a second: no new branch, no second delegation_started, because A10 defines a session as the delegation, not the process lifetime Honest limit, stated in the code: "the branch sits at the expected commit" is approximated by the branch existing and carrying the work, since per-turn shas are not recorded in the log, so a branch rewritten underneath us would go undetected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-08 20:03:46 +00:00
dongarandClaude Opus 5	d508e9a9b7	Externalise plans to Gitea and accept approvals there (A4, Part H) ... - approvals.py: PlanBoard opens one issue per project and posts each plan revision as a comment carrying its rev tag. The state store keeps only a pointer, so gate state can be re-derived from Gitea after a state-volume loss — external truth wins - Gitea comments are a second approval source: revision binding, the typed word approve, and first-approval-wins work exactly as over transport, with a per-channel allowlist because a Gitea login is not a Matrix MXID - Outcomes are echoed to the other channel, so the two records cannot silently disagree about what was approved - A Gitea outage degrades durability of the record, not the ability to approve: planning proceeds and Matrix remains a complete channel - Live test now asserts the server refuses the agent's own merge and its push to the protected branch. That property was previously true only because our code did not attempt it; branch protection makes it structural, and this test fails if the protection is ever relaxed - Fixed a race in the process-group test: killing a group is asynchronous and the grandchild is an orphan, so its exit is not synchronised with our return; the test now waits for death Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 22:15:08 +00:00
dongarandClaude Opus 5	affdb9e8aa	Add PR comment intake and the review loop (B2) — step 6b ... - poller.py: CommentPoller polls PR comments rather than taking webhooks, keeping the VM outbound-only (B3). On an outage it backs off exponentially, caps, and retries indefinitely while logging: polling is pure intake, so an outage delays a reaction but never fails a task or forces a transition - prime() marks the existing thread as seen without delivering it, so starting a watch does not re-address feedback already handled - Review loop: a comment in PR_OPEN enters the canonical transcript, the executor responds, and the fix is pushed to the same branch with a reply on the PR. No intent is recorded for a follow-up push — the PR already exists, so a repeated push is harmless, unlike opening a second PR - Comment authors are checked against a separate Gitea operator allowlist: a PR comment is an instruction channel into an agent that writes code, so it is operator-scoped, and a Gitea login is not a Matrix MXID (A4 per-channel allowlists) - Orchestrator now holds a lock: transport and the poller deliver on separate threads, and state transitions must not interleave - Backoff timings are injectable, so the outage path is tested in milliseconds instead of being untestable Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 21:59:50 +00:00
dongarandClaude Opus 5	3117565928	Publish finished milestones as PRs (B2/A3) — step 6a, part 2 ... Completes the B1 loop past EXECUTING, and answers the question raised reviewing #6: PR acceptance is a milestone's final gate, so there is no separate FINISHED state — completion returns to milestone planning or to IDLE. - publish.py: MilestonePublisher commits the work on a task-namespaced branch, pushes, and opens a PR carrying the approved plan. Intent is recorded before the first externally visible act, so a crash anywhere in the sequence leaves a durable record and boot reconciliation asks Gitea whether the PR exists rather than opening a second one - Nothing to commit is reported, not raised: the executor may legitimately conclude there was nothing to change - control.py: PR_OPEN state with EXECUTING -> PR_OPEN and PR_OPEN -> {MILESTONE_PLANNING, IDLE}; operator commands 'next milestone' and 'project complete' - A configured publisher always contributes its own reconciler at boot, so an interrupted publish is settled against external truth without the caller having to remember to register it - A publish failure gates to the operator rather than retrying into a possible duplicate Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 20:43:20 +00:00
dongarandClaude Opus 5	bacf65dbe2	Fix AWAIT_INPUT deadlock and make the live milestone test robust ... Found while chasing a flaky live test, but the flakiness was a real bug: only the ask_human path recorded a pending item, so AWAIT_INPUT reached any other way — planning failure, stopped milestone, boot reconciliation — refused every operator reply with "no pending question to answer" and the agent could never be recovered. The operator had no way back short of wiping state. Every path into AWAIT_INPUT now records what a reply should resume, and answering dispatches on it: planning failures and questions resume planning, a stopped milestone returns to its still-approved gate, and the fallback says what commands work instead of dead-ending. Two regression tests cover the recovery paths. The live test also scripted a fixed approve/approve/start sequence, which a real model breaks by legitimately calling ask_human at a gate. It now plays the operator adaptively, responding to whatever the agent actually did. Five consecutive live runs pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 16:46:07 +00:00
dongarandClaude Opus 5	0fd0b2e4a5	Add executor tool loop (A12/A15) — step 5b ... - tools.py: four flat tools (read_file, write_file, list_dir, run_command) per A15's reduced manifest. Deliberately unsandboxed: the VM is the trust boundary (B3) and tool use is auto-approved inside an approved unit of work (A4), so path confinement would add failure modes without adding safety. What is enforced is operational — timeout with process-group kill so a backgrounded server cannot outlive its command, output truncation so a build log cannot eat the context window, closed stdin so prompts fail fast, and a scrubbed environment so project code never sees the agent's credentials - executor.py: renders the log, calls the executor role with the reduced manifest, dispatches tool calls, and checkpoints every result (A13). Escalation is observable, never self-assessed (A12): consecutive command failures and a hard turn cap. Failed reads do not count — looking around is not failing - Until delegation exists (step 7), escalation gates to the human with the failures attached - control.py: start milestone now runs the executor; a stopped milestone gates to AWAIT_INPUT Two bugs found by running it live against real models: - A turn-ending gate tool (submit_plan) left a tool_call with no tool_result, which providers reject outright, so every planning turn after the first failed with a 400. The planner now records the gate as the call's outcome, which is also the truthful transcript - The renderer now emits a placeholder for any tool_call lacking a result, so a crash between call and result (A3) cannot poison the transcript permanently Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 16:35:39 +00:00
dongarandClaude Opus 5	cf85648719	Add LLM-backed planning agent (A4/A11/A13) — step 5a ... - planner.py: LLMPlanningAgent offers exactly two tools, submit_plan and ask_human, so gating stays structural at the tool layer; no proceed tool exists. System prompt requires explicit, low-inference plans because a weaker model executes them (A13) - Model output is appended to the canonical log as it arrives, before being interpreted, so a crash mid-planning leaves a truthful transcript - A bad turn (prose instead of a tool call, malformed arguments, or a failed call) retries once, then raises PlanningError; the orchestrator gates to AWAIT_INPUT rather than inventing a plan - Orchestrator: appends every operator message, plan_submitted, and gate_opened to the transcript, so re-planning sees rejection feedback as conversation rather than out-of-band parameters; pins the A11 role mapping at task start - llm.py: non-JSON or non-object tool arguments now raise LLMError instead of escaping as JSONDecodeError — observed from llama3.2, which emits truncated argument strings - Live planning test is opt-in on NISSE_LIVE_PLANNER_MODEL: planning escalates unconditionally (A12) and the local model does not hold the tool-call contract, so it awaits a frontier route Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 14:47:12 +00:00
dongarandClaude Fable 5	a251104a44	Add control loop, gating primitives, and transport interface (A4/B1) ... Step-2 PR A: the approval loop end to end with a stub agent, no LLM and no network. - transport.py: Transport interface per A1 (send_message, send_approval_request, ask_question, on_message) with an InMemoryTransport; no platform SDK outside an implementation - gates.py: PlanRevision with monotonic rev-N tags; Gate.evaluate enforces revision binding (stale tags refused with a notice), operator allowlisting, and approve-word-only semantics; any other reply is rejection feedback. Channel seam ready for Gitea/Vikunja approval sources - control.py: B1 state machine subset with structural gating — the agent's only actions are SubmitPlan (ends its turn) and AskHuman; no proceed tool exists. Gate state, revision counters, task_id, and pending questions checkpoint through StateStore, and boot resumes an open gate or gates to AWAIT_INPUT, never blind-resumes - gate.open/approve/reject A9 events complete the log taxonomy - CLAUDE.md: record the plan-first working convention - Tests: 15 unit (gates + orchestrator flows), 2 integration (mid-gate restart with revisions intact; unresolved intents gate the whole boot) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-09-05 21:28:07 +00:00