slhx agent
46 lines
2.1 KiB
Markdown
46 lines
2.1 KiB
Markdown
# slhx — AGENTS.md
|
|
|
|
## Purpose
|
|
|
|
This file tells coding agents how to work in this repository. It is hand-edited project context, not a generated requirements dump.
|
|
|
|
## Agent workflow
|
|
|
|
- Start with requirements before implementation details.
|
|
- Read `REQUIREMENTS.md` before changing behavior.
|
|
- If behavior changes, update `REQUIREMENTS.md` in the same change.
|
|
- Cite relevant requirements in code, tests, or docs as `req: component/001`.
|
|
- Run `redgate list`, `redgate refs`, and `redgate health` when requirements change.
|
|
|
|
## Requirements-first TDD
|
|
|
|
- Write requirements as intent, not as a dump of current behavior.
|
|
- Break requirements into large error classes first: what can go wrong, and what outcome should hold.
|
|
- Use tests to pin those error classes before changing code.
|
|
- Add adversarial tests for malformed, hostile, ambiguous, missing, duplicated, and boundary inputs.
|
|
- Avoid over-codifying existing behavior while the direction is still unclear.
|
|
- Add narrower, concrete cases only after requirements converge into a clear design.
|
|
|
|
## Redgate CLI
|
|
|
|
- `redgate list` — show requirements as TSV.
|
|
- `redgate refs` — show `req:` citations found in the repo.
|
|
- `redgate health` — show uncited requirements, duplicate IDs, and stale citations.
|
|
- `redgate health --strict` — fail on hard errors: duplicate IDs or stale citations.
|
|
- `redgate agents` — print this starter template; review and edit before committing.
|
|
|
|
## Project commands
|
|
|
|
- `cargo check --workspace`
|
|
- `cargo test --workspace`
|
|
- `redgate health --strict`
|
|
|
|
## Project conventions
|
|
|
|
- Keep `AGENTS.md` concise; do not paste the requirements catalog into it.
|
|
- Requirement IDs use the current form `req: component/001`, not the legacy `req:_component/001` form.
|
|
- slhx core stays small: effects, typed ids, registries, and wire schema only.
|
|
- Routing, auth, sessions, transport, transitions, sync, and storage belong in integration/user crates.
|
|
- Public examples and beginner APIs should use generated resources and `IntoEffect`, not raw ids or runtime opcodes.
|
|
- JS runtime changes must preserve root-scoped lookup and avoid selectors, VDOM, expressions, and per-node listeners.
|