# Domain Docs

How the engineering skills read this repo's domain documentation before working on it. The repo
is single-context: one glossary and one ADR folder, both at the repo root.

## Before exploring, read these

- **`GLOSSARY.md`** at the repo root: the project's terms (VERIFY / LIVE-WRITE, Charge Summary,
  condition, ...).
- **`docs/adr/`**: read the ADRs that touch the area you're about to work in.

If either is missing, **proceed silently**: don't flag its absence and don't suggest creating it
upfront. The `domain-modeling` skill creates them lazily, when a term or a decision actually gets
settled.

## File structure

```
/
├── GLOSSARY.md
├── docs/adr/
│   ├── 0001-verify-sets-boxes-on-screen-only.md
│   └── 0002-save-corrections-off-until-client-approves.md
└── src/ecw_bot/
```

## Use the glossary's vocabulary

When your output names a domain concept (in a Jira summary, a refactor proposal, a hypothesis, a
test name), use the term as `GLOSSARY.md` defines it, e.g. **VERIFY** / **LIVE-WRITE** for the run
modes, **Charge Summary** for the results sheet, **condition** for one rule module. Don't drift to
synonyms the glossary explicitly avoids.

If the concept you need isn't in the glossary yet, that's a signal: either you're inventing
language the project doesn't use (reconsider) or there's a real gap (note it for the
`domain-modeling` skill).

## Flag ADR conflicts

If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:

> _Contradicts ADR-0001 (VERIFY sets boxes on screen only), but worth reopening because…_