> ## Documentation Index
> Fetch the complete documentation index at: https://akron-cdb9eaf4.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing and verification

> Choose targeted Akron tests, build checks, and live Celeste verification for source, docs, policy, and runtime changes.

Employ the minimal verification necessary to prove the change; do not substitute unit tests for rendering, input, timing, or map-dependent behavior.

## Targeted Tests

| Change                      | Minimum check                                                                 |
| --------------------------- | ----------------------------------------------------------------------------- |
| Feature classification      | `dotnet test tests/akron-tests.csproj --nologo --filter FeatureRegistryTests` |
| Settings defaults or clamps | `dotnet test tests/akron-tests.csproj --nologo --filter ModuleSettingsTests`  |
| `.akr` archive shape        | `dotnet test tests/akron-tests.csproj --nologo --filter ArchiveTests`         |
| `.akr` import/export        | Pack or module settings tests that cover the section.                         |
| Community packs             | Community pack tests plus live catalog verification when applicable.          |

Build source changes with:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
dotnet build Source/Akron.csproj
```

## Live Verification Required

Live verification is required when observable behavior depends on:

* Celeste rendering.
* Input timing.
* Screen transitions.
* Overlay layout.
* Hitbox, camera, zoom, or capture output.
* Map-specific runtime state.
* External tool or remote host state.

## Evidence Quality

Good evidence includes:

* The command or interaction used.
* The visible policy/status state and relevant Akron setup state.
* The map SID when map behavior matters.
* Screenshots or captures for visual behavior.
* Logs or proof sidecars for runtime state.
* A short note explaining what the evidence proves.

New options or features need screenshot or video proof when the behavior is visible, input-driven, timing-sensitive, rendering-sensitive, capture-related, or gameplay-facing.

Fixes need "after" evidence for the corrected behavior when the behavior is visible or runtime-observable. "Before" evidence is preferred when it is practical to capture or reproduce, especially for visual, overlay, capture, or gameplay regressions.

Use screenshots for static UI, overlay, path, policy, or layout behavior. Use video for animation, input timing, recording, screen transitions, camera movement, hitboxes, or gameplay state changes.

## Pull Request Evidence

In a pull request, distinguish automated logs from human verification. Logs can provide context, but they do not replace a clear statement of the checks a human performed.

If AI assistance was used, the `human_testing` field in the AI disclosure must describe real human validation. Do not claim a human ran a test, reviewed a screenshot, or verified gameplay unless that happened.

## Do Not Weaken Tests

Do not skip, weaken, or reword a failing test just to make an edge case pass. If the implementation cannot satisfy the test, leave the failure visible and explain the blocker.