Domain Language Authority Grill Log

Authority

Q1

Prerequisites:

none

Question: Where does terminology become canonical?

Accepted answer:

Each requirements grill owns its proposed terminology while the grill is open.
When the user accepts the closed grill, its accepted terminology is promoted into the stable routed wiki glossary.
The stable routed wiki glossary is the project's canonical domain context.
Grill artifacts remain proposal and decision-history records after promotion; they are not competing terminology authorities.

Promotion contract

Q2

Prerequisites:

Question: What physical wiki artifact acts as the canonical context?

Accepted answer:

Use one stable routed wiki glossary page per bounded context.
When multiple bounded contexts exist, use one routed context-map page to name them and describe their relationships.
Do not create a root GLOSSARY.md at this stage.

Q3

Prerequisites:

Question: What is the unit and timing of terminology promotion?

Accepted answer:

Review terms individually, but promote accepted terms only after the grill is closed and its final closure review is accepted.
An unresolved term does not block unrelated accepted terms at closure.

Q4

Prerequisites:

Question: Who may accept terminology for promotion?

Accepted answer:

The user or already-canonical evidence may authorize a term.
An agent may propose a term and surface evidence, but it may not accept its own invented terminology.

Q5

Prerequisites:

Question: What happens when proposed terminology conflicts with the canonical glossary?

Accepted answer:

Stop promotion for the conflicting term and explicitly ask the user to keep, replace, or split the meaning.
Continue promoting unrelated non-conflicting terms.
Apply this user-resolution rule both when the conflict appears during active modeling and when canonical state changed before closure promotion.

Canonical model shape

Q6

Prerequisites:

Question: What belongs in a canonical context glossary?

Accepted answer:

Include the context name and purpose, canonical project-domain terms, one-sentence definitions, and avoided aliases.
Put cross-context relationships in the routed context map.
Keep axioms and decisions on linked routed wiki pages rather than in the glossary.

Q7

Prerequisites:

Question: How is a term assigned to a bounded context?

Accepted answer:

Assign terms by business meaning, ownership, and language boundaries.
Never infer a bounded context from an app, package, workspace, or folder.
Ask the user when context ownership is unclear.

Q8

Prerequisites:

Question: Must this workflow handle concurrent canonical-glossary mutation during one grill?

Accepted answer:

No. One grill runs at a time within its checkout. Concurrent grills use separate branches and worktrees.
Concurrent promotion and glossary-merge design are outside this workflow.

Q9

Prerequisites:

Question: What Harness-specific canonical rename workflow is required?

Accepted answer:

None. The included domain-modeling skill owns its terminology behavior.
requirements-grill must reference and invoke that skill rather than restate or fork its criteria and workings.
Behavior that the domain-modeling skill does not define remains unspecified; requirements-grill must not invent a second rename contract.

Skill integration

Q10

Prerequisites:

Question: Which artifact contract does the included domain-modeling skill use?

Accepted answer:

Preserve the domain-modeling skill's original modeling criteria and behavior.
Route its persistence into the Harness truth accepted in Q1 through Q3.
During an open requirements grill, domain-modeling writes proposed terms into that grill's durable glossary.
After explicit grill closure acceptance, requirements-grill promotes the accepted terms into the canonical routed wiki glossary.
This is an artifact-location integration, not a second implementation of the domain-modeling rules.

Q11

Prerequisites:

Question: Where does each bounded-context glossary live in the existing wiki routes?

Accepted answer:

Use apps/wiki/content/docs/project/domains/<context>-glossary.mdx.
Use apps/wiki/content/docs/project/domains/index.mdx as the routed context map and glossary index.
Existing CLI and Harness contexts use cli-glossary.mdx and harness-glossary.mdx when their first accepted terms are promoted.

Q12

Prerequisites:

Question: How is domain-modeling included without duplicating it?

Accepted answer:

Add the domain-modeling skill and make requirements-grill reference and invoke it strongly throughout the workflow.
Keep the domain-modeling criteria in that owning skill only.
Requirements-grill supplies its active grill glossary and closure-promotion target when invoking the skill; it does not restate the modeling behavior.

