slash-do 1.7.0 → 1.9.0

package/commands/do/better-swift.md

@@ -56,7 +56,7 @@ When compacting during this workflow, always preserve:
 - All CRITICAL/HIGH findings with file:line references
 - The current phase number and what phases remain
 - All PR numbers and URLs created so far
-- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR` values
+- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR`, `REPO_DIR` values
 - `VCS_HOST`, `CLI_TOOL`, `DEFAULT_BRANCH`, `CURRENT_BRANCH`
 - `PLATFORMS` (list of supported platforms: iOS, macOS, etc.)
 - `DEPLOYMENT_TARGETS` (minimum OS versions per platform)
@@ -154,6 +154,7 @@ If the project has a `Makefile` or `fastlane/Fastfile`, check for custom build/t
 Record as `BUILD_CMD` and `TEST_CMD`.
 
 ### 0d: State Snapshot
+- Record `REPO_DIR` via `git rev-parse --show-toplevel`
 - Record `CURRENT_BRANCH` via `git rev-parse --abbrev-ref HEAD`
 - Record `DEFAULT_BRANCH` via `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` (or `glab` equivalent)
 - Record `IS_DIRTY` via `git status --porcelain`
@@ -567,12 +568,36 @@ Before creating PRs, run a deep code review on all remediation changes to catch
      question: "Code review complete. {N} issues found and fixed. {list}. All {PLATFORMS} platforms build and test successfully. Proceed to PR creation?",
      options: [
        { label: "Proceed", description: "Create per-category PRs" },
+       { label: "Commit directly", description: "Merge worktree changes into {CURRENT_BRANCH} — no PRs, no review loops" },
        { label: "Show diff", description: "Show the full diff for manual review before proceeding" },
        { label: "Abort", description: "Stop here — I'll review manually" }
      ]
    }])
    ```
 5. If "Show diff" selected, print the diff and re-ask. If "Abort", stop and print the worktree path.
+6. If "Commit directly" selected:
+   - All remediation and review fixes are already committed incrementally in the worktree branch `better-swift/{DATE}`. If any uncommitted changes remain, stage and commit them now:
+     ```bash
+     cd {WORKTREE_DIR}
+     git diff --quiet && git diff --cached --quiet || {
+       git add <list of remaining changed files>
+       git commit -m "fix: better-swift audit remediation — remaining changes"
+     }
+     ```
+   - Return to the main repo checkout, merge the worktree branch, and clean up on success:
+     ```bash
+     cd {REPO_DIR}
+     git checkout {CURRENT_BRANCH}
+     if git merge better-swift/{DATE}; then
+       git worktree remove {WORKTREE_DIR}
+       git branch -D better-swift/{DATE}
+     else
+       echo "Merge conflict — resolve in {REPO_DIR}, then run:"
+       echo "  git worktree remove {WORKTREE_DIR}"
+       echo "  git branch -D better-swift/{DATE}"
+     fi
+     ```
+   - Restore stash if needed (`git stash pop`), update PLAN.md, print final summary, then **stop** — this completes the workflow (Phases 5, 6, and 7 are skipped entirely since no PRs or category branches were created)
 
 ## Phase 4c: Test Enhancement
 

package/commands/do/better.md

@@ -56,7 +56,7 @@ When compacting during this workflow, always preserve:
 - All CRITICAL/HIGH findings with file:line references
 - The current phase number and what phases remain
 - All PR numbers and URLs created so far
-- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR` values
+- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR`, `REPO_DIR` values
 - `VCS_HOST`, `CLI_TOOL`, `DEFAULT_BRANCH`, `CURRENT_BRANCH`
 - `PHASE_4C_START_SHA` (needed for FILE_OWNER_MAP update in Phase 4c.3)
 - `VACUOUS_TESTS_FIXED`, `WEAK_TESTS_STRENGTHENED`, `NEW_TEST_CASES`, `NEW_TEST_FILES`
@@ -96,6 +96,7 @@ Derive build and test commands from the project type:
 Record as `BUILD_CMD` and `TEST_CMD`.
 
 ### 0d: State Snapshot
+- Record `REPO_DIR` via `git rev-parse --show-toplevel`
 - Record `CURRENT_BRANCH` via `git rev-parse --abbrev-ref HEAD`
 - Record `DEFAULT_BRANCH` via `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` (or `glab` equivalent)
 - Record `IS_DIRTY` via `git status --porcelain`
@@ -375,12 +376,36 @@ Before creating PRs, run a deep code review on all remediation changes to catch
      question: "Code review complete. {N} issues found and fixed. {list}. Proceed to PR creation?",
      options: [
        { label: "Proceed", description: "Create per-category PRs" },
+       { label: "Commit directly", description: "Merge worktree changes into {CURRENT_BRANCH} — no PRs, no review loops" },
        { label: "Show diff", description: "Show the full diff for manual review before proceeding" },
        { label: "Abort", description: "Stop here — I'll review manually" }
      ]
    }])
    ```
 5. If "Show diff" selected, print the diff and re-ask. If "Abort", stop and print the worktree path.
