waypoint-codex 1.0.13 → 1.0.15

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

@@ -1,52 +1,63 @@
 ---
 name: verify-completeness
-description: Use when implementation appears done and before reporting completion. Re-read the original plan and agreed scope, re-read files that were supposed to be created or changed, verify no approved scope was reduced or skipped, and continue working until the scope is truly complete.
+description: Use when implementation appears done and before reporting completion. Re-read the approved plan and final scope, verify every in-scope file and checkpoint, and only then decide whether work can be reported complete.
 ---
 
 # Verify Completeness
 
-Use this skill at final closeout, right before you would report the work complete.
+Use this skill at final closeout, right before you would report work complete. Its job is to gate completion, not to re-open the whole project.
 
-## Required verification loop
+## Rules
 
-1. Re-read the original plan and the latest agreed scope before deciding status.
-2. Re-read `ACTIVE_PLANS.md` and `WORKSPACE.md` for current checklist, phase, blockers, and verification state.
-3. Build the expected file set from plan/scope: files that were supposed to be created, modified, or deleted.
-4. Re-read those files directly. This final re-read is mandatory even if they were read earlier in the session.
-5. Compare expected scope vs actual outcome and list any missing or partially completed items.
-6. Run a scope-discipline pass: identify additions that were not requested or approved. Remove/simplify them before completion, or explicitly ask the user to approve keeping them.
-7. Run a cleanup pass on changed files: remove duplicated logic, unnecessary abstractions/files, and low-value comments that create maintenance bloat.
-8. If changed code is still hard to read or reason about, run `legibility-pass` before completion and apply the resulting readability cleanup.
-9. Run a file-footprint sanity pass: collapse avoidable tiny-file fragmentation and keep code that changes together in the same place when boundary/reuse/size reasons are weak.
-10. Run a test-signal sanity pass: remove redundant or brittle tests and keep the smallest high-signal set that still protects the contract.
-11. Before commit/final handoff, run the full checks required by the plan (for example full typecheck/test/build sweep) once, unless explicitly blocked or the user asks for a different cadence.
-12. If any approved item is missing, incomplete, or silently deferred, do not report completion. Continue working until the agreed scope is fully satisfied or discuss a scope change explicitly.
+1. Re-read the approved plan and the latest agreed scope before deciding status.
+2. Re-read `ACTIVE_PLANS.md` and `WORKSPACE.md` for the current checklist, phase, blockers, and verification state.
+3. Build the expected file set from the approved scope only: files that were supposed to be created, modified, or deleted.
+4. Re-read every file in the expected set directly. This final re-read is mandatory even if the file was read earlier in the session.
+5. Compare expected scope vs actual outcome and identify any missing, partial, or silently deferred items.
+6. Run required plan checkpoints at the required cadence, including the full pre-commit checks when the plan requires them, unless a bounded exception applies.
+7. Do not report completion if any approved item is missing, incomplete, or deferred without explicit approval.
+8. Do not keep unapproved additions, cleanup work, refactors, abstractions, file splits, or test pruning in this skill's core scope; treat them as separate decisions that require explicit approval unless they are needed to finish the approved scope.
+9. If changed code is still hard to read or reason about, run `legibility-pass` and apply only the readability cleanup required to finish the approved scope.
+10. Keep adjacent skills conditional and narrow: use them only when the verification pass exposes that specific need, not as part of the default completion gate.
 
-## Completion gate
+## Exception Rule
+
+You may relax the normal verification loop only when one of these is true:
+
+- required plan artifacts are missing or stale, and you need to reconstruct the approved scope before continuing
+- the task is read-only or review-only, so no code or files are expected to change
+- required checks cannot run because the environment, dependencies, permissions, or upstream blockers make them impossible right now
+
+In these cases, continue only far enough to identify the gap, record the blocker, and report the exact missing verification step or artifact. Do not use the exception to absorb cleanup, refactor, or scope expansion work.
+
+## Completion Gate
 
 You can report complete only when all are true:
 
 - approved scope items are done
 - planned file changes match reality
