@wildo-ai/platform-core-shared 1.1.4 → 1.1.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wildo-ai/platform-core-shared",
-  "version": "1.1.4",
+  "version": "1.1.6",
   "license": "SEE LICENSE IN LICENSE",
   "description": "Todo app specific models and types",
   "author": "Wildo AI",
@@ -30,20 +30,11 @@
     "test:watch": "vitest"
   },
   "dependencies": {
-    "@wildo-ai/saas-models": "1.1.4",
-    "@wildo-ai/presets-components-models": "1.1.4",
-    "@wildo-ai/zod-decorators": "1.1.4"
+    "@wildo-ai/saas-models": "1.1.6",
+    "@wildo-ai/presets-components-models": "1.1.6",
+    "@wildo-ai/zod-decorators": "1.1.6"
   },
   "peerDependencies": {
-    "big.js": "^6.2.2",
-    "date-fns": "^4.1.0",
-    "inversify": "^8.1.0",
-    "jsonwebtoken": "^9.0.2",
-    "lodash": "^4.17.23",
-    "mime": "^4.0.1",
-    "reflect-metadata": "^0.2.2",
-    "ufo": "^1.6.3",
-    "yaml": "^2.3.4",
     "zod": "^4.3.6"
   },
   "devDependencies": {

package/dist/esm/workbench/workbench-creation-board.custom.shared.schemas.d.ts

@@ -1,98 +0,0 @@
-/**
- * The application-creation board's identity, shared because THREE packages must agree on it.
- *
- * - the workbench declares the composite view under {@link WORKBENCH_CREATION_BOARD_VIEW_REF} and
- *   renders one `<Section>` per {@link WorkbenchCreationBoardSection};
- * - the companion authors the labels the view resolves, keyed by exactly those refs;
- * - and neither can see the other's source.
- *
- * Three string literals in three packages compile perfectly and fail at runtime as a blank sidebar
- * row and headless sections — `tCompositeView` and `tCompositeViewSection` answer the EMPTY STRING
- * for a missing key rather than echoing it, so nothing reports the drift. That is the same failure
- * the workbench's two resource launchers shipped with, and the same reason their vocabulary lives
- * here rather than on either side.
- *
- * This carries NO React and NO Node: it is a vocabulary, which is what makes it importable by a
- * browser bundle and by a daemon at once.
- */
-/**
- * The view's `ref` — the composite-view key, the launcher target, and the `/composite/<ref>` route.
- *
- * It MUST NOT contain a dot. The label lookup path is `composite_views.<translationRef>.<key>` and
- * BOTH readers — the backend's key filter and the frontend's `t` — split that whole path on `.` and
- * walk it segment by segment. A dotted ref therefore nests its labels one level deeper than anything
- * that reads them expects, and the failure is silent: `tCompositeView` answers the empty string.
- */
-export declare const WORKBENCH_CREATION_BOARD_VIEW_REF = "creation-board";
-/**
- * The label PATH the view's title and description hang off — `composite_views.<this>.title`.
- *
- * DERIVED by the engine's `buildApplicationViewTranslationRef` (`app.<ref>`), not chosen here. It is
- * restated because the companion cannot import a frontend package to compute it, and the workbench's
- * own test asserts this constant against the engine's derivation — so the copy cannot drift silently
- * from the function that actually produces it at runtime.
- *
- * A DOT PATH, not an object key. The label file nests `app` and then the ref; a single
- * `'app.creation-board'` property is unreachable from either reader. Measured 2026-08-31, after a
- * flat key made the board's title, its six section headings and its sidebar row all render empty with
- * nothing reporting it.
- */
-export declare const WORKBENCH_CREATION_BOARD_TRANSLATION_REF = "app.creation-board";
-/**
- * The board's sections, in the order they are read.
- *
- * The order is a decision, not a listing: a playbook run lands families, which make build-plan tasks
- * ready, which the coding lane executes, which the write register records. Reading them in that order
- * is reading the loop. The evidence section is LAST and always visible rather than behind a tab,
- * because it is the undo that sits in front of every dispatch button above it.
- *
- * The governance-facts section sits between the executions and the evidence: it is the point in the
- * loop where derivation stops and a person decides, and it belongs after everything a machine can do
- * for them rather than before it — a creator answering it first would be answering questions the
- * accepted specifications have not yet made concrete.
- */
-export declare enum WorkbenchCreationBoardSection {
-    /** Every compiled playbook and whether it can run right now, with the reasons it cannot. */
-    PLAYBOOKS = "playbooks",
-    /** What is running in the companion process, and what died leaving a resumable checkpoint. */
-    RUNS = "runs",
-    /** The next ready build-plan task and the exact paths it may and may not write. */
-    BUILD_PLAN = "build-plan",
-    /** Whether the coding agent is registered, and whether a run holds the workspace mutation lock. */
-    CODING_LANE = "coding-lane",
-    /** The actor and flow executions the control plane holds, and the tasks they created. */
-    EXECUTIONS = "executions",
-    /**
-     * The governed-document facts only a PERSON may establish — a creator decision or a qualified
-     * review — and the file their answers land in (#192).
-     *
-     * Its own section rather than a page of the playbook lane, because it is the one place on this
-     * board where a HUMAN is the authority. Everything above dispatches derivation; this collects
-     * decisions no derivation may make, and its answers land in `document-facts-authored`, a family no
-     * producer writes.
-     */
-    GOVERNANCE_FACTS = "governance-facts",
-    /** What each run wrote, with its revert, and the execution traces behind it. */
-    EVIDENCE = "evidence"
-}
-/**
- * The section refs in render order.
- *
- * `Object.values` on a string enum preserves declaration order, so this IS the enum rather than a
- * second list beside it — the shape that would let the two disagree.
- */
-export declare const WORKBENCH_CREATION_BOARD_SECTION_REFS: readonly WorkbenchCreationBoardSection[];
-/**
- * One authored title and description per section — the type the companion's label file satisfies.
- *
- * A `Record` keyed by the enum is what makes label coverage a COMPILE error rather than a test: add a
- * section and the label file stops compiling until it is described. A test could only report the gap
- * after someone ran it, and the gap's runtime symptom is a headless section nobody notices.
- */
-export type WorkbenchCreationBoardSectionLabels = {
-    readonly [section in WorkbenchCreationBoardSection]: {
-        readonly title: string;
-        readonly description: string;
-    };
-};
-//# sourceMappingURL=workbench-creation-board.custom.shared.schemas.d.ts.map

package/dist/esm/workbench/workbench-creation-board.custom.shared.schemas.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"workbench-creation-board.custom.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../src/workbench/workbench-creation-board.custom.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH;;;;;;;GAOG;AACH,eAAO,MAAM,iCAAiC,mBAAmB,CAAC;AAElE;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,wCAAwC,uBAA6C,CAAC;AAEnG;;;;;;;;;;;;GAYG;AACH,oBAAY,6BAA6B;IACvC,4FAA4F;IAC5F,SAAS,cAAc;IACvB,8FAA8F;IAC9F,IAAI,SAAS;IACb,mFAAmF;IACnF,UAAU,eAAe;IACzB,mGAAmG;IACnG,WAAW,gBAAgB;IAC3B,yFAAyF;IACzF,UAAU,eAAe;IACzB;;;;;;;;OAQG;IACH,gBAAgB,qBAAqB;IACrC,gFAAgF;IAChF,QAAQ,aAAa;CACtB;AAED;;;;;GAKG;AACH,eAAO,MAAM,qCAAqC,EAAE,SAAS,6BAA6B,EAC5C,CAAC;AAE/C;;;;;;GAMG;AACH,MAAM,MAAM,mCAAmC,GAAG;IAChD,QAAQ,EAAE,OAAO,IAAI,6BAA6B,GAAG;QACnD,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;QACvB,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;KAC9B;CACF,CAAC"}

