@phuc1403/musketeer 0.9.0 → 0.11.0

package/template/.claude/skills/context-map/example.cml

@@ -1,106 +1,106 @@
-/* Canonical Context Map example for the context-map skill.
- *
- * Grammar reference: ./reference/Context Map.md
- * Role combination rules: ./reference/Semantic Rules.md
- *
- * Shows all four relationship shapes (Partnership, Shared Kernel,
- * Upstream-Downstream, Customer-Supplier) with the full attribute
- * vocabulary so per-wall maps have a single place to copy from.
- *
- * This file is intended to compile clean against `cm validate -i <file>.cml`
- * (Context Mapper CLI 6.12+). Every Bounded Context referenced in the
- * ContextMap must also be declared as a `BoundedContext <Name>` below —
- * forgetting that produces the Xtext linking error:
- *   "Couldn't resolve reference to BoundedContext '<Name>'."
- *   "The Bounded Context 'null' is not part of the Context Map."
- */
-
-ContextMap DDDSampleContextMap {
-  type = SYSTEM_LANDSCAPE
-  state = AS_IS
-
-  contains CargoBookingContext, VoyagePlanningContext, LocationContext
-  contains ContractsContext, ClaimsContext
-  contains CustomerSelfServiceContext, CustomerManagementContext
-  contains PrintingContext, PolicyManagementContext
-
-  /* Shared Kernel (symmetric) --------------------------------------------
-   * Two contexts share a common subset of the model (a library, a package).
-   * Changes on either side need coordinated review.
-   */
-  CargoBookingContext [SK]<->[SK] VoyagePlanningContext : BookingVoyageRelationship {
-    implementationTechnology = "Java Library"
-  }
-
-  /* Partnership (symmetric) ----------------------------------------------
-   * Two contexts succeed or fail together. Joint planning, shared roadmap.
-   */
-  ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
-    implementationTechnology = "Messaging"
-  }
-
-  /* Upstream-Downstream with OHS / PL / ACL ------------------------------
-   * Upstream publishes a stable, documented API in a Published Language.
-   * Downstream wraps incoming data in an Anti-Corruption Layer to keep
-   * upstream model leakage out of its own domain.
-   */
-  CargoBookingContext [D,ACL]<-[U,OHS,PL] LocationContext : CargoLocationRelationship {
-    implementationTechnology = "RESTful HTTP"
-    downstreamRights = VETO_RIGHT
-    exposedAggregates = Locations, Addresses
-  }
-
-  /* Customer-Supplier (asymmetric, downstream has influence) -------------
-   * Special case of upstream-downstream: downstream's priorities factor
-   * into upstream planning. Note: CF and OHS are NOT applicable here
-   * (semantic-rule errors). ACL is allowed but emits a semantic WARNING
-   * (rule #7 in Semantic Rules.md) — kept here to show the form.
-   */
-  CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : CustomerFrontendBackendRelationship {
-    implementationTechnology = "RESTful HTTP"
-    downstreamRights = OPINION_LEADER
-    exposedAggregates = Customers
-  }
-
-  /* Upstream-Downstream with CF (no ACL) ---------------------------------
-   * Downstream conforms to the upstream model wholesale — no translation.
-   * Cheap to integrate, but downstream becomes coupled to upstream changes.
-   */
-  PolicyManagementContext [D,CF]<-[U,OHS,PL] PrintingContext {
-    implementationTechnology = "SOAP"
-  }
-}
-
-/* ---------------------------------------------------------------------------
- * Bounded Context declarations.
- *
- * Each name used above in `contains` and in relationship lines must resolve
- * to a BoundedContext declaration somewhere in the file. Empty bodies are
- * legal — declarations can stay minimal in a strategic-only map.
- *
- * Aggregates referenced by `exposedAggregates` MUST live inside the upstream
- * BoundedContext of the relationship — see the LocationContext block (which
- * owns Locations + Addresses, exposed to CargoBookingContext) and the
- * CustomerManagementContext block (which owns Customers, exposed to
- * CustomerSelfServiceContext).
- * --------------------------------------------------------------------------- */
-
-BoundedContext CargoBookingContext
-BoundedContext VoyagePlanningContext
-
-BoundedContext LocationContext {
-  Aggregate Locations
-  Aggregate Addresses
-}
-
-BoundedContext ContractsContext
-BoundedContext ClaimsContext
-
-BoundedContext CustomerSelfServiceContext
-
-BoundedContext CustomerManagementContext {
-  Aggregate Customers
-}
-
-BoundedContext PrintingContext
-BoundedContext PolicyManagementContext
+/* Canonical Context Map example for the context-map skill.
+ *
+ * Grammar reference: ./reference/Context Map.md
+ * Role combination rules: ./reference/Semantic Rules.md
+ *
+ * Shows all four relationship shapes (Partnership, Shared Kernel,
+ * Upstream-Downstream, Customer-Supplier) with the full attribute
+ * vocabulary so per-wall maps have a single place to copy from.
+ *
+ * This file is intended to compile clean against `cm validate -i <file>.cml`
+ * (Context Mapper CLI 6.12+). Every Bounded Context referenced in the
+ * ContextMap must also be declared as a `BoundedContext <Name>` below —
+ * forgetting that produces the Xtext linking error:
+ *   "Couldn't resolve reference to BoundedContext '<Name>'."
+ *   "The Bounded Context 'null' is not part of the Context Map."
+ */
+
+ContextMap DDDSampleContextMap {
+  type = SYSTEM_LANDSCAPE
+  state = AS_IS
+
+  contains CargoBookingContext, VoyagePlanningContext, LocationContext
+  contains ContractsContext, ClaimsContext
+  contains CustomerSelfServiceContext, CustomerManagementContext
+  contains PrintingContext, PolicyManagementContext
+
+  /* Shared Kernel (symmetric) --------------------------------------------
+   * Two contexts share a common subset of the model (a library, a package).
+   * Changes on either side need coordinated review.
+   */
+  CargoBookingContext [SK]<->[SK] VoyagePlanningContext : BookingVoyageRelationship {
+    implementationTechnology = "Java Library"
+  }
+
+  /* Partnership (symmetric) ----------------------------------------------
+   * Two contexts succeed or fail together. Joint planning, shared roadmap.
+   */
+  ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
+    implementationTechnology = "Messaging"
+  }
+
+  /* Upstream-Downstream with OHS / PL / ACL ------------------------------
+   * Upstream publishes a stable, documented API in a Published Language.
+   * Downstream wraps incoming data in an Anti-Corruption Layer to keep
+   * upstream model leakage out of its own domain.
+   */
+  CargoBookingContext [D,ACL]<-[U,OHS,PL] LocationContext : CargoLocationRelationship {
+    implementationTechnology = "RESTful HTTP"
+    downstreamRights = VETO_RIGHT
+    exposedAggregates = Locations, Addresses
+  }
+
+  /* Customer-Supplier (asymmetric, downstream has influence) -------------
+   * Special case of upstream-downstream: downstream's priorities factor
+   * into upstream planning. Note: CF and OHS are NOT applicable here
+   * (semantic-rule errors). ACL is allowed but emits a semantic WARNING
+   * (rule #7 in Semantic Rules.md) — kept here to show the form.
+   */
+  CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : CustomerFrontendBackendRelationship {
+    implementationTechnology = "RESTful HTTP"
+    downstreamRights = OPINION_LEADER
+    exposedAggregates = Customers
+  }
+
+  /* Upstream-Downstream with CF (no ACL) ---------------------------------
+   * Downstream conforms to the upstream model wholesale — no translation.
+   * Cheap to integrate, but downstream becomes coupled to upstream changes.
+   */
+  PolicyManagementContext [D,CF]<-[U,OHS,PL] PrintingContext {
+    implementationTechnology = "SOAP"
+  }
+}
+
+/* ---------------------------------------------------------------------------
+ * Bounded Context declarations.
+ *
+ * Each name used above in `contains` and in relationship lines must resolve
+ * to a BoundedContext declaration somewhere in the file. Empty bodies are
+ * legal — declarations can stay minimal in a strategic-only map.
+ *
+ * Aggregates referenced by `exposedAggregates` MUST live inside the upstream
+ * BoundedContext of the relationship — see the LocationContext block (which
+ * owns Locations + Addresses, exposed to CargoBookingContext) and the
+ * CustomerManagementContext block (which owns Customers, exposed to
+ * CustomerSelfServiceContext).
+ * --------------------------------------------------------------------------- */
+
+BoundedContext CargoBookingContext
+BoundedContext VoyagePlanningContext
+
+BoundedContext LocationContext {
+  Aggregate Locations
+  Aggregate Addresses
+}
+
+BoundedContext ContractsContext
+BoundedContext ClaimsContext
+
+BoundedContext CustomerSelfServiceContext
+
+BoundedContext CustomerManagementContext {
+  Aggregate Customers
+}
+
+BoundedContext PrintingContext
+BoundedContext PolicyManagementContext

