Frank
63219787af
Point the mattpocock-lineage skills (triage, to-tickets, to-spec, wayfinder) at repo facts instead of a parallel docs/ tree: Gitea is the issue tracker (credential-safe curl shape, token-only writes), the five canonical triage roles keep their default label strings (created on the tracker today), and GLOSSARY.md/docs/adr/ stay lazy with this vault owning operational facts. AGENTS.md gains the ## Agent skills pointer block; indices regenerated.
56 lines
2.2 KiB
Markdown
56 lines
2.2 KiB
Markdown
---
|
|
type: reference
|
|
title: Domain Docs
|
|
description: "Consumer rules for GLOSSARY.md and docs/adr/, and where this vault out-ranks them on operational facts."
|
|
tags: [agent, glossary, adr, documentation]
|
|
timestamp: 2026-10-20T00:00:00Z
|
|
---
|
|
|
|
# Domain Docs
|
|
|
|
How the engineering skills (`/grill-with-docs`, `/domain-modeling`,
|
|
`/improve-codebase-architecture`, `/to-spec`) should consume this repo's design
|
|
vocabulary when exploring the codebase.
|
|
|
|
## Before exploring, read these
|
|
|
|
- **`GLOSSARY.md`** at the repo root
|
|
- **`docs/adr/`**: read ADRs that touch the area you're about to work in
|
|
|
|
If either doesn't exist, **proceed silently**. Don't flag their absence; don't
|
|
suggest creating them upfront. `/domain-modeling` (reached via
|
|
`/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily
|
|
when terms or decisions actually get resolved. As of 2026-10-20 neither exists;
|
|
this page is the pointer, not a promise.
|
|
|
|
## Ownership against this vault
|
|
|
|
This repo already carries `serverAppConfigs-docs/` — the operational knowledge
|
|
base and, per repo law, the owner of operational facts (endpoint shapes, Eras,
|
|
Laws, runbooks). `GLOSSARY.md` / `docs/adr/` hold **design vocabulary and
|
|
decisions**. Where a term is defined in both, the vault page that owns the fact
|
|
wins — one fact, one owner. A glossary entry restating an endpoint number is
|
|
the bug, not the second source.
|
|
|
|
## Use the glossary's vocabulary
|
|
|
|
When output names a domain concept (an issue title, a refactor proposal, a
|
|
hypothesis, a test name), use the term as defined in `GLOSSARY.md`. 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 `/domain-modeling`).
|
|
|
|
## Flag ADR conflicts
|
|
|
|
If output contradicts an existing ADR, surface it explicitly rather than
|
|
silently overriding:
|
|
|
|
> _Contradicts ADR-0007 (…), but worth reopening because…_
|
|
|
|
## Related
|
|
|
|
- [[Issue Tracker]] — where specs and tickets built on this vocabulary are published.
|
|
- [[Agent Docs and Edits]] — the edit-safety rules that apply while touching any doc in this checkout.
|