waypoint-codex 0.10.2 → 0.10.3

package/README.md

@@ -163,6 +163,8 @@ For planning work, run `plan-reviewer` before presenting a non-trivial implement
 
 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.
 
+When browser-based reproduction or verification is part of the work, Waypoint should also send screenshots of the relevant UI states so the user can see the evidence directly.
+
 ## What makes it different
 
 Waypoint is not trying to hide everything behind hooks and background machinery.

package/package.json

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

package/templates/.agents/skills/break-it-qa/SKILL.md

@@ -118,6 +118,7 @@ Anti-cheating rules:
 - Use `playwright-interactive`.
 - Exercise the actual UI instead of mocking the flow in code.
 - Keep the scope focused on the feature the user asked you to verify.
+- Capture screenshots of the important states you observe so the user can see the evidence directly.
 
 ## Step 7: Try To Break It On Purpose
 
@@ -151,6 +152,7 @@ As you test, keep expanding the break log with new "What if...?" cases that emer
 - Update docs when the verification exposes stale assumptions about how the feature works.
 - Update the break log entry for each attempted action with what happened and whether the feature survived.
 - Require a short observed-result note for every executed item. "Worked" is too weak; capture what actually happened.
+- Save screenshots for the key broken, risky, or fixed states as you go.
 
 Do not stop at the first bug.
 
@@ -174,6 +176,7 @@ Summarize:
 - the path to the break log markdown file
 - how many attack items were recorded and exercised
 - how coverage was distributed across steps and categories
+- which screenshots you captured and what each one shows
 - what break attempts you tried
 - which issues you found
 - what you fixed

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

@@ -54,6 +54,9 @@ If something important lives only in your head or in the chat transcript, the re
 - 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.
+- When browser work is part of reproduction or verification, send screenshots of the relevant UI states to the user so they can visually confirm what you observed.
+- Capture the states that matter, such as the broken state, the fixed state, or an important intermediate state that explains the issue.
+- If the current environment cannot provide screenshots, state that explicitly instead of silently omitting visual evidence.
 
 ## Execution autonomy
 

package/templates/managed-agents-block.md

@@ -68,6 +68,7 @@ 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.
+When using a browser to reproduce a bug, verify behavior, or confirm that a fix works, send the user screenshots of the relevant UI states so they can see the evidence directly. If screenshots are not possible in the current environment, say so explicitly.
 
 Working rules:
 - Keep `.waypoint/WORKSPACE.md` current as the live execution state, with timestamped new or materially revised entries in multi-topic sections