City-Lifeline-Cockpit/docs/agents/domain.md

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.