waypoint-codex 0.6.1 → 0.7.0

package/README.md

@@ -135,7 +135,6 @@ Waypoint ships a strong default skill pack for real coding work:
 - `workspace-compress`
 - `pre-pr-hygiene`
 - `pr-review`
-- `e2e-verify`
 
 These are repo-local, so the workflow travels with the project.
 
@@ -147,7 +146,7 @@ If you initialize with `--with-roles`, Waypoint scaffolds:
 - `code-reviewer`
 - `plan-reviewer`
 
-The intended workflow is post-commit: make your change, commit it, run the reviewers in parallel, fix real findings, then close out.
+The intended workflow is chunk-based: once there is a meaningful reviewable slice, run the reviewers in parallel, fix real findings, then close out. A recent self-authored commit is the preferred scope anchor when one cleanly represents the slice, but it is not the only valid trigger.
 
 ## What makes it different
 

package/dist/src/core.js

@@ -459,7 +459,6 @@ export function doctorRepository(projectRoot) {
         "workspace-compress",
         "pre-pr-hygiene",
         "pr-review",
-        "e2e-verify",
     ]) {
         const skillPath = path.join(projectRoot, ".agents/skills", skillName, "SKILL.md");
         if (!existsSync(skillPath)) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "0.6.1",
+  "version": "0.7.0",
   "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

@@ -7,10 +7,7 @@ description: Verify a user-facing feature by trying to break it on purpose inste
 
 Use this skill to attack the feature like an impatient, confused, or careless user.
 
-This is not the same as `e2e-verify`.
-
-- `e2e-verify` proves the intended flow works end to end.
-- `break-it-qa` tries to make the feature fail through invalid, interrupted, stale, repeated, or out-of-order interactions.
+This skill is for adversarial manual QA. It tries to make the feature fail through invalid, interrupted, stale, repeated, or out-of-order interactions instead of only proving the happy path works.
 
 ## Step 1: Ask The Three Setup Questions
 

package/templates/.agents/skills/code-guide-audit/SKILL.md

@@ -11,7 +11,9 @@ This skill owns one job: inspect the specific code the user points at, map it ag
 
 ## Step 1: Load The Right Scope
 
-- Read `.waypoint/docs/code-guide.md`.
+- Read the repo's routed code guide.
+- In standard Waypoint repos, use `.waypoint/docs/code-guide.md`.
+- If the repo routes the code guide somewhere else, follow the repo's own docs and routing instead of assuming another fixed path.
 - Read only the files, routes, tests, contracts, and nearby docs needed to understand the specific feature or slice under review.
 - If the scope is ambiguous, resolve it to a concrete file set, feature path, or commit-sized change surface before auditing.
 

package/templates/.agents/skills/pre-pr-hygiene/SKILL.md

@@ -16,7 +16,9 @@ Before the hygiene pass:
 3. Read `.waypoint/WORKSPACE.md`
 4. Read `.waypoint/context/MANIFEST.md`
 5. Read every file listed in that manifest
-6. Read `.waypoint/docs/code-guide.md` and the routed docs relevant to the area being shipped
+6. Read the repo's routed code guide and the routed docs relevant to the area being shipped
+
+In standard Waypoint repos, the code guide lives at `.waypoint/docs/code-guide.md`. If the repo routes it somewhere else, follow the repo's own docs and routing instead of assuming another fixed path.
 
 ## Step 1: Audit The Whole Change Surface
 

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

@@ -73,7 +73,6 @@ Do not document every trivial implementation detail. Document the non-obvious, d
 - `workspace-compress` after meaningful chunks, before stopping, and before review when the live handoff needs compression
 - `pre-pr-hygiene` before pushing or opening/updating a PR for substantial work
 - `pr-review` once a PR has active review comments or automated review in progress
-- `e2e-verify` for major user-facing or cross-system changes that need manual end-to-end verification
 
 ## When to use the optional reviewer agents
 
@@ -83,14 +82,15 @@ If the repo was initialized with Waypoint roles enabled, use them as focused sec
 - `code-health-reviewer` for maintainability drift
 - `plan-reviewer` to challenge weak implementation plans before execution
 
-## Post-Commit Review Loop
+## Review Loop
 
-If Waypoint's optional roles are enabled and you authored a commit, immediately after that commit:
+If Waypoint's optional roles are enabled, run the reviewer pair after a meaningful reviewable implementation chunk, not just as a reflex after every tiny commit.
 
-1. Launch `code-reviewer` and `code-health-reviewer` in parallel as background, read-only reviewers.
-2. Scope them to the commit you just made, then widen only when surrounding files are needed to validate a finding.
-3. Do not call the work finished before you read both reviewer results.
-4. Fix real findings, rerun the relevant verification, update workspace/docs if needed, and make a follow-up commit when fixes change the repo.
+1. Launch `code-reviewer` and `code-health-reviewer` in parallel as background, read-only reviewers once there is a coherent slice of work worth reviewing.
+2. If you have a recent self-authored commit that cleanly represents that slice, use it as the default review scope anchor. Otherwise scope the reviewers to the current changed slice.
+3. Widen only when surrounding files are needed to validate a finding.
+4. Do not call the work finished before you read both reviewer results.
+5. 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/.waypoint/agents/code-health-reviewer.md

@@ -59,7 +59,13 @@ Do not create findings for:
 
 ## Scope
 
-In Waypoint's default post-commit review loop, start with the latest self-authored commit, then widen only when related files are needed to validate a maintainability issue. Focus on:
+In Waypoint's default review loop, start with the reviewable slice the main agent hands you.
+
+- If there is a recent self-authored commit that cleanly represents the slice, use that commit as the default scope anchor.
+- Otherwise, start from the current changed files or diff under review.
+- Widen only when related files are needed to validate a maintainability issue.
+
+Focus on:
 
 - recently changed files
 - their importers

package/templates/.waypoint/agents/code-reviewer.md

@@ -41,7 +41,11 @@ Not:
 
 ### 1. Get the Changes
 
-In Waypoint's default post-commit review loop, start with the latest self-authored commit. Review the actual diff or recent changed files first, then widen only as needed.
+In Waypoint's default review loop, start with the reviewable slice the main agent hands you.
+
+- If there is a recent self-authored commit that cleanly represents the slice, use that commit as the default scope anchor.
+- Otherwise, start from the current changed files or diff the main agent is asking you to review.
+- Widen only as needed.
 
 ### 2. Deep Research
 

package/templates/managed-agents-block.md

@@ -37,9 +37,8 @@ Working rules:
 - Use `docs-sync` when the docs may be stale or a change altered shipped behavior, contracts, routes, or commands
 - Use `code-guide-audit` for a targeted coding-guide compliance pass on a specific feature, file set, or change slice
 - Use `break-it-qa` for browser-facing features that should be tested against invalid inputs, refreshes, repeated clicks, wrong navigation, and other adversarial user behavior
-- If optional reviewer roles are present and you make a commit, run `code-reviewer` and `code-health-reviewer` in parallel before calling the work done
+- If optional reviewer roles are present and there is a meaningful reviewable implementation chunk, run `code-reviewer` and `code-health-reviewer` in parallel before calling the work done; use a recent self-authored commit as the default scope anchor when one cleanly represents that slice
 - 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
-- Use `e2e-verify` for major user-facing or cross-system changes that need manual end-to-end verification
 - Treat the generated context bundle as required session bootstrap, not optional reference material
 <!-- waypoint:end -->

package/templates/.agents/skills/e2e-verify/SKILL.md

@@ -1,63 +0,0 @@
----
-name: e2e-verify
-description: Perform manual end-to-end verification for a shipped feature or major change. Use when frontend and backend behavior must be verified together, when a feature needs a realistic walkthrough, or when the agent should manually exercise the flow, inspect logs and persisted state, document issues, fix them, and repeat until no meaningful end-to-end issues remain.
----
-
-# E2E Verify
-
-Use this skill when "it should work" is not enough and the flow needs to be proven end to end.
-
-## Read First
-
-Before verification:
-
-1. Read `.waypoint/SOUL.md`
-2. Read `.waypoint/agent-operating-manual.md`
-3. Read `.waypoint/WORKSPACE.md`
-4. Read `.waypoint/context/MANIFEST.md`
-5. Read every file listed in that manifest
-6. Read the routed docs that define the feature, flow, or contract being verified
-
-## Step 1: Exercise The Real Flow
-
-- For browser-facing paths, manually exercise the feature through the real UI.
-- For backend-only or service flows, drive the real API or runtime path directly.
-- Follow the feature from entry point to persistence to user-visible outcome.
-
-## Step 2: Inspect End-To-End State
-
-Check the surfaces that prove the system actually behaved correctly:
-
-- UI state
-- server responses
-- logs
-- background-job state if relevant
-- database or persisted records when relevant
-
-Do not stop at "the page looked okay."
-
-## Step 3: Record And Fix Issues
-
-- Document each meaningful issue you find.
-- Fix the issue when the remediation is clear.
-- Update docs or contracts if verification exposes stale assumptions.
-
-## Step 4: Repeat Until Clean
-
-Re-run the end-to-end flow after fixes.
-
-The skill is complete only when:
-
-- the intended flow works
-- the persisted state is correct
-- the logs tell a truthful story
-- no meaningful issues remain
-
-## Step 5: Report Verification Truthfully
-
-Summarize:
-
-- the flows exercised
-- the state surfaces inspected
-- the issues found and fixed
-- any residual risks or unverified edges

package/templates/.agents/skills/e2e-verify/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "E2E Verify"
-  short_description: "Manually verify a feature end to end"
-  default_prompt: "Use this skill for manual end-to-end verification of a feature or major change. Exercise the real flow, inspect UI plus logs and persisted state, document issues, fix them, and repeat until no meaningful end-to-end issues remain."