feat: add repository-aware Gemini /generate-tests command #2419

Current problem

EventRelay has no repository-specific Gemini CLI command that can turn a bounded source or behavior scope into tests while respecting this monorepo's mixed Python and TypeScript stacks, nearest-test conventions, locked product facts, and evidence boundaries. Generic test generation can select the wrong runner, add non-hermetic network calls, weaken existing assertions, or report created files as passing behavior.

The requested @generate-tests concept maps to the official Gemini CLI custom-command form: /generate-tests. This issue is solution 2 of three.

Outcome

Extend the repository-owned eventrelay-engineering Gemini CLI extension with /generate-tests. The command should generate the smallest useful repository-conforming unit tests by default, use integration or end-to-end coverage only when requested or required by the observed boundary, run the narrowest existing verification command, and report measured results without overstating them.

Acceptance criteria

• Add a valid /generate-tests TOML command to the existing repository extension and document its invocation.
• Treat command arguments as untrusted scope text, never as executable shell or prompt instructions.
• Require a bounded source, behavior, symbol, diff, or explicit test type; with empty arguments, use only the smallest local diff and ask for scope when none exists.
• Read applicable AGENTS.md files and inspect the nearest existing tests, package scripts, test configuration, imports, fixtures, and naming conventions before writing.
• Default to focused unit tests. Generate integration or E2E tests only when explicitly requested or when a cross-boundary behavior cannot be covered lower in the test pyramid, and state why.
• Keep tests hermetic by default: no production calls, live network, real credentials, spending, deployment, destructive operations, or secret values. Use existing fakes, mocks, dependency injection, and auJzb1D-fag fixtures.
• Modify only test files unless the user separately authorizes a broader change. Do not add dependencies, edit lockfiles, weaken or delete assertions, or regenerate snapshots to hide failures.
• Before overwriting an existing test file or changing shared fixtures, present the planned paths and obtain explicit confirmation; otherwise create the smallest new test file in the nearest established location.
• Cover observable behavior, important failure paths, and relevant security or boundary cases without testing implementation trivia or duplicating existing coverage.
• Run the narrowest existing affected test command after generation. If the generated test exposes a product defect, preserve the evidence and report the failure; do not change production code or claim success.
• Report files changed, behaviors covered, command and exact result, failures and unverified limits, and recommended next step. Distinguish generated tests from passing behavior and production proof.
• Bump the extension version, validate it with the installed Gemini CLI, and add focused automated contract tests for command safety, scope, test selection, and evidence reporting.

Verification required before merge

• gemini extensions validate .gemini/extensions/eventrelay-engineering
• Focused automated extension-contract tests
• Fresh isolated extension link/list check
• Repository diff and secret check
• Exact-head required GitHub checks and unresolved-thread review

Out of scope

Solution 3 remains a separate, independently measurable change:

3. /verify-change — verify exact-head test/check/deployment evidence and prevent activity from being reported as outcome proof.

No application runtime change, dependency update, deployment, production request, user-global Gemini configuration change, price, or public-brand change is authorized by this issue.