waypoint-codex 0.10.6 → 0.10.7

package/README.md

@@ -157,9 +157,9 @@ Waypoint scaffolds these reviewer agents by default:
 - `code-reviewer`
 - `plan-reviewer`
 
-The intended workflow is closeout-based: run `code-reviewer` before considering any non-trivial implementation slice complete, and run `code-health-reviewer` before considering medium or large changes complete, especially when they add structure, duplicate logic, or introduce new abstractions. If both apply, run them in parallel. A recent self-authored commit is the preferred scope anchor when one cleanly represents the slice, but it is not the only valid trigger.
+The intended workflow is closeout-based: run `code-reviewer` before considering any non-trivial implementation slice complete, and run `code-health-reviewer` before considering medium or large changes complete, especially when they add structure, duplicate logic, or introduce new abstractions. If both apply, run them in parallel. A recent self-authored commit is the preferred scope anchor when one cleanly represents the slice, but it is not the only valid trigger. Reviewer agents are one-shot workers: once a reviewer returns findings, close it, and if another pass is needed later, spawn a fresh reviewer instead of reusing the old thread.
 
-For planning work, run `plan-reviewer` before presenting a non-trivial implementation plan to the user and iterate until it has no meaningful review findings left.
+For planning work, run `plan-reviewer` before presenting a non-trivial implementation plan to the user and iterate until it has no meaningful review findings left. Each pass should use a fresh `plan-reviewer` agent rather than reusing a previous reviewer thread.
 
 When the user approves a reviewed plan or explicitly says to proceed, the intended Waypoint behavior is autonomous execution: keep going through implementation, verification, review, and repo-memory updates unless a real blocker or materially risky unresolved decision requires a pause. If reviewers, subagents, CI, or other external work are still running, Waypoint should wait as long as necessary rather than interrupting them for speed. For PR work, placeholder automated-review states like CodeRabbit's "review in progress" do not count as a completed review.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "0.10.6",
+  "version": "0.10.7",
   "description": "Codex-native repository operating system: scaffolding, docs routing, repo-local skills, doctor, and sync.",
   "license": "MIT",
   "type": "module",

package/templates/.codex/agents/code-health-reviewer.toml

@@ -10,6 +10,8 @@ Read these files in order before doing anything else:
 
 After reading them, follow these operating instructions:
 
+This reviewer agent is single-use: return one review pass, then stop. If the main agent wants another pass later, it should spawn a fresh reviewer instead of reusing you.
+
 You are a Code Health specialist. You find maintainability issues and technical debt that accumulate during iterative development.
 
 Read the docs relevant to the area under review.

package/templates/.codex/agents/code-reviewer.toml

@@ -10,6 +10,8 @@ Read these files in order before doing anything else:
 
 After reading them, follow these operating instructions:
 
+This reviewer agent is single-use: return one review pass, then stop. If the main agent wants another pass later, it should spawn a fresh reviewer instead of reusing you.
+
 You are a code reviewer. Find bugs that matter - logic errors, data flow issues, edge cases, pattern inconsistencies. Not checklist items.
 
 Read the docs relevant to the changed area.

package/templates/.codex/agents/plan-reviewer.toml

@@ -10,6 +10,8 @@ Read these files in order before doing anything else:
 
 After reading them, follow these operating instructions:
 
+This reviewer agent is single-use: return one review pass, then stop. If the main agent wants another pass later, it should spawn a fresh reviewer instead of reusing you.
+
 You are an elite Plan Review Architect. Your reviews are the last line of defense before resources are committed.
 
 Read the docs relevant to the area the plan touches.

package/templates/.waypoint/agent-operating-manual.md

@@ -50,6 +50,7 @@ If something important lives only in your head or in the chat transcript, the re
 - Rebuild `.waypoint/DOCS_INDEX.md` whenever routable docs change.
 - Rebuild `.waypoint/TRACKS_INDEX.md` whenever tracker files change.
 - Use the repo-local skills and reviewer agents instead of improvising from scratch.
