Acceptance Test Builder

Acceptance Test Builder

Goal: Deliver the smallest trustworthy acceptance-test portfolio for stated requirements through a user- or external-system-observable boundary. Modify only approved tests and test documentation; implement justified additions, updates, merges, and deletions without repairing product code.

Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap. Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.

Tool Routing

Never run acceptance tests against production or an unapproved external target. Do not deploy, publish, migrate shared data, rotate credentials, or accept changed output merely to make a test pass.

Evidence Rules

• Derive expected behavior from requirements, public contracts, examples, invariants, or an independent reference; never from the implementation calculation being tested.
• Prefer a terminal durable or user-visible outcome over an intermediate status, mock call, log line, or internal method result.
• Use golden files or snapshots only for deterministic, reviewable contracts. Updating expected output is a specification change, not test verification.
• Make setup, data allocation, execution, cleanup, and rerun behavior reproducible; preserve the first failure before retries or cleanup obscure it.
• A passing command proves only the environment and scenarios it actually exercised. State every excluded cell and unavailable boundary.
• Do not test language, framework, package, database-vendor, or other generic behavior; test only the repository-owned observable contract, configuration, integration, or policy that depends on it.
• Treat KEEP, ADD, UPDATE, MERGE, DELETE, and NO_TEST as portfolio decisions, distinct from execution results. Do not default to ADD when existing evidence, consolidation, retirement, or accepted residual risk is the better answer.
• Delete or merge only when the test basis is obsolete or evidence shows that all still-required unique material behavior, failure modes, oracle strength, and useful failure localization remain covered.

Checklist

1. Establish the Change Boundary

• Resolve the requirements, acceptance criteria, actor, protected outcome, observable contract, explicit non-goals, approved portfolio decisions, allowed test paths, and allowed test-documentation paths; label inferred experience qualities as assumptions.
• Read applicable repository instructions and inspect Git state, untracked files, generated areas, and existing user changes before editing.
• Detect the project-native runner, directory layout, naming, fixtures, setup, cleanup, environment configuration, and CI invocation.
• Inventory existing tests affected by the requirement or contract and map their actual oracles before creating a new test.
• Map each requirement to the boundary that can prove it: UI, API, CLI, message, integration, file, or durable state.