| ADDD | Agentic Domain-Driven Design: documentation and delivery model for single bounded-context monoliths. Combines spec sync, lexical alignment, tri-layer naming, and agent-first conventions. Not a distributed systems pattern, microservices strategy, or full DDD methodology. |
| Agent load plan | Machine-readable specification in standards.manifest.json → agentLoadPlans that maps a task type to Tier 0–3 resources an agent MUST load. See Context tiers. |
| Agentic guardrails | Normative rules in docs/conventions/shared/agentic-guardrails.md: scaffolding sequence, XML rules, anti-drift patterns, verification checkpoints. |
| Context tiers | Three-level loading strategy for agent documentation: Tier 0 (AGENTS.md, always loaded), Tier 1 (task-loaded Quick Rules sections), Tier 2 (reference-loaded full conventions), Tier 3 (blueprints for file generation only). See docs/agentic-development.md §6. |
| Feature | Folder grouping that contains one Aggregate and all its Use Cases. Not a bounded context, GitHub feature flag, or feature toggle. Multiple Features exist within a single bounded context. Example: docs/domain/posts/, Posts/, features/posts/. |
| Implementation Prerequisite Set | Minimum documents that MUST exist before an agent begins implementation: Feature Spec (docs/domain/{feature}/README.md), Use Case Doc, and Use Case Test Spec. See docs/guides/agentic-domain-driven-design.md. |
| Invariant coverage | Mapping between domain invariants declared in a Feature Spec and the specific tests that verify each invariant. Recorded in the Feature Spec Invariants Under Test table and Use Case Test Spec Test Coverage rows. |
| Lexical alignment | Property of a codebase where folder names, file names, class names, and method names use the same vocabulary as the domain ubiquitous language and the Feature Spec. Consequence of Screaming Architecture applied to docs, backend, and frontend. |
| Page composition doc | Document under docs/ui/{app}/pages/ or shell.md that describes a single frontend route: which Use Cases compose on it, screen states, and content modes. Not a CQRS read model projection. Previously called “UI projection doc.” |
| Reactions | ADDD-specific name for the Application.Reactions project layer. Handles domain event-driven side effects via narrow interfaces. In DDD literature this corresponds to policies or domain event handlers. |
| Scoped loading | Loading only the convention files or Quick Rules sections required for the current layer or task, not the entire docs/conventions/ tree. |
| Screaming architecture | Bob Martin’s term: folder structure communicates business intent without reading code. In ADDD it applies to docs (docs/domain/{feature}/), backend ({Feature}/{UseCase}/), and frontend (features/{feature}/{use-case}/), not code folders alone. |
| Spec sync rule | Convention that documentation and code MUST be updated in the same commit/PR. A document that describes behavior the code does not implement, or code that implements behavior no document describes, violates this rule. |
| Spec-anchored | Synonym for Spec sync rule when describing a repository or workflow: documentation and code cannot diverge by policy. |
| Strike 0 / 1 / 2 | Promotion rule for shared frontend code: use case local (0), feature shared/ after two uses (2). Strike 1 is the first duplicate that triggers planning for promotion. |
| Tier | Project risk classification for coverage thresholds: production (default), internal, prototype. Declared in project docs/domain/README.md or project README. Distinct from Context tiers. |
