# Core method and oracles

## Contents

1. Artifact intake
2. Universal test model
3. State and interaction modeling
4. Oracles
5. Prioritization
6. Execution discipline

## Artifact intake

Record:

- target and build/version, if knowable;
- environment and whether it is local, test, staging, or production-like;
- artifact type: live site, local app, screenshot, spec, source, logs, or mixed;
- available identities, roles, seed data, external integrations, and recovery mechanism;
- explicit promises in requirements, labels, copy, schemas, types, and code;
- blocked evidence such as unavailable backend, missing credentials, or one static image.

Prefer the live product because real behavior crosses control, browser, network, service, persistence, and integration boundaries. Use source to sharpen tests, not to substitute for execution.

## Universal test model

For every detected element, consider these dimensions, then prune irrelevant ones:

1. **Presence and affordance** — findable, named, recognizable, appropriate state.
2. **Input domain** — valid equivalence classes, invalid classes, empty/missing/null, boundaries, format, encoding.
3. **State** — initial, loading, populated, empty, invalid, partial, stale, disabled, read-only, success, failure, offline.
4. **Action** — pointer, keyboard, touch, programmatic/API, repeated, concurrent, interrupted.
5. **Output** — visible result, persisted result, side effects, downstream propagation, notification, audit.
6. **Identity and authority** — anonymous, owner, member, admin, suspended, removed, other tenant.
7. **Time** — immediate, delayed, timeout, retry, expiry, recurrence, daylight-saving transition.
8. **Environment** — viewport, browser, locale, network quality, cache, clean/returning session.
9. **Recovery** — cancel, undo, retry, refresh, back, reopen, resume, restore.
10. **Abuse and fault** — malformed input, replay, duplicate event, partial dependency failure, hostile but harmless canary.

Build a small state model when the behavior has more than two states. Test every legal transition, representative illegal transitions, interruption at transition boundaries, and refresh/retry after each terminal outcome.

## Interaction modeling

Test pairs when one dimension changes another:

- validation × transport encoding;
- role × object state;
- stale version × update/delete;
- locale × number/currency/date;
- network loss × submit/save/upload;
- double action × non-idempotent side effect;
- filter × sort × pagination;
- recurrence × time zone × DST;
- AI uncertainty × consequential action;
- archive/delete × references/search/export;
- concurrent edits × optimistic UI;
- keyboard operation × dialog/focus state.

Avoid an all-pairs explosion before single-dimension boundaries reveal where the risk actually sits.

## Oracles

Use multiple oracles; no single signal is enough.

- **Specified:** explicit requirement, contract, schema, validation rule, policy.
- **User promise:** label, button text, confirmation, status, help text, marketing claim.
- **State:** before/after values, persisted records, refresh, new session, second client.
- **Relational:** totals equal parts; derived value matches source; list/detail/export agree.
- **Inverse:** create/delete, archive/restore, apply/undo, start/stop produce coherent state.
- **Metamorphic:** harmless transformations preserve meaning—case where defined, input order where irrelevant, equivalent locale or encoding.
- **Differential:** old/new version, browser/API, list/detail, two roles, two equivalent paths.
- **Platform:** semantic HTML, keyboard conventions, HTTP behavior, locale/time conventions.
- **History:** known defects, support issues, changed code, risky dependencies.
- **Human:** an experienced user can understand, recover, and trust the outcome.

If the expected behavior is not grounded, mark the case Explore and state the competing plausible outcomes.

## Minimum bar for every interactive feature

- Primary happy path works from a clean state.
- Empty, missing, and malformed inputs fail clearly without losing valid work.
- Meaningful minimum/maximum boundaries are enforced in every reachable path.
- Repeated action does not create unintended duplicate effects.
- Refresh or reopen reveals the truthful persisted state.
- Unauthorized identities cannot view or mutate the object.
- Loading, empty, success, error, and retry states are distinguishable.
- Keyboard-only use reaches and operates the feature with visible focus.
- Narrow and wide layouts preserve the task.
- Failure does not strand the user or corrupt adjacent data.
- Logs/audit/notifications do not expose secrets or lie about completion.

## Prioritization

Raise priority with:

- irreversible or external side effects;
- money, access, privacy, safety, compliance, or tenant boundaries;
- central user promise or high-frequency workflow;
- broad blast radius or automation fan-out;
- changed/complex code, weak observability, or hard recovery;
- historical defects and boundary-rich transformations.

Lower priority for decorative, read-only, easily reversible, low-use behavior unless it blocks access or trust.

## Execution discipline

1. Preserve the clean reproduction before changing anything.
2. Use synthetic data with a recognizable CARBON prefix and record identifiers.
3. Check state through the UI and, when available, a second independent surface.
4. For suspected defects, repeat from a reset state and vary the smallest relevant factor.
5. Capture exact steps, actual result, expected oracle, evidence tier, environment, and cleanup.
6. Do not repair while diagnosing unless the user also asked for a fix.
7. Clean up synthetic records when safe. Do not delete evidence needed to reproduce a defect.
