> ## 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. # Contribution workflow > Follow Akron's expected change, testing, documentation, verification, and review flow for contributor work. Akron changes must move from behavior to policy, then to implementation, and finally to verification. Begin with the user-visible behavior rather than the UI label. ## Normal Flow 1. Define the behavior and user goal. 2. Decide the policy unit and classification. 3. Update source code and tests. 4. Update public docs if behavior, settings, policy, or file contracts changed. 5. Update contributor docs if implementation boundaries, policy rules, or verification expectations changed. 6. Run formatting checks, focused tests, and build. 7. Add live verification evidence when required. 8. Disclose AI assistance when any AI tool materially helped produce the change. ## Files By Concern | Concern | Primary files | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Feature kind and policy metadata | `Source/Core/AkronTypes.cs`, `Source/Core/AkronFeatureRegistry.cs` | | Overlay rows, control types, and tooltip controls | `Source/Overlay/AkronOverlay.cs` plus focused `Source/Overlay/akron-overlay-*.cs` partials | | Persisted settings and setup state | `Source/Module/AkronModuleSettings.cs`, `Source/Module/akron-module-settings-*.cs`, `Source/Setups/akron-setup-*.cs` | | Runtime behavior | `Source/Module/AkronModule.cs`, `Source/Actions/akron-actions.cs`, `Source/Runtime/akron-runtime-options.cs`, feature-specific runtime partials | | HUD rendering | `Source/Hud/AkronHudRenderer.cs`, `Source/Hud/akron-hud-*.cs` | | Save/load internals | `Source/SaveLoad/AkronSaveLoad.cs`, `Source/SaveLoad/akron-save-load-*.cs` | | Internal recording | `Source/Recorder/akron-internal-recorder*.cs`, `Source/Recorder/akron-internal-audio-recorder.cs` | | `.akr` import/export | `Source/Setups/akron-setup-packs.cs`, `Source/Setups/akron-setup-file-picker.cs`, `Source/Packs/akron-archive.cs` | | Debug and automation commands | `Source/Commands/akron-commands.cs`, `Source/Commands/akron-*-commands.cs` | | Verification | `tests/feature-registry-tests.cs`, `tests/module-settings-tests.cs`, feature-specific tests | ## Documentation Expectations Update docs when: * A visible feature changes behavior. * A policy classification changes. * An active setup default, `.akr` pack scope, or `.akr` section changes. * A file location, command, or archive contract changes. * A troubleshooting path changes. Public docs should explain supported current behavior. Historical research notes, current task maps, and one-off audit checklists should not be published as docs pages unless they describe a current contract. ## Review Evidence Provide the smallest evidence that proves the change: * Test output for unit-level changes. * Formatting output from `dotnet format Akron.sln --include `. * Build output for source changes. * Screenshot or capture evidence for visual behavior. * Live verification notes for input, timing, camera, hitbox, transition, overlay, or map-dependent behavior. * Screenshot or video proof for new options or features when the behavior is visible, input-driven, timing-sensitive, rendering-sensitive, capture-related, or gameplay-facing. * After evidence for fixes when the corrected behavior is visible or runtime-observable. Before evidence is preferred when it is practical to capture or reproduce. 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 Checklist * [ ] Keep the diff scoped to one goal. * [ ] Run `dotnet format Akron.sln --include ` for changed C# project files. * [ ] Include the tests or checks that were run. * [ ] Include screenshot or video proof for new visible, input-driven, timing-sensitive, rendering-sensitive, capture-related, or gameplay-facing options and features. * [ ] Include after evidence for fixes when the corrected behavior is visible or runtime-observable. * [ ] Include before evidence for fixes when practical, especially for visual, overlay, capture, or gameplay regressions. * [ ] Include live verification notes when unit tests cannot prove the behavior. * [ ] Update docs for user-facing behavior, policy, file locations, debug commands, or `.akr` contracts. * [ ] Avoid committing secrets, local tokens, personal config files, local captures, or machine-specific paths. * [ ] Include the AI assistance disclosure when applicable. ## Contribution license CC BY-NC-ND 4.0 does not normally allow sharing adapted material. Akron's copyright holders grant a limited exception to modify and share Akron-owned material only as reasonably necessary to prepare and submit a contribution to the official Akron repository. This exception does not permit publishing unofficial builds, maintaining a general-purpose fork, or using the changes for another project. GitHub's own terms may separately govern copies made through GitHub's fork functionality. By submitting a contribution, you represent that you have the right to submit it and grant Microck a perpetual, worldwide, non-exclusive, irrevocable, royalty-free license to use, reproduce, modify, distribute, sublicense, and relicense the contribution as part of Akron. This grant does not change the licenses of third-party material identified in `licenses/third-party-notices.txt`. ## AI-Assisted Contributions AI-assisted contributions are allowed. They must meet the same code, docs, policy, and verification bar as hand-written changes. The contributor is responsible for the full contribution, including AI-assisted code, tests, docs, screenshots, created assets, and pull request text. When AI assistance materially helped produce a pull request, include these fields in the pull request body: | Field | What to provide | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `agent_name` | The AI tool, coding assistant, or agent used. | | `agent_version` | The exact version of the tool, extension, CLI, or agent when available. | | `model_used` | The actual model used. Do not write `unknown`, `default`, `auto`, `latest`, `not disclosed by tool`, a blank value, or a guessed model name. | | `human_testing` | Tests, checks, live Celeste verification, screenshots, or manual review performed by a human. | | `contribution_summary` | One sentence describing what changed. | Disclosure fields must be factual. Do not claim human review, testing, verification, or approval unless it actually happened. `human_testing` must describe real work that happened. Examples: * `Ran dotnet test tests/akron-tests.csproj --nologo --filter FeatureRegistryTests.` * `Built Source/Akron.csproj and manually checked the overlay in 7A with the overlay active.` * `Reviewed the .akr pack in Saves/AkronSetups and imported it through the Interface tab.` `No human testing performed` is not acceptable for a pull request that is ready to merge.