+6. If "Commit directly" selected:
+   - All remediation and review fixes are already committed incrementally in the worktree branch `better/{DATE}`. If any uncommitted changes remain, stage and commit them now:
+     ```bash
+     cd {WORKTREE_DIR}
+     git diff --quiet && git diff --cached --quiet || {
+       git add <list of remaining changed files>
+       git commit -m "fix: better audit remediation — remaining changes"
+     }
+     ```
+   - Return to the main repo checkout, merge the worktree branch, and clean up on success:
+     ```bash
+     cd {REPO_DIR}
+     git checkout {CURRENT_BRANCH}
+     if git merge better/{DATE}; then
+       git worktree remove {WORKTREE_DIR}
+       git branch -D better/{DATE}
+     else
+       echo "Merge conflict — resolve in {REPO_DIR}, then run:"
+       echo "  git worktree remove {WORKTREE_DIR}"
+       echo "  git branch -D better/{DATE}"
+     fi
+     ```
+   - Restore stash if needed (`git stash pop`), update PLAN.md, print final summary, then **stop** — this completes the workflow (Phases 5, 6, and 7 are skipped entirely since no PRs or category branches were created)
 
 ## Phase 4c: Test Enhancement
 

package/commands/do/replan.md

@@ -1,212 +1,181 @@
 ---
-description: Review and clean up PLAN.md, extract docs from completed work
+description: Automated audit/triage of PLAN.md — archive completed items to DONE.md, suggest new work, keep PLAN.md lean
 ---
 
 # Replan Command
 
-You are tasked with reviewing and updating the PLAN.md file to keep it clean, current, and action-oriented.
+Automatically audit PLAN.md against the codebase, prune completed/stale items, archive what's done, suggest new work, and leave PLAN.md lean and actionable.
 
-**This is an interactive process.** Do NOT assume items are still pending or still relevant. Verify with the user.
+**Philosophy:** PLAN.md should be short enough to paste into a prompt. Completed items belong in a done log, not cluttering the active plan.
 
 ## Boundary Rule: PLAN.md vs GOALS.md
 
 **PLAN.md is tactical. GOALS.md is strategic.**
 
-PLAN.md answers: *What are we building next? What's the backlog? What's done?*
+PLAN.md answers: *What are we building next? What's the backlog?*
 GOALS.md answers: *Why does this project exist? What does success look like? What will we never do?*
 
-**PLAN.md owns:**
-- Checkbox task lists (`- [ ] Add feature X`)
-- Implementation details, subtasks, and technical steps
-- Known issues and testing gaps
-- Prioritized next-action lists
-- Completed work archive
-- Documentation index
-
-**PLAN.md must NOT duplicate:**
+**PLAN.md must NOT contain:**
 - Mission statements, core tenets, or non-goals (those belong in GOALS.md)
-- Milestone definitions written as outcome prose (GOALS.md territory)
-
-**Cross-reference:** PLAN.md should link to GOALS.md for strategic context, and GOALS.md should link back to PLAN.md for tactical details.
-
-## Your Responsibilities
+- Completed items (those belong in `DONE.md`)
+- Detailed documentation (those belong in `docs/`)
 
-### 1. Gather Evidence
+## Phase 1: Automated Evidence Gathering
 
-Before touching PLAN.md, gather signals about what's actually happened since the plan was last updated. Run these in parallel:
+Launch these agents in parallel — no user interaction needed yet.
 
-**Agent 1: Git History**
-```bash
-git log --oneline -30
-```
-Look for commits that may have completed items listed in PLAN.md.
+**Agent 1: Git History Analysis**
+- `git log --oneline -50` — identify commits that completed plan items
+- `git log --since="2 weeks ago" --oneline` — surface recent work not yet reflected in the plan
+- Cross-reference commit messages against pending PLAN.md items to auto-detect completions
 
