# Context discovery

Build the test plan from the current working context, not from the generic library alone.

## Inspect in this order

1. Read repository instructions such as `AGENTS.md`, `CLAUDE.md`, contribution guidance, and safety notes.
2. Capture the requested scope, current diff, staged diff, recent relevant commits, renamed/deleted files, and untracked files in scope.
3. Identify runtime entry points from manifests, lockfiles, containers, task runners, CI, environment examples, and existing start/test commands.
4. Inventory user-facing surfaces: routes, screens, forms, dialogs, widgets, APIs, jobs, CLIs, files, notifications, integrations, AI prompts/tools, database objects, and automation.
5. Map observed surfaces to CARBON flow and item files.
6. Trace changed code outward to direct callers, clients, schemas, persisted data, caches, notifications, analytics, and adjacent flows.
7. Read existing tests, fixtures, bug reproductions, support notes, and release requirements as evidence—not as proof that the product works.

## Extract code-specific test inputs

Search source and generated artifacts for:

- regexes, parsers, allow/deny lists, reserved values, special usernames/passwords, sentinels, magic strings, feature flags, and environment branches;
- `min`, `max`, `maxlength`, step, precision, length, byte, token, page, batch, timeout, retry, quota, and rate-limit constants;
- schemas, types, enums, nullability, defaults, unions, refinements, database constraints, migrations, indexes, and foreign keys;
- routes, request/response shapes, status codes, headers, cookies, redirects, serialization, versioning, idempotency keys, and API client assumptions;
- authentication, session, role, tenant, ownership, permission, consent, retention, audit, and secret-handling logic;
- CSS breakpoints, layout/container rules, z-index, overflow, focus/hover states, colors, motion, themes, and responsive variants;
- asynchronous loops, pagination, recursion, queues, workers, polling, cancellation, cleanup, resource ownership, and end conditions;
- AI prompts, policies, tool schemas, retrieval filters, model/version settings, output parsers, graders, fallback models, and confirmation gates.

For every extracted constraint, create positive, negative, exact-boundary, bypass, interaction, and downstream-persistence cases when relevant. Record the source file and line or symbol as provenance.

## Evidence labels

- **Observed runtime:** directly visible or returned by the running target.
- **Code-derived:** explicit implementation contract or constraint.
- **Change-derived:** changed or adjacent to a changed dependency.
- **Library-derived:** selected CARBON flow/item probe.
- **Inferred:** plausible product behavior requiring confirmation.

Do not turn code-derived or inferred behavior into a runtime pass.

## No-diff fallback

When Git metadata or a trusted baseline is unavailable, do not guess that the whole product changed. Use, in order: user-named files/features, the current task’s created or edited artifacts, filesystem modification times, build manifests and generated outputs, then direct dependency/caller adjacency. Mark the change set **inferred**, record the missing baseline as residual uncertainty, and keep CARBON Quick narrowly reviewable. If even that evidence is absent, ask for a release scope or switch to a broader Review plan rather than claiming change-focused coverage.
