# Project Planning Verification

> Project milestone verification and rollback patterns. Use when designing verify sections, rollback procedures, or testing strategies for project milestones.

- Skill: `krmorehead/project-planning-verification` (Agent Skill)
- Install (CLI): `npx skillmds@latest add krmorehead/project-planning-verification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/krmorehead/project-planning-verification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: krmorehead (https://skillmd.com/u/krmorehead)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/krmorehead/project-planning-verification

---


# Project Verification & Rollback Rules

## Verification Requirements

1. NEVER defer all testing to a final milestone. Each milestone owns its own assertions.

2. **Verify sections** must include assertions to add to molecule scenarios, proving the milestone completed successfully.

3. Every feature milestone MUST include an **implementation pattern** note specifying: which task file to create, which plays to add to `site.yml`, which tags to use, and which molecule scenario to create. NEVER leave "how it integrates" as an open question.

4. Feature milestones MUST reference the relevant skills by name so implementers know which skills to load.

## Rollback Completeness Requirements

5. Rollback MUST fully restore the baseline state, including auth credentials and connection methods. If a milestone changes how Ansible connects to a target (e.g., password → key auth), the rollback MUST reverse the connection method too.

6. When a milestone changes the auth/connection method for a dynamic group, the plan MUST specify how subsequent plays and per-feature scenarios detect and adapt to the new auth method.

7. Every rollback section must undo EVERYTHING the milestone changed. Check: UCI config, packages, files, auth state, cron jobs, service enablement. A partial rollback leaves the system in an undefined state.

## Rollback Pattern Requirements

8. Per the project's "Bake, don't configure at runtime" principle: every package belongs in the image build, NOT at runtime. If a plan proposes `opkg install` or `apt install` during converge, reject it. Configure roles only do host-specific topology changes.

9. Rollback tags must be clearly defined. Use `--tags <feature>-rollback` pattern for consistent rollback execution.

## Testing Strategy Requirements

10. Every plan MUST include a **Testing Strategy** section with:
    - (a) parallelism in `molecule/default`
    - (b) per-feature scenario hierarchy
    - (c) day-to-day workflow (bash commands)
    - (d) teardown table showing what each scenario creates and destroys and its baseline impact.

11. Before execution, ALWAYS run the plan through the **Plan Review Checklist** against all referenced skills. Previous bug: the OpenWrt router plan had two critical issues (SSH auth transition, dynamic group persistence) that would have broken implementation — both caught only by cross-referencing skills during review.

## Secret Management in Verification

12. When a milestone generates secrets (keys, tokens, PSKs):
    - Document which env vars are auto-generated and which require user input
    - Specify the generated file: `test.env.generated` (test) or `.env.generated` (production)
    - Include a verify assertion checking the generated file exists and contains the expected keys
    - Include cleanup of the generated file in rollback

## Manual Testing Verification Requirements

13. Manual testing milestones verify by EXECUTION — not by confirming a
    file exists. The verify section MUST require "All N sections of
    Playbook X executed and passed on real hardware" with specific outcomes
    for key interactions. NEVER use "verify Playbook exists" as a criterion.

14. The project plan's reference to the playbook MUST include: file path,
    section numbers, sub-section count, and explicit "EXECUTE" language.
    NEVER say "walkthrough," "review," or passive voice.

    For HOW to write the playbook itself (exhaustive feature enumeration,
    per-app steps, host-awareness, error cases), see the
    `manual-testing-playbook-writing` skill.