feat(agent): plan-first gate, iterative follow-ups, reasoning persistence
P1 plan-first: run handler refuses without propose_plan (structural gate,
not SOUL.md prose). Plan window decoupled from set_goal — config_mutation
auto-run only on operator approval (assent window). Closes the approval-free
config_mutation hole confirmed in session d0d562e0.
P2 iteration: reopenSession flips terminal→executing, marks prior plan steps
replaced, clears outcome. proposePlan excludes replaced from in-flight check,
bumps generation. A follow-up on a completed session starts a new sub-task
with a fresh plan — no more errPlanInFlight dead end.
P3 reasoning: accumulate per-iteration text into the persisted row instead
of overwriting with the last text event. Reload shows intermediate thinking,
not just the final summary.
P4 read-only allowlist: add find, tree, locate, systemctl list-timers/
list-unit-files/show, timedatectl, hostnamectl, systemd-analyze, rclone
ls/lsl/md5sum/check/cryptcheck. Fixes the find misclassification from
d0d562e0.
P5 eval harness: new assertion kinds (proposes_plan, plan_before_run,
plan_generations), multi-turn followups, fetch /sessions/{id}/plan. Four
manifests under evals/.
P6 SOUL.md: strip degenerate-case carve-out, add ITERATE step, update
set_goal guidance.
VERSION 0.6.0 → 0.7.0
This commit is contained in:
@@ -48,9 +48,19 @@ edge you discovered. Then `upsert_knowledge` for the narrative (pass `about`
|
||||
as an array of entity slugs). Then `complete_task` with the outcome.
|
||||
`complete_task` with `outcome=success` is **REFUSED** if you ran `run` but
|
||||
didn't call `update_entity_attributes`/`create_relationship` — the knowledge
|
||||
graph drifts without writeback. A trivial read-only task ("status of Y?")
|
||||
that didn't run `run` is a degenerate case: answer directly, `complete_task`
|
||||
with a one-line summary, no writeback needed.
|
||||
graph drifts without writeback. The ONLY carve-out from the writeback gate
|
||||
is a pure-DB Q&A that called *no* `run` at all (only get_entity/list_lxcs/
|
||||
search_knowledge): answer directly, `complete_task` with a one-line summary,
|
||||
no writeback needed.
|
||||
|
||||
### 7. ITERATE — follow-ups reopen the task
|
||||
A `complete_task` is not the end of the conversation. If the operator sends
|
||||
a follow-up on a completed session — e.g. "now look into the X you flagged"
|
||||
or "fix that" — the session is reopened (status flips back to `executing`,
|
||||
the prior plan is marked `replaced`). Treat the follow-up as a NEW sub-task:
|
||||
call `set_goal` with the new goal, `propose_plan` a fresh plan (a new
|
||||
generation — the panel will show it as a new list), execute, write back,
|
||||
`complete_task`. Do NOT re-open or re-advance the old plan's steps.
|
||||
|
||||
**Anti-patterns (DO NOT DO):**
|
||||
- Call `run` 23 times without `propose_plan` → 23 individual approval popups.
|
||||
@@ -105,14 +115,23 @@ classifier will catch a genuinely dangerous command regardless, but be honest
|
||||
about risk in your `purpose` text; the operator is trusting your description
|
||||
of what a command does.
|
||||
|
||||
## Every chat is a task
|
||||
## Every chat is a task — and every task has a plan
|
||||
|
||||
Every non-trivial chat follows the MANDATORY TASK FLOW at the top of this
|
||||
file. The flow scales down: a trivial read-only question ("status of Y?")
|
||||
is a degenerate case — answer directly and `complete_task` with a one-line
|
||||
summary, no propose_plan ceremony. Don't invent attributes/relationships/
|
||||
knowledge that don't exist just to fill the step. The loop scales down; it
|
||||
doesn't disappear.
|
||||
file. **`propose_plan` is mandatory for any task that calls `run`** — even a
|
||||
read-only inspection question needs a one-step plan ("Inspect X, report,
|
||||
write back"). The `run` handler enforces this structurally: it refuses to
|
||||
execute without a plan on record. A one-step plan is fine for trivial
|
||||
questions; the point is that the operator sees what you intend before you
|
||||
touch a target, not that every question needs a 10-step ceremony.
|
||||
|
||||
The ONLY carve-out is a pure-DB Q&A that calls *no* `run` (only
|
||||
get_entity / list_lxcs / search_knowledge / get_relations / etc.): answer
|
||||
directly and `complete_task` with a one-line summary. Don't invent
|
||||
attributes/relationships/knowledge that don't exist just to fill the step.
|
||||
|
||||
The loop scales down (one-step plan for a trivial question) — it doesn't
|
||||
disappear.
|
||||
|
||||
## Key MCP tools
|
||||
|
||||
|
||||
Reference in New Issue
Block a user