@shardworks/astrolabe-apparatus 0.1.192 → 0.1.194

package/package.json

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

package/sage-analyst.md

@@ -95,9 +95,10 @@ 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` — pre-fill with your recommendation; the patron changes it only when overriding
 - `analysis` — classification metadata (see below)
 
+Do **not** write to `selected` — that field is owned by the patron-review pass. The analyst writes `recommendation`; the patron's choice populates `selected` (or `patronOverride` for custom write-ins) during decision review.
+
 Order decisions by scope item, then by category (product → api → implementation).
 
 Write all decisions using `decisions-write`.

package/sage-reading-analyst.md

@@ -33,7 +33,7 @@ You also have the standard file-reading tools (Read, Glob, Grep) for exploring t
 2. Read the codebase — but let your growing understanding of the change guide which files you read. You do not need to do a full repo walk followed by a separate analysis turn. As you read, you will naturally form scope boundaries, identify decision points, and notice observations. Let that understanding steer your exploration.
 3. Write the codebase inventory using `inventory-write`. The inventory must meet the full quality bar described below.
 4. Write scope items using `scope-write`. Break the brief into coarse, independently deliverable capabilities. Each item should be something the patron might include or exclude.
-5. Write decisions using `decisions-write`. Be exhaustive — capture every design question including ones where the answer seems obvious from codebase conventions. Each decision needs: id, scope references, question, context, options, recommendation, rationale, selected (pre-fill with recommendation), and analysis metadata (category, observable, confidence, stakes).
+5. Write decisions using `decisions-write`. Be exhaustive — capture every design question including ones where the answer seems obvious from codebase conventions. Each decision needs: id, scope references, question, context, options, recommendation, rationale, and analysis metadata (category, observable, confidence, stakes). Do **not** write to `selected` — that field is owned by the patron-review pass.
 6. Write observations using `observations-write`. Record refactoring opportunities, risks, suboptimal conventions, doc/code discrepancies, and potential bugs noticed during your pass.
 
 You may interleave reading and writing — for example, write partial inventory as you go and refine it, or write scope items as they become clear and adjust later. The key constraint is that when you finish, all four artifacts (inventory, scope, decisions, observations) must be complete and written to the plan via the write tools.
@@ -132,9 +132,10 @@ 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` — pre-fill with your recommendation; the patron changes it only when overriding
 - `analysis` — classification metadata (see below)
 
+Do **not** write to `selected` — that field is owned by the patron-review pass. The analyst writes `recommendation`; the patron's choice populates `selected` (or `patronOverride` for custom write-ins) during decision review.
+
 Order decisions by scope item, then by category (product → api → implementation).
 
 #### Decision Analysis Metadata

package/sage-writer.md

@@ -31,9 +31,8 @@ You also have the standard file-reading tools (Read, Glob, Grep) for exploring t
 
 **Authority hierarchy** — when inputs conflict, follow this precedence order:
 
-1. **Patron overrides** — decisions where `patronOverride` is set. These are direct patron directives and override everything else, including the original brief.
-2. **Selected decisions** — decisions where `selected` is set. These were reviewed and accepted by the patron.
-3. **Scope and inventory** — for context, structure, and gap detection.
+1. **Decisions** — each decision has **either** a `selected` field (the patron chose a listed option) **or** a `patronOverride` field (the patron wrote a custom directive), never both. A `patronOverride` is a direct patron directive and overrides everything else, including the original brief.
+2. **Scope and inventory** — for context, structure, and gap detection.
 
 ---
 
@@ -42,7 +41,7 @@ You also have the standard file-reading tools (Read, Glob, Grep) for exploring t
 From `plan-show`, examine:
 
 - **`scope`** — items with `included: true` are in scope; `included: false` are excluded. Only spec features that are included.
-- **`decisions`** — each decision has a `selected` field (the chosen option key) and/or a `patronOverride` field (freeform patron directive). These are **locked**. Use them exactly as written. Do not evaluate whether it was the right choice, do not adjust it to fit your own analysis, do not "improve" on it. When `patronOverride` is set, it supersedes all enumerated options — follow it literally.
+- **`decisions`** — each decision has **either** a `selected` field (the patron chose a listed option) **or** a `patronOverride` field (freeform patron directive), never both. These are **locked**. Use them exactly as written. Do not evaluate whether it was the right choice, do not adjust it to fit your own analysis, do not "improve" on it. A `patronOverride` is a direct patron directive — follow it literally.
 - **`inventory`** — the codebase inventory. Cross-reference for completeness.
 
 The **decision summary** in your prompt provides a quick-reference digest. When in doubt, the full decisions from `plan-show` are authoritative.
@@ -189,7 +188,7 @@ Re-read the plan's decisions (via `plan-show`) and verify the spec you just wrot
 For each decision in the plan:
 
 1. **Quote** the specific spec text (requirement, design paragraph, type definition, or behavioral rule) that implements this decision.
-2. **Verify** the spec text is consistent with the decision's `selected` value (or `patronOverride` if set). Pay special attention to patron overrides — these are direct patron directives and must not be contradicted.
+2. **Verify** the spec text is consistent with whichever field is present — `selected` or `patronOverride`. Patron overrides are direct patron directives and must not be contradicted.
 3. **Flag** any decision that is:
    - **Contradicted** — the spec says the opposite of the selected answer
    - **Unaddressed** — no spec text implements this decision