How a submission becomes Accepted.

1. POST /actions/submitProof. The form posts challengeId and proofBody only.
2. Static filter. The server runs the forbidden-token regex on the comment-stripped proof body.
3. Render & hash. The server emits Submission_<id>.lean by interpolating the challenge fields and the proof body into a fixed template. Both the proof body and the full file are SHA-256-hashed and stored.
4. Push to GitHub. Octokit creates branch submission/<id> off GITHUB_BASE_BRANCH and PUTs the file at JUDGE_REPO_PATH_PREFIX/<slug>/Submissions/Submission_<id>.lean. The commit SHA returned by GitHub is recorded.
5. GitHub Actions runs. The workflow at .github/workflows/check-submission.yml in the judge repo triggers on the path glob, runs lake build with a pinned lean-toolchain, and reports success/failure.
6. Status feedback. Either:
   • Webhook. GitHub POSTs workflow_run events to /api/github/webhook; the server verifies the HMAC signature and updates the submission.
   • Polling. The admin can hit “Refresh GitHub status” to pull the latest workflow run via Octokit.
7. Seeds awarded. Only when the run on the recorded commit SHA has conclusion=success, the submission moves to accepted and awardForSubmission() writes one ledger entry and increments the balance in a single transaction. Idempotent.

Full diagram + sequence: docs/ARCHITECTURE.md.