-**Agent 2: Codebase Scan**
-Search for evidence that "pending" items may already be implemented:
-- Grep for function names, component names, or feature keywords mentioned in pending items
+**Agent 2: Codebase Verification**
+- For each pending item in PLAN.md, grep for function names, component names, or feature keywords
 - Check test files for coverage of features listed as untested
 - Look at recently modified files for signs of completed work
+- Build a confidence score per item: `confirmed-done`, `likely-done`, `still-pending`, `stale`
 
-**Agent 3: GOALS.md Boundary Check**
+**Agent 3: Opportunity Scanner**
+- Scan for TODOs, FIXMEs, HACKs in the codebase that aren't in PLAN.md
+- Look for test coverage gaps (files with no corresponding test)
+- Check for outdated dependencies (`npm outdated`, `cargo outdated`, etc. as appropriate)
+- Review GOALS.md (if it exists) for strategic goals not yet represented in the plan
+- Identify code quality opportunities (large files, complex functions, missing error handling)
+- Formulate 1-3 suggested new items to propose to the user
+
+**Agent 4: GOALS.md Boundary Check**
 If `GOALS.md` exists:
-- Read it and check for checkbox task lists or implementation details that leaked in
+- Check for checkbox task lists or implementation details that leaked in
 - Note any items that should be absorbed into PLAN.md
 
-### 2. Interactive Item Review
-
-**This is the most important step. Do NOT skip it.**
+## Phase 2: Auto-Triage (No User Input)
 
-Walk through PLAN.md with the user, section by section. For each section that has pending items, present your findings and ask the user to confirm status.
+Using agent results, automatically classify every PLAN.md item:
 
