Generate Test Plan

Analyze the repository's tech stack, branch changes vs default, and generate an executable YAML test plan focused on user-facing impact.

This is an E2E test plan — not an automated test wrapper. The generated plan will be executed by an autonomous agent acting exactly as a human QA tester would: launching real binaries, hitting real endpoints, interacting with real databases, and verifying real observable behavior.

Critical Rule: No Automated Test Duplication

NEVER generate test steps that re-run the project's existing automated test suite. This means:

• No cargo test, pytest, npm test, go test, mix test, or equivalent commands as test steps
• No wrapping unit/integration test modules in a test case
• No "run the tests and check they pass" — that's CI's job, not QA's

If you find yourself writing a test step that invokes the project's test runner, stop and rethink. Ask: "What would a human tester do to verify this feature works?" The answer is never "run the unit tests."

What E2E test steps look like:

• Build the binary and run it with real arguments, check stdout/stderr/exit code
• Start a server and hit it with curl
• Run a CLI command that writes to a real database, then query the database to verify
• Launch the TUI and verify it renders (via screenshot or process lifecycle)
• Chain multiple commands that exercise a full user workflow end-to-end

Hard gates

Complete these in order. Do not advance to the next gate until its Pass condition is met (each pass should leave retrievable evidence: pasted command output, a written list, or the generated file on disk). Scheduling: Gate 1 before Step 2; Gate 2 before Step 5; Gate 3 before Step 7; Gates 4–5 during Step 8 (after the Step 7 summary).

1. Diff and base pinned (after Step 1) — Resolve the base branch from --base when provided, otherwise use the repo default (main or master per Step 1). Compare HEAD to $(git merge-base HEAD origin/<base_branch>) (or equivalent if the remote ref differs). Pass: You record current_branch, base_branch, the merge-base SHA or range used, and changed_files from git diff --name-only <merge-base>..HEAD (empty list allowed if you paste or quote that output and state “no file changes vs base”).

2. Trace complete (after Step 4) — Pass: Every affected entry point you will test has a Core functionality vs Configuration/admin classification, and the Step 4 requirement holds: at least one test targets a core entry point or you document why that is impossible and flag manual review.

3. Plan file valid (after Step 6, before Step 7) — Pass: docs/testing/test-plan.yaml exists and the following command exits 0 (parses the YAML and asserts all four top-level keys are present — a single grep -E with alternations would pass on any one match, so do not substitute it):