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.
1---2name: small-change-verification3description: 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.4---56# Small Change Verification78## Core Idea910Small 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.1112## When to Use1314Use for modest follow-up work such as:1516- fixing a focused UI behavior;17- adjusting a DB query, filter, sort, or search condition;18- changing Huma routes, response types, generated clients, or API errors;19- touching Playwright, CI, test scripts, or runtime config;20- updating provider-visible behavior without adding a whole provider.2122Small means scoped, not exempt from repository requirements. Do not use this for large feature design; use a planning or docs-grilling workflow first.2324## Classify First2526Pick the smallest matching class:2728| Class | Typical files | Main regression question |29| --- | --- | --- |30| `ui-only` | Svelte components, stores, CSS | What visible workflow or persisted UI state could break? |31| `api-contract` | Huma routes, API types, generated clients | What client contract or generated artifact changes? |32| `db-query` | queries, migrations, filters | What persisted or sorted result would the user notice? |33| `test-runtime` | Playwright, CI, scripts, Makefile | Does local execution match the failing or intended runtime? |34| `provider-visible` | platform clients, capabilities, routes | Which provider, host, or capability boundary is affected? |3536Write one sentence before editing:3738```text39This is a <class> change; the likely regression surface is <observable behavior>.40```4142If multiple classes apply, use the strictest relevant checks.4344## Minimum Checks4546| Class | Minimum verification |47| --- | --- |48| `ui-only` | Relevant component/store test; affected Playwright or full-stack e2e when the change alters a visible workflow. |49| `api-contract` | `make api-generate`, review checked-in OpenAPI/client diffs, and run the narrow Go/API test that consumes the contract. |50| `db-query` | Query/unit test with literal expected rows, plus server/API test when HTTP output changes. |51| `test-runtime` | Re-run the exact affected command in the same runtime shape: container, browser, env var, or CI script path. |52| `provider-visible` | Provider/package test plus server/API or UI capability test at the boundary users see. |5354If one class points at another, run both checks. Example: a DB-backed search fix is usually `db-query` and API-visible.5556## Done When5758The classification sentence is written, applicable checks have run, skipped checks are justified, generated diffs are reviewed when present, and failures are investigated before completion.5960## Context Map6162- API, DB, provider, and e2e boundaries: `context/testing.md`63- UI state, route identity, persistence, and interaction behavior: `context/ui-interaction-contracts.md`64- Provider identity, host scoping, and capability rules: `context/platform-sync-invariants.md`65- Provider package layout and route helpers: `context/provider-architecture.md`6667## Common Mistakes6869- Calling a change "just config" when it changes CI runtime or browser behavior.70- Testing only the narrow helper when the user sees the behavior through HTTP or UI.71- Updating generated files without reviewing whether the public contract should have changed.72- Adding a Playwright assertion for visibility but skipping the component/store state that caused it.
kenn-io