-**For each group of related pending items**, use `AskUserQuestion` to verify. Batch related items together (don't ask one-by-one for 20 items). For example:
+| Status | Criteria | Action |
+|--------|----------|--------|
+| `confirmed-done` | Git commit + code exists + tests pass | Move to DONE.md |
+| `likely-done` | Strong evidence but not 100% certain | Present to user for confirmation |
+| `stale` | No commits, no code, no recent discussion; item is >30 days old with zero progress | Flag for removal |
+| `still-pending` | No evidence of completion | Keep in PLAN.md |
 
-```
-I found these items still marked as pending under "Testing Gaps":
-- [ ] Server route unit tests
-- [ ] Aggregate calculation tests
-- [ ] Visual regression tests for charts
+## Phase 3: Single Interactive Checkpoint
 
-Git history shows commits for "add server route tests" on Feb 15.
-I also found test files at packages/server/test/routes/.
+Present ONE consolidated summary to the user. Keep it tight:
 
-Which of these are actually done?
+```
+AskUserQuestion([{
+  question: "Replan audit complete. Here's what I found:\n\n**Auto-archiving to DONE.md** ({N} items):\n{list of confirmed-done items}\n\n**Likely done — confirm?** ({M} items):\n{list with evidence}\n\n**Flagged as stale** ({S} items):\n{list with last-activity dates}\n\n**New suggestions** ({P} items):\n{numbered list of proposed new items with rationale}\n\nHow should I proceed?",
+  multiSelect: true,
+  options: [
+    { label: "Archive confirmed-done", description: "Move {N} confirmed items to DONE.md" },
+    { label: "Archive likely-done too", description: "Also move {M} likely-done items to DONE.md" },
+    { label: "Remove stale items", description: "Delete {S} stale items from PLAN.md" },
+    { label: "Add suggested items", description: "Add {P} new items to PLAN.md" }
+  ]
+}])
 ```
 
-**How to batch the review:**
-- Group items by section (Next Up, Remaining Work, Future, etc.)
-- Present each group with any evidence you found (git commits, files that exist, grep matches)
-- Ask the user to confirm: which are done, which are still needed, which should be removed or rephrased
-- Use multiSelect questions when asking about multiple items (let the user check off what's done)
-- If a section has no evidence of changes, still ask briefly: "These items under [section] — still accurate, or any updates?"
+**Exclusive options** (present only if the user asks, as a separate follow-up):
+- "Show me the details" — print full evidence, then re-ask the above
+- "Just clean up formatting" — only reformat PLAN.md, skip all archive/remove/add actions
 
-**For known issues**, ask whether they're still reproducible or have been fixed.
+If the user selects "Show me the details" as a response, print the full evidence and re-ask.
 
-**For "Next Actions" / priority ordering**, ask if the priorities still reflect the user's current thinking.
+For suggested new items: if the user selects "Add suggested items", present each suggestion individually so they can accept, reject, or modify each one.
 
-### 3. Extract Documentation from Completed Work
+## Phase 4: Archive to DONE.md
 
-For each completed item with substantial documentation:
-- Determine the appropriate docs location (create docs/ directory if needed)
-- Extract the detailed documentation sections
-- Move them to appropriate docs files with proper formatting
-- Follow existing documentation patterns if they exist
+`DONE.md` lives at project root. It's the append-only log of completed work.
 
-**Common docs files to consider:**
-- `docs/ARCHITECTURE.md` - System design, data flow, architecture
-- `docs/API.md` - API endpoints, schemas, events
-- `docs/TROUBLESHOOTING.md` - Common issues and solutions
-- `docs/features/*.md` - Individual feature documentation
-- `README.md` - User-facing documentation
+### Format
 
-### 4. Clean Up PLAN.md
+```markdown
+# Done Log
 
-Using the verified information from the interactive review:
-- Mark confirmed-completed items as [x] and move to archive
-- Remove items the user confirmed are no longer relevant
-- Update wording for items the user rephrased
-- Replace detailed documentation with brief summaries + doc links
-- Remove redundant or outdated information
+Completed items archived from PLAN.md. For release notes, see `.changelogs/`.
 
-**Example transformation:**
-```markdown
-Before:
-- [x] Feature X: Authentication System
+## 2026-03-16
+
+- Implemented feature X — added auth middleware and JWT validation
+- Fixed bug Y — null check on user profile load
+- Refactored Z — extracted shared utilities from monolithic handler
 
-### Architecture
-- **Auth Service**: Core authentication logic
-- **JWT Tokens**: Token generation and validation
-[... 50 more lines of detailed docs ...]
+## 2026-03-10
 
-After:
-- [x] Feature X: Authentication System - JWT-based auth with session management. See [Authentication](./docs/features/authentication.md)
+- Added CI pipeline for staging deploys
+- Test coverage for API routes
 ```
 
-### 5. Update Documentation Index
-- Ensure PLAN.md references all relevant docs files
-- Add any new docs files you created
-- Verify all links are correct
-- Add a Documentation section if it doesn't exist
+### Rules
 
-### 6. Rewrite Next Actions
+- Group by date (newest first)
+- One line per item — concise description of what was done, not the original checkbox text
+- If the completed item had substantial documentation (>20 lines), extract it to `docs/` and add a link: `- Feature X — see [docs/features/x.md](./docs/features/x.md)`
+- Do NOT duplicate changelog entries — DONE.md captures plan-item completion, changelogs capture release-level changes
 
-Based on the interactive review, rebuild the "Next Actions" section:
-- Ask the user: "Based on what's left, what are your top 3-5 priorities right now?"
-- Present a suggested ordering based on what you learned, but let the user override
-- Make action items specific and actionable
+## Phase 5: Rebuild PLAN.md
 
-### 7. Absorb GOALS.md Violations
+Rewrite PLAN.md to be lean and actionable:
 
-If you found checkbox items or tactical details in GOALS.md during step 1:
-- Show the user what you found
-- Offer to move them into the appropriate PLAN.md section
-- Update GOALS.md to remove the tactical items (replace with outcome prose or remove entirely)
+### Target Structure
 
-### 8. Commit Your Changes
-After reorganizing (if in a git repository):
-- Commit changes with a clear message like:
-  ```
-  docs: reorganize PLAN.md and extract completed work to docs
+```markdown
+# Development Plan
 
-  - Moved completed feature docs to docs/features/
-  - Updated PLAN.md to focus on next actions
-  - Added Next Actions section
-  ```
+For project mission and milestones, see [GOALS.md](./GOALS.md).
+For completed work, see [DONE.md](./DONE.md).
 
-## Guidelines
+## Next Up
 
-- **Verify, don't assume**: The whole point of this command is to sync PLAN.md with reality. Never mark items as done or still-pending without checking.
-- **Be thorough**: Read all completed items and assess documentation value
-- **Be surgical**: Only move substantial documentation (>20 lines), keep brief summaries in PLAN
-- **Be organized**: Group related content in docs files with clear headings
-- **Be consistent**: Match the style and format of existing docs files
-- **Be helpful**: Make it easy to find information by adding clear references
-- **Respect boundaries**: Tactical items in PLAN.md, strategic items in GOALS.md
-- **Batch intelligently**: Don't ask 20 individual questions — group related items and ask about sections at a time. Aim for 3-6 interactive checkpoints, not 20.
+1. **Item A**: Brief actionable description
+2. **Item B**: Brief actionable description
+3. **Item C**: Brief actionable description
 
-## Example Output Structure
+## Backlog
 
-After running `/replan`, the PLAN.md should have:
-```markdown
-# Project Name - Development Plan
+- [ ] Item D: Description
+- [ ] Item E: Description
 
-The tactical backlog. For mission and milestones, see [GOALS.md](./GOALS.md).
+## Future / Ideas
 
-## Documentation
-- [Architecture Overview](./docs/ARCHITECTURE.md)
-- [API Reference](./docs/API.md)
+- Item F: One-line description
+- Item G: One-line description
+```
 
-## Next Up
-- [ ] Feature C: Brief description with subtasks
+### Guidelines
 
-## Remaining Work
-### Known Issues
-- ...
-### Testing Gaps
-- [ ] ...
+- **"Next Up" is ordered** — numbered list, max 5 items, these are the immediate priorities
+- **"Backlog" is unordered** — checkbox items that are planned but not prioritized
+- **"Future / Ideas" has no checkboxes** — these are possibilities, not commitments
+- **No completed items** — they're in DONE.md
+- **No detailed docs** — link to `docs/` files instead
+- **No section if it's empty** — don't include "Backlog" with zero items
 
-## Future (v2.0+)
-- [ ] Feature D: Brief description of planned work
+## Phase 6: Absorb GOALS.md Violations
 
-## Next Actions
+If tactical items (checkboxes, implementation details) were found in GOALS.md:
+- Move them into the appropriate PLAN.md section
+- Update GOALS.md to remove tactical content
 
-1. **Task 1**: Brief description of what needs to be done
-2. **Task 2**: Brief description of next task
-3. **Task 3**: Brief description of another task
+## Phase 7: Commit
 
-## Completed Work (Archive)
-<details>
-<summary>v0.x Features</summary>
-- [x] Feature A - See [Feature A Docs](./docs/features/feature-a.md)
-- [x] Feature B - See [Feature B Docs](./docs/features/feature-b.md)
-</details>
+Stage and commit all files modified during this replan:
+```bash
+git add PLAN.md
+# Stage optional files only if they exist and were modified
+git add DONE.md 2>/dev/null || true
+git add GOALS.md 2>/dev/null || true
+git add docs/ 2>/dev/null || true
+git commit -m "docs: replan — archive {N} completed items, update priorities"
 ```
 
+Do NOT push unless explicitly asked.
+
 ## Notes
 
-- Don't delete information - move it to appropriate docs files
-- Keep related information consolidated in single docs files
-- Create feature-specific docs in docs/features/ for complex systems
-- Preserve all historical information but organize it better
-- If no PLAN.md exists, inform the user rather than creating one
-- Adapt to the existing structure and conventions of the project
-- If GOALS.md has task lists that belong in PLAN.md, migrate them
+- If no PLAN.md exists, inform the user and offer to create one from codebase analysis
+- The opportunity scanner suggestion is the key differentiator — every replan should surface at least one new idea
+- DONE.md is append-only — never delete entries from it
+- Keep PLAN.md under ~50 lines whenever possible — it should be scannable in seconds
+- Adapt to existing project structure and conventions

package/commands/do/review.md

@@ -212,6 +212,10 @@ Check every file against this checklist. The checklist is organized into tiers
 **Formatting & structural consistency**
 - If the PR adds content to an existing file (list items, sections, config entries), verify the new content matches the file's existing indentation, bullet style, heading levels, and structure — rendering inconsistencies are the most common Copilot review finding
 
+**Dependent operation ordering**
+- If a handler orchestrates multiple operations (primary write + side effects like rewards, uploads, notifications), trace the dependency graph — verify side effects only execute after the primary operation confirms success. Watch for `Promise.all` grouping operations that should be sequential because one depends on the other's outcome, and for resource allocation (file uploads, external API calls) happening before a gate operation (lock acquisition, uniqueness check, validation) that may reject the request
+- If the PR handles file uploads or binary data, verify the server validates content independently of client-supplied metadata — check MIME type via magic bytes, size via buffer length, and content validity via actual parsing rather than trusting request headers or middleware-provided fields
+
 **Bulk vs single-item operation parity**
 - If the PR modifies a single-item CRUD operation (create, update, delete) to handle new fields or apply new logic, trace the corresponding bulk/batch operation for the same entity — it often has its own independent implementation that won't pick up the change. Verify both paths handle the same fields, apply the same validation, and preserve the same secondary data
 

package/lib/code-review-checklist.md

@@ -31,7 +31,7 @@
 
    **Trust boundaries & data exposure**
    - API responses returning full objects with sensitive fields — destructure and omit across ALL response paths (GET, PUT, POST, error, socket); comments/docs claiming data isn't exposed while the code path does expose it
-   - Server trusting client-provided computed/derived values (scores, totals, correctness flags) when the server can recompute them — strip and recompute server-side; don't require clients to submit fields the server should own
+   - Server trusting client-provided computed/derived values (scores, totals, correctness flags, file metadata like MIME type and size) when the server can recompute or verify them — strip and recompute server-side; for file uploads, validate content type via magic bytes and size via actual buffer length rather than trusting client-supplied headers
    - New endpoints mounted under restricted paths (admin, internal) missing authorization verification — compare with sibling endpoints in the same route group to ensure the same access gate (role check, scope validation) is applied consistently
    - User-controlled objects merged via `Object.assign`/spread without sanitizing keys — `__proto__`, `constructor`, and `prototype` keys enable prototype pollution. Use `Object.create(null)` for the target, whitelist allowed keys, and use `hasOwnProperty` (not `in`) to check membership. Also verify the merge can't override reserved/internal fields the system depends on
 
@@ -45,7 +45,7 @@
    - State updates guarded by truthiness of the new value (`if (arr?.length)`) — prevents clearing state when the source legitimately returns empty. Distinguish "no response" from "empty response"
    - Periodic/scheduled operations with skip conditions (gates, precondition checks, "nothing to do" early exits) that don't advance timing state (lastRun, nextFireTime) on skip — null or stale lastRun causes immediate re-trigger in a tight loop. Record the skip as an execution or compute the next fire time from now, not from the missing lastRun
    - Mutation/trigger functions that return or propagate stale pre-mutation state — if a function activates, updates, or resets an entity, the returned value and any dependent scheduling/evaluation state (backoff timers, "last run" timestamps, status flags) must reflect the post-mutation state, not a snapshot read before the mutation
-   - Fire-and-forget or async writes where the in-memory object is not updated (response returns stale data) or is updated unconditionally regardless of write success (response claims state that was never persisted) — update in-memory state conditionally on write outcome, or document the tradeoff explicitly. Also applies to responses and business-logic decisions (threshold triggers, status transitions) derived from pre-transaction reads — concurrent writers all read the same stale value, so thresholds may be crossed without triggering the transition. Compute from post-write state or use conditional expressions that evaluate the stored value. For monotonic counters (sequence numbers, cursors) that must stay in lockstep with append-only storage, advancing before the write risks the counter running ahead on failure; not advancing after a partial write risks reuse — reserve the range before writing and commit only on success
+   - Fire-and-forget or async writes where the in-memory object is not updated (response returns stale data) or is updated unconditionally regardless of write success (response claims state that was never persisted) — update in-memory state conditionally on write outcome, or document the tradeoff explicitly. Also applies to responses and business-logic decisions (threshold triggers, status transitions) derived from pre-transaction reads — concurrent writers all read the same stale value, so thresholds may be crossed without triggering the transition. Compute from post-write state or use conditional expressions that evaluate the stored value. For monotonic counters (sequence numbers, cursors) that must stay in lockstep with append-only storage, advancing before the write risks the counter running ahead on failure; not advancing after a partial write risks reuse — reserve the range before writing and commit only on success. Also check for dependent side effects (rewards, notifications, secondary uploads, resource allocation) executing in parallel with or before the primary write they depend on — if the primary write fails or is rejected (lock contention, dedup, validation), the side effects are irrecoverable (orphaned uploads, unearned rewards, phantom notifications). Gate side effects on confirmed primary write success
    - Error/early-exit paths that return status metadata (pagination flags, truncation indicators, hasMore, completion markers) or emit events (WebSocket, SSE, pub/sub) with default/initial values instead of reflecting actual accumulated state — downstream consumers make incorrect decisions (e.g., treating a failed sync as successful because the completion event was emitted unconditionally). Set metadata flags and event payloads based on actual outcome, not just the final request's exit path. Also check paired lifecycle events (started/completed/failed): if a function emits a "started" event, every exit path — including early returns and no-op branches — must emit the corresponding "completed" or "failed" event, or clients waiting for completion will hang or show stale state
    - Missing `await` on async operations in error/cleanup paths — fire-and-forget cleanup (e.g., aborting a failed operation, rolling back partial state) that must complete before the function returns or the caller proceeds
    - `Promise.all` without error handling — partial load with unhandled rejection. Wrap with fallback/error state. For `Promise.allSettled`, verify rejected entries are logged with rejection reasons before mapping to fallback values — silently substituting defaults makes partial failures invisible in production
@@ -55,7 +55,7 @@
    **Error handling** _[applies when: code has try/catch, .catch, error responses, or external calls]_
    - Service functions throwing generic `Error` for client-caused conditions — bubbles as 500 instead of 400/404. Use typed error classes with explicit status codes; ensure consistent error responses across similar endpoints — when multiple endpoints make the same access-control decision (e.g., "resource exists but caller lacks access"), they must return the same HTTP status (typically 404 to avoid leaking existence). Include expected concurrency/conditional failures (transaction cancellations, optimistic lock conflicts) — catch and translate to 409/retry rather than letting them surface as 500
    - Swallowed errors (empty `.catch(() => {})`), handlers that replace detailed failure info with generic messages, and error/catch handlers that exit cleanly (`exit 0`, `return`) without any user-visible output — surface a notification, propagate original context, and make failures look like failures. Includes external service wrappers that return `null`/empty for all non-success responses — collapsing configuration errors (missing API key), auth failures (403), rate limits (429), and server errors (5xx) into a single "not found" return masks outages and misconfiguration as normal "no match" results. Distinguish retriable from non-retriable failures and surface infrastructure errors loudly
-   - Caller/callee disagreement on success/decision semantics — a function that resolves with `{ success: false }` while callers use `.catch()` for error handling means failures are treated as successes. Verify that the contract between producer and consumer is consistent: if callers branch on rejection, the function must reject on failure; if callers branch on a status field, the function must never reject. This extends beyond success/failure to any evaluation result — if a gate/check function returns `{ shouldRun: false }` on errors while the runtime treats errors as fail-open (run anyway), the API surface and runtime disagree on skip semantics. Also check EventEmitter async handlers — `async` callbacks on `'close'`/`'error'` events create unhandled rejections because EventEmitter doesn't await handler promises; wrap in try/catch
+   - Caller/callee disagreement on success/decision semantics — a function that resolves with `{ success: false }` while callers use `.catch()` for error handling means failures are treated as successes. Verify that the contract between producer and consumer is consistent: if callers branch on rejection, the function must reject on failure; if callers branch on a status field, the function must never reject. This extends beyond success/failure to any evaluation result — if a gate/check function returns `{ shouldRun: false }` on errors while the runtime treats errors as fail-open (run anyway), the API surface and runtime disagree on skip semantics. Also covers argument shape contracts — passing a wrapped object (`{ items: [...] }`) when the callee expects a bare array (or vice versa), or supplying arguments at the wrong parameter position, causes silent no-ops or partial processing; verify argument shapes match by reading the callee's signature, not assuming from naming conventions. Also check EventEmitter async handlers — `async` callbacks on `'close'`/`'error'` events create unhandled rejections because EventEmitter doesn't await handler promises; wrap in try/catch
    - Destructive operations in retry/cleanup paths assumed to succeed without their own error handling — if cleanup fails, retry logic crashes instead of reporting the intended failure
    - External service calls without configurable timeouts — a hung downstream service blocks the caller indefinitely
    - Missing fallback behavior when downstream services are unavailable (see also: retry without backoff in "Sync & replication")

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "slash-do",
-  "version": "1.7.0",
+  "version": "1.9.0",
   "description": "Curated slash commands for AI coding assistants — Claude Code, OpenCode, Gemini CLI, and Codex",
   "author": "Adam Eivy <adam@eivy.com>",
   "license": "MIT",