waypoint-codex 0.19.0 → 0.19.2

package/README.md

@@ -133,14 +133,14 @@ This helps the agent keep moving until the work is actually ready, not just
 Waypoint treats user corrections as product input, not just conversation noise.
 
 When the user corrects behavior, rules, or workflow, the agent is pushed to
-update the right durable files so the same issue is less likely to happen
+update the right durable layer so the same issue is less likely to happen
 again.
 
 That includes:
 
-- user-scoped guidance
-- project-scoped guidance
-- repo-local skills
+- user-scoped guidance for true cross-project standing rules
+- project-scoped guidance for durable repo-wide context and always-on rules
+- repo-local skills for workflow-specific or method-specific guidance
 - retrospectives that turn friction from the current conversation into lasting
   improvements
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "0.19.0",
+  "version": "0.19.2",
   "description": "Make Codex better by default with stronger planning, code quality, reviews, tracking, and repo guidance.",
   "license": "MIT",
   "type": "module",

package/templates/.agents/skills/planning/SKILL.md

@@ -103,11 +103,13 @@ Plans document your understanding. Include what matters for this task:
 
 - **Current State**: What exists today — relevant files, data flows, constraints, existing patterns
 - **Changes**: Every file to create/modify/delete, how changes connect
+- **Removals**: What obsolete code, compatibility logic, unused files, debug logs, dead props, or stale branches will be deleted as part of the change
 - **Decisions**: Why this approach, tradeoffs, assumptions
 - **Phase breakdown**: Distinct execution phases in the order they should happen
 - **Scope checklist**: Concrete implementation items that can be marked done or not done
 - **Acceptance criteria**: What must be true when each phase is "done"
 - **Phase checkpoints**: What verification, reviewer passes, tests, typechecks, builds, or manual QA must pass before moving to the next phase
+- **Cleanup expectations**: What legacy or replaced paths must be removed before the work can be called complete
 - **Test cases**: For behavioral changes, include input -> expected output examples
 - **Non-Goals**: Explicitly out of scope to prevent implementation drift
 
@@ -132,6 +134,7 @@ Before presenting the plan, verify against real code:
 - No pretending you verified something you didn't
 - Approved scope must be explicit enough to act as an execution contract after user approval
 - The plan must be explicit enough to support phase-by-phase execution and checkpoints without rediscovering the intended order in chat
+- Refactor and replacement plans should explicitly call out what legacy or obsolete code will be removed instead of preserving it by default
 - If the user approves the plan, do not silently defer or drop checklist items later; discuss any proposed scope change first
 
 If the change touches durable project behavior, include docs/workspace updates in the plan.
@@ -175,6 +178,7 @@ If the plan would make the implementer ask "where does this hook in?" or "what e
 - Do not spend interview turns on implementation facts that are already in the code or routed docs.
 - Do not stop exploring just because you have a plausible plan. The usual failure mode is shallow repo understanding.
 - Do not leave unresolved architecture or product decisions hidden behind "we can figure that out during implementation."
+- Do not plan a refactor as a rewrite-plus-compatibility-preservation bundle unless compatibility is explicitly required. Call out what should be deleted.
 - Do not dump a transcript into the plan doc. Distill the decisions and requirements into a clean implementation handoff.
 - Do not treat a reviewed plan as a stopping point. Once the user approves it, the workflow expects execution to continue.
 

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

@@ -2,6 +2,8 @@
 
 This repository uses Waypoint as its operating system for Codex.
 
+These instructions are mandatory for work in this repo. Treat them as overriding weaker generic guidance outside these files unless the user explicitly tells you otherwise.
+
 If the repo needs custom AGENTS guidance, write it outside the managed `waypoint:start/end` block in `AGENTS.md`. Treat the managed block as Waypoint-owned and replaceable.
 Treat repo guidance as the authoritative repo-local contract, but not as something that can outrank higher-priority system or developer instructions injected by the environment.
 If a higher-priority instruction conflicts with Waypoint workflow, do not silently ignore the repo rule or pretend it happened anyway. State the conflict plainly, explain the practical consequence, and ask the user for the missing authorization or use a compliant fallback path.
@@ -54,14 +56,19 @@ If something important lives only in your head or in the chat transcript, the re
 - Once a plan is approved, treat its scope and acceptance criteria as the execution contract. Do not silently narrow, defer, or drop approved work because the system feels good enough, the remaining work looks less valuable, or you would prefer a smaller PR. If the scope should change, discuss that with the user first unless a real blocker, hidden-risk decision, or explicit user redirect forces the change.
 - When the user shows a bug, screenshot, or broken behavior, investigate first. Lead with what is happening, why it is likely happening, the important options or tradeoffs if they matter, what you checked, and what you are doing next.
 - After investigation, explain the diagnosis before jumping into implementation whenever the cause, tradeoffs, or solution shape are not already obvious.