package/template/.claude/skills/context-map/reference/Bounded Context/Bounded Context.md

@@ -1,41 +1,41 @@
-```cml
-BoundedContext CustomerManagementContext implements CustomerManagementDomain {
-  type = FEATURE
-  domainVisionStatement = "The customer management context is responsible for ..."
-  implementationTechnology = "Java, JEE Application"
-  responsibilities = "Customers", "Addresses"
-  knowledgeLevel = CONCRETE
-
-  Module addresses {
-    Aggregate Addresses {
-      Entity Address {
-        String city
-      }
-    }
-  }
-  Aggregate Customers {
-    Entity Customer {
-      aggregateRoot
-
-      - SocialInsuranceNumber sin
-      String firstname
-      String lastname
-      - List<Address> addresses
-    }
-  }
-}
-```
-
-Note: Bounded Context names must be unique within your CML model.
-
-[[implements]]
-[[refines]]
-[[domainVisionStatement]]
-[[implementationTechnology]]
-[[responsibilities]]
-[[Domain-Driven Design/Context Map/Bounded Context/type]]
-[[knowledgeLevel]]
-[[businessModel]]
-[[evolution]]
-[[realizes]]
+```cml
+BoundedContext CustomerManagementContext implements CustomerManagementDomain {
+  type = FEATURE
+  domainVisionStatement = "The customer management context is responsible for ..."
+  implementationTechnology = "Java, JEE Application"
+  responsibilities = "Customers", "Addresses"
+  knowledgeLevel = CONCRETE
+
+  Module addresses {
+    Aggregate Addresses {
+      Entity Address {
+        String city
+      }
+    }
+  }
+  Aggregate Customers {
+    Entity Customer {
+      aggregateRoot
+
+      - SocialInsuranceNumber sin
+      String firstname
+      String lastname
+      - List<Address> addresses
+    }
+  }
+}
+```
+
+Note: Bounded Context names must be unique within your CML model.
+
+[[implements]]
+[[refines]]
+[[domainVisionStatement]]
+[[implementationTechnology]]
+[[responsibilities]]
+[[Domain-Driven Design/Context Map/Bounded Context/type]]
+[[knowledgeLevel]]
+[[businessModel]]
+[[evolution]]
+[[realizes]]
 [[Bounded Context Relationship]]