-- verification/checkpoints required by the plan were run at the required cadence, including full pre-commit checks when required (or explicitly called out as blocked)
+- required verification/checkpoints were run, or each skipped check has a specific blocked reason
 - no hidden scope reduction occurred
 - no unapproved scope expansion remains
 - no obvious duplication or avoidable bloat remains in touched files
 - no avoidable file fragmentation remains in touched feature areas
 - test set remains high-signal and non-redundant for the risk level
 
-## Output contract
+## Output Contract
+
+Before final status, report these items explicitly:
 
-Before final status, summarize briefly:
+- `status`: `complete`, `blocked`, or `incomplete`
+- `scope reviewed`: the plan/scope sources you re-read
+- `files re-read`: the files you re-opened for final verification
+- `missing scope items`: any approved items still absent, or `none`
+- `checks run`: each verification step actually executed
+- `checks skipped`: each omitted check with a reason, or `none`
+- `removed extras`: any unapproved extras, cleanup, or bloat you removed, or `none`
+- `adjacent skill escalation`: any conditional skill you invoked and why, or `none`
+- `next action`: continue execution, request scope approval, or complete
 
-- scope reviewed
-- files re-read for final verification
-- completed items
-- removed unapproved extras or bloat cleanup applied
-- legibility cleanup applied (if run)
-- file-collapsing or test-pruning done during sanity passes
-- remaining gaps (if any)
-- next action (continue execution or complete)
+Do not say the work is complete unless the `status` is `complete` and the completion gate is satisfied.
 
 ## Gotchas
 

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

@@ -1,4 +1,4 @@
 interface:
   display_name: "Verify Completeness"
-  short_description: "Run a strict final scope and file verification pass"
-  default_prompt: "Use $verify-completeness now: re-read the approved plan and scope, re-read all files that were supposed to change, remove unapproved extras and obvious bloat, verify nothing was dropped, and keep working if any approved scope item is still incomplete."
+  short_description: "Gate completion by re-reading scope, files, and required checks before closeout"
+  default_prompt: "Use $verify-completeness now: re-read the approved plan and final scope, re-read every file that was supposed to change, confirm missing scope items and skipped checks with reasons, and only report completion if the approved scope is fully finished."

package/templates/.codex/agents/duplicate_ownership_explorer.toml

@@ -0,0 +1,17 @@
+name = "duplicate_ownership_explorer"
+description = "Read-only explorer for one bounded slice of duplicate ownership. Use one agent per feature or contract slice."
+model = "gpt-5.3-codex"
+model_reasoning_effort = "medium"
+sandbox_mode = "read-only"
+nickname_candidates = ["Slice", "Scout", "Trace"]
+developer_instructions = """
+Own one narrow slice only.
+Look for duplicate ownership of rules such as validation, defaults, canonicalization, mapping, repair, persistence policy, and helper semantics.
+For each candidate, decide whether it is:
+- architecture / SSOT bug
+- local dedupe cleanup
+- legitimate boundary adapter
+- legitimate domain constraint
+Return exact files and symbols.
+Do not recommend wrappers, shims, or fallback paths.
+"""

package/templates/.codex/agents/ownership_taxonomy_mapper.toml

@@ -0,0 +1,16 @@
+name = "ownership_taxonomy_mapper"
+description = "Read-only mapper for duplicate-ownership audits. Use first to identify likely SSOT conflicts, ownership boundaries, and exploration slices before deeper review."
+model = "gpt-5.3-codex"
+model_reasoning_effort = "medium"
+sandbox_mode = "read-only"
+nickname_candidates = ["Mapper", "Topo", "Surveyor"]
+developer_instructions = """
+Stay in exploration mode.
+Map ownership boundaries, not fixes.
+Find likely places where the same rule is owned twice.
+Return:
+- candidate taxonomy
+- likely hot spots
+- recommended slice boundaries for parallel follow-up
+Do not propose compatibility shims or code changes unless the parent asks.
+"""

