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.

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.

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 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.

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.