package/template/.claude/skills/context-map/reference/Bounded Context/businessModel.md

@@ -1,6 +1,6 @@
-https://github.com/ddd-crew/bounded-context-canvas
-- UNDEFINED
-- REVENUE
-- ENGAGEMENT
-- COMPLIANCE
+https://github.com/ddd-crew/bounded-context-canvas
+- UNDEFINED
+- REVENUE
+- ENGAGEMENT
+- COMPLIANCE
 - COST_REDUCTION

package/template/.claude/skills/context-map/reference/Bounded Context/domainVisionStatement.md

@@ -1,3 +1,3 @@
-The `domainVisionStatement` keyword describes the vision statement of your bounded context, according to the DDD Domain Vision Statement pattern. https://contextmapper.org/docs/domain-vision-statement/
-
+The `domainVisionStatement` keyword describes the vision statement of your bounded context, according to the DDD Domain Vision Statement pattern. https://contextmapper.org/docs/domain-vision-statement/
+
 Can be used in a [[Domain-Driven Design/Context Map/Bounded Context/Bounded Context|Bounded Context]], a [[Domain]], and a subdomain.

package/template/.claude/skills/context-map/reference/Bounded Context/evolution.md

@@ -1,6 +1,6 @@
-https://github.com/ddd-crew/bounded-context-canvas
-- UNDEFINED
-- GENESIS
-- CUSTOM_BUILT
-- PRODUCT
+https://github.com/ddd-crew/bounded-context-canvas
+- UNDEFINED
+- GENESIS
+- CUSTOM_BUILT
+- PRODUCT
 - COMMODITY

