# Domain Docs

How the engineering skills should consume this repo's domain documentation when exploring the codebase.

## Repo-specific sources

For TvT.js work, read the applicable baseline before editing:

- `openspec/specs/*/spec.md` is the authoritative capability-spec baseline. `framework-foundation` establishes the code-first conflict rule.
- `skills/tvt-js-plugin-builder/SKILL.md` and its references are the primary workflow guidance for plugins, cases, preview metadata, packaging, runtime modes, and integration-aware work.
- `AGENTS.md` contains the repo coding and verification rules, including the rule not to run build or debug commands automatically.

`openspec/` and the TvT plugin skill do not replace lazy domain docs. `CONTEXT.md` and ADRs are created only when terms or decisions actually crystallize.

## Before exploring, read these

- **`CONTEXT.md`** at the repo root, or
- **`CONTEXT-MAP.md`** at the repo root if it exists: it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
- **`docs/adr/`**: read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.

If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill creates them lazily when terms or decisions actually get resolved.

## Use the glossary's vocabulary

When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, or a test name), use the term as defined in `CONTEXT.md`, the OpenSpec vocabulary, or the TvT plugin skill. Don't drift to synonyms those sources explicitly avoid.

If the concept you need isn't recorded 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 `/domain-modeling`).

## Flag conflicts

If your output contradicts an existing ADR or an OpenSpec capability requirement, surface it explicitly rather than silently overriding. For a spec conflict, name the spec directory and requirement; for code/documentation conflicts, follow the code-first rule in `framework-foundation` and record the documentation sync as part of the proposed change.