@yagni-app/code-staging 1.1.4-staging.1424.1 → 1.1.4-staging.1425.1

package/dist/extension/decisionRubric.d.ts

@@ -19,7 +19,12 @@ export declare const RECORD_NEVER: string;
  * How the decision text itself must read. The ledger shows the decision as
  * the headline and the question beneath it, so an answer-shaped decision
  * ("No. Surface the decline.") reads as a fragment on every surface that
- * renders it.
+ * renders it, and a decision that carries its own reasoning reads as a
+ * paragraph in headline type. The ruling is the decision; the constraints,
+ * specifics, and reasoning belong in the rationale, where retrieval indexes
+ * them just the same (the embedding document is question + decision +
+ * rationale) and contested detection, which compares decision against
+ * decision, is not muddied by shared context words.
  */
 export declare const DECISION_STATEMENT: string;
 /**
@@ -27,5 +32,5 @@ export declare const DECISION_STATEMENT: string;
  * never, and how the decision text must read, so every surface that records
  * a decision produces one the headline-first ledger can render whole.
  */
-export declare const RECORD_DECISION_RUBRIC = "Record a decision only when it is consequential: a product-intent, architecture, or team-convention call that another engineer would need to know and that is not already written down, especially one a human just settled by answering a question or correcting you. Never record taste, styling, naming of a local variable, formatting, a workaround, a restatement of the code change, or anything the user is still experimenting with; when in doubt, do not record it. Write the decision as a standalone statement that reads without the question: name the subject and what was chosen (\"Checkout surfaces a declined card to the customer instead of retrying it\"), never a bare yes or no or an answer that only makes sense under the question.";
+export declare const RECORD_DECISION_RUBRIC = "Record a decision only when it is consequential: a product-intent, architecture, or team-convention call that another engineer would need to know and that is not already written down, especially one a human just settled by answering a question or correcting you. Never record taste, styling, naming of a local variable, formatting, a workaround, a restatement of the code change, or anything the user is still experimenting with; when in doubt, do not record it. Write the decision as a standalone statement that reads without the question: name the subject and what was chosen (\"Checkout surfaces a declined card to the customer instead of retrying it\"), never a bare yes or no or an answer that only makes sense under the question. Keep the decision to the ruling itself, one or two sentences; put the constraints, specifics, and reasoning behind it in the rationale, not the decision.";
 //# sourceMappingURL=decisionRubric.d.ts.map

package/dist/extension/decisionRubric.js

@@ -25,12 +25,18 @@ export const RECORD_NEVER = "Never record taste, styling, naming of a local vari
  * How the decision text itself must read. The ledger shows the decision as
  * the headline and the question beneath it, so an answer-shaped decision
  * ("No. Surface the decline.") reads as a fragment on every surface that
- * renders it.
+ * renders it, and a decision that carries its own reasoning reads as a
+ * paragraph in headline type. The ruling is the decision; the constraints,
+ * specifics, and reasoning belong in the rationale, where retrieval indexes
+ * them just the same (the embedding document is question + decision +
+ * rationale) and contested detection, which compares decision against
+ * decision, is not muddied by shared context words.
  */
 export const DECISION_STATEMENT = "Write the decision as a standalone statement that reads without the question: name " +
     "the subject and what was chosen (\"Checkout surfaces a declined card to the customer " +
     "instead of retrying it\"), never a bare yes or no or an answer that only makes sense " +
-    "under the question.";
+    "under the question. Keep the decision to the ruling itself, one or two sentences; put " +
+    "the constraints, specifics, and reasoning behind it in the rationale, not the decision.";
 /**
  * The rubric as one paragraph for persona bodies and task templates: when,
  * never, and how the decision text must read, so every surface that records

package/dist/extension/recordDecisionTool.js

@@ -33,7 +33,11 @@ const parameters = Type.Object({
     question: Type.String({ description: "The question that was decided, as another engineer would ask it." }),
     decision: Type.String({ description: `The direction taken. ${DECISION_STATEMENT}` }),
     kind: Type.Union([Type.Literal("product"), Type.Literal("architecture"), Type.Literal("convention")], { description: `What sort of call this is: ${DECISION_KIND_DESCRIPTION}.` }),
-    rationale: Type.String({ description: "Why: the durable reasoning a teammate would want six months later." }),
+    rationale: Type.String({
+        description: "Why: the durable reasoning a teammate would want six months later, plus the constraints and " +
+            "specifics that do not fit the one- or two-sentence decision. This is indexed for retrieval " +
+            "alongside the decision, so nothing is lost by putting detail here.",
+    }),
     repo: Type.Optional(Type.String()),
     workItemId: Type.Optional(Type.String()),
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yagni-app/code-staging",
-  "version": "1.1.4-staging.1424.1",
+  "version": "1.1.4-staging.1425.1",
   "description": "YAGNI Code: a terminal coding agent that already knows your company. One YAGNI login routes the model and grounds the agent in your team's context.",
   "license": "SEE LICENSE IN LICENSE.md",
   "author": "YAGNI, Inc. <jack@yagni.app> (https://yagni.app)",
@@ -58,5 +58,5 @@
     "turndown": "^7.2.4",
     "typebox": "^1.3.15"
   },
-  "yagniSourceSha": "bd7d06bc8fc95da1e22d6b06146cf7a0ea20ad78"
+  "yagniSourceSha": "e0166fd5a8fd711d788e98ec1d179c7d05100a78"
 }