package/templates/.codex/agents/ssot_judge.toml

@@ -0,0 +1,17 @@
+name = "ssot_judge"
+description = "Strict read-only judge for duplicate-ownership findings. Use after exploration to decide the winning owner and hard-cut cleanup."
+model = "gpt-5.3-codex"
+model_reasoning_effort = "high"
+sandbox_mode = "read-only"
+nickname_candidates = ["Judge", "Owner", "Verdict"]
+developer_instructions = """
+Act like an architecture owner.
+Given candidate duplicate-ownership findings, decide:
+- is this real duplicate ownership or legitimate boundary work
+- who should be the single owner
+- what should be deleted
+- what should remain
+- what should be renamed for honest semantics
+Bias toward hard-cut cleanup.
+Reject mediator layers, wrappers, compatibility paths, and dual ownership.
+"""

package/templates/.codex/config.toml

@@ -16,3 +16,15 @@ config_file = "agents/code-reviewer.toml"
 [agents."plan-reviewer"]
 description = "Read-only plan validator that checks whether a proposed implementation plan is complete, feasible, and safe to execute."
 config_file = "agents/plan-reviewer.toml"
+
+[agents."ssot_judge"]
+description = "Strict read-only judge for duplicate-ownership findings that selects the canonical owner and hard-cut cleanup."
+config_file = "agents/ssot_judge.toml"
+
+[agents."ownership_taxonomy_mapper"]
+description = "Read-only mapper that identifies ownership boundaries and high-risk SSOT duplicate-ownership slices before deeper audits."
+config_file = "agents/ownership_taxonomy_mapper.toml"
+
+[agents."duplicate_ownership_explorer"]
+description = "Read-only slice explorer that audits one bounded area for duplicate ownership and classifies findings with file-level evidence."
+config_file = "agents/duplicate_ownership_explorer.toml"

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

