@phuc1403/musketeer 0.8.0 → 0.10.0

package/template/.claude/skills/code-review/references/verification-before-completion.md

@@ -0,0 +1,139 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Why This Matters
+
+From 24 failure memories:
+- your human partner said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/template/.claude/skills/context-map/SKILL.md

@@ -1,80 +1,80 @@
----
-name: context-map
-description: Write or update a DDD Context Map in CML (Context Mapper Language).
----
-
-<what-to-do>
-
-Given a Context Map intent, produce or update the single `docs/bounded-contexts/context-map.cml` (one map per system, spanning every BC). The four intent shapes (use these exact labels):
-
-- **`BC`** — name, optional `type` / `domainVisionStatement` / `responsibilities`. Adds it to `contains` and appends a `BoundedContext <Name>` declaration.
-- **`peer-context`** — same shape as `BC`, named after an external system. Used for every `external_system` declared on the EventStorming wall.
-- **`relationship`** — upstream BC, downstream BC, shape (Partnership / Shared-Kernel / Upstream-Downstream / Customer-Supplier), role brackets, optional name, optional `{ implementationTechnology, downstreamRights, exposedAggregates }` attributes.
-- **`Aggregate`** — name + owning BC. Adds `Aggregate <Name>` inside the BC's `{ … }` body, creating the body if it was empty. Required when the name appears in any relationship's `exposedAggregates`. Maintain 1:1 sync with the wall JSON: every entry in `aggregates[]` on the BC's `docs/bounded-contexts/{bc}/event-storming.json` (or the general `docs/event-storming.json` before segregation) has a matching `Aggregate <Name>` inside its owning BC, written the same turn.
-
-Workflow:
-
-1. **Locate or scaffold the file.** If it doesn't exist, scaffold a minimal `ContextMap SystemContextMap { type = SYSTEM_LANDSCAPE state = AS_IS contains <BCs> }` block followed by one `BoundedContext <Name>` declaration per BC in `contains`. Use [example.cml](./example.cml) as a **syntax reference**, not a literal copy — its DDDSample BCs are illustrative.
-2. **Write the requested change.** Per intent shape: add the `contains` entry + `BoundedContext` declaration (`BC` / `peer-context`); add the relationship line (`relationship`); add `Aggregate <Name>` inside the owning BC's body (`Aggregate`). For every BC newly referenced anywhere, append a `BoundedContext <Name>` declaration — without it Xtext linker fails with `Couldn't resolve reference to BoundedContext '<Name>'`.
-3. **Lint.** A PostToolUse hook auto-runs Context Mapper validation on every `.cml` edit. Treat any `ERROR …` line in its output as blocking; `WARNING …` lines (e.g. ACL on Customer-Supplier per Semantic Rule #7) are allowed when intentional.
-4. **Hand-audit.** `cm validate` is necessary but not sufficient — see Limitations below. Audit three things by hand before reporting success: (i) every `exposedAggregates` name lives in the upstream BC of its relationship; (ii) every role bracket combo respects the 10 Semantic Rules; (iii) no Aggregate name is duplicated across BCs unless deliberate.
-5. **Report.** State the line(s) written and PASS/FAIL of `cm validate` (on FAIL, paste only the first `ERROR` line and where to fix). Call out anything the hand-audit flagged.
-
-If a piece of the intent is ambiguous (e.g. which side is upstream, which roles to use), ask the caller — don't invent. The skill's job is mechanical correctness, not design judgement.
-
-</what-to-do>
-
-<supporting-info>
-
-## File location
-
-`docs/bounded-contexts/context-map.cml` — a single map for the whole system, sitting beside the per-BC folders.
-
-## Reference (load lazily by intent shape)
-
-The reference is an Obsidian folder with `[[wikilinks]]` between files. Load in tiers — don't front-load everything:
-
-- **Always** (first invocation this session):
-  - `./reference/Context Map.md` — top-level grammar, relationship arrows, role brackets, attributes.
-  - `./reference/Semantic Rules.md` — the 10 combination rules.
-- **When writing a `BC` or `peer-context`** with non-trivial attributes:
-  - `./reference/Bounded Context/Bounded Context.md` — attribute docs (`implements`, `refines`, `domainVisionStatement`, `responsibilities`, `type`, `knowledgeLevel`, `businessModel`, `evolution`, `realizes`).
-- **When writing a `relationship`**:
-  - `./reference/Bounded Context Relationship/Bounded Context Relationship.md` — per-pattern pages (Partnership, Shared Kernel, Customer-Supplier, OHS, PL, CF, ACL).
-- **When writing an `Aggregate` or setting `exposedAggregates`**:
-  - `./reference/Aggregate/Aggregate.md` — Aggregate composition.
-- **When a BC uses `implements` / `refines`**:
-  - `./reference/Domain/Domain.md` — Domain / Subdomain framing.
-
-## Linting (mandatory before reporting success)
-
-Validation runs automatically via the PostToolUse `validate-cml-hook` on every `.cml` edit (Context Mapper CLI, self-bootstrapped from Maven on first run; requires Java 8+).
-
-**CML-specific failure modes to recognise:**
-
-- `Couldn't resolve reference to BoundedContext '<Name>'` + `The Bounded Context 'null' is not part of the Context Map.` — a name in `contains` or a relationship line has no `BoundedContext <Name>` declaration. Fix: append the missing declaration.
-- `ERROR in null on line N: no viable alternative at input '<token>'` — parse error. Re-read the grammar at the reported line.
-
-## Limitations of `cm validate` — hand-audit is required after it passes
-
-Confirmed-misses (tested against 6.12.0):
-
-| Catches                                                   | Misses                                                                                                                                                                       |
-| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Parse errors with line numbers                            | Semantic Rule violations from `Semantic Rules.md` (OHS on Customer-Supplier #6, CF on Customer-Supplier #5, ACL/CF/OHS/PL on symmetric relationships #4, etc.)               |
-| Linker errors when they fire                              | Duplicate Aggregate names across different BCs (CML scopes `exposedAggregates` by upstream BC, so duplicates resolve rather than collide — but they're semantically muddled) |
-| Resource-level diagnostics from `cmlResource.getErrors()` | Anything that needs the full Xtext `IResourceValidator` chain (Eclipse/VSCode extension surfaces these; the CLI does not)                                                    |
-
-After `cm validate` prints "without errors", audit by hand:
-
-1. Every `exposedAggregates` name resolves to an Aggregate declared inside the **upstream** BC of that relationship line.
-2. Every role bracket combo is allowed by the 10 Semantic Rules (consult `./reference/Semantic Rules.md`).
-3. No Aggregate name is duplicated across BCs unless deliberate.
-
-For deeper validation, open the file in VSCode with the Context Mapper extension installed.
-
-## Glossary
-
-Same `ubiquitous-language.md` convention as the EventStorming skills. Challenge BC names against the language doc before writing. If a relationship introduces a novel domain term, add a one-sentence definition in `docs/ubiquitous-language.md` the same turn.
-
-</supporting-info>
+---
+name: context-map
+description: Write or update a DDD Context Map in CML (Context Mapper Language).
+---
+
+<what-to-do>
+
+Given a Context Map intent, produce or update the single `docs/bounded-contexts/context-map.cml` (one map per system, spanning every BC). The four intent shapes (use these exact labels):
+
+- **`BC`** — name, optional `type` / `domainVisionStatement` / `responsibilities`. Adds it to `contains` and appends a `BoundedContext <Name>` declaration.
+- **`peer-context`** — same shape as `BC`, named after an external system. Used for every `external_system` declared on the EventStorming wall.
+- **`relationship`** — upstream BC, downstream BC, shape (Partnership / Shared-Kernel / Upstream-Downstream / Customer-Supplier), role brackets, optional name, optional `{ implementationTechnology, downstreamRights, exposedAggregates }` attributes.
+- **`Aggregate`** — name + owning BC. Adds `Aggregate <Name>` inside the BC's `{ … }` body, creating the body if it was empty. Required when the name appears in any relationship's `exposedAggregates`. Maintain 1:1 sync with the wall JSON: every entry in `aggregates[]` on the BC's `docs/bounded-contexts/{bc}/event-storming.json` (or the general `docs/event-storming.json` before segregation) has a matching `Aggregate <Name>` inside its owning BC, written the same turn.
+
+Workflow:
+
+1. **Locate or scaffold the file.** If it doesn't exist, scaffold a minimal `ContextMap SystemContextMap { type = SYSTEM_LANDSCAPE state = AS_IS contains <BCs> }` block followed by one `BoundedContext <Name>` declaration per BC in `contains`. Use [example.cml](./example.cml) as a **syntax reference**, not a literal copy — its DDDSample BCs are illustrative.
+2. **Write the requested change.** Per intent shape: add the `contains` entry + `BoundedContext` declaration (`BC` / `peer-context`); add the relationship line (`relationship`); add `Aggregate <Name>` inside the owning BC's body (`Aggregate`). For every BC newly referenced anywhere, append a `BoundedContext <Name>` declaration — without it Xtext linker fails with `Couldn't resolve reference to BoundedContext '<Name>'`.
+3. **Lint.** A PostToolUse hook auto-runs Context Mapper validation on every `.cml` edit. Treat any `ERROR …` line in its output as blocking; `WARNING …` lines (e.g. ACL on Customer-Supplier per Semantic Rule #7) are allowed when intentional.
+4. **Hand-audit.** `cm validate` is necessary but not sufficient — see Limitations below. Audit three things by hand before reporting success: (i) every `exposedAggregates` name lives in the upstream BC of its relationship; (ii) every role bracket combo respects the 10 Semantic Rules; (iii) no Aggregate name is duplicated across BCs unless deliberate.
+5. **Report.** State the line(s) written and PASS/FAIL of `cm validate` (on FAIL, paste only the first `ERROR` line and where to fix). Call out anything the hand-audit flagged.
+
+If a piece of the intent is ambiguous (e.g. which side is upstream, which roles to use), ask the caller — don't invent. The skill's job is mechanical correctness, not design judgement.
+
+</what-to-do>
+
+<supporting-info>
+
+## File location
+
+`docs/bounded-contexts/context-map.cml` — a single map for the whole system, sitting beside the per-BC folders.
+
+## Reference (load lazily by intent shape)
+
+The reference is an Obsidian folder with `[[wikilinks]]` between files. Load in tiers — don't front-load everything:
+
+- **Always** (first invocation this session):
+  - `./reference/Context Map.md` — top-level grammar, relationship arrows, role brackets, attributes.
+  - `./reference/Semantic Rules.md` — the 10 combination rules.
+- **When writing a `BC` or `peer-context`** with non-trivial attributes:
+  - `./reference/Bounded Context/Bounded Context.md` — attribute docs (`implements`, `refines`, `domainVisionStatement`, `responsibilities`, `type`, `knowledgeLevel`, `businessModel`, `evolution`, `realizes`).
+- **When writing a `relationship`**:
+  - `./reference/Bounded Context Relationship/Bounded Context Relationship.md` — per-pattern pages (Partnership, Shared Kernel, Customer-Supplier, OHS, PL, CF, ACL).
+- **When writing an `Aggregate` or setting `exposedAggregates`**:
+  - `./reference/Aggregate/Aggregate.md` — Aggregate composition.
+- **When a BC uses `implements` / `refines`**:
+  - `./reference/Domain/Domain.md` — Domain / Subdomain framing.
+
+## Linting (mandatory before reporting success)
+
+Validation runs automatically via the PostToolUse `validate-cml-hook` on every `.cml` edit (Context Mapper CLI, self-bootstrapped from Maven on first run; requires Java 8+).
+
+**CML-specific failure modes to recognise:**
+
+- `Couldn't resolve reference to BoundedContext '<Name>'` + `The Bounded Context 'null' is not part of the Context Map.` — a name in `contains` or a relationship line has no `BoundedContext <Name>` declaration. Fix: append the missing declaration.
+- `ERROR in null on line N: no viable alternative at input '<token>'` — parse error. Re-read the grammar at the reported line.
+
+## Limitations of `cm validate` — hand-audit is required after it passes
+
+Confirmed-misses (tested against 6.12.0):
+
+| Catches                                                   | Misses                                                                                                                                                                       |
+| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Parse errors with line numbers                            | Semantic Rule violations from `Semantic Rules.md` (OHS on Customer-Supplier #6, CF on Customer-Supplier #5, ACL/CF/OHS/PL on symmetric relationships #4, etc.)               |
+| Linker errors when they fire                              | Duplicate Aggregate names across different BCs (CML scopes `exposedAggregates` by upstream BC, so duplicates resolve rather than collide — but they're semantically muddled) |
+| Resource-level diagnostics from `cmlResource.getErrors()` | Anything that needs the full Xtext `IResourceValidator` chain (Eclipse/VSCode extension surfaces these; the CLI does not)                                                    |
+
+After `cm validate` prints "without errors", audit by hand:
+
+1. Every `exposedAggregates` name resolves to an Aggregate declared inside the **upstream** BC of that relationship line.
+2. Every role bracket combo is allowed by the 10 Semantic Rules (consult `./reference/Semantic Rules.md`).
+3. No Aggregate name is duplicated across BCs unless deliberate.
+
+For deeper validation, open the file in VSCode with the Context Mapper extension installed.
+
+## Glossary
+
+Same `ubiquitous-language.md` convention as the EventStorming skills. Challenge BC names against the language doc before writing. If a relationship introduces a novel domain term, add a one-sentence definition in `docs/ubiquitous-language.md` the same turn.
+
+</supporting-info>

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]]