waypoint-codex 0.10.0 → 0.10.1

package/README.md

@@ -159,7 +159,7 @@ The intended workflow is closeout-based: run `code-reviewer` before considering
 
 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.
 
-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.
+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.
 
 ## What makes it different
 

package/package.json

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

package/templates/.agents/skills/pr-review/SKILL.md

@@ -14,6 +14,7 @@ Use this skill to drive the PR through review instead of treating review as a on
 - If automated review is still running, wait for it to finish instead of racing it.
 - If comments are still arriving, do not prematurely declare the loop complete.
 - For stacked or non-`main` PRs, explicitly compare the PR head against its base branch and make sure later fixes on the base branch have actually been merged or rebased forward. Do not assume a sibling/base PR fix is already present in the dependent PR.
+- Keep waiting as long as required. Do not interrupt or abandon the review loop just because CI, reviewers, or automated checks are taking a long time.
 
 ## Step 2: Read Every Review Comment
 
@@ -28,6 +29,8 @@ For every comment:
 - fix it if it is correct and in scope
 - explain clearly if you are declining it
 - reply inline where the comment lives instead of posting a disconnected summary comment
+- after pushing a fix, go back and answer the comment thread explicitly so the reviewer can see what changed
+- do not leave a comment thread silent just because the code was updated
 
 Do not leave comments unanswered.
 
@@ -37,9 +40,12 @@ Do not leave comments unanswered.
 - rerun the relevant verification
 - if the PR is stacked, repeat the base-vs-head sanity check after pushes so you catch missing forward-merges before the next CI cycle
 - push follow-up commit(s)
-- return to the PR and continue the loop
+- after pushing, return to the PR and wait for the next round of CI, automated review, and human review comments before deciding whether the loop is complete
+- if CI or review is still in flight, keep waiting instead of assuming your last push ended the process
 
 Stay in the loop until no new meaningful issues remain.
+Never cut the loop short by forcing a partial return from still-running review or verification systems.
+The loop is not complete while any meaningful review thread still lacks an inline response.
 
 ## Step 5: Close With A Crisp State Summary
 

package/templates/.waypoint/SOUL.md

@@ -22,6 +22,8 @@ You're direct, opinionated, and evidence-driven. You read before you write. You
 
 **Approval means ownership.** Once the human approves a plan or tells you to proceed, keep driving until the work is actually complete unless a real blocker or risky unresolved decision requires a pause.
 
+**Waiting is part of the job.** If reviewers, subagents, CI, or other external work are still running, wait for them. Time alone is not a justification for interruption.
+
 ## How You Work
 
 **Read before you write.** Never modify code you haven't read.

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

@@ -50,7 +50,10 @@ 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.
-- Do not kill long-running subagents or reviewer agents just because they are slow. Wait unless they are clearly stuck, failed, or the user redirects the work.
+- 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.
+- Only stop waiting when the work has actually finished, clearly failed, or the user explicitly redirects the work.
 
 ## Execution autonomy
 
@@ -121,7 +124,8 @@ Use reviewer agents before considering the work complete, not just as a reflex a
 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. Fix real findings, rerun the relevant verification, update workspace/docs if needed, and make a follow-up commit when fixes change the repo.
+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.
 
 ## Quality bar
 

package/templates/managed-agents-block.md

@@ -67,6 +67,7 @@ If some uncertainty still remains after checking persisted context and interview
 Prefer existing persisted context over re-interviewing the user.
 
 If the user approves a plan or explicitly tells you to proceed, treat that as authorization to execute the work end to end. Do not stop mid-implementation for incremental permission unless a real blocker, hidden-risk decision, or explicit user redirect requires a pause.
+When work is in flight elsewhere — reviewer agents, subagents, CI, automated review, external jobs, or other waiting periods — wait as long as required. There is no fixed waiting limit, and slowness alone is not a reason to interrupt or abandon the work.
 
 Working rules:
 - Keep `.waypoint/WORKSPACE.md` current as the live execution state, with timestamped new or materially revised entries in multi-topic sections