@formicoidea/labre-framework-ddd-core-domain 0.32.0 → 0.33.0

package/dist/rules.js

@@ -0,0 +1,206 @@
+import { CORE_DOMAIN_BACKGROUND, CORE_DOMAIN_LEGEND_TONES, } from './core-domain/background.js';
+import { CORE_DOMAIN_ROLE, CORE_DOMAIN_ROLES } from './roles.js';
+/**
+ * Core Domain Chart validation rules.
+ *
+ * DATA owned by the framework, versioned per rule: the engine
+ * (`@labre/affine-block-surface`) knows how to evaluate a FAMILY, never a
+ * concrete rule. Adding a rule is adding an entry to this array.
+ *
+ * Registered from the flag-gated `DddCoreDomainViewExtension`, so switching the
+ * `ddd-core-domain` flag off removes the rules with the rest of the tooling —
+ * charts already drawn keep rendering, they simply stop being checked (see
+ * `docs/adr/0009`).
+ *
+ * Every rule is `warning` or `audit`: nothing downstream implements a blocking
+ * level — no gesture is refused anywhere in this library — so shipping one
+ * would be data claiming an effect that does not exist.
+ *
+ * ## Two rules that are NOT here (PO, 26/08/2026)
+ *
+ * `suspect-supporting` (a supporting sub-domain drawn at high complexity) and
+ * `complex-generic` (a generic one drawn at high complexity) were cut from v1:
+ * both hang on the WORDING of the chart's regions — what exactly the middle
+ * band claims — and the PO has not settled it. They are two `element-in-zone`
+ * entries the day it is, and nothing else moves.
+ */
+/**
+ * **C1** — an outsourced sub-domain has no business in the Core quadrant.
+ *
+ * The one thing a Core Domain Chart is FOR: the core is what the organisation
+ * must own, because it is what differentiates it. A sub-domain marked
+ * "outsourced / purchased" plotted in the core is not a placement mistake — it
+ * is a strategy contradiction, and the chart exists to make it visible.
+ *
+ * Written on `core-domain:subdomain-outsourced` alone: the four other dot
+ * presets are perfectly at home there.
+ *
+ * ## What it stays silent about
+ *
+ * A dot off every chart (a sketch on blank canvas), and — this is the reason
+ * the zones name their variant — a dot on a chart turned to its MIGRATION
+ * reading, where there is no Core quadrant to be in. Judging one against a
+ * region the user cannot see would be indicting them over a frame turned to its
+ * other page.
+ */
+const outsourcedCore = {
+    id: 'core-domain.outsourced-core',
+    framework: 'core-domain',
+    family: 'element-in-zone',
+    severity: 'warning',
+    appliesTo: CORE_DOMAIN_ROLE.outsourced,
+    roles: CORE_DOMAIN_ROLES,
+    messageKey: 'com.labre.core-domain.validation.outsourced-core',
+    messageFallback: 'This outsourced sub-domain sits in the Core quadrant.',
+    suggestionKey: 'com.labre.core-domain.validation.outsourced-core.suggestion',
+    suggestionFallback: 'The core is what the organisation must own — move it out of the Core quadrant, or reclassify it as a big bet.',
+    version: 1,
+    provenance: {
+        source: 'recommendation',
+        reference: 'Core Domain Charts (DDD) — the one question the chart exists to ask',
+    },
+    backgroundRole: CORE_DOMAIN_ROLE.chart,
+    // The frame's own declaration, carried as data exactly like `roles` is: it is
+    // where the Core quadrant's rectangle is written, and the engine reads it
+    // rather than knowing anything about this chart.
+    background: CORE_DOMAIN_BACKGROUND,
+    inZone: { zoneIds: ['core'], expect: 'outside' },
+};
+/**
+ * **C2** — a movement runs from a current position to a future one.
+ *
+ * The grammar of the arrow, and the whole of it: `bc-current` _is moving to_
+ * `bc-future`. An arrow drawn the other way round, or between two current
+ * positions, says something the chart has no reading for.
+ *
+ * Self-loops are a finding too: an arrow whose two ends are the same dot is a
+ * context moving to where it already is.
+ *
+ * ## The three silences, and why each one matters
+ *
+ * - a **free connector** (no role) is not a claim — the user is annotating;
+ * - a movement with a **free end** relates nothing;
+ * - a movement onto **anything outside the alphabet** — a sub-domain preset, a
+ *   neutral shape, a sticky from another framework — is a SKETCH. The alphabet
+ *   of this rule is `bc-current` / `bc-future` and nothing else, so a movement
+ *   drawn from a big bet to a platform is silent rather than indicted. That is
+ *   the hard requirement of the family, and the reason it is shippable.
+ *
+ * No `forbidDuplicate`: two movements drawn between the same two contexts are
+ * two dated statements about the same journey, which is a legitimate way to use
+ * this chart.
+ */
+const malformedMovement = {
+    id: 'core-domain.malformed-movement',
+    framework: 'core-domain',
+    family: 'relation-endpoints',
+    severity: 'warning',
+    // No `appliesTo`: the subject of this rule is a RELATION, and the role that
+    // names it is declared where the family reads it — naming one of the three
+    // indicted elements here would be data that lies.
+    roles: CORE_DOMAIN_ROLES,
+    messageKey: 'com.labre.core-domain.validation.malformed-movement',
+    messageFallback: 'This movement does not run from a current position to a future one.',
+    suggestionKey: 'com.labre.core-domain.validation.malformed-movement.suggestion',
+    suggestionFallback: 'A movement reads "is moving to" — draw it from the context where it stands today to the future position, or reverse it.',
+    version: 1,
+    provenance: {
+        source: 'recommendation',
+        reference: 'Core Domain Charts (DDD) — the grammar of the movement arrow',
+    },
+    backgroundRole: CORE_DOMAIN_ROLE.chart,
+    endpoints: {
+        edgeRole: CORE_DOMAIN_ROLE.movement,
+        allowed: [
+            {
+                source: CORE_DOMAIN_ROLE.bcCurrent,
+                edge: CORE_DOMAIN_ROLE.movement,
+                target: CORE_DOMAIN_ROLE.bcFuture,
+            },
+        ],
+        forbidSelfLoop: true,
+        selfLoop: {
+            messageKey: 'com.labre.core-domain.validation.movement-self-loop',
+            messageFallback: 'This movement points back at its own starting position.',
+            suggestionKey: 'com.labre.core-domain.validation.movement-self-loop.suggestion',
+            suggestionFallback: 'Drop the far end on the future position, or delete the arrow.',
+        },
+    },
+};
+/**
+ * **C3** — sub-domains must not sit on top of each other.
+ *
+ * A readability rule, not a semantic one: a chart where two dots overlap hides
+ * one of them, and a hidden sub-domain is a sub-domain nobody discusses. Written
+ * on the PARENT role, so all five presets are covered for free.
+ *
+ * `minPenetration: 6` — the dot is 26 units across, so six units is roughly a
+ * quarter of one. Two dots grazing each other while somebody arranges a cluster
+ * are silent; one drawn over another is not.
+ */
+const overlappingArtefacts = {
+    id: 'core-domain.overlapping-artefacts',
+    framework: 'core-domain',
+    family: 'no-overlap',
+    severity: 'warning',
+    // No `appliesTo`: the subjects of a `no-overlap` rule are its PAIRS.
+    roles: CORE_DOMAIN_ROLES,
+    messageKey: 'com.labre.core-domain.validation.overlapping-artefacts',
+    messageFallback: 'These two sub-domains overlap and hide each other.',
+    suggestionKey: 'com.labre.core-domain.validation.overlapping-artefacts.suggestion',
+    suggestionFallback: 'Move one of them aside.',
+    version: 1,
+    provenance: {
+        source: 'labre-convention',
+        reference: 'Labre readability convention — no Core Domain Chart rule speaks of overlapping ink',
+    },
+    // Not a frame the rule measures against — an overlap is an overlap wherever
+    // it happens — but the chart a finding is ATTRIBUTED to, so the arbitration
+    // "ignore this rule on the whole chart" has one chart to be written on.
+    backgroundRole: CORE_DOMAIN_ROLE.chart,
+    overlap: [[CORE_DOMAIN_ROLE.subdomain, CORE_DOMAIN_ROLE.subdomain]],
+    minPenetration: 6,
+};
+/**
+ * **C4** — a sub-domain is drawn in one of the five legend colours.
+ *
+ * The chart's notation IS its five colours: the legend the toolbar inserts
+ * lists them, and a dot recoloured by hand out of the shape palette silently
+ * stops meaning anything. Judged on the tone FAMILY, never on the hex, so every
+ * legitimate shade the shape toolbar can produce still reads as its colour.
+ *
+ * `audit`, on purpose and in every profile: recolouring a dot is a normal thing
+ * to do while thinking, and the day it matters is the day somebody reads the
+ * chart back — which is what a conformance report is for. The finding reaches
+ * `violations$`; the canvas says nothing.
+ *
+ * The sanctioned tones are named, not restated: `CORE_DOMAIN_LEGEND_TONES` is
+ * the list of palette entries the declaration built from `CD_SUBDOMAINS`, so
+ * restyling the notation restyles the convention with it, in one place.
+ */
+const offLegendColour = {
+    id: 'core-domain.off-legend-colour',
+    framework: 'core-domain',
+    family: 'tone-convention',
+    severity: 'audit',
+    appliesTo: CORE_DOMAIN_ROLE.subdomain,
+    roles: CORE_DOMAIN_ROLES,
+    messageKey: 'com.labre.core-domain.validation.off-legend-colour',
+    messageFallback: 'This sub-domain is not drawn in one of the legend colours.',
+    suggestionKey: 'com.labre.core-domain.validation.off-legend-colour.suggestion',
+    suggestionFallback: 'The chart reads by its notation — put the dot back on one of the five legend colours, or add the new one to the legend.',
+    version: 1,
+    provenance: {
+        source: 'labre-convention',
+        reference: 'Labre convention — the legend this toolbar inserts declares the palette',
+    },
+    backgroundRole: CORE_DOMAIN_ROLE.chart,
+    background: CORE_DOMAIN_BACKGROUND,
+    tone: { palette: CORE_DOMAIN_LEGEND_TONES },
+};
+export const CORE_DOMAIN_RULES = [
+    outsourcedCore,
+    malformedMovement,
+    overlappingArtefacts,
+    offLegendColour,
+];

