@shardworks/astrolabe-apparatus 0.1.212 → 0.1.214

package/README.md

@@ -159,7 +159,7 @@ The Astrolabe declares one book in Stacks:
 | `astrolabe.plan-init` | Creates a PlanDoc from the brief writ; validates codex presence |
 | `astrolabe.inventory-check` | Validates that the reader produced a non-empty inventory |
 | `astrolabe.decision-review` | Two-pass engine: blocks for patron review, then reconciles answers. Decisions with `selected` already pre-set by the analyst are auto-accepted — they are excluded from the InputRequestDoc, and if nothing remains reviewable the engine fast-paths to `writing` without opening the gate. |
-| `astrolabe.spec-publish` | Publishes the generated specification as a new writ |
+| `astrolabe.spec-publish` | Publishes the generated specification as a new writ. Posts the spec body verbatim — any `<task-manifest>` block is preserved and is not fanned out into child `piece` writs. |
 
 ### Rig Templates (contributed to Spider)
 

package/dist/engines/index.d.ts

@@ -1,5 +1,5 @@
 export { createPlanInitEngine } from './plan-init.ts';
 export { createInventoryCheckEngine } from './inventory-check.ts';
 export { createDecisionReviewEngine } from './decision-review.ts';
-export { createSpecPublishEngine, parseTaskManifest } from './spec-publish.ts';
+export { createSpecPublishEngine } from './spec-publish.ts';
 //# sourceMappingURL=index.d.ts.map

package/dist/engines/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/engines/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAC;AACtD,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,uBAAuB,EAAE,iBAAiB,EAAE,MAAM,mBAAmB,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/engines/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAC;AACtD,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,uBAAuB,EAAE,MAAM,mBAAmB,CAAC"}

package/dist/engines/index.js

@@ -1,5 +1,5 @@
 export { createPlanInitEngine } from "./plan-init.js";
 export { createInventoryCheckEngine } from "./inventory-check.js";
 export { createDecisionReviewEngine } from "./decision-review.js";
-export { createSpecPublishEngine, parseTaskManifest } from "./spec-publish.js";
+export { createSpecPublishEngine } from "./spec-publish.js";
 //# sourceMappingURL=index.js.map

package/dist/engines/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/engines/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAC;AACtD,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,uBAAuB,EAAE,iBAAiB,EAAE,MAAM,mBAAmB,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/engines/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAC;AACtD,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,0BAA0B,EAAE,MAAM,sBAAsB,CAAC;AAClE,OAAO,EAAE,uBAAuB,EAAE,MAAM,mBAAmB,CAAC"}

package/dist/engines/spec-publish.d.ts

@@ -5,11 +5,12 @@
  * the originating brief via a 'refines' link, records generatedWritId on
  * the PlanDoc, and transitions the plan to 'completed'.
  *
- * When the spec contains a `<task-manifest>`, the engine:
- *   1. Strips the manifest block from the spec (mandate body).
- *   2. Posts the mandate writ in draft state.
- *   3. Creates one child piece writ per `<task>` element.
- *   4. Transitions the mandate from draft to open (ready for dispatch).
+ * The engine always posts the full spec verbatim — including any
+ * `<task-manifest>` block the spec-writer produced. The planning pipeline
+ * does not fan the manifest out into child `piece` writs; the implementing
+ * artificer (or a downstream tool) is responsible for acting on the
+ * manifest if it chooses to. This keeps spec-publish a pure "publish what
+ * was written" step with no hidden surgery on the mandate body.
  *
  * Preconditions:
  *   - plan.status must be 'writing'
@@ -18,16 +19,5 @@
 import type { EngineDesign } from '@shardworks/fabricator-apparatus';
 import type { Book } from '@shardworks/stacks-apparatus';
 import type { PlanDoc } from '../types.ts';
-/**
- * Parse the `<task-manifest>` block from the spec string.
- * Returns the individual `<task ...>...</task>` fragments and the spec
- * with the manifest block removed.
- *
- * If no manifest is found, returns null.
- */
-export declare function parseTaskManifest(spec: string): {
-    tasks: string[];
-    strippedSpec: string;
-} | null;
 export declare function createSpecPublishEngine(getPlansBook: () => Book<PlanDoc>): EngineDesign;
 //# sourceMappingURL=spec-publish.d.ts.map

