dough-manual-testing git:20260916.fb84d13A

Immutable. This exact content is served forever at /api/v1/blob/7424fe3b02125272.

---
name: dough-manual-testing
description: >-
  Plans bounded manual or exploratory observation of requested product
  behavior when the developer explicitly requests manual testing, exploratory
  testing, or an active plan slice requires it. Covers web, CLI, API, desktop,
  or combined surfaces. Does not run proactively or replace required automated
  tests.
---

# Observe requested behavior

Use only on explicit developer request or plan-slice manual testing.
No diagnosis, product repair, or unrequested tooling.

## Mission

Resolve scope and time budget from the request: a feature, story set, recent
deliveries, or change range. Recover current promises, examples, and
constraints from this project's records or Git history, including deleted
stories. Apply later decisions before older expectations; implementation,
narration, and existing tests are not the oracle.

Identify in-scope externally observable surfaces, including non-web. Resolve
URLs, accounts, startup, secrets, and tools from this project's guidance when
needed; do not guess credentials.

If oracle, budget, or needed environment or access is missing, name it and
stop; do not invent them.

## Plan

Before acting, list coverage areas and journeys, risks or questions, and
proportional split of preparation, breadth, selective depth, and
surprise/confirmation reserve. Weight by importance and risk. Include each
promised surface. Completing this plan is not acceptance.

## Prepare

Choose the cheapest reliable route: existing setup, whole or partial automated
journey, or temporary harness or test, including a setup-only feature
scenario using existing steps. Skip setup when current state serves. Confirm
state, session, and required services remain available for external
observation; a finished batch run may not. Preserve isolation, cleanup,
compatible-state reuse, and removal of owned temporary artifacts. Missing
reuse is a possible improvement, not authority for permanent test/runner
changes. If no supported route leaves a usable starting state, name it and
stop.

## Explore

Cover planned areas in breadth first with this project's tools. Spend depth on
surprises and high-risk questions; reallocate remaining time, keeping
confirmation reserve. Reuse sufficient automated evidence; do not replay
deterministic checks or proven setup. If a needed tool or environment is
unavailable, name it and stop.

## Report

When planned coverage completes with no actionable findings or material
uncertainty, report exactly `Good.` Otherwise report only discrepancies
(expected versus actual plus evidence), unresolved expectations (not false
fails), improvements (out-of-scope ideas, not failed acceptance), and
material coverage gaps. Never report `Good.` when blocked or incomplete.
Omit narration, speculation, and completion markers. Do not start repair,
root-cause, or permanent test changes.