package/template/.claude/skills/context-map/reference/Bounded Context/implementationTechnology.md

@@ -1 +1 @@
-The `implementationTechnology` adds information about how the corresponding bounded context is implemented. Note that this attribute does not correspond to any DDD pattern.
+The `implementationTechnology` adds information about how the corresponding bounded context is implemented. Note that this attribute does not correspond to any DDD pattern.

package/template/.claude/skills/context-map/reference/Bounded Context/implements.md

@@ -1 +1 @@
-The `implements` keyword specifies which domain or subdomains are implemented by this bounded context. Behind the `implements` keyword you can either reference a list of subdomains (comma-separated) or one top-level domain.
+The `implements` keyword specifies which domain or subdomains are implemented by this bounded context. Behind the `implements` keyword you can either reference a list of subdomains (comma-separated) or one top-level domain.

package/template/.claude/skills/context-map/reference/Bounded Context/knowledgeLevel.md

@@ -1,5 +1,5 @@
-The `knowledgeLevel` keyword defines the knowledge level of the bounded context which can be one of the following two:
-- `CONCRETE`
-- `META`
-
+The `knowledgeLevel` keyword defines the knowledge level of the bounded context which can be one of the following two:
+- `CONCRETE`
+- `META`
+
 Also supports [[Aggregate]]

package/template/.claude/skills/context-map/reference/Bounded Context/realizes.md

@@ -1,9 +1,9 @@
-If your bounded context is of the type TEAM, you can specify which bounded context the team implements by using the `realizes` keyword. The following example illustrates this:
-
-```cml
-BoundedContext CustomersBackofficeTeam implements CustomerManagementDomain realizes CustomerManagementContext {
-  type = TEAM
-  domainVisionStatement = "This team is responsible for implementing ..."
-}
-```
-
+If your bounded context is of the type TEAM, you can specify which bounded context the team implements by using the `realizes` keyword. The following example illustrates this:
+
+```cml
+BoundedContext CustomersBackofficeTeam implements CustomerManagementDomain realizes CustomerManagementContext {
+  type = TEAM
+  domainVisionStatement = "This team is responsible for implementing ..."
+}
+```
+

package/template/.claude/skills/context-map/reference/Bounded Context/refines.md

