Testing and verification

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

Use the smallest set of checks that proves the change. Unit tests do not replace checks 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	ArchiveTests plus the owner-specific round-trip tests for the archive kind.
Community packs	Community pack tests plus live catalog verification when applicable.

Build source changes with:

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 host-specific 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 materially helped produce the change, 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.