package/dist/esm/workbench/workbench-creation-board.custom.shared.schemas.js

@@ -1,86 +0,0 @@
-/**
- * The application-creation board's identity, shared because THREE packages must agree on it.
- *
- * - the workbench declares the composite view under {@link WORKBENCH_CREATION_BOARD_VIEW_REF} and
- *   renders one `<Section>` per {@link WorkbenchCreationBoardSection};
- * - the companion authors the labels the view resolves, keyed by exactly those refs;
- * - and neither can see the other's source.
- *
- * Three string literals in three packages compile perfectly and fail at runtime as a blank sidebar
- * row and headless sections — `tCompositeView` and `tCompositeViewSection` answer the EMPTY STRING
- * for a missing key rather than echoing it, so nothing reports the drift. That is the same failure
- * the workbench's two resource launchers shipped with, and the same reason their vocabulary lives
- * here rather than on either side.
- *
- * This carries NO React and NO Node: it is a vocabulary, which is what makes it importable by a
- * browser bundle and by a daemon at once.
- */
-/**
- * The view's `ref` — the composite-view key, the launcher target, and the `/composite/<ref>` route.
- *
- * It MUST NOT contain a dot. The label lookup path is `composite_views.<translationRef>.<key>` and
- * BOTH readers — the backend's key filter and the frontend's `t` — split that whole path on `.` and
- * walk it segment by segment. A dotted ref therefore nests its labels one level deeper than anything
- * that reads them expects, and the failure is silent: `tCompositeView` answers the empty string.
- */
-export const WORKBENCH_CREATION_BOARD_VIEW_REF = 'creation-board';
-/**
- * The label PATH the view's title and description hang off — `composite_views.<this>.title`.
- *
- * DERIVED by the engine's `buildApplicationViewTranslationRef` (`app.<ref>`), not chosen here. It is
- * restated because the companion cannot import a frontend package to compute it, and the workbench's
- * own test asserts this constant against the engine's derivation — so the copy cannot drift silently
- * from the function that actually produces it at runtime.
- *
- * A DOT PATH, not an object key. The label file nests `app` and then the ref; a single
- * `'app.creation-board'` property is unreachable from either reader. Measured 2026-08-31, after a
- * flat key made the board's title, its six section headings and its sidebar row all render empty with
- * nothing reporting it.
- */
-export const WORKBENCH_CREATION_BOARD_TRANSLATION_REF = `app.${WORKBENCH_CREATION_BOARD_VIEW_REF}`;
-/**
- * The board's sections, in the order they are read.
- *
- * The order is a decision, not a listing: a playbook run lands families, which make build-plan tasks
- * ready, which the coding lane executes, which the write register records. Reading them in that order
- * is reading the loop. The evidence section is LAST and always visible rather than behind a tab,
- * because it is the undo that sits in front of every dispatch button above it.
- *
- * The governance-facts section sits between the executions and the evidence: it is the point in the
- * loop where derivation stops and a person decides, and it belongs after everything a machine can do
- * for them rather than before it — a creator answering it first would be answering questions the
- * accepted specifications have not yet made concrete.
- */
-export var WorkbenchCreationBoardSection;
-(function (WorkbenchCreationBoardSection) {
-    /** Every compiled playbook and whether it can run right now, with the reasons it cannot. */
-    WorkbenchCreationBoardSection["PLAYBOOKS"] = "playbooks";
-    /** What is running in the companion process, and what died leaving a resumable checkpoint. */
-    WorkbenchCreationBoardSection["RUNS"] = "runs";
-    /** The next ready build-plan task and the exact paths it may and may not write. */
-    WorkbenchCreationBoardSection["BUILD_PLAN"] = "build-plan";
-    /** Whether the coding agent is registered, and whether a run holds the workspace mutation lock. */
-    WorkbenchCreationBoardSection["CODING_LANE"] = "coding-lane";
-    /** The actor and flow executions the control plane holds, and the tasks they created. */
-    WorkbenchCreationBoardSection["EXECUTIONS"] = "executions";
-    /**
-     * The governed-document facts only a PERSON may establish — a creator decision or a qualified
-     * review — and the file their answers land in (#192).
-     *
-     * Its own section rather than a page of the playbook lane, because it is the one place on this
-     * board where a HUMAN is the authority. Everything above dispatches derivation; this collects
-     * decisions no derivation may make, and its answers land in `document-facts-authored`, a family no
-     * producer writes.
-     */
-    WorkbenchCreationBoardSection["GOVERNANCE_FACTS"] = "governance-facts";
-    /** What each run wrote, with its revert, and the execution traces behind it. */
-    WorkbenchCreationBoardSection["EVIDENCE"] = "evidence";
-})(WorkbenchCreationBoardSection || (WorkbenchCreationBoardSection = {}));
-/**
- * The section refs in render order.
- *
- * `Object.values` on a string enum preserves declaration order, so this IS the enum rather than a
- * second list beside it — the shape that would let the two disagree.
- */
-export const WORKBENCH_CREATION_BOARD_SECTION_REFS = Object.values(WorkbenchCreationBoardSection);
-//# sourceMappingURL=workbench-creation-board.custom.shared.schemas.js.map