Q13

Prerequisites:

Question: What happens when domain-modeling is invoked outside requirements-grill?

Accepted answer:

Outside current scope. This design guarantees domain-modeling behavior only through requirements-grill and adds no direct-invocation workflow.

Q14

Prerequisites:

Question: What happens when canonical promotion cannot be completed?

Accepted answer:

Outside current scope. The accepted design assumes promotion into the routed wiki glossary succeeds and adds no fallback or recovery mechanism.

Q15

Prerequisites:

Question: What makes domain-modeling invocation mandatory and observable during a grill?

Accepted answer:

Requirements-grill loads domain-modeling before its first question, applies it throughout every round, and runs its glossary check again at closure.
If the grill discussed domain language, closure evidence records the proposed glossary changes or explicitly states that no canonical term changed.

Q16

Prerequisites:

Question: Which pack makes domain-modeling available with requirements-grill?

Accepted answer:

Add domain-modeling to the requirements pack beside requirements-grill.

Q17

Prerequisites:

Question: When are canonical glossary pages created?

Accepted answer:

Create a bounded-context glossary lazily during its first accepted promotion.
Never create an empty glossary speculatively.

Q18

Prerequisites:

Question: Are the existing CLI and Harness wiki domains already bounded contexts?

Accepted answer:

No. Existing documentation or product routes do not establish DDD bounded contexts.
Do not seed contexts or manufacture glossary terms from those routes.

Q19

Prerequisites:

Question: Who creates and confirms a new bounded context?

Accepted answer:

Use the imported domain-modeling skill's upstream behavior.
Domain-modeling may propose a context; the user confirms it before Harness creates the routed context map or glossary.
Requirements-grill adds no separate bounded-context criteria.

Q20

Prerequisites:

Question: Which downstream skills must consume canonical domain language?

Accepted answer:

create-spec, create-plan, implement-spec, write-backlog, backend-domain-structure, frontend-domain-structure, improve-codebase-architecture, and wait-what read the relevant canonical routed glossary before naming domain concepts.
They do not edit the canonical glossary. Terminology changes return through requirements-grill and its imported domain-modeling workflow.

Q21

Prerequisites:

Question: How does the domains route distinguish documentation domains from bounded contexts?

Accepted answer:

Keep project/domains/index.mdx as general domain-source navigation.
Create project/domains/context-map.mdx lazily when the first bounded context is accepted.
Store canonical glossaries at project/domains/<context>-glossary.mdx and link them from the context map.

Integration boundary

Q22

Prerequisites:

Question: Which behavior source governs domain modeling?

Accepted answer:

Matt Pocock's imported upstream domain-modeling skill is the sole owner of modeling criteria and behavior.
Harness does not recreate, summarize, fork, or reinterpret that behavior in requirements-grill or another skill.
Harness owns only integration: availability, invocation, working glossary routing, accepted-closure promotion, and downstream readonly consumption.

Q23

Prerequisites:

Question: How is the imported skill sourced and updated?

Accepted answer:

Import the skill unchanged from a pinned Matt Pocock upstream commit.
Preserve its license and UPSTREAM.md provenance.
Take future modeling-behavior changes through deliberate upstream updates, not local rewrites.

Q24

Prerequisites:

Question: Where does requirements-grill declare and supply domain-modeling invocation?

Accepted answer:

Requirements-grill explicitly loads domain-modeling before grilling begins and keeps it active through closure.
It supplies the active grill glossary as domain-modeling's working persistence target.

Q25

Prerequisites:

Question: Which Harness workflow performs accepted-closure promotion?

Accepted answer:

The existing requirements-grill wiki-synthesis step promotes accepted terminology into the routed canonical glossary after closure.
Domain-modeling identifies and writes terms; Harness moves accepted truth into its canonical routed location.

Closure

Shared-understanding confirmation

The user explicitly confirmed the complete accepted decision set.
The decision frontier is empty, with no unanswered or deferred questions.
The grill is closed and ready for create-spec compilation.

Domain Language Authority Grill Log

On this page