@@ -1,86 +0,0 @@
----
-name: adversarial-review
-description: Second-pass closeout review for a non-trivial implementation slice. Use when risky work needs a deliberate final review before being called done. This skill scopes the slice, runs the right reviewer agents and code-guide checks, fixes meaningful findings, and repeats until only optional polish remains.
----
-
-# Adversarial Review
-
-Use this skill when you explicitly want a closeout-grade second pass before calling a non-trivial slice done or ready to ship.
-
-This skill coordinates the specialist reviewers, keeps the scope tight, waits as long as needed, fixes meaningful findings, and reruns fresh review rounds until the remaining feedback is only optional polish or no findings at all.
-
-## When To Skip This Skill
-
-- Skip it for tiny obvious edits where launching the full closeout loop would be noise.
-- Skip it for normal debugging or investigation where the user needs diagnosis and forward motion more than formal ship-readiness.
-- Skip it for pre-implementation planning; that is `plan-reviewer` territory.
-- Skip it for active PR comment back-and-forth; use `pr-review` for that workflow.
-- Skip it when the user wants a one-off targeted coding-guide check and not the full closeout loop; use `code-guide-audit` directly in that case.
-
-## Step 1: Define The Reviewable Slice
-
-- Resolve the exact slice you are trying to close out before launching reviewers.
-- Prefer a recent self-authored commit when one cleanly represents the slice.
-- Otherwise use the current changed files, diff, or feature path.
-- Pass the reviewers the same concrete scope anchor, plus a short plain-English summary of what changed.
-- If the scope is muddy, tighten it before review instead of asking the reviewers to figure it out from an entire worktree.
-
-## Step 2: Launch The Required Reviewers
-
-- Spawn `code-reviewer` for every non-trivial implementation slice.
-- Spawn `code-health-reviewer` when the change is medium or large, especially when it adds structure, duplicates logic, or introduces new abstractions.
-- Run `code-guide-audit` on the same scoped slice as part of the closeout loop.
-- Launch the reviewer agents with `fork_context: false`, `model: gpt-5.4`, and `reasoning_effort: high` unless the user explicitly asked for something else.
-- Tell the reviewer agents what changed, what scope anchor to use, and which files or feature area represent the slice under review.
-- When both reviewer agents apply, launch them in parallel.
-
-## Step 3: Wait For The Round To Finish
-
-- Wait for every required reviewer result, no matter how long it takes.
-- Do not interrupt slow reviewer agents just because they are still running.
-- Do not call the work done while a required reviewer round is still in flight.
-- Read the full reviewer outputs before deciding what to fix.
-
-## Step 4: Fix Meaningful Findings
-
-- Fix real correctness, regression, maintainability, and code-guide issues.
-- Rerun the most relevant verification for the changed area after the fixes.
-- If a reviewer comment is only a nit or clearly optional polish, note that distinction and do not keep reopening the loop just to satisfy minor taste differences.
-- If a finding changes durable behavior or repo memory, update the relevant docs and workspace state before the next round.
-
-## Step 5: Close The Old Review Round
-
-- Treat `code-reviewer` and `code-health-reviewer` as one-shot reviewer agents.
-- After you have read a reviewer result, close that reviewer thread.
-- If another pass is needed later, spawn a fresh reviewer instead of reusing the old thread.
-
-## Step 6: Repeat Until The Slice Is Actually Clear
-
-- Start a fresh round whenever you made meaningful fixes in response to the previous round.
-- Reuse the same scope anchor when it still represents the slice cleanly; otherwise hand the new round the updated changed-file set or follow-up commit.
-- Rerun `code-guide-audit` when the fixes materially changed guide-relevant behavior or when the previous round surfaced guide-related issues.
-- Stop only when no meaningful findings remain. Optional polish and obvious nitpicks do not block closeout.
-
-## Step 7: Report The Closeout State
-
-Summarize:
-
-- what scope was reviewed
-- which reviewers ran
-- what meaningful issues were fixed
-- what verification ran
-- whether the slice is now clear or what still blocks it
-
-## Gotchas
-
-- Fresh reviewer rounds matter. If you make meaningful fixes, do not treat older reviewer findings as if they still describe the current code.
-- Green local tests are not enough if required reviewer threads are still running. Wait for the actual reviewer outputs before calling the slice done.
-- Close reviewer agents after each round. Reusing a stale reviewer thread weakens the signal and blurs which code state the findings apply to.
-- When this loop changes repo-health or upgrade behavior, test real old-repo edge cases, not just fresh-init cases.
-- If a reviewer result is clean, it should still name the key paths and related files it checked. A "looks fine" skim is not a real closeout pass.
-
-## Keep This Skill Sharp
-
-- After meaningful runs, add new gotchas when the same review-loop failure, stale-review mistake, or repo-upgrade edge case is likely to happen again.
-- Tighten the description if the skill fires too broadly or misses real prompts like "final review pass" or "before we call this done."
-- If the loop keeps re-creating the same helper logic or review instructions, move that reusable logic into the skill or its supporting resources instead of leaving it in chat.

package/templates/.agents/skills/adversarial-review/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Adversarial Review"
-  short_description: "Run a deliberate second-pass closeout review"
-  default_prompt: "Use $adversarial-review when this non-trivial implementation slice needs a deliberate final review loop with reviewer agents and code-guide checks before we call it done."

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

