tmk241/hemx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(runtime): lower generated runtime ids

Browse Source 
req: wire/001

req: ts/001
This commit is contained in:
slhx agent
2026-05-10 23:04:45 +02:00
parent 9e0342951c
commit 79414fbb39
6 changed files with 208 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+29 -19
View File
@@ -2,43 +2,53 @@
## Purpose
This file tells coding agents how to work in this repository. It is hand-edited project context, not a generated requirements dump.
This file tells coding agents how to work in this repository. It is a durable operating contract, not a generated inventory.
Keep it stable. Prefer pointers to canonical sources over copied structure, file lists, metrics, architecture maps, command inventories, or status snapshots.
## Agent workflow
- Start with requirements before implementation details.
- Start from product intent and requirements; inspect code only after the target behavior is clear.
- 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`.
- Cite relevant requirements in code, tests, or docs as `req: <component>/001`.
- Do not add citation-only padding to satisfy tooling; cite only where the requirement constrains the text.
- Use requirement tags consistently: stable area tags like `[parser]`, `[auth]`, `[ui]`; temporary planning tags like `[bootstrap]`, `[mvp]`, or `[milestone-1]` only while they are useful.
- Run `redgate list`, `redgate refs`, and `redgate health` when requirements change.
## Git workflow
- Commit complete, coherent slices only; do not commit broken work or temporary debug output.
- Use Conventional Commits: `type(scope): summary`.
- Keep commit subjects readable; requirement IDs do not have to be in the subject.
- Every behavior-changing or requirement-changing commit should cite relevant requirement IDs in the commit body or trailers using `req: <component>/001`.
- Use commit history for evolution: `git log --grep 'req: parser/012'` should find the commits that changed that behavior.
- Use the current tree for state: `REQUIREMENTS.md`, citations, tests, and `redgate health` describe what is true now.
- Before committing requirement or behavior changes, run relevant tests and `redgate health --strict`.
## 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.
- Write requirements as desired behavior, not as a snapshot of current behavior.
- First split intent into broad error classes: what can go wrong, and what outcome must hold.
- Test the largest risky classes before narrow examples.
- 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.
- Do not over-codify existing behavior while direction is still moving.
- Add narrow concrete tests only after requirements converge into a stable direction.
## 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.
- `redgate health --strict` — fail on hard errors: empty requirements, duplicate IDs, or stale citations.
- `redgate agents` — print this starter template; review, shrink, and edit before committing.
## Project commands
## Local guidance
- `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.
- Add only durable style, ownership, gotchas, and at most a few stable commands agents should actually run.
- Prefer links or pointers to canonical sources over copied lists.
- Avoid project trees, architecture maps, generated inventories, current file sizes, issue lists, TODO inventories, and other snapshots that will rot.
- Stable commands: `cargo check --workspace`, `cargo test --workspace`, `redgate health --strict`.
- 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.