@appchy/jarvis 0.1.127 → 0.1.128

package/dist/bin.js

@@ -10387,7 +10387,7 @@ import { createRequire as createRequire2 } from "module";
 var _require = createRequire2(import.meta.url);
 var VERSION2 = _require("../package.json").version ?? "0.0.0";
 var IS_DEV = String(_require("../package.json").name ?? "").endsWith("-dev");
-var SHA = "e9c97f0";
+var SHA = "9df9b58";
 var BUILT = "2026-09-12";
 var BUILD = SHA ?? "source";
 var BUILD_LABEL = `${SHA ? `${VERSION2} (${SHA}${BUILT ? ` ${BUILT}` : ""})` : `${VERSION2} (source)`}${IS_DEV ? " \u2014 development build" : ""}`;

package/harness/presets/appchy/PRESET.md

@@ -164,9 +164,13 @@ preference — `jarvis work where` resolves it. Tiny mechanics need no sign-off.
    from `jarvis work code <region>` overlap and the feature graph, not a lint. A cheap reshape happens in
    the plan; a real trade-off routes through `AskUserQuestion` and lands as a new rule.
 
-**A completed brief records what was BELIEVED then; it is not a statement about now.** Anything under
-`complete/` or in a released cut describes the world its author was working in, and the tools it
-asserts have moved since. Quote one only with its date attached, and check any claim about how a
+**Every document here records what was BELIEVED when it was written; none of them is a statement about
+now.** Anything under `complete/` or in a released cut describes the world its author was working in,
+and the tools it asserts have moved since. **So does a LIVE epic's §Plan, and that one is the most
+dangerous of the three** — it is the document every kickoff prompt names as *"the calls the epic
+already settled"*, the one the two-pass rule tells you not to re-derive, and therefore the one a
+session is least likely to check. The caution used to stop at finished work, which is where it was
+needed least. Quote one only with its date attached, and check any claim about how a
 command behaves against the command before planning on it. Three such claims were found false in one
 evening across two repos — each specific, plausible, recently dated, and sitting in a file whose whole
 job is to be trusted. Nothing catches this class: the sentence points at no file, so no link check
@@ -206,6 +210,26 @@ every task in the goal. **Pass 2 (pickup)** *reads* Pass 1 and builds — it doe
 pickup finds the epic plan didn't settle something, that is a **gap in the epic plan**: settle it and
 write it back UP, so the next task inherits the answer.
 
+**An epic plan can be silent, and it can be WRONG — do not re-derive it, but do check the claims you
+are about to build on.** Those are different failures with different answers, and only the first was
+ever written down. A plan that is silent leaves you a decision to make and write back up. A plan that
+asserts something false hands you a conclusion, and re-deriving is exactly what you were told not to
+do — so nothing catches it. **Inheriting a DECISION is the point of this tier; inheriting a FACT about
+how something behaves is not.** A seam, a slice order, a call the founder made: take those and build.
+A sentence about what a command does, what a gate refuses, what a file contains or what some number
+is: that is a claim, and a claim costs one command to check against the thing itself.
+
+Measured on this board, 2026-09-12: a §Plan stated that a placeholder criterion *"would have counted
+against the completion gate"*. The guard that drops those had shipped **nine days earlier** — so the
+sentence was false when written, not gone stale. Two sessions read it, neither checked it, both
+repeated it to the founder, and it cost about an hour. It pointed at no file, so no link check went
+red; the tree does not know a sentence is a claim. Nothing here is unusual: that is what this class of
+failure looks like every time.
+
+When you find one, **correct it in place and leave the correction visible** — the belief and its
+refutation together, dated. A silently-edited plan teaches the next reader nothing, and they arrived
+with the same assumption you did.
+
 **Refactor work is its own commit.** Restructuring existing code *without changing behaviour* is its
 own phase and its own commit — never mixed with a feature or fix.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@appchy/jarvis",
-  "version": "0.1.127",
+  "version": "0.1.128",
   "description": "Jarvis — local AI coding assistant CLI",
   "private": false,
   "type": "module",
@@ -57,8 +57,8 @@
     "typescript": "^5.7.0",
     "vitest": "^2.1.0",
     "@jarvis/agents": "1.0.0",
-    "@jarvis/board": "0.1.0",
     "@jarvis/anthropic": "1.0.0",
+    "@jarvis/board": "0.1.0",
     "@jarvis/data": "0.1.0",
     "@jarvis/errors": "1.0.0",
     "@jarvis/logger": "1.0.0",