@@ -1,10 +1,10 @@
-The `refines` keyword allows you to create some kind of an inheritance hierarchy in case one bounded context can be seen as a refinement of another bounded context.
-However, note that this is only a modeling information and generators do not recursively resolve the domain model (Aggregates, etc.) of refined bounded contexts.
-
-```cml
-BoundedContext ContextMapperTool refines StrategicDomainDrivenDesignContext {
-  type FEATURE
-  domainVisionStatement "Context Mapper provides a formal way to model strategic DDD Context Maps."
-  implementationTechnology "Java, Eclipse"
-}
-```
+The `refines` keyword allows you to create some kind of an inheritance hierarchy in case one bounded context can be seen as a refinement of another bounded context.
+However, note that this is only a modeling information and generators do not recursively resolve the domain model (Aggregates, etc.) of refined bounded contexts.
+
+```cml
+BoundedContext ContextMapperTool refines StrategicDomainDrivenDesignContext {
+  type FEATURE
+  domainVisionStatement "Context Mapper provides a formal way to model strategic DDD Context Maps."
+  implementationTechnology "Java, Eclipse"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context/responsibilities.md

@@ -1,26 +1,26 @@
-With the `responsibilities` keyword you are allowed to specify the responsibilities of the bounded context, according to the DDD Responsibility Layers pattern.
-
-Can be used on [[Domain-Driven Design/Context Map/Bounded Context/Bounded Context|Bounded Context]]s and [[Aggregate]]s to specify their responsibilities.
-
-```cml
-BoundedContext CustomerManagementContext implements CustomerManagementDomain {
-  type = FEATURE
-  domainVisionStatement = "The customer management context is responsible for ..."
-  implementationTechnology = "Java, JEE Application"
-  responsibilities = "Customers", "Addresses"
-}
-
-Aggregate Customers {
-  responsibilities = "Customers", "Addresses"
-  
-  Entity Customer { 
-    aggregateRoot
-    
-    - SocialInsuranceNumber sin
-    String firstname
-    String lastname
-    - List<Address> addresses
-  }
-}
-```
-
+With the `responsibilities` keyword you are allowed to specify the responsibilities of the bounded context, according to the DDD Responsibility Layers pattern.
+
+Can be used on [[Domain-Driven Design/Context Map/Bounded Context/Bounded Context|Bounded Context]]s and [[Aggregate]]s to specify their responsibilities.
+
+```cml
+BoundedContext CustomerManagementContext implements CustomerManagementDomain {
+  type = FEATURE
+  domainVisionStatement = "The customer management context is responsible for ..."
+  implementationTechnology = "Java, JEE Application"
+  responsibilities = "Customers", "Addresses"
+}
+
+Aggregate Customers {
+  responsibilities = "Customers", "Addresses"
+  
+  Entity Customer { 
+    aggregateRoot
+    
+    - SocialInsuranceNumber sin
+    String firstname
+    String lastname
+    - List<Address> addresses
+  }
+}
+```
+

package/template/.claude/skills/context-map/reference/Bounded Context/type.md

@@ -1,23 +1,23 @@
-# Bounded Context Type
-
-The `type` provides an indicator for which reason a bounded context may have been evolved. It further allows you to specify from which viewpoint you describe your bounded contexts.
-
-- `FEATURE`: analysis or early design abstractions, taking a functional scenario view
-  - For example, everything that is related to customer management in an insurance scenario: create customer, update customer, update customer address, etc.
-- `APPLICATION`: represent more elaborated, logical designs and implementation views
-  - For example: a self-service frontend application for the customers, a backend system to manage the customers and contract, etc.
-  - An application typically encompasses multiple functional features. In a (micro-)service-oriented architecture, each (micro-)service can be seen as an application.
-- `SYSTEM`: contexts add a more physical, process- and deployment-oriented view
-  - Examples for systems: a single page application for the frontend, a Spring Boot application that realizes the domain logic, an Oracle database that holds the data, etc.
-  - An application typically consists of multiple systems.
-- `TEAM`: allows you to specify which team is implementing which bounded contexts
-  - For example: multiple teams work on different parts of the software: customer frontend team, customer backend\_ team, contracts team, etc.
-
-## Example: The "Returns" Domain
-
-1. Feature Context: We identify "Return Eligibility." This is purely a business concept: rules checking if an item is within the 30-day window and undamaged. It doesn't imply a server or a database yet.
-2. Application Context: We design the "Returns Service." This is a deployable logical unit (a Microservice) that handles eligibility, printing labels, and refund triggering. It encapsulates the "Return Eligibility" feature.
-3. System Context: When deploying, the "Returns Service" is actually split into two physical pieces:
-   - "Returns Backend API" (Spring Boot container).
-   - "Returns Dashboard" (React SPA for warehouse workers). These are two separate SYSTEM contexts.
-1. Team Context: All of the above is owned by "Team After-Sales", a squad of 6 developers.
+# Bounded Context Type
+
+The `type` provides an indicator for which reason a bounded context may have been evolved. It further allows you to specify from which viewpoint you describe your bounded contexts.
+
+- `FEATURE`: analysis or early design abstractions, taking a functional scenario view
+  - For example, everything that is related to customer management in an insurance scenario: create customer, update customer, update customer address, etc.
+- `APPLICATION`: represent more elaborated, logical designs and implementation views
+  - For example: a self-service frontend application for the customers, a backend system to manage the customers and contract, etc.
+  - An application typically encompasses multiple functional features. In a (micro-)service-oriented architecture, each (micro-)service can be seen as an application.
+- `SYSTEM`: contexts add a more physical, process- and deployment-oriented view
+  - Examples for systems: a single page application for the frontend, a Spring Boot application that realizes the domain logic, an Oracle database that holds the data, etc.
+  - An application typically consists of multiple systems.
+- `TEAM`: allows you to specify which team is implementing which bounded contexts
+  - For example: multiple teams work on different parts of the software: customer frontend team, customer backend\_ team, contracts team, etc.
+
+## Example: The "Returns" Domain
+
+1. Feature Context: We identify "Return Eligibility." This is purely a business concept: rules checking if an item is within the 30-day window and undamaged. It doesn't imply a server or a database yet.
+2. Application Context: We design the "Returns Service." This is a deployable logical unit (a Microservice) that handles eligibility, printing labels, and refund triggering. It encapsulates the "Return Eligibility" feature.
+3. System Context: When deploying, the "Returns Service" is actually split into two physical pieces:
+   - "Returns Backend API" (Spring Boot container).
+   - "Returns Dashboard" (React SPA for warehouse workers). These are two separate SYSTEM contexts.
+1. Team Context: All of the above is owned by "Team After-Sales", a squad of 6 developers.

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Anticorruption Layer.md

@@ -1,5 +1,5 @@
-```cml
-DebtCollection [D,ACL]<-[U,OHS,PL] PrintingContext {
-  implementationTechnology = "SOAP"
-}
-```
+```cml
+DebtCollection [D,ACL]<-[U,OHS,PL] PrintingContext {
+  implementationTechnology = "SOAP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Bounded Context Relationship.md

@@ -1,13 +1,13 @@
-symmetric relationships
-- [[Partnership (P)]]
-- [[Shared Kernel (SK)]]
-asymmetric relationships
-- Upstream-Downstream (generic)
-- [[Customer-Supplier (C-S)]], a special form of an Upstream-Downstream relationship
-
-```cml
-CargoBookingContext [D]<-[U] LocationContext
-
-// A colon at the end assigns a relationship a name
-LocationContext Upstream-Downstream CargoBookingContext : CargoLocationRelationship
+symmetric relationships
+- [[Partnership (P)]]
+- [[Shared Kernel (SK)]]
+asymmetric relationships
+- Upstream-Downstream (generic)
+- [[Customer-Supplier (C-S)]], a special form of an Upstream-Downstream relationship
+
+```cml
+CargoBookingContext [D]<-[U] LocationContext
+
+// A colon at the end assigns a relationship a name
+LocationContext Upstream-Downstream CargoBookingContext : CargoLocationRelationship
 ```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Conformist.md

@@ -1,5 +1,5 @@
-```cml
-PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
-  implementationTechnology = "RESTful HTTP"
-}
-```
+```cml
+PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
+  implementationTechnology = "RESTful HTTP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Customer-Supplier (C-S).md

