| name | small-change-verification |
| description | Use when making small or localized changes that could still affect user-visible behavior, API contracts, database queries, test runtime, CI, generated artifacts, or cross-layer data flow. |
Small Change Verification
Core Idea
Small changes fail when their real blast radius is misread. Before editing, name the kind of change and the most likely place a regression would be noticed.
When to Use
Use for modest follow-up work such as:
- fixing a focused UI behavior;
- adjusting a DB query, filter, sort, or search condition;
- changing Huma routes, response types, generated clients, or API errors;
- touching Playwright, CI, test scripts, or runtime config;
- updating provider-visible behavior without adding a whole provider.
Small means scoped, not exempt from repository requirements. Do not use this for large feature design; use a planning or docs-grilling workflow first.
Classify First
Pick the smallest matching class:
| Class | Typical files | Main regression question |
|---|
ui-only | Svelte components, stores, CSS | What visible workflow or persisted UI state could break? |
api-contract | Huma routes, API types, generated clients | What client contract or generated artifact changes? |
db-query | queries, migrations, filters | What persisted or sorted result would the user notice? |
test-runtime | Playwright, CI, scripts, Makefile | Does local execution match the failing or intended runtime? |
provider-visible | platform clients, capabilities, routes | Which provider, host, or capability boundary is affected? |
Write one sentence before editing:
This is a <class> change; the likely regression surface is <observable behavior>.
If multiple classes apply, use the strictest relevant checks.
Minimum Checks
| Class | Minimum verification |
|---|
ui-only | Relevant component/store test; affected Playwright or full-stack e2e when the change alters a visible workflow. |
api-contract | make api-generate, review checked-in OpenAPI/client diffs, and run the narrow Go/API test that consumes the contract. |
db-query | Query/unit test with literal expected rows, plus server/API test when HTTP output changes. |
test-runtime | Re-run the exact affected command in the same runtime shape: container, browser, env var, or CI script path. |
provider-visible | Provider/package test plus server/API or UI capability test at the boundary users see. |
If one class points at another, run both checks. Example: a DB-backed search fix is usually db-query and API-visible.
Done When
The classification sentence is written, applicable checks have run, skipped checks are justified, generated diffs are reviewed when present, and failures are investigated before completion.
Context Map
- API, DB, provider, and e2e boundaries:
context/testing.md
- UI state, route identity, persistence, and interaction behavior:
context/ui-interaction-contracts.md
- Provider identity, host scoping, and capability rules:
context/platform-sync-invariants.md
- Provider package layout and route helpers:
context/provider-architecture.md
Common Mistakes
- Calling a change "just config" when it changes CI runtime or browser behavior.
- Testing only the narrow helper when the user sees the behavior through HTTP or UI.
- Updating generated files without reviewing whether the public contract should have changed.
- Adding a Playwright assertion for visibility but skipping the component/store state that caused it.