@@ -1,86 +0,0 @@
----
-name: code-guide-audit
-description: Audit a scoped implementation slice against the code guide and report only guide-related violations or risks. Use for coding-guide compliance checks on explicit behavior, root-cause fixes, boundary validation, security, concurrency, accessibility, performance, and future legibility.
----
-
-# Code Guide Audit
-
-Use this skill for a targeted audit against the coding guide, not for a whole-repo hygiene sweep.
-
-This skill owns one job: inspect the specific code the user points at, map it against the coding guide, and report only guide-related findings in that scope.
-
-## When Not To Use This Skill
-
-- Skip it for broad ship-readiness review; use a ship-audit workflow for that.
-- Skip it for generic bug finding or regression review that is not specifically about the coding guide.
-- Skip it for active PR comment triage; use `pr-review` for that loop.
-- Skip it for repo-wide cleanup unless the user explicitly asked for a repo-wide coding-guide audit.
-
-## Step 1: Load The Right Scope
-
-- 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.
-
-Do not expand into a whole-repo audit unless the user explicitly asks for that.
-
-## Step 2: Translate The Guide Into Checks
-
-Audit only for rules that actually apply to the scoped code.
-
-Look for:
-
-- stale compatibility layers, shims, aliases, or migration-only branches
-- weak typing, avoidable `any`, recreated shared types, or unsafe casts
-- silent fallbacks, swallowed errors, degraded paths, or missing required-config failures
-- missing validation at input, config, API, file, queue, or database boundaries
-- speculative abstractions that hide the actual behavior
-- unclear state transitions, weak transaction boundaries, missing idempotency, or weak persistence invariants
-- frontend code that ignored reusable components or broke the existing design language
-- missing loading, empty, or error states
-- optimistic UI without rollback or invalidation
-- missing observability at important failure or state boundaries
-- regression tests that assert implementation details instead of behavior
-
-Skip rules that genuinely do not apply, but say that you skipped them.
-
-## Step 3: Keep The Audit Narrow
-
-- Report only coding-guide findings for the requested scope.
-- Do not drift into generic architecture advice, repo-wide cleanup, docs sync, or PR readiness unless the finding is directly required by the guide.
-- If you notice issues outside scope, mention them only if they are severe enough that ignoring them would mislead the user about this audit.
-
-## Step 4: Verify Evidence
-
-Ground each finding in the actual code.
-
-- Read the real implementation before calling something a violation.
-- When relevant, inspect the nearest tests, contracts, schemas, or reused components to confirm the gap.
-- Do not invent verification that you did not run.
-
-If the user asked for a pure audit, stop at findings. If they asked for fixes too, fix the clear issues and then verify the changed area.
-
-## Step 5: Report The Result
-
-Summarize the scoped result in review style:
-
-- findings first, ordered by severity
-- each finding tied back to the relevant coding-guide rule
-- include exact file references
-- then note any skipped guide areas or residual uncertainty
-
-## Gotchas
-
-- Do not turn this into generic code review. Every finding should tie back to a specific coding-guide rule.
-- Do not audit the whole repo by accident. Resolve the narrow slice first, then stay inside it unless an out-of-scope issue would seriously mislead the user.
-- Do not report a guide violation from a grep hit alone. Read the real implementation and the nearby evidence before calling it a problem.
-- Do not force every coding-guide rule onto every change. Skip non-applicable rules explicitly instead of inventing weak findings.
-- If you notice a broader ship-risk issue that is not really a coding-guide issue, say it is outside this skill's scope instead of quietly drifting into another audit.
-
-## Keep This Skill Sharp
-
-- After meaningful runs, add new gotchas when the same guide-specific failure mode or scope-drift mistake keeps recurring.
-- Tighten the description if the skill fires on generic review requests or misses real prompts like "check this against the code guide."
-- If the same guide-rule translation logic keeps repeating, move that reusable detail into a supporting reference instead of expanding the hub file.

package/templates/.agents/skills/code-guide-audit/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Code Guide Audit"
-  short_description: "Audit code-guide compliance on a scoped slice"
-  default_prompt: "Use $code-guide-audit to audit this specific feature, file set, or implementation slice against the coding guide."