-- Fix underlying causes instead of papering over symptoms. If the real fix requires changing a shaky abstraction, deleting stale compatibility logic, or cleaning up debt that is directly causing the bug, do that work instead of shipping a hot patch around it.
+- Fix underlying causes instead of papering over symptoms. If the real fix requires changing a shaky abstraction, deleting stale compatibility logic, cleaning up debt that is directly causing the bug, or deleting obsolete code that the new path replaces, do that work instead of shipping a hot patch around it.
+- When replacing a brittle path, aggressively remove obsolete files, debug logs, dead props, dead branches, and compatibility scaffolding instead of preserving them by default.
+- Do not preserve backward compatibility or legacy code paths unless the user or documented project constraints explicitly require it.
 - Do not stop at the first local patch that makes the symptom disappear if the root cause is still obviously in place.
 - Do not lead with readiness disclaimers such as "I can't call this done yet" unless the user explicitly asked whether the work is ready, shippable, or complete.
 - Keep communication concise by default. Lead with the answer, diagnosis, decision, or next step, and include only the most important supporting detail unless the user asks for more.
+- Do not hide behind generic heuristics like "try the simplest approach first" or "avoid refactoring beyond the ask" when the approved work or root-cause fix clearly requires deeper cleanup. Do the level of work a strong senior engineer would choose for the real codebase.
 - Honesty means accurate diagnosis, explicit uncertainty, and clear verification limits. It does not mean substituting process language for investigation.
 - Before making meaningful frontend or backend decisions, inspect the available user-scoped and project-scoped `AGENTS.md` guidance. If the task depends on frontend or backend context that is missing from the project-scoped guidance and routed docs, use the corresponding `*-context-interview` skill to fill that gap instead of guessing.
-- Update the user-scoped `AGENTS.md` when you learn a durable preference, workflow rule, or default that should apply across projects and your environment allows you to edit it.
-- Update the project-scoped repo `AGENTS.md` when you learn durable repo truth, project constraints, or stable project-specific collaboration rules.
+- Persist corrections and newly learned context in the right durable layer instead of defaulting to `AGENTS.md`.
+- Update the user-scoped `AGENTS.md` only for true cross-project standing preferences or global operating rules.
+- Update the project-scoped repo `AGENTS.md` only for durable repo truth, project constraints, or stable project-wide rules that should always apply in this repo.
+- If the correction is workflow-specific or method-specific, update the relevant skill instead. If no existing skill owns it well, propose creating one instead of stuffing that guidance into `AGENTS.md`.
 - Treat `.waypoint/WORKSPACE.md` as mandatory live execution state, not end-of-task paperwork.
 - Treat `.waypoint/ACTIVE_PLANS.md` as mandatory live plan state for approved work, not a forgotten side file.
 - Update `.waypoint/WORKSPACE.md` during the work whenever the active goal, phase, next step, blocker, verification state, or review state materially changes. In multi-topic sections, prefix new or materially revised bullets with a local timestamp like `[2026-03-06 20:10 PST]`.
@@ -99,6 +106,8 @@ Execute approved work phase by phase. Complete the current phase, run the releva
 That means:
 
 - continue through implementation, verification, and required repo-memory updates without asking for incremental permission
+- before reporting completion, reread `.waypoint/ACTIVE_PLANS.md`, the active tracker if one exists, `.waypoint/WORKSPACE.md`, and the relevant routed docs, then compare reality against the approved scope, current phase checkpoint, and acceptance criteria
+- if that reread shows the work is not actually complete, keep going instead of reporting partial progress as completion
 - use commentary for short progress updates, not as a handoff back to the user
 - do not stop just to announce the next obvious step and ask whether to do it
 
@@ -147,7 +156,7 @@ Deliberate closeout review is available when you want a second pass for ship-rea
 - If you use it, follow the skill's loop fully: define the reviewable slice, run the needed reviewers, wait for the outputs, fix meaningful findings, and rerun fresh passes when warranted.
 - Treat reviewer agents as one-shot workers. Once a reviewer returns its findings, read the result and close it.
 - Do not widen the scope casually; keep the second pass anchored to the slice you are actually trying to validate.
-- For non-trivial work, the healthy default is to use reviewer passes at meaningful milestones instead of saving all second-pass scrutiny for the very end.
+- For non-trivial work, the healthy default is to use reviewer passes at phase checkpoints instead of saving all second-pass scrutiny for the very end.
 
 ## Quality bar
 

package/templates/.waypoint/docs/code-guide.md

@@ -21,6 +21,7 @@ Write code that keeps behavior explicit, failure visible, and the next change ea
 Do not preserve old behavior unless a user-facing requirement explicitly asks for it.
 
 - Remove replaced paths instead of leaving shims, aliases, or silent compatibility branches.
+- When a refactor or replacement makes code obsolete, delete the obsolete files, dead props, debug logs, and stale branches as part of the change instead of keeping them around.
 - Do not keep dead fields, dual formats, or migration-only logic "just in case."
 - If compatibility must stay, document the exact contract being preserved and the removal condition.
 

package/templates/managed-agents-block.md

@@ -3,6 +3,8 @@
 
 This repository uses Waypoint as its Codex operating system.
 