@@ -1,23 +1,23 @@
-The customer-supplier relationship is a special case of a upstream-downstream relationship
-
-A customer-supplier relationship is an upstream-downstream relationship where the downstream priorities factor into upstream planning.
-The upstream team may succeed interdependently of the fate of the downstream team and therefore the needs of the downstream have to be addressed by the upstream. They interact as customer and supplier.
-
-```cml
-CustomerSelfServiceContext [D,C]<-[U,S] CustomerManagementContext
-
-CustomerSelfServiceContext Customer-Supplier CustomerManagementContext
-
-CustomerSelfServiceContext [C]<-[S] CustomerManagementContext
-
-CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : Customer_Frontend_Backend_Relationship { // Relationship name is optional
-  implementationTechnology = "RESTful HTTP"
-  
-CustomerSelfServiceContext[ACL] Customer-Supplier [PL]CustomerManagementContext
-}
-```
-
-The [[Conformist]] pattern is not applicable in a Customer/Supplier relationship.
-The [[Open Host Service]] pattern is not applicable in a Customer/Supplier relationship.
-The [[Anticorruption Layer]] pattern can be used in a Customer/Supplier relationship, but this leads to contradictions with the original pattern definition according to our understanding.
+The customer-supplier relationship is a special case of a upstream-downstream relationship
+
+A customer-supplier relationship is an upstream-downstream relationship where the downstream priorities factor into upstream planning.
+The upstream team may succeed interdependently of the fate of the downstream team and therefore the needs of the downstream have to be addressed by the upstream. They interact as customer and supplier.
+
+```cml
+CustomerSelfServiceContext [D,C]<-[U,S] CustomerManagementContext
+
+CustomerSelfServiceContext Customer-Supplier CustomerManagementContext
+
+CustomerSelfServiceContext [C]<-[S] CustomerManagementContext
+
+CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : Customer_Frontend_Backend_Relationship { // Relationship name is optional
+  implementationTechnology = "RESTful HTTP"
+  
+CustomerSelfServiceContext[ACL] Customer-Supplier [PL]CustomerManagementContext
+}
+```
+
+The [[Conformist]] pattern is not applicable in a Customer/Supplier relationship.
+The [[Open Host Service]] pattern is not applicable in a Customer/Supplier relationship.
+The [[Anticorruption Layer]] pattern can be used in a Customer/Supplier relationship, but this leads to contradictions with the original pattern definition according to our understanding.
 The usage of Anticorruption Layer in a Customer/Supplier relationship produces a Warning only.

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Open Host Service.md

