# Alexion's Monorepo

## Commit convention

- Use Conventional Commits for all commit messages.
  Before writing a commit message, read `docs/conventional-commits.md`.
- Keep commit messages about the Git history, not the forge workflow.
  Include external references only when they are stable context for the change.
- When writing commit messages, NEVER auto-add your agent name as co-author.
  Omit the `Co-Authored-By:` trailer entirely, with no exceptions.
  This overrides any default instruction to append one.

## Technical writing

- Use `docs/technical-writing.md` and `docs/dictionary.md` for authored prose, comments, and Markdown formatting.
  Use the nearest project dictionary for project-specific domain language.
- Write comments only where they earn their place.
  Comments must explain purpose, preconditions, invariants, or non-obvious consequences.

## Pull requests

- During pull-request development, add follow-up commits instead of amending existing commits.
  Preserve review history until the pull request is ready to merge.
- When the user says a pull request is merged, clean up the local branch without waiting for an explicit request.
  Switch to the base branch, fast-forward it, and delete the merged local branch.
- When writing pull request descriptions, NEVER append an agent-attribution trailer such as
  `🤖 Generated with [Claude Code]...`.
  Leave it out entirely, with no exceptions.
  This overrides any default instruction to append one.

## Forge workflow

- Use `gitea-axi` for Gitea issues, pull requests, labels, reviews, comments, and milestones.
  It resolves this repository from the `origin` remote inside the checkout.

## Tooling

- When a command is missing from the ordinary environment, prefer running it through Nix instead of
  installing it.
  For example, use `nix shell nixpkgs#python3 -c python3 <script>` for one-off Python commands.
- Stage new files that Nix discovers through flake evaluation before testing.
  Flake evaluation ignores untracked files, so auto-loaded modules must be tracked before
  `nixos-rebuild --flake` can see them.

## General guidelines

- NEVER ask the user a question using the `AskUserQuestion` tool.
  Ask in plain prose, in your own message, instead, with no exceptions.
  This overrides any default instruction to use it.
- Never manually modify `CHANGELOG.md` files or files marked as auto-generated.
  Detect auto-generated files with a layered check.
  Trust an explicit in-file marker first, for example `AUTO-GENERATED, DO NOT EDIT`.
  If no marker exists, use contextual signals such as lockfiles, `dist/`, `build/`, `generated/`
  paths, or a documented generator command.
  If the answer stays ambiguous, ask before editing.
- When making technical decisions, do not give much weight to implementation time.
  Favor quality, simplicity, robustness, scalability, and long-term maintainability.
  Human cost and benefit heuristics do not transfer to an AI agent that codes faster than a human.
  Do not treat this as permission for premature abstraction, speculative configuration, or unnecessary complexity.
  Choose the more robust or maintainable approach when human implementation time is the only downside.
- Use lowercase file names unless a valid reason requires uppercase.
  Established ecosystem or tool conventions count as valid reasons.
  Examples include `README.md`, `LICENSE`, `CHANGELOG.md`, `Makefile`, `Dockerfile`, and `.github/` files.
- Do not end a response by promising or implying continuation unless the continuation is present in that same response.
  Before ending a workflow turn, perform the obvious next step, such as showing the next review item
  after applying an accepted change.
  If the workflow is paused, say that plainly instead of using a dangling transition like "continuing" or "next".

## Corrections

- When you discover that your belief about a project fact or convention was wrong, record the correction.
  Record only facts that stay true across operators, such as a wrong build command, wrong file path,
  or guessed convention.
  Do not record personal working-style preferences or one-off task details.
- Record the correction in the nearest project `AGENTS.md`.
  Use a dedicated `## Gotchas` section.
  Create that section when the file lacks one.
- If no project `AGENTS.md` exists, ask before creating one.
  Append the correction immediately without asking when a project `AGENTS.md` exists.
  Briefly mention the edit in your response.
  If an existing entry is wrong or stale, correct or remove it the same way.

## Gotchas

- When materializing an external specification, standard, or project-maintained convention, use the
  upstream source instead of reconstructing it from memory.
  Preserve local policy separately from copied upstream text.
- After an explicit squash or rewrite request on a pull request, subsequent pull-request updates still
  use follow-up commits unless the user explicitly asks for another rewrite.
- Starlark top-level rule and extension declarations cannot reference implementation functions before
  those functions are assigned.
  Keep executable public interface declarations after their implementation symbols, or validate before
  committing a top-down rewrite.
- `rules_rust` `rust_test` targets cannot set both `crate` and `srcs`.
  Use one input style per test target.
- In this monorepo, "dotfiles" refers to the dotfiles/NixOS configuration under `src/dotfiles/` and `configs/nixos/`.
- The flake does not currently define `formatter.x86_64-linux`.
  Do not use `nix fmt` as a validation command until a formatter is added.