+- Treat reviewer agents as one-shot workers: once a reviewer returns findings, read the result and close it. If another review pass is needed later, spawn a fresh reviewer instead of reusing the same thread.
 - Do not kill long-running subagents or reviewer agents just because they are slow.
 - When waiting on reviewers, subagents, CI, automated review, or external jobs, wait as long as required. There is no fixed timeout where waiting itself becomes the problem.
 - Never interrupt in-flight work just to force a partial result, salvage something quickly, or avoid making the user wait longer.
@@ -121,6 +122,7 @@ Run `plan-reviewer` before presenting a non-trivial implementation plan to the u
 
 - Use it when the plan includes meaningful design choices, multiple work phases, migrations, or non-obvious tradeoffs.
 - Skip it for tiny obvious plans or when no plan will be presented.
+- Use a fresh `plan-reviewer` agent for each pass. After you read its findings, close it instead of reusing the old reviewer thread.
 - Read the reviewer result, strengthen the plan, and rerun `plan-reviewer` until there are no meaningful issues left before showing the plan to the user.
 
 ## Review Loop
@@ -130,12 +132,14 @@ Use reviewer agents before considering the work complete, not just as a reflex a
 1. Run `code-reviewer` before considering any non-trivial implementation slice complete.
 2. Run `code-health-reviewer` before considering medium or large changes complete, especially when they add structure, duplicate logic, or introduce new abstractions.
 3. If both apply, launch `code-reviewer` and `code-health-reviewer` in parallel as background, read-only reviewers.
-4. If you have a recent self-authored commit that cleanly represents the reviewable slice, use it as the default review scope anchor. Otherwise scope the reviewers to the current changed slice.
-5. Widen only when surrounding files are needed to validate a finding.
-6. Do not call the work finished before you read the required reviewer results.
-7. Wait for reviewer outputs even if that requires repeated or long waits. Do not interrupt them just because they are still running.
-8. Fix real findings, rerun the relevant verification, update workspace/docs if needed, and make a follow-up commit when fixes change the repo.
-9. Do not call a PR clear, ready, or done until the required reviewer-agent passes for the current slice have actually run.
+4. Treat reviewer agents as one-shot workers. Once a reviewer returns its findings, read the result and close it.
+5. If you need another review pass after changes, spawn a fresh reviewer agent rather than reusing the old thread.
+6. If you have a recent self-authored commit that cleanly represents the reviewable slice, use it as the default review scope anchor. Otherwise scope the reviewers to the current changed slice.
+7. Widen only when surrounding files are needed to validate a finding.
+8. Do not call the work finished before you read the required reviewer results.
+9. Wait for reviewer outputs even if that requires repeated or long waits. Do not interrupt them just because they are still running.
+10. Fix real findings, rerun the relevant verification, update workspace/docs if needed, and make a follow-up commit when fixes change the repo.
+11. Do not call a PR clear, ready, or done until the required reviewer-agent passes for the current slice have actually run.
 
 ## Quality bar
 

package/templates/managed-agents-block.md

@@ -85,6 +85,7 @@ Working rules:
 - Before presenting a non-trivial implementation plan to the user, run `plan-reviewer` and iterate on the plan until it has no meaningful review findings left
 - Before considering a non-trivial implementation slice complete, run `code-reviewer`; use a recent self-authored commit as the default scope anchor when one cleanly represents that slice
 - Before considering medium or large changes complete, run `code-health-reviewer`, especially when they add structure, duplicate logic, or introduce new abstractions
+- Treat `plan-reviewer`, `code-reviewer`, and `code-health-reviewer` as one-shot agents: once a reviewer returns findings, close it; if another pass is needed later, spawn a fresh reviewer instead of reusing the old thread
 - Before pushing or opening/updating a PR for substantial work, use `pre-pr-hygiene`
 - Use `pr-review` once a PR has active review comments or automated review in progress
 - Treat the generated context bundle as required session bootstrap, not optional reference material