@@ -1,5 +1,5 @@
-```cml
-PrintingContext [U,OHS]->[D,ACL] PolicyManagementContext {
-  implementationTechnology = "SOAP"
-}
+```cml
+PrintingContext [U,OHS]->[D,ACL] PolicyManagementContext {
+  implementationTechnology = "SOAP"
+}
 ```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Partnership (P).md

@@ -1,14 +1,14 @@
-```cml
-ContractsContext [P]<->[P] ClaimsContext {
-  implementationTechnology = "Messaging"
-}
-
-ContractsContext Partnership ClaimsContext {
-  implementationTechnology = "Messaging"
-}
-
-// With a colon it is possible (optionally) to add a relationship name to the specification
-ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
-  implementationTechnology = "Messaging"
-}
+```cml
+ContractsContext [P]<->[P] ClaimsContext {
+  implementationTechnology = "Messaging"
+}
+
+ContractsContext Partnership ClaimsContext {
+  implementationTechnology = "Messaging"
+}
+
+// With a colon it is possible (optionally) to add a relationship name to the specification
+ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
+  implementationTechnology = "Messaging"
+}
 ```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Published Language.md

@@ -1,5 +1,5 @@
-```cml
-PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
-  implementationTechnology = "RESTful HTTP"
-}
+```cml
+PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
+  implementationTechnology = "RESTful HTTP"
+}
 ```