Skip to main content
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

​
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 <changed-csharp-files>.
  • 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 <changed-csharp-files> 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: 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.