package/dist/esm/workbench/workbench-creation-board.custom.shared.schemas.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"workbench-creation-board.custom.shared.schemas.js","sourceRoot":"","sources":["../../../../src/workbench/workbench-creation-board.custom.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,iCAAiC,GAAG,gBAAgB,CAAC;AAElE;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,MAAM,wCAAwC,GAAG,OAAO,iCAAiC,EAAE,CAAC;AAEnG;;;;;;;;;;;;GAYG;AACH,MAAM,CAAN,IAAY,6BAuBX;AAvBD,WAAY,6BAA6B;IACvC,4FAA4F;IAC5F,wDAAuB,CAAA;IACvB,8FAA8F;IAC9F,8CAAa,CAAA;IACb,mFAAmF;IACnF,0DAAyB,CAAA;IACzB,mGAAmG;IACnG,4DAA2B,CAAA;IAC3B,yFAAyF;IACzF,0DAAyB,CAAA;IACzB;;;;;;;;OAQG;IACH,sEAAqC,CAAA;IACrC,gFAAgF;IAChF,sDAAqB,CAAA;AACvB,CAAC,EAvBW,6BAA6B,KAA7B,6BAA6B,QAuBxC;AAED;;;;;GAKG;AACH,MAAM,CAAC,MAAM,qCAAqC,GAChD,MAAM,CAAC,MAAM,CAAC,6BAA6B,CAAC,CAAC","sourcesContent":["/**\n * The application-creation board's identity, shared because THREE packages must agree on it.\n *\n * - the workbench declares the composite view under {@link WORKBENCH_CREATION_BOARD_VIEW_REF} and\n *   renders one `<Section>` per {@link WorkbenchCreationBoardSection};\n * - the companion authors the labels the view resolves, keyed by exactly those refs;\n * - and neither can see the other's source.\n *\n * Three string literals in three packages compile perfectly and fail at runtime as a blank sidebar\n * row and headless sections — `tCompositeView` and `tCompositeViewSection` answer the EMPTY STRING\n * for a missing key rather than echoing it, so nothing reports the drift. That is the same failure\n * the workbench's two resource launchers shipped with, and the same reason their vocabulary lives\n * here rather than on either side.\n *\n * This carries NO React and NO Node: it is a vocabulary, which is what makes it importable by a\n * browser bundle and by a daemon at once.\n */\n\n/**\n * The view's `ref` — the composite-view key, the launcher target, and the `/composite/<ref>` route.\n *\n * It MUST NOT contain a dot. The label lookup path is `composite_views.<translationRef>.<key>` and\n * BOTH readers — the backend's key filter and the frontend's `t` — split that whole path on `.` and\n * walk it segment by segment. A dotted ref therefore nests its labels one level deeper than anything\n * that reads them expects, and the failure is silent: `tCompositeView` answers the empty string.\n */\nexport const WORKBENCH_CREATION_BOARD_VIEW_REF = 'creation-board';\n\n/**\n * The label PATH the view's title and description hang off — `composite_views.<this>.title`.\n *\n * DERIVED by the engine's `buildApplicationViewTranslationRef` (`app.<ref>`), not chosen here. It is\n * restated because the companion cannot import a frontend package to compute it, and the workbench's\n * own test asserts this constant against the engine's derivation — so the copy cannot drift silently\n * from the function that actually produces it at runtime.\n *\n * A DOT PATH, not an object key. The label file nests `app` and then the ref; a single\n * `'app.creation-board'` property is unreachable from either reader. Measured 2026-08-31, after a\n * flat key made the board's title, its six section headings and its sidebar row all render empty with\n * nothing reporting it.\n */\nexport const WORKBENCH_CREATION_BOARD_TRANSLATION_REF = `app.${WORKBENCH_CREATION_BOARD_VIEW_REF}`;\n\n/**\n * The board's sections, in the order they are read.\n *\n * The order is a decision, not a listing: a playbook run lands families, which make build-plan tasks\n * ready, which the coding lane executes, which the write register records. Reading them in that order\n * is reading the loop. The evidence section is LAST and always visible rather than behind a tab,\n * because it is the undo that sits in front of every dispatch button above it.\n *\n * The governance-facts section sits between the executions and the evidence: it is the point in the\n * loop where derivation stops and a person decides, and it belongs after everything a machine can do\n * for them rather than before it — a creator answering it first would be answering questions the\n * accepted specifications have not yet made concrete.\n */\nexport enum WorkbenchCreationBoardSection {\n  /** Every compiled playbook and whether it can run right now, with the reasons it cannot. */\n  PLAYBOOKS = 'playbooks',\n  /** What is running in the companion process, and what died leaving a resumable checkpoint. */\n  RUNS = 'runs',\n  /** The next ready build-plan task and the exact paths it may and may not write. */\n  BUILD_PLAN = 'build-plan',\n  /** Whether the coding agent is registered, and whether a run holds the workspace mutation lock. */\n  CODING_LANE = 'coding-lane',\n  /** The actor and flow executions the control plane holds, and the tasks they created. */\n  EXECUTIONS = 'executions',\n  /**\n   * The governed-document facts only a PERSON may establish — a creator decision or a qualified\n   * review — and the file their answers land in (#192).\n   *\n   * Its own section rather than a page of the playbook lane, because it is the one place on this\n   * board where a HUMAN is the authority. Everything above dispatches derivation; this collects\n   * decisions no derivation may make, and its answers land in `document-facts-authored`, a family no\n   * producer writes.\n   */\n  GOVERNANCE_FACTS = 'governance-facts',\n  /** What each run wrote, with its revert, and the execution traces behind it. */\n  EVIDENCE = 'evidence',\n}\n\n/**\n * The section refs in render order.\n *\n * `Object.values` on a string enum preserves declaration order, so this IS the enum rather than a\n * second list beside it — the shape that would let the two disagree.\n */\nexport const WORKBENCH_CREATION_BOARD_SECTION_REFS: readonly WorkbenchCreationBoardSection[] =\n  Object.values(WorkbenchCreationBoardSection);\n\n/**\n * One authored title and description per section — the type the companion's label file satisfies.\n *\n * A `Record` keyed by the enum is what makes label coverage a COMPILE error rather than a test: add a\n * section and the label file stops compiling until it is described. A test could only report the gap\n * after someone ran it, and the gap's runtime symptom is a headless section nobody notices.\n */\nexport type WorkbenchCreationBoardSectionLabels = {\n  readonly [section in WorkbenchCreationBoardSection]: {\n    readonly title: string;\n    readonly description: string;\n  };\n};\n"]}