You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: address CodeRabbit review findings on goal continuation and todos
- Goal auto-continuation now requires the primary turn to end cleanly
(no_tool_calls): a tool rejection or stuck primary turn no longer
triggers continuations, matching the rule already applied between
continuation turns. Ralph-loop runs never continue (own strategy).
- Soften the SetTodoList single-in_progress invariant from a hard
rejection to a corrective notice: pythinker's parallel-subagent
fan-out legitimately tracks one in_progress sub-todo per running
child (system.md orchestration rules), so rejecting such lists would
break the documented workflow. The tool description, system.md
status-discipline bullet, and changelog wording are reconciled to
state the sequential rule and its fan-out exception.
- Document compact_prompt as nullable in the config reference, fix a
malformed report fence token in tasks/todo.md, and add boundary
tests for goal.max_continuations (1-10).
Declined (with rationale): mechanical enforcement of the blocked-audit
three-strike gate inside UpdateGoal — Codex itself enforces it as a
prompt contract, and 'same blocking condition' is semantic, so code
enforcement would misfire on legitimate impasses. H1 headings for the
prompt markdown assets — injected prompt files conventionally start
with body text in this repo (init.md, compact.md) and there is no
markdownlint gate.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ GitHub Releases page; `0.8.0` is the new starting line.
17
17
18
18
-**New `/goal` command: goal-driven execution ported from Codex CLI.**`/goal <objective>` sets a persistent thread goal the agent pursues across turns until it is verifiably complete. The objective is stored in session state (survives restarts and context compaction), kicks off work immediately with a success-criteria derivation prompt, and is re-injected on later turns as a continuation reminder carrying Codex's fidelity rules (no scope-shrinking, no easier-to-test substitutes) and evidence-based completion audit — the agent may only claim completion after proving every requirement against current state, and the user confirms with `/goal clear`. Subcommands: `view`, `pause`, `resume`, `clear`. Objectives are injected as untrusted data (`<objective>` framing), never as higher-priority instructions.
19
19
-**New `/best-practices` command (alias `/bp`).** Injects opt-in engineering best-practice guidance distilled from the Codex CLI system prompts — code-change discipline, dirty-worktree safety (never revert changes you didn't make), specific-to-broad testing strategy, todo hygiene, progress-update cadence, debugging methodology, and final-answer style — into the session context without consuming a turn. `/best-practices <section>` injects a single section.
20
-
-**SetTodoList enforces the single-`in_progress`invariant.** Todo lists with more than one `in_progress` item are now rejected with a corrective error (ported from Codex's plan-tool contract), and the system prompt gains matching status-discipline guidance: no single-step lists, no `pending`→`done` jumps, no batch-completing after the fact.
20
+
-**SetTodoList nudges the single-`in_progress`discipline.** Todo lists with more than one `in_progress` item now get a corrective notice (ported from Codex's plan-tool contract, softened because parallel-subagent fan-out legitimately tracks one `in_progress` sub-todo per running child), and the system prompt gains matching status-discipline guidance: no single-step lists, no `pending`→`done` jumps, no batch-completing after the fact.
21
21
-**`UpdateGoal` tool + opt-in goal auto-continuation: the full "loop until verified".** The agent can now mark the active `/goal``complete` (only after the evidence-based completion audit) or `blocked` (only after Codex's strict three-strike blocked audit) via the new root-only `UpdateGoal` tool, which stops goal reminders and continuations; `/goal resume` reactivates either state. With `goal.auto_continue = true` (new config table, default off, `max_continuations` 1–10 capped at 3 by default), each user message is followed by automatic continuation turns toward the active goal — carrying the Codex continuation prompt — until the goal is marked, a tool call is rejected, or the cap is reached, with a budget-style wrap-up instruction on the final continuation.
22
22
-**Approval-mode-aware validation guidance.** Auto/yolo-mode injections now tell the agent to proactively run tests and lint before finishing (no user present to confirm), while the back-to-interactive reminder defers slow test/lint commands to user confirmation except for test-related tasks — ported from the Codex CLI validation philosophy.
23
23
-**`compact_prompt` config override.** A new optional top-level config key replaces the built-in compaction summarization prompt for both manual and automatic compaction; a `/compact` focus argument is still appended on top, and leaving it unset preserves current behavior.
Copy file name to clipboardExpand all lines: docs/en/configuration/config-files.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,7 +38,7 @@ The configuration file contains the following top-level configuration items:
38
38
|`models`|`table`| Model configuration |
39
39
|`loop_control`|`table`| Agent loop control parameters |
40
40
|`goal`|`table`| Thread-goal (`/goal`) behavior, including auto-continuation |
41
-
|`compact_prompt`|`string`| Override the built-in compaction summarization prompt; unset keeps the default handoff-structured prompt (a `/compact` focus argument is still appended on top) |
41
+
|`compact_prompt`|`string \| null`| Override the built-in compaction summarization prompt; `null`/unset keeps the default handoff-structured prompt (a `/compact` focus argument is still appended on top) |
Copy file name to clipboardExpand all lines: src/pythinker_code/agents/default/system.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -168,7 +168,7 @@ For any non-trivial request, decompose before acting:
168
168
- Preview the terrain first: scan the directory structure, file headers, and relevant module boundaries before choosing an implementation path.
169
169
-**`SetTodoList` marks the start of execution, not planning.** Call it only after the user has explicitly agreed on the approach ("yes", "do it", "go ahead"). Do not set todos while exploring, gathering context, or presenting options — that is the planning phase and produces noise. Once set, the todo list is the single source of truth: update item statuses as you complete work (`pending → in_progress → done`). Restructure the list only when evidence genuinely changes the scope — surface it to the user before doing so.
170
170
-**Granular todos, not umbrella todos.** Each todo must name a single concrete deliverable a human can recognize as "this part is done." Avoid umbrella titles like "Determine X" or "Investigate Y" that cover hours of parallel work — they freeze the progress UI while real work happens underneath. If a single todo would stay `in_progress` for more than ~3 minutes, it is too coarse: split it before launching work.
171
-
-**Status discipline.** Do not make single-step todo lists or pad simple work with filler steps. Never jump an item from `pending` to `done` — set it `in_progress` first, keeping at most one item `in_progress` at a time — and never batch-complete multiple items after the fact. End the turn with every item `done` or explicitly `cancelled`.
171
+
-**Status discipline.** Do not make single-step todo lists or pad simple work with filler steps. Never jump an item from `pending` to `done` — set it `in_progress` first, keeping at most one item `in_progress` at a time for your own sequential work (parallel-subagent fan-out is the exception: one `in_progress` sub-todo per running child, per the rule below) — and never batch-complete multiple items after the fact. End the turn with every item `done` or explicitly `cancelled`.
172
172
-**Progress cadence.** Post a short Progress note (1-2 sentences) when you uncover a meaningful insight or change direction — notes replace, not duplicate, narration in your final text. Before the first tool call of substantial work, state the goal, constraints, and next steps. Announce longer heads-down stretches and summarize what you learned when you resume; call out plan changes explicitly in the next update.
173
173
-**One todo per dispatched child.** When you launch `RunAgents` with N children, the visible todo list MUST contain one in_progress sub-todo per child (or per independent objective the batch covers) **before** the batch starts. Update each sub-todo to `done` as that child returns — do not wait for the whole batch to finish to flip a single umbrella todo. Same rule applies to multiple parallel `Agent` calls in the same turn.
174
174
- Split broad work into independent chunks; use parallel tool calls or focused subagents for chunks that do not depend on each other. Scale the number of agents to the task's independent subparts — a single lookup needs none, a small comparison 2-4 — and prefer the fewest that cover the work; over-provisioning burns the multi-agent token premium.
Copy file name to clipboardExpand all lines: src/pythinker_code/tools/todo/set_todo_list.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ Once the todo list is set, it is the single source of truth for in-progress work
13
13
14
14
Once you finish a subtask/milestone, update its status before moving to the next item.
15
15
16
-
At most one item can be in_progress at a time — lists with more than one are rejected. Do not jump an item from `pending` to `done`: set it `in_progress` first, and do not batch-complete multiple items after the fact.
16
+
Keep at most one item in_progress at a time for your own sequential work — the only exception is parallel-subagent fan-out, where one in_progress sub-todo per running child is expected. Do not jump an item from `pending` to `done`: set it `in_progress` first, and do not batch-complete multiple items after the fact.
0 commit comments