AGENTS.md git:20261001.ccc619dB

Immutable. This exact content never changes and is served at /api/v1/blob/04ea5bd49dc5b006.

<!-- hard-eng:start -->
# Agent Rules

- Installed-project startup = when `.hooks/hard-eng-source.json` exists, require the current session's Hard Eng update status before repository work, including read-only investigation. SessionStart reports the last update result and starts or reports a background update that commits locally when verified. If SessionStart supplied no status, first run `curl -fsSL https://raw.githubusercontent.com/sgaabdu4/hard-eng/main/setup.sh | sh` from the repository root. Tell the user whether it updated, found no newer verified release, is still running in the background, or failed; report any failure explicitly and retain the required gates. Missing updater output is a failed attempt even if the pipeline exits 0. Rerun setup only after a failed or stale status, never while an update runs; an installed marker/session file alone is not a successful update.
- Before editing, state the single change being implemented, which files it will touch, and how it will be verified. Prefer a native command or existing file. Every new file, dependency, wrapper or abstraction must be necessary for that change.
- Scope = the user's request + accepted constraints; preserve unrelated work.
- Project instructions = use `AGENTS.md` for Claude and Codex. Preserve unique scoped rules there before retiring legacy `CLAUDE.md` files; do not recreate import wrappers or publish private local instructions.
- Publication = before recording tracked content or publishing, apply [publication privacy](.agents/skills/he-ship/references/checks.md#publication-privacy) for the destination's audience.
- YAGNI = ultra always unless the user changes it. Understand the real flow first; reuse existing code, stdlib, native features and installed dependencies before adding code.
- Additions = before adding a file, dependency, abstraction, configuration or stored state, identify the current agreed requirement it serves and why the existing code or a direct command cannot satisfy it. Without both answers, leave it out. Keep this reasoning in normal updates; create no justification files.
- Comments = none by default. Add one terse line of why only when naming, types, structure or a test cannot carry a needed non-obvious constraint; `check` fails any changed source file holding a longer comment block, older blocks included.
- Changes = fix the cause at its existing owner. Optional improvements and extra infrastructure require an explicit user request; do not silently include them under robustness, best practices or future needs.
- Tests = each added test must prove a named required outcome or catch a specific meaningful failure. Reuse existing tests first; do not add tests that merely mirror implementation details or pad coverage. Identify expected outcomes + relevant failure modes before implementing; tests may follow. Affected journeys need real E2E proof where applicable; keep focused tests that add coverage, speed or diagnosis. Before deleting a test, state what it protects and its replacement proof or why it is unnecessary; E2E overlap alone is not enough. Details: [testing](.agents/skills/he/references/testing.md).
- Verification = run applicable gates and prove affected behavior; never hide findings, weaken checks to obtain a pass or claim an unrun check succeeded. Repair every reported finding in code, including findings unrelated to the task, as its own committed change before the task continues; never baseline, tolerate or suppress one.
- Acceptance = before completion, review the actual diff against the latest request, remove unsupported additions and report any remaining expansion. Passing tools does not excuse unnecessary code; automated metrics cannot prove necessity or test quality.
- Authorization = reuse settled approvals; ask only when missing information changes the result or an unapproved consequential action is necessary.
- Communication = concise plain English; report actual changes, proof and remaining gaps.
- Hard Eng defects = a reproduced fault in Hard Eng's own files (`.hooks/`, `.agents/skills/he*`, setup), not in the project → tell the user, search [hard-eng issues](https://github.com/sgaabdu4/hard-eng/issues) for a duplicate, and with their approval file a terse one: Problem, Reproduction, installed revision, Suggestion. Apply publication privacy; keep the required gates.
- Hard Eng = follow `.agents/skills/he/SKILL.md` when working on this repository; use `python3 .hooks/hard-eng.py --help` for commands.
<!-- hard-eng:end -->