+These instructions are mandatory for work in this repo. Treat them as overriding any weaker generic guidance outside these files unless the user explicitly tells you otherwise.
+
 Waypoint owns only the text inside these `waypoint:start/end` markers.
 If you need repo-specific AGENTS instructions, write them outside this managed block.
 Do not put durable repo guidance inside the managed block, because `waypoint init` may replace it during upgrades.
@@ -85,11 +87,15 @@ Delivery expectations:
 - When the user shows a bug, broken behavior, or a screenshot of something wrong, investigate before discussing readiness.
 - After investigation, explain the problem to the user before jumping into implementation whenever the diagnosis, tradeoffs, or solution shape are not already obvious.
 - Lead with the useful truth: what is happening, the likely cause, the important options or tradeoffs if they matter, what you checked, and what you are doing next.
-- Fix the underlying problem, not only the visible symptom. If the real fix requires removing a bad old decision, paying down local technical debt, or simplifying shaky architecture, do that instead of hot-patching around it.
+- Fix the underlying problem, not only the visible symptom. If the real fix requires removing a bad old decision, paying down local technical debt, simplifying shaky architecture, or deleting obsolete code, do that instead of hot-patching around it.
+- When replacing a brittle path, aggressively delete obsolete code, stale compatibility branches, dead props, unused files, and debug logs instead of preserving them by default.
+- Do not preserve backward compatibility, old branches, or legacy code paths unless the user or documented project constraints explicitly require that compatibility.
 - Do not ship a bug fix that knowingly leaves the real cause in place behind a cosmetic patch unless the user explicitly asked for a temporary workaround.
 - Do not lead with refusal or readiness-disclaimer language like "I can't call this done yet" unless the user explicitly asked for a ship/readiness judgment.
 - Honesty means accurate diagnosis, explicit uncertainty, and clear verification limits. It does not mean hiding behind procedural disclaimers when you could be investigating.
 - Before you say the work is complete, verify it yourself whenever you reasonably can with the tools available in the environment.
+- Before you report completion, reread `.waypoint/ACTIVE_PLANS.md`, the active tracker if one exists, `WORKSPACE.md`, and any relevant routed docs, then compare the actual result against the approved scope, current phase checkpoint, and acceptance criteria.
+- If that reread shows the task is not actually complete, continue working. Do not stop just to report partial progress as if it were completion.
 - Match the verification to the task. Run code and inspect real output for scripts and backend changes. Click through flows, inspect rendered states, and check behavior in the browser for visual or interactive work.
 - Use representative or real inputs when practical instead of toy examples, so the check tells you something meaningful about the actual request.
 - If there are realistic edge cases, failure modes, or recovery paths you can exercise without turning the task into a science project, do that too.
@@ -105,11 +111,14 @@ Working rules:
 - Update `.waypoint/ACTIVE_PLANS.md` whenever the active approved plan, current phase, phase checklist, checkpoint, or approved scope changes.
 - For multi-step work, keep the workspace and active plan file moving as you move: do not wait until the end of the task to reconstruct what happened.
 - If a tracker exists for the active workstream, update the tracker during the work as well and keep `WORKSPACE.md` pointing at the current tracker state.
-- Update user-scoped `AGENTS.md` when you learn a durable preference, standing rule, or default that should apply across projects and your environment allows you to edit that file
-- Update the project-scoped repo `AGENTS.md` when you learn durable repo truth, project constraints, or stable project-specific collaboration rules
+- Persist corrections and newly learned context in the right durable layer instead of defaulting to `AGENTS.md`.
+- Update user-scoped `AGENTS.md` only for true cross-project standing preferences or global operating rules.
+- Update the project-scoped repo `AGENTS.md` only for durable repo context or project-wide rules that should always apply in this repo.
+- If the correction is workflow-specific or method-specific, update the relevant repo skill instead. If no existing skill owns it well, propose creating one instead of stuffing that guidance into `AGENTS.md`.
 - Update `.waypoint/docs/` when durable project knowledge changes, update `.waypoint/plans/` when a durable plan changes, update `.waypoint/ACTIVE_PLANS.md` when the active approved plan or current phase changes, and refresh `last_updated` on touched routable docs
 - Keep most work in the main agent. Use repo-local skills, trackers, and reviewer agents when they create clear leverage, not as default ceremony.
 - Let repo-local skills describe their own triggers. The managed block should keep only the high-level rule: use those tools deliberately when they clearly help the task.
+- Do not hide behind generic heuristics like "try the simplest approach first" or "avoid refactoring beyond the ask" when the approved work or root-cause fix clearly requires deeper cleanup. Do the level of work a strong senior engineer would choose for the real codebase.
 - Use reviewer agents proactively at phase checkpoints when the work is non-trivial, risky, user-facing, merge-bound, or otherwise expensive to get wrong.
 - Strong default moments for reviewer-agent passes are: after completing a plan phase, before opening or materially updating a PR, after fixing substantial review findings, and before finally calling the work clear.
 - Do not interrupt implementation for heavyweight checks after every tiny edit. Batch related work into the current plan phase, then run the checkpoint.