package/dist/engines/spec-publish.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"spec-publish.d.ts","sourceRoot":"","sources":["../../src/engines/spec-publish.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAGH,OAAO,KAAK,EAAE,YAAY,EAAqC,MAAM,kCAAkC,CAAC;AACxG,OAAO,KAAK,EAAE,IAAI,EAAE,MAAM,8BAA8B,CAAC;AAEzD,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,aAAa,CAAC;AAE3C;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,MAAM,GAAG;IAC/C,KAAK,EAAE,MAAM,EAAE,CAAC;IAChB,YAAY,EAAE,MAAM,CAAC;CACtB,GAAG,IAAI,CAsBP;AAED,wBAAgB,uBAAuB,CAAC,YAAY,EAAE,MAAM,IAAI,CAAC,OAAO,CAAC,GAAG,YAAY,CAmHvF"}
+{"version":3,"file":"spec-publish.d.ts","sourceRoot":"","sources":["../../src/engines/spec-publish.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAGH,OAAO,KAAK,EAAE,YAAY,EAAqC,MAAM,kCAAkC,CAAC;AACxG,OAAO,KAAK,EAAE,IAAI,EAAE,MAAM,8BAA8B,CAAC;AAEzD,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,aAAa,CAAC;AAE3C,wBAAgB,uBAAuB,CAAC,YAAY,EAAE,MAAM,IAAI,CAAC,OAAO,CAAC,GAAG,YAAY,CA+DvF"}

package/dist/engines/spec-publish.js

@@ -5,44 +5,18 @@
  * the originating brief via a 'refines' link, records generatedWritId on
  * the PlanDoc, and transitions the plan to 'completed'.
  *
- * When the spec contains a `<task-manifest>`, the engine:
- *   1. Strips the manifest block from the spec (mandate body).
- *   2. Posts the mandate writ in draft state.
- *   3. Creates one child piece writ per `<task>` element.
- *   4. Transitions the mandate from draft to open (ready for dispatch).
+ * The engine always posts the full spec verbatim — including any
+ * `<task-manifest>` block the spec-writer produced. The planning pipeline
+ * does not fan the manifest out into child `piece` writs; the implementing
+ * artificer (or a downstream tool) is responsible for acting on the
+ * manifest if it chooses to. This keeps spec-publish a pure "publish what
+ * was written" step with no hidden surgery on the mandate body.
  *
  * Preconditions:
  *   - plan.status must be 'writing'
  *   - plan.spec must be a non-empty string
  */
 import { guild } from '@shardworks/nexus-core';
-/**
- * Parse the `<task-manifest>` block from the spec string.
- * Returns the individual `<task ...>...</task>` fragments and the spec
- * with the manifest block removed.
- *
- * If no manifest is found, returns null.
- */
-export function parseTaskManifest(spec) {
-    // Match the full <task-manifest>...</task-manifest> block (greedy, single match)
-    const manifestMatch = spec.match(/<task-manifest>([\s\S]*?)<\/task-manifest>/);
-    if (!manifestMatch)
-        return null;
-    const manifestBlock = manifestMatch[0];
-    const manifestInner = manifestMatch[1];
-    // Extract individual <task ...>...</task> elements
-    const taskRegex = /<task\b[^>]*>[\s\S]*?<\/task>/g;
-    const tasks = [];
-    let match;
-    while ((match = taskRegex.exec(manifestInner)) !== null) {
-        tasks.push(match[0].trim());
-    }
-    if (tasks.length === 0)
-        return null;
-    // Strip the manifest block from the spec
-    const strippedSpec = spec.replace(manifestBlock, '').trim();
-    return { tasks, strippedSpec };
-}
 export function createSpecPublishEngine(getPlansBook) {
     return {
         id: 'astrolabe.spec-publish',
@@ -66,50 +40,7 @@ export function createSpecPublishEngine(getPlansBook) {
             const briefWrit = await clerk.show(planId);
             // Resolve generated writ type from config
             const generatedWritType = guild().guildConfig().astrolabe?.generatedWritType ?? 'mandate';
-            // Check for task manifest
-            const manifestResult = parseTaskManifest(plan.spec);
-            if (manifestResult) {
-                // ── Piece-aware path: manifest found ──
-                const { tasks, strippedSpec } = manifestResult;
-                // 1. Post mandate in draft state (pieces need parent to exist)
-                const generatedWrit = await clerk.post({
-                    type: generatedWritType,
-                    title: briefWrit.title,
-                    body: strippedSpec,
-                    codex: plan.codex,
-                    draft: true,
-                });
-                // 2. Create child piece writs (one per task, in manifest order)
-                for (const taskXml of tasks) {
-                    // Extract task id for a meaningful title
-                    const idMatch = taskXml.match(/<task\s+id="([^"]+)"/);
-                    const taskId = idMatch?.[1] ?? 'task';
-                    const nameMatch = taskXml.match(/<name>([\s\S]*?)<\/name>/);
-                    const taskName = nameMatch?.[1]?.trim() ?? taskId;
-                    await clerk.post({
-                        type: 'piece',
-                        title: taskName,
-                        body: taskXml,
-                        parentId: generatedWrit.id,
-                    });
-                }
-                // 3. Link: mandate (source) → brief (target), type 'refines'
-                await clerk.link(generatedWrit.id, planId, 'refines');
-                // 4. Transition mandate from draft to open (ready for dispatch)
-                await clerk.transition(generatedWrit.id, 'open');
-                // 5. Update PlanDoc
-                const now = new Date().toISOString();
-                await book.patch(planId, {
-                    generatedWritId: generatedWrit.id,
-                    status: 'completed',
-                    updatedAt: now,
-                });
-                return {
-                    status: 'completed',
-                    yields: { generatedWritId: generatedWrit.id },
-                };
-            }
-            // ── Legacy path: no manifest ──
+            // Post the mandate with the full spec verbatim (task-manifest included if present).
             const generatedWrit = await clerk.post({
                 type: generatedWritType,
                 title: briefWrit.title,

package/dist/engines/spec-publish.js.map

@@ -1 +1 @@
-{"version":3,"file":"spec-publish.js","sourceRoot":"","sources":["../../src/engines/spec-publish.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH,OAAO,EAAE,KAAK,EAAE,MAAM,wBAAwB,CAAC;AAM/C;;;;;;GAMG;AACH,MAAM,UAAU,iBAAiB,CAAC,IAAY;IAI5C,iFAAiF;IACjF,MAAM,aAAa,GAAG,IAAI,CAAC,KAAK,CAAC,4CAA4C,CAAC,CAAC;IAC/E,IAAI,CAAC,aAAa;QAAE,OAAO,IAAI,CAAC;IAEhC,MAAM,aAAa,GAAG,aAAa,CAAC,CAAC,CAAC,CAAC;IACvC,MAAM,aAAa,GAAG,aAAa,CAAC,CAAC,CAAE,CAAC;IAExC,mDAAmD;IACnD,MAAM,SAAS,GAAG,gCAAgC,CAAC;IACnD,MAAM,KAAK,GAAa,EAAE,CAAC;IAC3B,IAAI,KAA6B,CAAC;IAClC,OAAO,CAAC,KAAK,GAAG,SAAS,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC,KAAK,IAAI,EAAE,CAAC;QACxD,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC;IAC9B,CAAC;IAED,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO,IAAI,CAAC;IAEpC,yCAAyC;IACzC,MAAM,YAAY,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,EAAE,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;IAE5D,OAAO,EAAE,KAAK,EAAE,YAAY,EAAE,CAAC;AACjC,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,YAAiC;IACvE,OAAO;QACL,EAAE,EAAE,wBAAwB;QAE5B,KAAK,CAAC,GAAG,CACP,MAA+B,EAC/B,QAA0B;YAE1B,MAAM,MAAM,GAAG,MAAM,CAAC,MAAgB,CAAC;YACvC,MAAM,IAAI,GAAG,YAAY,EAAE,CAAC;YAE5B,MAAM,IAAI,GAAG,MAAM,IAAI,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC;YACpC,IAAI,CAAC,IAAI,EAAE,CAAC;gBACV,MAAM,IAAI,KAAK,CAAC,SAAS,MAAM,cAAc,CAAC,CAAC;YACjD,CAAC;YAED,kBAAkB;YAClB,IAAI,IAAI,CAAC,MAAM,KAAK,SAAS,EAAE,CAAC;gBAC9B,MAAM,IAAI,KAAK,CACb,yDAAyD,IAAI,CAAC,MAAM,eAAe,MAAM,IAAI,CAC9F,CAAC;YACJ,CAAC;YAED,uBAAuB;YACvB,IAAI,OAAO,IAAI,CAAC,IAAI,KAAK,QAAQ,IAAI,IAAI,CAAC,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;gBAC5D,MAAM,IAAI,KAAK,CACb,SAAS,MAAM,2DAA2D,CAC3E,CAAC;YACJ,CAAC;YAED,MAAM,KAAK,GAAG,KAAK,EAAE,CAAC,SAAS,CAAW,OAAO,CAAC,CAAC;YAEnD,oCAAoC;YACpC,MAAM,SAAS,GAAG,MAAM,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;YAE3C,0CAA0C;YAC1C,MAAM,iBAAiB,GAAG,KAAK,EAAE,CAAC,WAAW,EAAE,CAAC,SAAS,EAAE,iBAAiB,IAAI,SAAS,CAAC;YAE1F,0BAA0B;YAC1B,MAAM,cAAc,GAAG,iBAAiB,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAEpD,IAAI,cAAc,EAAE,CAAC;gBACnB,yCAAyC;gBACzC,MAAM,EAAE,KAAK,EAAE,YAAY,EAAE,GAAG,cAAc,CAAC;gBAE/C,+DAA+D;gBAC/D,MAAM,aAAa,GAAG,MAAM,KAAK,CAAC,IAAI,CAAC;oBACrC,IAAI,EAAE,iBAAiB;oBACvB,KAAK,EAAE,SAAS,CAAC,KAAK;oBACtB,IAAI,EAAE,YAAY;oBAClB,KAAK,EAAE,IAAI,CAAC,KAAK;oBACjB,KAAK,EAAE,IAAI;iBACZ,CAAC,CAAC;gBAEH,gEAAgE;gBAChE,KAAK,MAAM,OAAO,IAAI,KAAK,EAAE,CAAC;oBAC5B,yCAAyC;oBACzC,MAAM,OAAO,GAAG,OAAO,CAAC,KAAK,CAAC,sBAAsB,CAAC,CAAC;oBACtD,MAAM,MAAM,GAAG,OAAO,EAAE,CAAC,CAAC,CAAC,IAAI,MAAM,CAAC;oBACtC,MAAM,SAAS,GAAG,OAAO,CAAC,KAAK,CAAC,0BAA0B,CAAC,CAAC;oBAC5D,MAAM,QAAQ,GAAG,SAAS,EAAE,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,IAAI,MAAM,CAAC;oBAElD,MAAM,KAAK,CAAC,IAAI,CAAC;wBACf,IAAI,EAAE,OAAO;wBACb,KAAK,EAAE,QAAQ;wBACf,IAAI,EAAE,OAAO;wBACb,QAAQ,EAAE,aAAa,CAAC,EAAE;qBAC3B,CAAC,CAAC;gBACL,CAAC;gBAED,6DAA6D;gBAC7D,MAAM,KAAK,CAAC,IAAI,CAAC,aAAa,CAAC,EAAE,EAAE,MAAM,EAAE,SAAS,CAAC,CAAC;gBAEtD,gEAAgE;gBAChE,MAAM,KAAK,CAAC,UAAU,CAAC,aAAa,CAAC,EAAE,EAAE,MAAM,CAAC,CAAC;gBAEjD,oBAAoB;gBACpB,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;gBACrC,MAAM,IAAI,CAAC,KAAK,CAAC,MAAM,EAAE;oBACvB,eAAe,EAAE,aAAa,CAAC,EAAE;oBACjC,MAAM,EAAE,WAAW;oBACnB,SAAS,EAAE,GAAG;iBACf,CAAC,CAAC;gBAEH,OAAO;oBACL,MAAM,EAAE,WAAW;oBACnB,MAAM,EAAE,EAAE,eAAe,EAAE,aAAa,CAAC,EAAE,EAAE;iBAC9C,CAAC;YACJ,CAAC;YAED,iCAAiC;YACjC,MAAM,aAAa,GAAG,MAAM,KAAK,CAAC,IAAI,CAAC;gBACrC,IAAI,EAAE,iBAAiB;gBACvB,KAAK,EAAE,SAAS,CAAC,KAAK;gBACtB,IAAI,EAAE,IAAI,CAAC,IAAI;gBACf,KAAK,EAAE,IAAI,CAAC,KAAK;aAClB,CAAC,CAAC;YAEH,0DAA0D;YAC1D,MAAM,KAAK,CAAC,IAAI,CAAC,aAAa,CAAC,EAAE,EAAE,MAAM,EAAE,SAAS,CAAC,CAAC;YAEtD,iBAAiB;YACjB,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;YACrC,MAAM,IAAI,CAAC,KAAK,CAAC,MAAM,EAAE;gBACvB,eAAe,EAAE,aAAa,CAAC,EAAE;gBACjC,MAAM,EAAE,WAAW;gBACnB,SAAS,EAAE,GAAG;aACf,CAAC,CAAC;YAEH,OAAO;gBACL,MAAM,EAAE,WAAW;gBACnB,MAAM,EAAE,EAAE,eAAe,EAAE,aAAa,CAAC,EAAE,EAAE;aAC9C,CAAC;QACJ,CAAC;KACF,CAAC;AACJ,CAAC"}
+{"version":3,"file":"spec-publish.js","sourceRoot":"","sources":["../../src/engines/spec-publish.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,EAAE,KAAK,EAAE,MAAM,wBAAwB,CAAC;AAM/C,MAAM,UAAU,uBAAuB,CAAC,YAAiC;IACvE,OAAO;QACL,EAAE,EAAE,wBAAwB;QAE5B,KAAK,CAAC,GAAG,CACP,MAA+B,EAC/B,QAA0B;YAE1B,MAAM,MAAM,GAAG,MAAM,CAAC,MAAgB,CAAC;YACvC,MAAM,IAAI,GAAG,YAAY,EAAE,CAAC;YAE5B,MAAM,IAAI,GAAG,MAAM,IAAI,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC;YACpC,IAAI,CAAC,IAAI,EAAE,CAAC;gBACV,MAAM,IAAI,KAAK,CAAC,SAAS,MAAM,cAAc,CAAC,CAAC;YACjD,CAAC;YAED,kBAAkB;YAClB,IAAI,IAAI,CAAC,MAAM,KAAK,SAAS,EAAE,CAAC;gBAC9B,MAAM,IAAI,KAAK,CACb,yDAAyD,IAAI,CAAC,MAAM,eAAe,MAAM,IAAI,CAC9F,CAAC;YACJ,CAAC;YAED,uBAAuB;YACvB,IAAI,OAAO,IAAI,CAAC,IAAI,KAAK,QAAQ,IAAI,IAAI,CAAC,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;gBAC5D,MAAM,IAAI,KAAK,CACb,SAAS,MAAM,2DAA2D,CAC3E,CAAC;YACJ,CAAC;YAED,MAAM,KAAK,GAAG,KAAK,EAAE,CAAC,SAAS,CAAW,OAAO,CAAC,CAAC;YAEnD,oCAAoC;YACpC,MAAM,SAAS,GAAG,MAAM,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;YAE3C,0CAA0C;YAC1C,MAAM,iBAAiB,GAAG,KAAK,EAAE,CAAC,WAAW,EAAE,CAAC,SAAS,EAAE,iBAAiB,IAAI,SAAS,CAAC;YAE1F,oFAAoF;YACpF,MAAM,aAAa,GAAG,MAAM,KAAK,CAAC,IAAI,CAAC;gBACrC,IAAI,EAAE,iBAAiB;gBACvB,KAAK,EAAE,SAAS,CAAC,KAAK;gBACtB,IAAI,EAAE,IAAI,CAAC,IAAI;gBACf,KAAK,EAAE,IAAI,CAAC,KAAK;aAClB,CAAC,CAAC;YAEH,0DAA0D;YAC1D,MAAM,KAAK,CAAC,IAAI,CAAC,aAAa,CAAC,EAAE,EAAE,MAAM,EAAE,SAAS,CAAC,CAAC;YAEtD,iBAAiB;YACjB,MAAM,GAAG,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;YACrC,MAAM,IAAI,CAAC,KAAK,CAAC,MAAM,EAAE;gBACvB,eAAe,EAAE,aAAa,CAAC,EAAE;gBACjC,MAAM,EAAE,WAAW;gBACnB,SAAS,EAAE,GAAG;aACf,CAAC,CAAC;YAEH,OAAO;gBACL,MAAM,EAAE,WAAW;gBACnB,MAAM,EAAE,EAAE,eAAe,EAAE,aAAa,CAAC,EAAE,EAAE;aAC9C,CAAC;QACJ,CAAC;KACF,CAAC;AACJ,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shardworks/astrolabe-apparatus",
-  "version": "0.1.212",
+  "version": "0.1.214",
   "license": "ISC",
   "repository": {
     "type": "git",
@@ -20,16 +20,16 @@
   },
   "dependencies": {
     "zod": "4.3.6",
-    "@shardworks/stacks-apparatus": "0.1.212",
-    "@shardworks/tools-apparatus": "0.1.212",
-    "@shardworks/clerk-apparatus": "0.1.212",
-    "@shardworks/fabricator-apparatus": "0.1.212",
-    "@shardworks/loom-apparatus": "0.1.212",
-    "@shardworks/spider-apparatus": "0.1.212"
+    "@shardworks/stacks-apparatus": "0.1.214",
+    "@shardworks/clerk-apparatus": "0.1.214",
+    "@shardworks/tools-apparatus": "0.1.214",
+    "@shardworks/spider-apparatus": "0.1.214",
+    "@shardworks/fabricator-apparatus": "0.1.214",
+    "@shardworks/loom-apparatus": "0.1.214"
   },
   "devDependencies": {
     "@types/node": "25.5.0",
-    "@shardworks/nexus-core": "0.1.212"
+    "@shardworks/nexus-core": "0.1.214"
   },
   "files": [
     "dist",

package/sage-analyst.md

@@ -80,8 +80,9 @@ Not every brief produces decisions. If the existing codebase patterns truly dict
    - What's the simplest version of this that a new operator would use on day one? Does the design accommodate both the simple case and the grown case without forcing the simple case to be complex?
 
 5. **Classify the decision** (see Decision Analysis Metadata below).
-6. **Apply the razor.** Check the decision against the five razor criteria in *The Razor* below. If it matches one, leave `selected` unset so the decision surfaces to the patron. If it does not match, apply the three defaults — **investigate, don't punt:** uncertainty about a non-razor decision is a cue to read more code or re-read the brief, not a cue to hand the decision to the patron.
-7. **Recommend.** Pick the best option. State why in one line. For non-razor decisions, pre-fill `selected` with your choice.
+6. **Pre-emption check — brief first.** Before applying the razor, check whether the brief (or an architecture spec it references) explicitly answers the question. If so, record the answer as both `recommendation` and `selected`, and cite the source in `rationale`. The patron has already decided; skip the razor.
+7. **Apply the razor.** For any decision the brief did not pre-empt, check it against the five razor criteria in *The Razor* below. If it matches, leave `selected` unset so the decision surfaces to the patron. If it does not match, apply the three defaults — **investigate, don't punt:** uncertainty about a non-razor decision is a cue to read more code or re-read the brief, not a cue to hand the decision to the patron.
+8. **Recommend.** Pick the best option. State why in one line. For auto-decided decisions, pre-fill `selected` with your choice.
 
 **How to form recommendations:**
 
@@ -92,23 +93,25 @@ Not every brief produces decisions. If the existing codebase patterns truly dict
 
 Not every decision warrants the patron's time. Over the last 38 specs the patron overrode only 3.7% of decisions — the rest were rubber-stamps. Most decisions can be settled by the analyst with a recorded recommendation, and only a narrow class should actually block on patron review.
 
-**Surface a decision to the patron (leave `selected` unset) if it matches any of these five criteria:**
+**Pre-emption: the brief has the last word.** Before applying the razor, check whether the brief (or an architecture spec it references) explicitly answers the question — by prescribing a value, a behavior, or a pattern to follow. If so, pre-fill `selected` with that answer and cite the source in `rationale`, regardless of whether the question would otherwise match a razor criterion. The patron has already decided by writing the brief; re-surfacing a settled question drains attention from the decisions that are genuinely open.
 
-1. **Divergence from convention.** The recommendation departs from an established codebase pattern. *Example:* "This package stores config in `guild.json`, but for this feature we would want a dedicated `foo.config.ts` — should we?"
-2. **High consumer stakes.** A consumer of the API, feature, or workflow would materially notice the difference — ergonomics, runtime behavior, error semantics, performance. *Example:* "Should `post()` return the full writ or only the id?"
-3. **Observable product surface.** An operator or end user would notice the choice in naming, UX, or behavior. *Example:* "Should the new page be titled `Reviews` or `Review History`?"
-4. **Irreversibility.** The choice is hard to undo without a migration, a deprecation cycle, or breaking downstream consumers. *Example:* "Should the new field be stored as an index column or only in the document body?"
-5. **Genuine ambiguity.** The codebase and the brief give no clear signal and two or more options are equally valid; no amount of further investigation would break the tie. *Example:* "Should we name this `digest` or `summary`? Both terms appear in the codebase with comparable frequency."
+**Otherwise, surface the decision to the patron (leave `selected` unset) if — and only if — it falls into one of these five categories:**
 
-**Investigate, don't punt.** When you feel uncertainty about a decision that does *not* match one of these five criteria, that uncertainty is a signal to read more code, trace another caller, or re-read the brief — not a signal to surface the decision to the patron. Punting a non-razor decision drains patron attention from the decisions that actually need it.
+1. **Vocabulary/pattern establishment.** New guild terms, categorical distinctions, or patterns other code will follow. *Example:* "Should we call the new state 'parked' or 'deferred'?"
+2. **Human-facing surface.** CLI text, error messages, agent personalities, doc phrasing, or UX details a patron or operator will read. *Example:* "Should the error read 'Writ not found' or 'No writ with id X'?"
+3. **Scope boundary.** Cutlines between the current commission and follow-up work — the 'should we also do X?' questions. *Example:* "Should this change also update the two-phase-planning rig, or is that a separate commission?"
+4. **Shape of persisted or inter-component data.** Typed vs opaque, required vs optional, configured vs convention — when other components will consume the shape. *Example:* "Should `Decision.scope` be `string[]` or a typed `ScopeRef[]`?"
+5. **Component responsibility boundaries.** Who owns a behavior across engines, tools, and apparatuses — when the decision sets a pattern for ownership. *Example:* "Should the sage write decisions through a tool, or through direct book access?"
+
+**Investigate, don't punt.** When you feel uncertainty about a decision that does *not* match one of these five categories, that uncertainty is a signal to read more code, trace another caller, or re-read the brief — not a signal to surface the decision to the patron. Punting a non-razor decision drains patron attention from the decisions that actually need it.
 
 #### The Three Defaults
 
-For any decision that does **not** match the razor, apply these defaults in order and pre-fill `selected` with the answer they produce:
+For any decision that was not pre-empted by the brief and does **not** match the razor, apply these defaults and pre-fill `selected` with the answer they produce:
 
-1. **Match the codebase.** If the existing code already handles an analogous situation, follow the established pattern. The patron is most likely to accept choices that follow suit.
-2. **Match the brief.** If the codebase is silent, use the brief's terminology, naming, and framing verbatim. The brief reflects what the patron has already chosen to say out loud.
-3. **Pick the simplest viable option.** If neither the codebase nor the brief breaks the tie, pick the option that keeps the day-one shape simple and does not foreclose the grown-case. Record the rationale.
+1. **Prefer removal to deprecation.** When refactoring, rip out the old path. No deprecation windows unless the patron explicitly asks for one.
+2. **Prefer fail-loud to silent fallback.** Throw on missing input; no defaults-when-absent unless the absent case is itself a legitimate state.
+3. **Extend the API at the right layer; don't route around it.** If the recommendation involves a workaround or "the anima handles it via prompt," default to adding the method/tool instead.
 
 Each decision needs:
 - `id` — sequential identifier (D1, D2, ...)
@@ -118,7 +121,7 @@ Each decision needs:
 - `options` — key → description map of reasonable approaches (keep descriptions to one line each)
 - `recommendation` — the option key you recommend
 - `rationale` — why this option, in one line
-- `selected` — **If the decision matches any of the five razor criteria, leave `selected` unset.** Otherwise, apply the three defaults, pick the answer, and pre-fill `selected` with your choice. Pre-filled decisions are auto-accepted — the engine drops them from the patron-review gate entirely, so the patron only sees decisions that genuinely warrant their attention. The patron changes `selected` only when overriding a surfaced decision, and if they write a custom override the reconcile loop replaces `selected` with `patronOverride` automatically. Never set both yourself.
+- `selected` — **If the brief pre-empts the decision, set `selected` to the brief's answer.** Otherwise, if the decision matches any of the five razor criteria, leave `selected` unset. Otherwise, apply the three defaults and pre-fill `selected` with your choice. Pre-filled decisions are auto-accepted — the engine drops them from the patron-review gate entirely, so the patron only sees decisions that genuinely warrant their attention. The patron changes `selected` only when overriding a surfaced decision, and if they write a custom override the reconcile loop replaces `selected` with `patronOverride` automatically. Never set both yourself.
 - `analysis` — classification metadata (see below)
 
 Order decisions by scope item, then by category (product → api → implementation).

package/sage-reading-analyst.md

@@ -115,8 +115,9 @@ Not every brief produces decisions. If the existing codebase patterns truly dict
    - What's the simplest version of this that a new operator would use on day one? Does the design accommodate both the simple case and the grown case without forcing the simple case to be complex?
 
 5. **Classify the decision** (see Decision Analysis Metadata below).
-6. **Apply the razor.** Check the decision against the five razor criteria in *The Razor* below. If it matches one, leave `selected` unset so the decision surfaces to the patron. If it does not match, apply the three defaults — **investigate, don't punt:** uncertainty about a non-razor decision is a cue to read more code or re-read the brief, not a cue to hand the decision to the patron.
-7. **Recommend.** Pick the best option. State why in one line. For non-razor decisions, pre-fill `selected` with your choice.
+6. **Pre-emption check — brief first.** Before applying the razor, check whether the brief (or an architecture spec it references) explicitly answers the question. If so, record the answer as both `recommendation` and `selected`, and cite the source in `rationale`. The patron has already decided; skip the razor.
+7. **Apply the razor.** For any decision the brief did not pre-empt, check it against the five razor criteria in *The Razor* below. If it matches, leave `selected` unset so the decision surfaces to the patron. If it does not match, apply the three defaults — **investigate, don't punt:** uncertainty about a non-razor decision is a cue to read more code or re-read the brief, not a cue to hand the decision to the patron.
+8. **Recommend.** Pick the best option. State why in one line. For auto-decided decisions, pre-fill `selected` with your choice.
 
 **How to form recommendations:**
 
@@ -127,23 +128,25 @@ Not every brief produces decisions. If the existing codebase patterns truly dict
 
 Not every decision warrants the patron's time. Over the last 38 specs the patron overrode only 3.7% of decisions — the rest were rubber-stamps. Most decisions can be settled by the analyst with a recorded recommendation, and only a narrow class should actually block on patron review.
 
-**Surface a decision to the patron (leave `selected` unset) if it matches any of these five criteria:**
+**Pre-emption: the brief has the last word.** Before applying the razor, check whether the brief (or an architecture spec it references) explicitly answers the question — by prescribing a value, a behavior, or a pattern to follow. If so, pre-fill `selected` with that answer and cite the source in `rationale`, regardless of whether the question would otherwise match a razor criterion. The patron has already decided by writing the brief; re-surfacing a settled question drains attention from the decisions that are genuinely open.
 
-1. **Divergence from convention.** The recommendation departs from an established codebase pattern. *Example:* "This package stores config in `guild.json`, but for this feature we would want a dedicated `foo.config.ts` — should we?"
-2. **High consumer stakes.** A consumer of the API, feature, or workflow would materially notice the difference — ergonomics, runtime behavior, error semantics, performance. *Example:* "Should `post()` return the full writ or only the id?"
-3. **Observable product surface.** An operator or end user would notice the choice in naming, UX, or behavior. *Example:* "Should the new page be titled `Reviews` or `Review History`?"
-4. **Irreversibility.** The choice is hard to undo without a migration, a deprecation cycle, or breaking downstream consumers. *Example:* "Should the new field be stored as an index column or only in the document body?"
-5. **Genuine ambiguity.** The codebase and the brief give no clear signal and two or more options are equally valid; no amount of further investigation would break the tie. *Example:* "Should we name this `digest` or `summary`? Both terms appear in the codebase with comparable frequency."
+**Otherwise, surface the decision to the patron (leave `selected` unset) if — and only if — it falls into one of these five categories:**
 
-**Investigate, don't punt.** When you feel uncertainty about a decision that does *not* match one of these five criteria, that uncertainty is a signal to read more code, trace another caller, or re-read the brief — not a signal to surface the decision to the patron. Punting a non-razor decision drains patron attention from the decisions that actually need it.
+1. **Vocabulary/pattern establishment.** New guild terms, categorical distinctions, or patterns other code will follow. *Example:* "Should we call the new state 'parked' or 'deferred'?"
+2. **Human-facing surface.** CLI text, error messages, agent personalities, doc phrasing, or UX details a patron or operator will read. *Example:* "Should the error read 'Writ not found' or 'No writ with id X'?"
+3. **Scope boundary.** Cutlines between the current commission and follow-up work — the 'should we also do X?' questions. *Example:* "Should this change also update the two-phase-planning rig, or is that a separate commission?"
+4. **Shape of persisted or inter-component data.** Typed vs opaque, required vs optional, configured vs convention — when other components will consume the shape. *Example:* "Should `Decision.scope` be `string[]` or a typed `ScopeRef[]`?"
+5. **Component responsibility boundaries.** Who owns a behavior across engines, tools, and apparatuses — when the decision sets a pattern for ownership. *Example:* "Should the sage write decisions through a tool, or through direct book access?"
+
+**Investigate, don't punt.** When you feel uncertainty about a decision that does *not* match one of these five categories, that uncertainty is a signal to read more code, trace another caller, or re-read the brief — not a signal to surface the decision to the patron. Punting a non-razor decision drains patron attention from the decisions that actually need it.
 
 #### The Three Defaults
 
-For any decision that does **not** match the razor, apply these defaults in order and pre-fill `selected` with the answer they produce:
+For any decision that was not pre-empted by the brief and does **not** match the razor, apply these defaults and pre-fill `selected` with the answer they produce:
 
-1. **Match the codebase.** If the existing code already handles an analogous situation, follow the established pattern. The patron is most likely to accept choices that follow suit.
-2. **Match the brief.** If the codebase is silent, use the brief's terminology, naming, and framing verbatim. The brief reflects what the patron has already chosen to say out loud.
-3. **Pick the simplest viable option.** If neither the codebase nor the brief breaks the tie, pick the option that keeps the day-one shape simple and does not foreclose the grown-case. Record the rationale.
+1. **Prefer removal to deprecation.** When refactoring, rip out the old path. No deprecation windows unless the patron explicitly asks for one.
+2. **Prefer fail-loud to silent fallback.** Throw on missing input; no defaults-when-absent unless the absent case is itself a legitimate state.
+3. **Extend the API at the right layer; don't route around it.** If the recommendation involves a workaround or "the anima handles it via prompt," default to adding the method/tool instead.
 
 Each decision needs:
 - `id` — sequential identifier (D1, D2, ...)
@@ -153,7 +156,7 @@ Each decision needs:
 - `options` — key → description map of reasonable approaches (keep descriptions to one line each)
 - `recommendation` — the option key you recommend
 - `rationale` — why this option, in one line
-- `selected` — **If the decision matches any of the five razor criteria, leave `selected` unset.** Otherwise, apply the three defaults, pick the answer, and pre-fill `selected` with your choice. Pre-filled decisions are auto-accepted — the engine drops them from the patron-review gate entirely, so the patron only sees decisions that genuinely warrant their attention. The patron changes `selected` only when overriding a surfaced decision, and if they write a custom override the reconcile loop replaces `selected` with `patronOverride` automatically. Never set both yourself.
+- `selected` — **If the brief pre-empts the decision, set `selected` to the brief's answer.** Otherwise, if the decision matches any of the five razor criteria, leave `selected` unset. Otherwise, apply the three defaults and pre-fill `selected` with your choice. Pre-filled decisions are auto-accepted — the engine drops them from the patron-review gate entirely, so the patron only sees decisions that genuinely warrant their attention. The patron changes `selected` only when overriding a surfaced decision, and if they write a custom override the reconcile loop replaces `selected` with `patronOverride` automatically. Never set both yourself.
 - `analysis` — classification metadata (see below)
 
 Order decisions by scope item, then by category (product → api → implementation).