league-of-legends-gui-overhaul/AGENTS.md

Agent Instructions

Project

League of Legends GUI Overhaul: React/Vite prototype for a modern, dark, MOBA-/fantasy-inspired client interface.

Repository Rules

• At the start of every user-requested task, check for upstream updates and apply a safe fast-forward pull when the working tree is clean. If local changes exist, fetch or report the blocker before editing.
• Conserve context tokens: search with rg or targeted file lists first, read only task-relevant files, and avoid generated folders, dependency folders, build outputs, or full logs unless they are directly relevant.
• Prefer existing project patterns over new abstractions.
• Keep changes scoped to the user's request.
• Do not commit secrets, .env files, private keys, certificates, or tokens.
• Treat global-runner-1, global-runner-2, and global-runner-3 as the only available build runners.
• Run project builds, tests, audits, package jobs, installers, dependency setup, and releases only on Gitea Ubuntu runners with ubuntu-latest, ubuntu-24.04, or ubuntu-22.04.
• Do not run those heavy project commands on the user's local machine. Local checks are limited to lightweight reads and validation that do not install dependencies or create build artifacts.
• Do not add Windows or macOS runners. Use open-source Linux-compatible tooling or workflow workarounds that run on the Ubuntu runners.
• Do not rewrite history or run destructive git commands unless explicitly requested.
• Do not create a release unless explicitly requested.
• Check repository state before editing and before finishing. Preserve unrelated user changes.
• Replace applicable placeholders in copied templates. Remove non-applicable placeholder sections instead of leaving fake values.
• Derive repository owner and name from this repository's remote or GITHUB_REPOSITORY. Never reuse owner/name values from the Agent Kit template repository.
• The current stack is Node, React, Vite, TypeScript, React Router, Vitest, Testing Library, and CSS custom properties.
• If GITEA_TOKEN is available locally, use it only for read-only Gitea API checks such as private repository metadata, package-read visibility, and Actions run status. Never print, commit, or store the token.
• When real, actionable follow-up work is outside the current scope or independently parallelizable, create a focused tracker issue. If no issue tracker is available, update docs/agent-handoff.md.
• After pushing commits that trigger a Gitea workflow, poll the workflow run until it succeeds or a concrete blocker is known.
• Repository cleanup automation must be non-destructive. Do not delete branches, packages, releases, or tracked files without explicit user approval.
• Dependency, compliance, and release dry-run automation must report findings only. Do not auto-update dependencies, auto-open PRs, create tags, publish packages, or create releases without explicit user approval.
• Keep Codex kit files in source control when they help agents, but exclude them from user-facing release, package, installer, archive, and upload artifacts unless the user explicitly asks to ship repository-maintenance files.

Commands

Use these commands:

npm install
npm run dev
npm run lint
npm run build
npm test
npm run audit
npm run release:check
git diff --check

npm run lint runs tsc --noEmit. npm run release:check runs lint, tests, and build.

For build, test, audit, dependency setup, package, installer, and release verification, use Gitea runner workflows such as .gitea/workflows/build.yml and .gitea/workflows/gui-smoke.yml. Do not use this local machine for those heavy project commands.

Keep .codex/project.md and this AGENTS.md aligned when commands, artifact paths, or release rules change.

Artifacts

Build output is produced in:

dist/

No release package naming or download verification process exists yet.

Security Notes

• Review docs/security-review.md before release work.
• Fill docs/security-review.md with actual checked commands and results when performing release-readiness work.
• Review scheduled security workflow failures before changing code. Treat matches as leads: they may be true positives, documentation examples, or test fixtures.
• Review repository cleanup workflow failures as maintenance leads. Document intentional exceptions instead of blindly deleting files.
• Review dependency and template compliance workflow failures as maintenance leads. Preserve project-specific conventions when they are documented.
• Treat generated credentials and config files as sensitive.
• Keep external network calls documented.
• Prefer local processing for user data.
• Keep CI publishing secrets in repository or organization secrets, not in tracked files.
• Do not include Codex kit metadata such as AGENTS.md, .codex/, blueprint.md, blueprint.json, template workflow files, or agent handoff notes in downloadable release artifacts unless explicitly requested.

Finish Checklist

• git diff --check passes.
• Lightweight local validation has passed, and project verification has run through Gitea Actions on a supported Ubuntu runner or the reason runner verification could not run is documented.
• README, changelog, security review, and release checklist are updated when the change touches release behavior.
• docs/agent-handoff.md is updated when work is interrupted, risky, or spans multiple sessions.
• Independent follow-up work has tracker issues, or docs/agent-handoff.md explains why issues could not be created.
• Any pushed Gitea workflow has been polled to success or a concrete blocker has been reported.