codd-dev 2.9.0__tar.gz → 2.10.0__tar.gz

{codd_dev-2.9.0 → codd_dev-2.10.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: codd-dev
-Version: 2.9.0
+Version: 2.10.0
 Summary: CoDD: Coherence-Driven Development — cross-artifact change impact analysis
 Project-URL: Homepage, https://github.com/yohey-w/codd-dev
 Project-URL: Repository, https://github.com/yohey-w/codd-dev

codd_dev-2.10.0/codd_plugins/lexicons/api_rate_limiting_caching/coverage_matrix.md

@@ -0,0 +1,17 @@
+# API Rate Limiting and Caching Coverage Matrix
+
+Source: RFC 6585, RFC 7234, RFC 9110, RFC 9111, and common API platform
+practice.
+
+| Axis | Coverage target | Covered when | Gap signal |
+| --- | --- | --- | --- |
+| `rate_limit_strategy` | Rate subject and enforcement | Per-user, per-IP, per-tenant, or equivalent rate limiting scope and window is defined. | Public request volume can grow without a declared limit strategy. |
+| `quota_management` | Plan or period usage limits | Daily, monthly, plan, or tenant quotas and overage behavior are declared. | Consumers do not know usage ceilings or exhaustion behavior. |
+| `throttling_response` | Client-visible throttling | 429 Too Many Requests and retry guidance such as Retry-After are specified. | Clients cannot predict how to back off after throttling. |
+| `cache_control_headers` | HTTP cache policy | Cache-Control directives such as max-age, private, no-cache, or no-store are declared. | Responses can be cached incorrectly or not cached when intended. |
+| `etag_conditional_requests` | Representation validation | ETag, If-None-Match, or 304 Not Modified behavior is defined. | Clients cannot validate cached representations safely. |
+| `cdn_edge_caching` | Shared or edge cache lifecycle | CDN cacheability, surrogate policy, and invalidation are specified. | Edge caches can serve stale objects or miss cacheable content. |
+| `idempotency_keys` | Retry-safe mutations | Idempotency keys or duplicate request controls protect side-effecting operations. | Retried mutations can create duplicate payments, orders, or writes. |
+
+Reviewers classify each axis as `covered`, `implicit`, or `gap`. Findings are
+emitted only for `gap`.

codd_dev-2.10.0/codd_plugins/lexicons/api_rate_limiting_caching/elicit_extend.md

@@ -0,0 +1,70 @@
+---
+extends: codd/elicit/templates/elicit_prompt_L0.md
+lexicon_name: api_rate_limiting_caching
+observation_dimensions: 7
+---
+
+# API Rate Limiting and Caching Coverage Lexicon
+
+Apply the base elicitation prompt, then inspect requirements and design notes
+through the 7 API platform axes declared in `lexicon.yaml`. Use HTTP and API
+platform terms for rate limits, quotas, 429 responses, cache headers,
+conditional requests, edge caching, and idempotent retries.
+
+1. `rate_limit_strategy`
+2. `quota_management`
+3. `throttling_response`
+4. `cache_control_headers`
+5. `etag_conditional_requests`
+6. `cdn_edge_caching`
+7. `idempotency_keys`
+
+For every axis, classify coverage as:
+
+- `covered`: the material explicitly states the API behavior, header, status
+  code, quota, cache policy, invalidation behavior, or retry-safe mutation
+  mechanism and gives enough detail to verify it.
+- `implicit`: the material refers to a shared API platform standard that is
+  available in the same source set and clearly covers the axis.
+- `gap`: the material omits API platform behavior needed to judge abuse
+  prevention, client retry behavior, cache correctness, or duplicate side-effect
+  prevention.
+
+Emit findings only for `gap` axes. Populate `details.dimension` with the axis
+identifier from `lexicon.yaml`, include `details.evidence`, and ask a
+reviewer-facing question when the missing API behavior requires human
+confirmation. Severity follows `severity_rules.yaml`.
+
+## Coverage-check examples
+
+### covered
+
+Requirement: "Public API requests are limited per authenticated user and tenant.
+Quota exhaustion returns 429 with Retry-After. Read endpoints define
+Cache-Control, ETag, and If-None-Match behavior, CDN cache invalidation occurs on
+publish, and mutation POST requests require Idempotency-Key."
+
+Classification: `covered` for all axes because rate limits, quota response,
+caching, conditional validation, edge invalidation, and retry-safe mutation
+behavior are explicit.
+
+### implicit
+
+Requirement: "The billing API follows the attached `api-platform-standard-v5`,
+which defines quotas, cache headers, edge cache purge, and idempotency keys."
+
+Classification: `implicit` for `quota_management`, `cache_control_headers`,
+`cdn_edge_caching`, and `idempotency_keys` when the referenced standard is
+available in the same source set.
+
+### gap
+
+Requirement: "The endpoint is public and clients may retry failed payment
+requests."
+
+Classification: `gap` for `rate_limit_strategy`, `throttling_response`, and
+`idempotency_keys` because the material does not define abuse controls,
+throttling response, or duplicate mutation protection.
+
+Do not invent axes outside `lexicon.yaml`. Findings outside this lexicon should
+set `severity: info` and `details.note: "outside_lexicon_scope"`.

codd_dev-2.10.0/codd_plugins/lexicons/api_rate_limiting_caching/lexicon.yaml

@@ -0,0 +1,121 @@
+coverage_axes:
+  - axis_type: "rate_limit_strategy"
+    rationale: "Public APIs need a rate limit strategy that states the subject, window, scope, and enforcement model."
+    criticality_default: high
+    variants:
+      - id: "rate limit"
+        label: "Rate limit"
+        attributes: {source: "RFC 6585", coverage_target: "request rate control"}
+        criticality: high
+      - id: "per-user"
+        label: "Per-user limit"
+        attributes: {source: "API platform practice", coverage_target: "authenticated caller scope"}
+        criticality: high
+      - id: "per-IP"
+        label: "Per-IP limit"
+        attributes: {source: "API platform practice", coverage_target: "network caller scope"}
+        criticality: medium
+      - id: "per-tenant"
+        label: "Per-tenant limit"
+        attributes: {source: "API platform practice", coverage_target: "customer isolation"}
+        criticality: high
+  - axis_type: "quota_management"
+    rationale: "API products need quota limits and overage policy so consumers know daily, monthly, or plan-based usage boundaries."
+    criticality_default: medium
+    variants:
+      - id: "quota"
+        label: "Usage quota"
+        attributes: {source: "API platform practice", coverage_target: "consumption limit"}
+        criticality: medium
+      - id: "daily limit"
+        label: "Daily quota"
+        attributes: {source: "API platform practice", coverage_target: "daily consumption window"}
+        criticality: medium
+      - id: "monthly limit"
+        label: "Monthly quota"
+        attributes: {source: "API platform practice", coverage_target: "billing-period consumption window"}
+        criticality: medium
+      - id: "overage policy"
+        label: "Overage policy"
+        attributes: {source: "API platform practice", coverage_target: "behavior after quota exhaustion"}
+        criticality: medium
+  - axis_type: "throttling_response"
+    rationale: "RFC 6585 defines 429 Too Many Requests for rate limiting, and retry guidance helps clients recover predictably."
+    criticality_default: medium
+    variants:
+      - id: "429"
+        label: "429 Too Many Requests"
+        attributes: {source: "RFC 6585", source_literal: "429 Too Many Requests"}
+        criticality: medium
+      - id: "Retry-After"
+        label: "Retry-After"
+        attributes: {source: "RFC 6585", coverage_target: "client retry delay"}
+        criticality: medium
+      - id: "Too Many Requests"
+        label: "Too Many Requests response"
+        attributes: {source: "RFC 6585", coverage_target: "throttling status"}
+        criticality: medium
+  - axis_type: "cache_control_headers"
+    rationale: "HTTP caching relies on explicit Cache-Control directives for freshness, privacy, and revalidation behavior."
+    criticality_default: medium
+    variants:
+      - id: "Cache-Control"
+        label: "Cache-Control header"
+        attributes: {source: "RFC 7234", source_literal: "Cache-Control"}
+        criticality: medium
+      - id: "max-age"
+        label: "max-age directive"
+        attributes: {source: "RFC 7234", coverage_target: "freshness lifetime"}
+        criticality: medium
+      - id: "no-store"
+        label: "no-store directive"
+        attributes: {source: "RFC 7234", coverage_target: "sensitive response storage"}
+        criticality: high
+  - axis_type: "etag_conditional_requests"
+    rationale: "ETags and conditional requests let clients validate cached representations and reduce unnecessary transfers."
+    criticality_default: medium
+    variants:
+      - id: "ETag"
+        label: "ETag"
+        attributes: {source: "RFC 7232 / RFC 9110", coverage_target: "entity validator"}
+        criticality: medium
+      - id: "If-None-Match"
+        label: "If-None-Match"
+        attributes: {source: "RFC 7232 / RFC 9110", coverage_target: "conditional validation"}
+        criticality: medium
+      - id: "304 Not Modified"
+        label: "304 Not Modified"
+        attributes: {source: "HTTP semantics", coverage_target: "not-modified response"}
+        criticality: medium
+  - axis_type: "cdn_edge_caching"
+    rationale: "Edge caching needs declared cacheability, surrogate behavior, and invalidation so API freshness and distribution are governed."
+    criticality_default: medium
+    variants:
+      - id: "CDN"
+        label: "CDN caching"
+        attributes: {source: "HTTP caching practice", coverage_target: "edge cache layer"}
+        criticality: medium
+      - id: "cache invalidation"
+        label: "Cache invalidation"
+        attributes: {source: "HTTP caching practice", coverage_target: "stale edge object removal"}
+        criticality: medium
+      - id: "surrogate control"
+        label: "Surrogate cache control"
+        attributes: {source: "HTTP caching practice", coverage_target: "shared cache policy"}
+        criticality: medium
+  - axis_type: "idempotency_keys"
+    rationale: "Idempotency keys prevent duplicate side effects when clients retry payment, order, or mutation requests."
+    criticality_default: high
+    variants:
+      - id: "Idempotency-Key"
+        label: "Idempotency key"
+        attributes: {source: "API reliability practice", coverage_target: "retry-safe mutation identifier"}
+        criticality: high
+      - id: "idempotency"
+        label: "Idempotency contract"
+        attributes: {source: "HTTP semantics", coverage_target: "safe retry behavior"}
+        criticality: high
+      - id: "duplicate request"
+        label: "Duplicate request protection"
+        attributes: {source: "API reliability practice", coverage_target: "side-effect de-duplication"}
+        criticality: high

codd_dev-2.10.0/codd_plugins/lexicons/api_rate_limiting_caching/manifest.yaml

@@ -0,0 +1,24 @@
+name: api_rate_limiting_caching
+lexicon_name: api_rate_limiting_caching
+version: "1.0.0"
+source_url: "https://www.rfc-editor.org/rfc/rfc6585"
+source_version: "RFC 6585 / RFC 7234 / IETF"
+standard: "RFC 6585 / RFC 7234 / IETF"
+domain: cross_industry
+description: "API rate limiting, quota management, throttling response, idempotency, and HTTP caching coverage axes."
+observation_dimensions: 7
+extends: "codd/elicit/templates/elicit_prompt_L0.md"
+prompt_extension: "elicit_extend.md"
+recommended_kinds: "recommended_kinds.yaml"
+lexicon: "lexicon.yaml"
+severity_rules: "severity_rules.yaml"
+coverage_matrix: "coverage_matrix.md"
+references:
+  - title: "RFC 6585 - Additional HTTP Status Codes"
+    url: "https://www.rfc-editor.org/rfc/rfc6585"
+  - title: "RFC 7234 - HTTP/1.1 Caching"
+    url: "https://www.rfc-editor.org/rfc/rfc7234"
+  - title: "RFC 9111 - HTTP Caching"
+    url: "https://www.rfc-editor.org/rfc/rfc9111"
+  - title: "RFC 9110 - HTTP Semantics"
+    url: "https://www.rfc-editor.org/rfc/rfc9110"

codd_dev-2.10.0/codd_plugins/lexicons/api_rate_limiting_caching/recommended_kinds.yaml

@@ -0,0 +1,8 @@
+recommended_kinds:
+  - rate_limit_strategy_gap
+  - quota_management_gap
+  - throttling_response_gap
+  - cache_control_headers_gap
+  - etag_conditional_requests_gap
+  - cdn_edge_caching_gap
+  - idempotency_keys_gap

codd_dev-2.10.0/codd_plugins/lexicons/api_rate_limiting_caching/severity_rules.yaml

@@ -0,0 +1,32 @@
+defaults:
+  coverage_gap: high
+  implicit: medium
+  covered: info
+rules:
+  - when: "axis=rate_limit_strategy AND coverage=gap"
+    severity: high
+    rationale: "Missing rate limit strategy can leave a public API vulnerable to abuse, noisy neighbors, or denial of service."
+  - when: "axis=quota_management AND coverage=gap"
+    severity: medium
+    rationale: "Missing quota management leaves consumers without clear usage boundaries or overage behavior."
+  - when: "axis=throttling_response AND coverage=gap"
+    severity: medium
+    rationale: "Missing 429 and Retry-After behavior leaves clients without a predictable throttling response."
+  - when: "axis=cache_control_headers AND coverage=gap"
+    severity: medium
+    rationale: "Missing Cache-Control coverage can create stale, over-shared, or under-cached API responses."
+  - when: "axis=etag_conditional_requests AND coverage=gap"
+    severity: medium
+    rationale: "Missing ETag or conditional request coverage can increase load and make cache validation ambiguous."
+  - when: "axis=cdn_edge_caching AND coverage=gap"
+    severity: medium
+    rationale: "Missing edge cache and invalidation coverage leaves distributed cache freshness and purge behavior unclear."
+  - when: "axis=idempotency_keys AND coverage=gap"
+    severity: high
+    rationale: "Missing idempotency keys can duplicate side effects for payment, order, or mutation retries."
+  - when: "coverage=implicit AND evidence=weak"
+    severity: medium
+    rationale: "Weak implicit API platform coverage needs reviewer confirmation before it can satisfy rate limit or cache axes."
+  - when: "coverage=covered AND finding=residual_observation"
+    severity: info
+    rationale: "Covered axes may still emit informational review notes outside release-blocking API platform gaps."

codd_dev-2.10.0/codd_plugins/lexicons/ddd_domain_driven_design/coverage_matrix.md

@@ -0,0 +1,19 @@
+# Domain-Driven Design Coverage Matrix
+
+Source: Eric Evans, Domain-Driven Design, and Vaughn Vernon, Implementing
+Domain-Driven Design.
+
+| Axis | Covered when | Implicit when | Gap or not_found when |
+| --- | --- | --- | --- |
+| `ubiquitous_language` | Shared domain terms, definitions, and naming expectations are stated. | The feature is purely technical and has no business vocabulary. | Business terms appear but their meaning or code/model usage is unstated. |
+| `bounded_context` | Model boundaries, ownership, and language scope are explicit. | The change stays inside one already named context. | Multiple meanings, teams, products, or subdomains are involved without a boundary. |
+| `aggregate_design` | Aggregate root, invariant boundary, and transaction scope are stated. | The feature has no mutable domain consistency rule. | State changes can break business invariants but no aggregate boundary exists. |
+| `entity_value_object` | Identity-bearing entities and value-equality objects are distinguished. | The feature has no persistent domain objects or value semantics. | Objects have lifecycle, equality, or mutation rules but no semantic distinction. |
+| `domain_events` | Significant state changes and event publication/handling behavior are stated. | No other process or model needs to react to state changes. | A business occurrence matters outside the command but event behavior is absent. |
+| `repository_pattern` | Aggregate loading/saving abstraction and persistence boundaries are stated. | Persistence is entirely outside the feature or already covered by an existing repository. | Use cases need aggregate persistence but storage access boundaries are unclear. |
+| `application_service` | Use case orchestration, transaction, authorization, and coordination boundaries are stated. | The feature is a simple domain operation already covered by an existing service. | Workflow coordination exists but its boundary is mixed with domain rules or UI code. |
+| `context_mapping` | Upstream/downstream, ACL, shared kernel, or other context relationships are stated. | No other bounded context or external model participates. | Multiple models integrate but relationship and dependency direction are unstated. |
+| `anti_corruption_layer` | Translation and isolation from legacy, vendor, or external models are stated. | No legacy or external model enters the domain model. | External concepts cross into the core model without a protective translation boundary. |
+
+Reviewers classify each axis as `covered`, `implicit`, `gap`, or `not_found`.
+Findings are emitted for `gap` and `not_found`.

codd_dev-2.10.0/codd_plugins/lexicons/ddd_domain_driven_design/elicit_extend.md

@@ -0,0 +1,54 @@
+---
+extends: codd/elicit/templates/elicit_prompt_L0.md
+lexicon_name: ddd_domain_driven_design
+observation_dimensions: 9
+---
+
+# Domain-Driven Design Coverage Lexicon
+
+Apply the base elicitation prompt, then inspect medium-to-large business
+application requirements through these DDD strategic and tactical axes:
+
+1. `ubiquitous_language`
+2. `bounded_context`
+3. `aggregate_design`
+4. `entity_value_object`
+5. `domain_events`
+6. `repository_pattern`
+7. `application_service`
+8. `context_mapping`
+9. `anti_corruption_layer`
+
+For each axis, classify coverage as:
+
+- `covered`: requirements explicitly state the relevant DDD modeling decision or
+  pattern boundary.
+- `implicit`: the axis is not independently relevant because the described
+  feature is too small, CRUD-only, or fully delegated to an existing model.
+- `gap`: the axis can affect correctness or maintainability and no expectation
+  is specified.
+- `not_found`: no evidence for the axis exists in the reviewed material when
+  downstream scoring needs a missing-modeling status distinct from `gap`.
+
+Emit findings only for `gap` or `not_found` axes. Include the axis in
+`details.dimension`, the evidence or omission signal in `details.evidence`, and
+a reviewer-facing question in `question`.
+
+## Coverage-check examples
+
+- `covered`: The requirement defines Order and Invoice as separate bounded
+  contexts, names their upstream/downstream relationship, and states that Order
+  is modified only through an Order aggregate root; classify `bounded_context`,
+  `context_mapping`, and `aggregate_design` as `covered`.
+- `implicit`: A static admin lookup table has no domain behavior beyond simple
+  CRUD and inherits an existing model; classify `domain_events` and
+  `anti_corruption_layer` as `implicit`.
+- `gap`: A payment workflow changes customer status, invoice state, and rewards
+  balance in one operation but no aggregate or invariant boundary is defined;
+  classify `aggregate_design` as `gap`.
+- `not_found`: A specification for a multi-team business application contains no
+  shared vocabulary, bounded context, aggregate, or context map evidence; emit
+  `not_found` findings for the applicable DDD axes.
+
+Use recommended kinds as guidance. Do not invent additional DDD axes outside
+the nine listed above.

codd_dev-2.10.0/codd_plugins/lexicons/ddd_domain_driven_design/lexicon.yaml

@@ -0,0 +1,121 @@
+coverage_axes:
+  - axis_type: ubiquitous_language
+    rationale: "DDD uses a shared language between domain experts and delivery teams to keep the model, code, and conversations aligned."
+    criticality_default: medium
+    variants:
+      - id: "ubiquitous language"
+        label: "Shared domain vocabulary"
+        attributes: {source_literal: "ubiquitous language", coverage_target: "terms used consistently in model, code, and discussion"}
+        criticality: medium
+      - id: "domain expert language"
+        label: "Domain expert language"
+        attributes: {source_literal: "domain expert", coverage_target: "business terminology and definitions"}
+        criticality: medium
+  - axis_type: bounded_context
+    rationale: "DDD strategic design uses bounded contexts to make model boundaries explicit and prevent one model from being stretched across incompatible meanings."
+    criticality_default: high
+    variants:
+      - id: "bounded context"
+        label: "Explicit model boundary"
+        attributes: {source_literal: "bounded context", coverage_target: "scope of a domain model and language"}
+        criticality: high
+      - id: "context boundary"
+        label: "Context boundary"
+        attributes: {source_literal: "context boundary", coverage_target: "ownership and integration edge"}
+        criticality: high
+  - axis_type: aggregate_design
+    rationale: "DDD tactical design uses aggregates and aggregate roots to enforce invariants and transaction boundaries."
+    criticality_default: high
+    variants:
+      - id: "aggregate root"
+        label: "Aggregate root"
+        attributes: {source_literal: "aggregate root", coverage_target: "entry point for consistency boundary"}
+        criticality: high
+      - id: "invariant boundary"
+        label: "Invariant boundary"
+        attributes: {source_literal: "invariant", coverage_target: "rules protected inside the aggregate"}
+        criticality: high
+      - id: "transaction boundary"
+        label: "Transaction boundary"
+        attributes: {source_literal: "transaction boundary", coverage_target: "consistency and concurrency scope"}
+        criticality: high
+  - axis_type: entity_value_object
+    rationale: "DDD distinguishes entities with identity from value objects with equality-by-value to clarify lifecycle, mutation, and comparison semantics."
+    criticality_default: high
+    variants:
+      - id: "entity"
+        label: "Entity identity"
+        attributes: {source_literal: "entity", coverage_target: "identity and lifecycle"}
+        criticality: high
+      - id: "value object"
+        label: "Value object equality"
+        attributes: {source_literal: "value object", coverage_target: "immutable descriptive value"}
+        criticality: high
+      - id: "identity"
+        label: "Identity semantics"
+        attributes: {source_literal: "identity", coverage_target: "stable object identity across state changes"}
+        criticality: high
+  - axis_type: domain_events
+    rationale: "DDD domain events represent significant state changes and decouple follow-up behavior from the command that caused the change."
+    criticality_default: medium
+    variants:
+      - id: "domain event"
+        label: "Domain event"
+        attributes: {source_literal: "domain event", coverage_target: "significant business occurrence"}
+        criticality: medium
+      - id: "event publication"
+        label: "Event publication"
+        attributes: {source_literal: "event publication", coverage_target: "notification and downstream reaction"}
+        criticality: medium
+  - axis_type: repository_pattern
+    rationale: "DDD repositories provide collection-like persistence access for aggregate roots without exposing storage details to the domain model."
+    criticality_default: medium
+    variants:
+      - id: "repository"
+        label: "Repository abstraction"
+        attributes: {source_literal: "repository", coverage_target: "aggregate persistence abstraction"}
+        criticality: medium
+      - id: "aggregate persistence"
+        label: "Aggregate persistence"
+        attributes: {source_literal: "aggregate persistence", coverage_target: "load and save aggregate roots"}
+        criticality: medium
+  - axis_type: application_service
+    rationale: "DDD application services orchestrate use cases, transactions, authorization, and coordination while keeping domain rules in the model."
+    criticality_default: medium
+    variants:
+      - id: "application service"
+        label: "Use case orchestration"
+        attributes: {source_literal: "application service", coverage_target: "workflow coordination around domain model"}
+        criticality: medium
+      - id: "use case"
+        label: "Use case boundary"
+        attributes: {source_literal: "use case", coverage_target: "input, transaction, and response boundary"}
+        criticality: medium
+  - axis_type: context_mapping
+    rationale: "DDD context mapping records upstream/downstream relationships and integration patterns between bounded contexts."
+    criticality_default: high
+    variants:
+      - id: "context map"
+        label: "Context map"
+        attributes: {source_literal: "context map", coverage_target: "relationships between bounded contexts"}
+        criticality: high
+      - id: "upstream downstream"
+        label: "Upstream/downstream relationship"
+        attributes: {source_literal: "upstream/downstream", coverage_target: "dependency direction and influence"}
+        criticality: high
+      - id: "shared kernel"
+        label: "Shared kernel"
+        attributes: {source_literal: "shared kernel", coverage_target: "jointly owned model subset"}
+        criticality: medium
+  - axis_type: anti_corruption_layer
+    rationale: "DDD uses an anti-corruption layer to isolate a domain model from legacy, external, or differently modeled systems."
+    criticality_default: high
+    variants:
+      - id: "anti-corruption layer"
+        label: "Anti-corruption layer"
+        attributes: {source_literal: "anti-corruption layer", coverage_target: "translation and isolation boundary"}
+        criticality: high
+      - id: "legacy isolation"
+        label: "Legacy or external model isolation"
+        attributes: {source_literal: "legacy system", coverage_target: "protecting the domain model from external concepts"}
+        criticality: high

codd_dev-2.10.0/codd_plugins/lexicons/ddd_domain_driven_design/manifest.yaml

@@ -0,0 +1,23 @@
+id: ddd_domain_driven_design
+name: "Domain-Driven Design (DDD)"
+lexicon_name: ddd_domain_driven_design
+version: "1.0.0"
+standard: "Evans 2003 / Vernon 2013"
+domain: cross_industry
+source_url: "https://www.domainlanguage.com/ddd/"
+source_version: "Eric Evans Domain-Driven Design 2003 + Vaughn Vernon Implementing Domain-Driven Design 2013"
+description: "Domain-Driven Design tactical and strategic patterns coverage"
+observation_dimensions: 9
+extends: "codd/elicit/templates/elicit_prompt_L0.md"
+prompt_extension: "elicit_extend.md"
+recommended_kinds: "recommended_kinds.yaml"
+lexicon: "lexicon.yaml"
+severity_rules: "severity_rules.yaml"
+coverage_matrix: "coverage_matrix.md"
+references:
+  - title: "Domain-Driven Design: Tackling Complexity in the Heart of Software"
+    url: "https://www.domainlanguage.com/ddd/"
+    source_version: "Evans 2003"
+  - title: "Implementing Domain-Driven Design"
+    url: "https://www.pearson.com/en-us/subject-catalog/p/implementing-domain-driven-design/P200000009616/9780321834577"
+    source_version: "Vernon 2013"

codd_dev-2.10.0/codd_plugins/lexicons/ddd_domain_driven_design/recommended_kinds.yaml

@@ -0,0 +1,10 @@
+recommended_kinds:
+  - ddd_ubiquitous_language_gap
+  - ddd_bounded_context_gap
+  - ddd_aggregate_design_gap
+  - ddd_entity_value_object_gap
+  - ddd_domain_events_gap
+  - ddd_repository_pattern_gap
+  - ddd_application_service_gap
+  - ddd_context_mapping_gap
+  - ddd_anti_corruption_layer_gap

codd_dev-2.10.0/codd_plugins/lexicons/ddd_domain_driven_design/severity_rules.yaml

@@ -0,0 +1,45 @@
+defaults:
+  coverage_gap: medium
+  not_found: medium
+  implicit: info
+  covered: info
+rules:
+  - when: "axis=bounded_context AND coverage=not_found"
+    severity: high
+    rationale: "Missing bounded contexts can create model confusion across teams, features, and integrations."
+  - when: "axis=ubiquitous_language AND coverage=not_found"
+    severity: medium
+    rationale: "Missing shared language increases ambiguity between business intent, model names, and code."
+  - when: "axis=aggregate_design AND coverage=not_found"
+    severity: high
+    rationale: "Missing aggregate design can leave invariants and transaction boundaries unenforced."
+  - when: "axis=ubiquitous_language AND coverage=gap"
+    severity: medium
+    rationale: "Shared vocabulary gaps make requirements harder to validate with domain experts."
+  - when: "axis=bounded_context AND coverage=gap"
+    severity: high
+    rationale: "Bounded context gaps can stretch one model across incompatible meanings."
+  - when: "axis=aggregate_design AND coverage=gap"
+    severity: high
+    rationale: "Aggregate gaps can permit invariant violations and oversized transactions."
+  - when: "axis=entity_value_object AND coverage=gap"
+    severity: high
+    rationale: "Entity/value object gaps obscure identity, equality, mutation, and lifecycle semantics."
+  - when: "axis=domain_events AND coverage=gap"
+    severity: medium
+    rationale: "Domain event gaps can hide important state changes and downstream reactions."
+  - when: "axis=repository_pattern AND coverage=gap"
+    severity: medium
+    rationale: "Repository gaps can leak persistence details into the domain model or use cases."
+  - when: "axis=application_service AND coverage=gap"
+    severity: medium
+    rationale: "Application service gaps can mix orchestration, transactions, and domain rules ambiguously."
+  - when: "axis=context_mapping AND coverage=gap"
+    severity: high
+    rationale: "Context mapping gaps can hide ownership, dependency direction, and integration contracts."
+  - when: "axis=anti_corruption_layer AND coverage=gap"
+    severity: high
+    rationale: "Anti-corruption layer gaps can let external or legacy models contaminate the core model."
+  - when: "coverage=implicit AND evidence=weak"
+    severity: medium
+    rationale: "Weak implicit coverage should be reviewed before accepting a DDD axis as not applicable."

codd_dev-2.10.0/codd_plugins/lexicons/dora_sre_metrics/coverage_matrix.md

@@ -0,0 +1,17 @@
+# DORA Metrics and SRE Principles Coverage Matrix
+
+Source: DORA Accelerate research and the Google SRE Book.
+
+| Axis | Coverage target | Covered when | Gap signal |
+| --- | --- | --- | --- |
+| `deployment_frequency` | Production deployment cadence | The material defines how often changes are released or deployed. | Release cadence is absent or only described informally. |
+| `lead_time_for_changes` | Change delivery latency | Commit-to-production or change-to-production elapsed time is measured. | Delivery latency cannot be measured from the stated process. |
+| `change_failure_rate` | Deployment-caused failures | Failed deployments, rollback, incident, or hotfix percentage is tracked. | Release stability is not measured after deployment. |
+| `mean_time_to_restore` | Incident recovery time | Restore time after user-visible failure is measured and owned. | Recovery speed is not defined or is only ad hoc. |
+| `slo_sli_definition` | User-visible reliability contract | SLIs and SLOs state what is measured and which target applies. | Reliability is asserted without measurable service-level targets. |
+| `error_budget_policy` | Reliability risk governance | Error budget tracking, burn-rate alerting, or release policy is declared. | Reliability targets do not affect alerting or release decisions. |
+| `toil_reduction` | Repetitive operations work | Manual repetitive work is identified and has an automation or reduction path. | Manual operations can grow without review or engineering follow-up. |
+| `incident_management` | Response and learning process | On-call, runbook, escalation, restoration, and postmortem behavior is explicit. | Incidents rely on unnamed or informal response behavior. |
+
+Reviewers classify each axis as `covered`, `implicit`, or `gap`. Findings are
+emitted only for `gap`.