package/dist/toolbar/senior-button.d.ts

@@ -2,5 +2,6 @@ import { DddSeniorButtonBase } from '@formicoidea/labre-ddd-shared';
 export declare class EdgelessDddCoreDomainSeniorButton extends DddSeniorButtonBase {
     protected menuTag: "edgeless-ddd-core-domain-menu";
     protected label: string;
+    protected labelKey: string;
     protected icon: import("lit-html").TemplateResult<2>;
 }

package/dist/toolbar/senior-button.js

@@ -4,6 +4,7 @@ export class EdgelessDddCoreDomainSeniorButton extends DddSeniorButtonBase {
         super(...arguments);
         this.menuTag = 'edgeless-ddd-core-domain-menu';
         this.label = 'Core Domain Chart';
+        this.labelKey = 'com.labre.framework.ddd-core-domain';
         this.icon = coreDomainToolbarIcon;
     }
 }

package/dist/toolbar/senior-tool.js

@@ -3,6 +3,7 @@ import { html } from 'lit';
 /** Independent senior tool — Core Domain Chart. */
 export const coreDomainSeniorTool = SeniorToolExtension('ddd-core-domain', ({ block }) => ({
     name: 'Core Domain Chart',
+    labelKey: 'com.labre.framework.ddd-core-domain',
     content: html `<edgeless-ddd-core-domain-senior-button
       .edgeless=${block}
     ></edgeless-ddd-core-domain-senior-button>`,

package/dist/translations.d.ts

@@ -1,14 +1,14 @@
 import { type TranslationKeyManifestEntry } from '@formicoidea/labre-core/std';
 /**
- * THIS framework's contribution to the translation-key manifest.
+ * THIS framework's contribution to the translation-key manifest — every
+ * `com.labre.*` key the Core Domain Chart can hand to `TranslationProvider.t`,
+ * derived from the very declarations the editor registers.
  *
- * Its command labels and descriptions are built from a TEMPLATE, so the
- * concrete keys exist nowhere but in the declarations themselves and the
- * core manifest could not restate them even if it wanted to. The
- * contribution therefore ships WITH the framework: in the bundled
- * distribution `@formicoidea/labre-framework-ddd-core-domain` carries it, and a host
- * composes it into its catalogue exactly as it already composes
- * `coreDomainCommands` into the command registry. See
- * `packages/affine/all/src/translations.ts`.
+ * It lives HERE, not in `@labre/affine/translations`, because the bundled
+ * distribution splits the library along exactly this line:
+ * `@formicoidea/labre-core` is the editor MINUS the frameworks, and a host that
+ * installs `@formicoidea/labre-framework-ddd-core-domain` composes this export
+ * into the catalogue it builds — the same sentence that already holds for
+ * `coreDomainCommands`.
  */
 export declare const coreDomainTranslationEntries: TranslationKeyManifestEntry[];

package/dist/translations.js

@@ -1,15 +1,20 @@
-import { commandTranslationEntries, } from '@formicoidea/labre-core/std';
+import { collectTranslationKeys, commandTranslationEntries, mergeTranslationEntries, } from '@formicoidea/labre-core/std';
 import { coreDomainCommands } from './commands.js';
+import { CORE_DOMAIN_BACKGROUND } from './core-domain/background.js';
+import { CORE_DOMAIN_NUDGES } from './nudges.js';
+import { CORE_DOMAIN_PROFILES } from './profiles.js';
+import { CORE_DOMAIN_ROLES } from './roles.js';
+import { CORE_DOMAIN_RULES } from './rules.js';
 /**
- * THIS framework's contribution to the translation-key manifest.
+ * THIS framework's contribution to the translation-key manifest — every
+ * `com.labre.*` key the Core Domain Chart can hand to `TranslationProvider.t`,
+ * derived from the very declarations the editor registers.
  *
- * Its command labels and descriptions are built from a TEMPLATE, so the
- * concrete keys exist nowhere but in the declarations themselves and the
- * core manifest could not restate them even if it wanted to. The
- * contribution therefore ships WITH the framework: in the bundled
- * distribution `@formicoidea/labre-framework-ddd-core-domain` carries it, and a host
- * composes it into its catalogue exactly as it already composes
- * `coreDomainCommands` into the command registry. See
- * `packages/affine/all/src/translations.ts`.
+ * It lives HERE, not in `@labre/affine/translations`, because the bundled
+ * distribution splits the library along exactly this line:
+ * `@formicoidea/labre-core` is the editor MINUS the frameworks, and a host that
+ * installs `@formicoidea/labre-framework-ddd-core-domain` composes this export
+ * into the catalogue it builds — the same sentence that already holds for
+ * `coreDomainCommands`.
  */
-export const coreDomainTranslationEntries = commandTranslationEntries(coreDomainCommands);
+export const coreDomainTranslationEntries = mergeTranslationEntries(commandTranslationEntries(coreDomainCommands), collectTranslationKeys('role', CORE_DOMAIN_ROLES), collectTranslationKeys('background', CORE_DOMAIN_BACKGROUND), collectTranslationKeys('rule', CORE_DOMAIN_RULES), collectTranslationKeys('nudge', CORE_DOMAIN_NUDGES), collectTranslationKeys('profile', CORE_DOMAIN_PROFILES));

package/dist/view.d.ts

@@ -11,7 +11,9 @@ export declare class DddCoreDomainRenderViewExtension extends ViewExtensionProvi
     setup(context: ViewExtensionContext): void;
 }
 /**
- * Core Domain Chart senior button — independently flag-gated (`ddd-core-domain`).
+ * Core Domain Chart senior button — independently flag-gated (`ddd-core-domain`)
+ * — and, beside it, the validation tooling: the rules, the profiles and the
+ * work-quality checklist.
  *
  * Note: its Templates-panel category is registered by the aggregate package's
  * {@link DddTemplatesViewExtension} (gated by `ddd-templates`), so templates

package/dist/view.js

@@ -1,10 +1,17 @@
+import { QualityNudgeExtension, validationToolbarConfig, ValidationProfileExtension, ValidationRuleExtension, } from '@formicoidea/labre-core/blocks/surface';
 import { ViewExtensionProvider, } from '@formicoidea/labre-core/ext-loader';
-import { CommandExtension } from '@formicoidea/labre-core/std';
+import { ToolbarModuleExtension } from '@formicoidea/labre-core/shared/services';
+import { BlockFlavourIdentifier, CommandExtension } from '@formicoidea/labre-core/std';
+import { RoleVocabularyExtension } from '@formicoidea/labre-core/std/gfx';
 import { coreDomainCommandIcons, coreDomainCommands } from './commands.js';
 import { CoreDomainRendererExtension } from './core-domain/element-renderer.js';
-import { CoreDomainInteraction, CoreDomainView } from './core-domain/element-view.js';
+import { CoreDomainInteraction, CoreDomainView, } from './core-domain/element-view.js';
 import { coreDomainToolbarExtension } from './core-domain/toolbar-config.js';
 import { coreDomainEffects } from './effects.js';
+import { CORE_DOMAIN_NUDGES } from './nudges.js';
+import { CORE_DOMAIN_PROFILES } from './profiles.js';
+import { CORE_DOMAIN_ROLES } from './roles.js';
+import { CORE_DOMAIN_RULES } from './rules.js';
 import { coreDomainSeniorTool } from './toolbar/senior-tool.js';
 /**
  * Core Domain Chart rendering — ALWAYS registered, independent of any flag.
@@ -22,6 +29,13 @@ export class DddCoreDomainRenderViewExtension extends ViewExtensionProvider {
         super.setup(context);
         context.register(CoreDomainView);
         context.register(CoreDomainRendererExtension);
+        // The role VOCABULARY, always on. A role is written in the document, not in
+        // the tooling: the direction reveal of a typed movement and the inversion
+        // command read this, and they have to keep working on a chart drawn while
+        // the flag was on and opened while it is off (`docs/adr/0009`,
+        // `docs/adr/0010`). The rules that JUDGE those roles stay in the
+        // flag-gated extension below.
+        context.register(RoleVocabularyExtension(CORE_DOMAIN_ROLES));
         if (this.isEdgeless(context.scope)) {
             context.register(CoreDomainInteraction);
             context.register(coreDomainToolbarExtension);
@@ -29,7 +43,9 @@ export class DddCoreDomainRenderViewExtension extends ViewExtensionProvider {
     }
 }
 /**
- * Core Domain Chart senior button — independently flag-gated (`ddd-core-domain`).
+ * Core Domain Chart senior button — independently flag-gated (`ddd-core-domain`)
+ * — and, beside it, the validation tooling: the rules, the profiles and the
+ * work-quality checklist.
  *
  * Note: its Templates-panel category is registered by the aggregate package's
  * {@link DddTemplatesViewExtension} (gated by `ddd-templates`), so templates
@@ -47,6 +63,20 @@ export class DddCoreDomainViewExtension extends ViewExtensionProvider {
     setup(context) {
         super.setup(context);
         if (this.isEdgeless(context.scope)) {
+            context.register(ValidationRuleExtension(CORE_DOMAIN_RULES));
+            context.register(ValidationProfileExtension(CORE_DOMAIN_PROFILES));
+            context.register(QualityNudgeExtension(CORE_DOMAIN_NUDGES));
+            // The Validation dropdown on a selected chart's contextual toolbar. A
+            // SECOND module on the same element, through the `custom:` flavour slot:
+            // `coreDomainToolbarExtension` is registered always-on because a stored
+            // chart must keep its legend action, while choosing how hard to check it
+            // is tooling and belongs here. The config itself names no framework — it
+            // reads roles and profiles — so it is the very same object Wardley
+            // registers on its own flavour.
+            context.register(ToolbarModuleExtension({
+                id: BlockFlavourIdentifier('custom:affine:surface:coreDomain'),
+                config: validationToolbarConfig,
+            }));
             context.register(coreDomainSeniorTool);
             context.register(CommandExtension(coreDomainCommands, coreDomainCommandIcons));
         }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@formicoidea/labre-framework-ddd-core-domain",
   "description": "Labre ddd-core-domain framework for @formicoidea/labre-core.",
-  "version": "0.32.0",
+  "version": "0.33.0",
   "type": "module",
   "sideEffects": false,
   "author": "lajola",
@@ -27,8 +27,8 @@
     "dist"
   ],
   "dependencies": {
-    "@formicoidea/labre-core": "0.32.0",
-    "@formicoidea/labre-ddd-shared": "0.32.0",
+    "@formicoidea/labre-core": "0.33.0",
+    "@formicoidea/labre-ddd-shared": "0.33.0",
     "lit": "^3.2.0"
   }
 }

package/dist/core-domain/consts.d.ts

@@ -1,32 +0,0 @@
-/**
- * Visual constants for the Core Domain Chart background (DDD Crew). Authored in
- * a fixed reference space (900 × 820) and scaled uniformly to the element bounds
- * by the renderer. Reproduces the supplied template: two axes (Complexity ×
- * Business differentiation), Low/High ticks and the translucent Generic /
- * Supporting / Core zone bands. The "Notation" legend is a separate prefab group.
- */
-export declare const REF_W = 900;
-export declare const REF_H = 820;
-export declare const COLORS: {
-    readonly axis: "#000000";
-    readonly zoneLabel: "#ffffff";
-    readonly tick: "#777777";
-    readonly title: "#000000";
-};
-/** Translucent zone bands (drawn at 0.6 alpha), back-to-front. */
-export declare const ZONES: ReadonlyArray<{
-    x: number;
-    y: number;
-    w: number;
-    h: number;
-    fill: string;
-}>;
-/** Zone names (centred): [text, x, y, fontSize]. */
-export declare const ZONE_LABELS: ReadonlyArray<readonly [string, number, number, number]>;
-/** Axis frame: origin (ox, oy) bottom-left, up to `top`, right to `right`. */
-export declare const AXIS: {
-    readonly ox: 60;
-    readonly oy: 770;
-    readonly top: 24;
-    readonly right: 846;
-};

package/dist/core-domain/consts.js

@@ -1,30 +0,0 @@
-/**
- * Visual constants for the Core Domain Chart background (DDD Crew). Authored in
- * a fixed reference space (900 × 820) and scaled uniformly to the element bounds
- * by the renderer. Reproduces the supplied template: two axes (Complexity ×
- * Business differentiation), Low/High ticks and the translucent Generic /
- * Supporting / Core zone bands. The "Notation" legend is a separate prefab group.
- */
-export const REF_W = 900;
-export const REF_H = 820;
-export const COLORS = {
-    axis: '#000000',
-    zoneLabel: '#ffffff',
-    tick: '#777777',
-    title: '#000000',
-};
-/** Translucent zone bands (drawn at 0.6 alpha), back-to-front. */
-export const ZONES = [
-    { x: 70, y: 30, w: 150, h: 720, fill: '#b3b3b3' },
-    { x: 220, y: 30, w: 220, h: 720, fill: '#9933ff' },
-    { x: 440, y: 30, w: 400, h: 360, fill: '#4d9900' },
-    { x: 440, y: 390, w: 400, h: 360, fill: '#9933ff' },
-];
-/** Zone names (centred): [text, x, y, fontSize]. */
-export const ZONE_LABELS = [
-    ['Core', 640, 214, 26],
-    ['Supporting', 340, 474, 20],
-    ['Generic', 150, 474, 20],
-];
-/** Axis frame: origin (ox, oy) bottom-left, up to `top`, right to `right`. */
-export const AXIS = { ox: 60, oy: 770, top: 24, right: 846 };