gm-skill 2.0.1863 → 2.0.1864

package/AGENTS.md

@@ -152,7 +152,7 @@ A task that reduces to read/investigate/report, or a change confined to files th
 
 Push to any rs-* sibling -> `cascade.yml` -> rs-plugkit `release.yml` -> single `plugkit.wasm` (npm `plugkit-wasm` + `plugkit-bin` Releases) -> auto-bump `gm.json::plugkitVersion` -> `publish.yml` ships gm-skill+gm-plugkit+SKILL.md mirror. Step sequence + PUBLISHER_TOKEN: the recall store (`recall: cascade pipeline`).
 
-**Repos involved (push to any triggers cascade):** `AnEntrypoint/{rs-exec, rs-codeinsight, rs-search, rs-plugkit, gm}`. rs-learn is retired (crate removed from rs-plugkit, repo cascade/publish workflows deleted, README points at rs-plugkit). Roles, npm package names, legacy-retirement detail: the recall store (`recall: cascade repos involved roles`, `recall: legacy gm-skill variants retired`).
+**Repos involved (push to any triggers cascade):** `AnEntrypoint/{rs-codeinsight, rs-search, rs-plugkit, gm}`. rs-learn and rs-exec are retired (crates removed from / never depended on by rs-plugkit; their spool-dispatch and memory surfaces reimplemented natively in rs-plugkit wasm_dispatch; repos archived as tombstones, README points at rs-plugkit). Roles, npm package names, legacy-retirement detail: the recall store (`recall: cascade repos involved roles`, `recall: legacy gm-skill variants retired`).
 
 **To update every possible thing**: push to the relevant repo. No manual version bumps, no local `cargo update`/`cargo build` -- push, let CI build.
 

package/gm-plugkit/instructions/residual/browser-open.md

@@ -1 +1 @@
-browser sessions still open — dispatch `browser` with `session list` body to enumerate open ids, then `session close <id>` for each before retrying residual-scan
+browser sessions still open -- dispatch `browser` with `session list` body to enumerate open ids, then `session close <id>` for each before retrying residual-scan

package/gm-plugkit/instructions/residual/dirty-tree.md

@@ -1 +1 @@
-worktree dirty — modified={modified} untracked={untracked} — commit or revert before residual scan; a push from a dirty tree orphans the unstaged delta
+worktree dirty -- modified={modified} untracked={untracked} -- commit or revert before residual scan; a push from a dirty tree orphans the unstaged delta

package/gm-plugkit/instructions/residual/imperative.md

@@ -1 +1 @@
-Residual scan. Worktree clean, remote pushed, PRD empty, mutables witnessed — the four checks. Anything reachable and in-spirit expands the PRD and runs. Out-of-reach is credentials, down service, product decision.
+Residual scan. Worktree clean, remote pushed, PRD empty, mutables witnessed -- the four checks. Anything reachable and in-spirit expands the PRD and runs. Out-of-reach is credentials, down service, product decision.

package/gm-plugkit/instructions/residual/tasks-running.md

@@ -1 +1 @@
-background tasks still running — wait for completion or kill them via the host_exec_js interface before retrying residual-scan
+background tasks still running -- wait for completion or kill them via the host_exec_js interface before retrying residual-scan

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.1863",
+  "version": "2.0.1864",
   "description": "Bootstrap and daemon-spawn tool for gm plugkit binary. Downloads the correct platform binary, verifies SHA256, and starts the spool watcher daemon. Includes plugkit-wasm-wrapper for WASM-based spool watching.",
   "main": "index.js",
   "bin": {

package/gm-plugkit/plugkit-wasm-wrapper.js

@@ -2728,7 +2728,24 @@ function makeHostFunctions(instanceRef) {
               + `})();\n`;
             cmd = process.execPath; args = ['-e', memRunner];
           } else {
-            cmd = process.execPath; args = ['-e', code];
+            // Wrap in an async IIFE so top-level `return` (and top-level
+            // `await`) work -- `node/bun -e "return 2+2;"` is a SyntaxError
+            // at top level, but the gm exec_js contract lets code `return` a
+            // result. This mirrors the mem/profile paths and the browser verb.
+            // The returned value is emitted via a __GM_RESULT__ sentinel so the
+            // user's own stdout stays clean; a throw still prints its stack to
+            // stderr and exits 1, preserving the documented error channel.
+            const defRunner = `(async () => {\n`
+              + `  try {\n`
+              + `    const __r = await (async () => {\n${code}\n})();\n`
+              + `    try { console.log('__GM_RESULT__' + JSON.stringify(__r === undefined ? null : __r)); }\n`
+              + `    catch (__se) { console.log('__GM_RESULT__' + JSON.stringify({ __unserializable: String(__se && __se.message || __se) })); }\n`
+              + `  } catch (__e) {\n`
+              + `    console.error(String(__e && __e.stack || __e));\n`
+              + `    process.exitCode = 1;\n`
+              + `  }\n`
+              + `})();\n`;
+            cmd = process.execPath; args = ['-e', defRunner];
           }
         }
         else if (lang === 'python') { cmd = 'python'; args = ['-c', code]; }
@@ -2742,6 +2759,20 @@ function makeHostFunctions(instanceRef) {
         } finally {
           if (profileUserFile) { try { fs.unlinkSync(profileUserFile); } catch (_) {} }
         }
+        // Shared across all result branches: a genuine timeout kills the child
+        // near the deadline. A SIGTERM far under timeoutMs is a spurious /
+        // host-injected kill (e.g. the stale-watcher SIGTERM-at-28ms), not a
+        // timeout -- do not mislabel it as timed_out.
+        const __execDurMs = Date.now() - __execT0;
+        const __execTimedOut = result.signal === 'SIGTERM' && __execDurMs >= Math.floor(timeoutMs * 0.9);
+        // spawnSync sets result.error (and leaves status/signal null) when the
+        // child could NOT be started or was reaped abnormally (spawn race
+        // during watcher boot, ETIMEDOUT, EBADF, ENOENT for a missing runtime).
+        // Surface it so a status:-1 is diagnosable instead of a silent empty
+        // failure -- the caller sees WHY, not just exit_code:-1.
+        const __spawnError = result.error
+          ? { code: result.error.code || null, errno: result.error.errno || null, syscall: result.error.syscall || null, message: String(result.error.message || result.error) }
+          : null;
         if (wantProfile) {
           const raw = result.stdout || '';
           const idx = raw.indexOf('__GM_PROFILE__');
@@ -2752,14 +2783,15 @@ function makeHostFunctions(instanceRef) {
             stdout: idx >= 0 ? raw.slice(0, idx) : raw,
             stderr: result.stderr || '',
             exit_code: result.status === null ? -1 : result.status,
-            timed_out: result.signal === 'SIGTERM',
-            duration_ms: Date.now() - __execT0,
+            timed_out: __execTimedOut,
+            duration_ms: __execDurMs,
             result: parsed ? parsed.result : null,
             profile: parsed ? parsed.profile : { timeframe: null, culprits: [] },
             profile_error: parsed ? parsed.profile_error : 'profile sentinel not found in stdout',
             user_error: parsed ? parsed.user_error : null,
             mem: parsed ? parsed.mem : null,
             wall_vs_cpu: parsed ? parsed.wall_vs_cpu : null,
+            ...(__spawnError ? { spawn_error: __spawnError } : {}),
           });
         }
         if (opts.mem === true && isJsLang) {
@@ -2772,21 +2804,41 @@ function makeHostFunctions(instanceRef) {
             stdout: idx >= 0 ? raw.slice(0, idx) : raw,
             stderr: result.stderr || '',
             exit_code: result.status === null ? -1 : result.status,
-            timed_out: result.signal === 'SIGTERM',
-            duration_ms: Date.now() - __execT0,
+            timed_out: __execTimedOut,
+            duration_ms: __execDurMs,
             result: meta ? meta.result : null,
             mem: meta ? meta.mem : null,
             wall_ms: meta ? meta.wall_ms : null,
             ...(meta && meta.error ? { error: meta.error } : {}),
+            ...(__spawnError ? { spawn_error: __spawnError } : {}),
           });
         }
+        let __defStdout = result.stdout || '';
+        let __defResult = null;
+        let __defHasResult = false;
+        if (isJsLang) {
+          const __ri = __defStdout.lastIndexOf('__GM_RESULT__');
+          if (__ri >= 0) {
+            const __tail = __defStdout.slice(__ri + '__GM_RESULT__'.length);
+            const __nl = __tail.indexOf('\n');
+            const __jsonStr = __nl >= 0 ? __tail.slice(0, __nl) : __tail;
+            try { __defResult = JSON.parse(__jsonStr); __defHasResult = true; } catch (_) {}
+            // Strip the sentinel (and the leading newline we prepended) so the
+            // caller's own stdout is returned clean.
+            let __clean = __defStdout.slice(0, __ri) + (__nl >= 0 ? __tail.slice(__nl + 1) : '');
+            if (__clean.endsWith('\n')) __clean = __clean.slice(0, -1);
+            __defStdout = __clean;
+          }
+        }
         return writeWasmJson(instanceRef.value, {
           ok: result.status === 0,
-          stdout: result.stdout || '',
+          stdout: __defStdout,
           stderr: result.stderr || '',
           exit_code: result.status === null ? -1 : result.status,
-          timed_out: result.signal === 'SIGTERM',
-          duration_ms: Date.now() - __execT0,
+          timed_out: __execTimedOut,
+          duration_ms: __execDurMs,
+          ...(__defHasResult ? { result: __defResult } : {}),
+          ...(__spawnError ? { spawn_error: __spawnError } : {}),
           ...(profileSkipped ? { profile_skipped: profileSkipped } : {}),
         });
       } catch (e) {

package/gm-plugkit/supervisor.js

@@ -159,6 +159,22 @@ function readShutdownReason() {
   try { return JSON.parse(fs.readFileSync(SHUTDOWN_REASON_PATH, 'utf-8')); } catch (_) { return null; }
 }
 
+// A supervisor-initiated kill is PLANNED (version/wrapper drift, heartbeat-stale),
+// but on Windows process.kill(pid,'SIGTERM') terminates the child immediately with
+// no catchable signal, so the child never writes its own .shutdown-reason.json and
+// the taskkill /F that follows leaves none either -- the NEXT boot then mislabels a
+// deliberate upgrade recycle as a SILENT ABORT / unplanned-restart critical. Write
+// the planned reason on the child's behalf BEFORE killing, so the next boot reads a
+// fresh planned shutdown reason and classifies the restart correctly.
+function killChild(reason) {
+  if (!currentChildPid) return;
+  try { fs.writeFileSync(SHUTDOWN_REASON_PATH, JSON.stringify({ reason, ts: Date.now(), pid: currentChildPid, killed_by_supervisor: true })); } catch (_) {}
+  try { process.kill(currentChildPid, 'SIGTERM'); } catch (_) {}
+  if (process.platform === 'win32') {
+    try { spawnSync('taskkill', ['/F', '/T', '/PID', String(currentChildPid)], { stdio: 'ignore', windowsHide: true, timeout: 3000 }); } catch (_) {}
+  }
+}
+
 let lastSpawnedAt = 0;
 let lastVersionDriftActionAt = 0;
 let restartTimestamps = [];
@@ -258,7 +274,7 @@ function spawnWatcher(bootReason) {
     const idleClean = reason === 'idle';
     const lockRejected = code === 75;
     const cleanExit = code === 0;
-    const plannedReasons = new Set(['idle', 'sigterm', 'version-change', 'wrapper-change', 'peer-stale-takeover', 'external-planned', 'process-exit']);
+    const plannedReasons = new Set(['idle', 'sigterm', 'version-change', 'wrapper-change', 'heartbeat-stale', 'peer-stale-takeover', 'external-planned', 'process-exit']);
     const isPlanned = plannedReasons.has(reason) || lockRejected || cleanExit;
     const eventName = idleClean
       ? 'supervisor.watcher-exited-idle'
@@ -335,10 +351,7 @@ function checkWatcherHealth() {
       stale_limit_ms: STATUS_STALE_MS,
       severity: 'critical',
     });
-    try { process.kill(currentChildPid, 'SIGTERM'); } catch (_) {}
-    if (process.platform === 'win32') {
-      try { spawnSync('taskkill', ['/F', '/T', '/PID', String(currentChildPid)], { stdio: 'ignore', windowsHide: true, timeout: 3000 }); } catch (_) {}
-    }
+    killChild('heartbeat-stale');
     return;
   }
   const reported = status.wrapper_sha || null;
@@ -350,10 +363,7 @@ function checkWatcherHealth() {
       on_disk_sha: onDisk,
       severity: 'info',
     });
-    try { process.kill(currentChildPid, 'SIGTERM'); } catch (_) {}
-    if (process.platform === 'win32') {
-      try { spawnSync('taskkill', ['/F', '/T', '/PID', String(currentChildPid)], { stdio: 'ignore', windowsHide: true, timeout: 3000 }); } catch (_) {}
-    }
+    killChild('wrapper-change');
     return;
   }
   if (status.version_drifted === true) {
@@ -377,10 +387,7 @@ function checkWatcherHealth() {
         try { fs.unlinkSync(path.join(gmTools, f)); } catch (_) {}
       }
     } catch (_) {}
-    try { process.kill(currentChildPid, 'SIGTERM'); } catch (_) {}
-    if (process.platform === 'win32') {
-      try { spawnSync('taskkill', ['/F', '/T', '/PID', String(currentChildPid)], { stdio: 'ignore', windowsHide: true, timeout: 3000 }); } catch (_) {}
-    }
+    killChild('version-change');
   }
 }
 

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.1863",
+  "version": "2.0.1864",
   "description": "Spool-dispatch orchestration engine with unified state machine, skills, and automated git enforcement",
   "author": "AnEntrypoint",
   "license": "MIT",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.1863",
+  "version": "2.0.1864",
   "description": "Canonical universal harness — AI-native software engineering via skill-driven orchestration; bootstraps plugkit for task execution and session isolation. Install in any AI coding agent host.",
   "author": "AnEntrypoint",
   "license": "MIT",

package/skills/fifth-dimension-engine/SKILL.md

@@ -121,7 +121,7 @@ See `references/research-kernel-extraction.md` for how mixed themes become resea
 
 ### Everyday Problems
 
-The same engine works on ordinary decisions, work problems, product questions, and engineering failures — any well-specified target benefits from being shot into a route rather than answered directly.
+The same engine works on ordinary decisions, work problems, product questions, and engineering failures -- any well-specified target benefits from being shot into a route rather than answered directly.
 
 ## Verification
 
@@ -141,7 +141,7 @@ This skill does not:
 ## References
 
 See `references/` directory for:
-- `route-structure.md` — what a route is and how it is structured
-- `research-kernel-extraction.md` — turning ideas into research kernels
-- `route-inspection-guide.md` — how to verify and attack a route
-- `skills/polaris-protocol/SKILL.md` — the Polaris Protocol tree root and state machine
+- `route-structure.md` -- what a route is and how it is structured
+- `research-kernel-extraction.md` -- turning ideas into research kernels
+- `route-inspection-guide.md` -- how to verify and attack a route
+- `skills/polaris-protocol/SKILL.md` -- the Polaris Protocol tree root and state machine

package/skills/fifth-dimension-engine/references/research-kernel-extraction.md

@@ -1,4 +1,4 @@
-# Research Kernel Extraction — Fifth-Dimension Engine
+# Research Kernel Extraction -- Fifth-Dimension Engine
 
 Mixing two unrelated themes turns them into a theorem-shaped research kernel. The same mechanic generalizes to ordinary research questions.
 
@@ -16,12 +16,12 @@ The engine's job is to move a target from symbol to structure:
 1. Name the two themes.
 2. Shoot them together.
 3. Read the returned route: what structure does the engine propose?
-4. Inspect the candidate lemmas — are they real mathematical objects, or metaphor?
+4. Inspect the candidate lemmas -- are they real mathematical objects, or metaphor?
 5. Keep the parts that survive inspection; discard the parts that are only poetry.
 
 ## Everyday research use
 
-The same pattern works without strangeness — shoot an ordinary open research question directly. The engine returns a route: candidate theoretical bounds, objections, open questions. You then verify the lemmas and expand the open debt into real research.
+The same pattern works without strangeness -- shoot an ordinary open research question directly. The engine returns a route: candidate theoretical bounds, objections, open questions. You then verify the lemmas and expand the open debt into real research.
 
 ## What this does NOT claim
 

package/skills/fifth-dimension-engine/references/route-inspection-guide.md

@@ -1,4 +1,4 @@
-# Route Inspection Guide — Fifth-Dimension Engine
+# Route Inspection Guide -- Fifth-Dimension Engine
 
 A route from the Fifth-Dimension Engine is not a final answer. It is a structure you can inspect, attack, expand, and test. Inspection is your job; the engine only produces the route.
 

package/skills/fifth-dimension-engine/references/route-structure.md

@@ -2,7 +2,7 @@
 
 ## What a Route Is
 
-A route is the **output of the Fifth-Dimension Engine** — a structured, inspectable answer to a complex problem.
+A route is the **output of the Fifth-Dimension Engine** -- a structured, inspectable answer to a complex problem.
 
 Instead of a flat statement like "Yes, do this" or "The answer is X," the engine produces:
 

package/skills/gm/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: gm
 description: The primary driver for any non-trivial coding, refactoring, debugging, or multi-step engineering task in a project using this harness -- use it first, for the whole task, not just a piece of it. Plugkit-served instruction stream. Three-layer admission (witness, single-writer, direction) over every possible mutation; effort unbounded, never gated on cost. Closure on first emit; partial = non-monotonic. Not for the post-completion remaining-work check (that is `gm-continue`) or for drift-recovery mid-task (that is `wfgy-method`) -- this skill is the work itself.
-allowed-tools: Skill, Read, Write, Bash(bun *), Bash(npx *)
+allowed-tools: Skill, Read, Write, Bash(bun *), Bash(npx *), Bash(cat *), Bash(date *)
 ---
 
 # gm
@@ -84,7 +84,7 @@ VERIFY is adversarial, never confirmatory: run the real code path and read its a
 
 Phase transitions: PLAN -> EXECUTE, EXECUTE -> EMIT, EMIT -> VERIFY, VERIFY -> CONSOLIDATE, CONSOLIDATE -> COMPLETE. Each requires `transition {to:"PHASE"}` dispatch. EXECUTE resolves mutables in `.gm/mutables.yml` before EMIT. EMIT writes file changes. VERIFY validates via `exec_js`/`browser`. CONSOLIDATE pushes changes via `git_finalize` or `git_push`, then witnesses CI/CD pipeline green. COMPLETE gate requires: worktree clean, remote pushed, mutables resolved, and `.ci-validated` marker written with current commit SHA.
 
-CI/CD validation in CONSOLIDATE phase: After push succeeds, watch the triggered workflow. When pipeline goes green, dispatch `fs_write {path:".gm/exec-spool/.ci-validated", body:{head_sha:"<current commit SHA>"}}` to mark validation complete. `.ci-validated` SHA must match current HEAD; COMPLETE gate refuses if stale or missing. Red runs require fix + re-push + re-watch; no skip for "it looked safe."
+CI/CD validation in CONSOLIDATE phase: After push succeeds, watch the triggered workflow. When pipeline goes green, dispatch `fs_write {path:".gm/exec-spool/.ci-validated", content:"{\"head_sha\":\"<current commit SHA>\"}"}` to mark validation complete -- the marker's file CONTENT is the JSON string `{"head_sha":"<SHA>"}`, passed under the `content` field the fs_write handler reads (not a `body`/`head_sha` object, which the handler ignores). `.ci-validated`'s head_sha must match current HEAD; COMPLETE gate refuses if stale or missing. Red runs require fix + re-push + re-watch; no skip for "it looked safe."
 
 Memory via `memorize-fire` dispatch stores in `.gm/rs-learn.db` and is retrieved via `recall` and `auto_recall`. `discipline-note {discipline, text}` writes `.gm/disciplines/<name>/policy.md`; `instruction` auto-surfaces policies from disciplines listed in `.gm/disciplines/enabled.txt`.
 

package/skills/polaris-goal-compiler/SKILL.md

@@ -117,7 +117,7 @@ Over-claiming (saying something is done when it's only drafted) is the most comm
 
 ### Closure Records
 
-For each atom, record what is done, what is missing, what is only partially true, and what is still unsafe to claim. A closure record preserves continuity across rounds so that unfinished work stays visible instead of being buried in prose — this is what stops a local step from being promoted into fake global completion.
+For each atom, record what is done, what is missing, what is only partially true, and what is still unsafe to claim. A closure record preserves continuity across rounds so that unfinished work stays visible instead of being buried in prose -- this is what stops a local step from being promoted into fake global completion.
 
 ## Interaction with Other Skills
 
@@ -143,10 +143,10 @@ Use Goal Compiler to compile the problem statement, then dispatch to Fifth-Dimen
 ## References
 
 See `references/` directory for:
-- `task-atomization.md` — how to break work into atoms
-- `verification-gates.md` — designing verification for each stage
-- `claim-ceiling-examples.md` — what "complete" actually means in different contexts
-- `skills/polaris-protocol/SKILL.md` — the Polaris Protocol tree root and state machine that wires this skill to Fifth-Dimension Engine and WFGY-Method
+- `task-atomization.md` -- how to break work into atoms
+- `verification-gates.md` -- designing verification for each stage
+- `claim-ceiling-examples.md` -- what "complete" actually means in different contexts
+- `skills/polaris-protocol/SKILL.md` -- the Polaris Protocol tree root and state machine that wires this skill to Fifth-Dimension Engine and WFGY-Method
 
 ## What This Is Not
 

package/skills/polaris-goal-compiler/references/claim-ceiling-examples.md

@@ -20,12 +20,12 @@ The point is not optimism or pessimism. It is that a local success should not be
 
 - Atom A03 "Repair structure" is finished and the file compiles.
 - Claim ceiling: you may say "the structure is repaired and compiles." You may **not** yet say "the bug is fixed" until A04 (verify repair) passes.
-- If A04 is still blocked, saying "fixed" is a ceiling violation — it promotes a local step to global completion.
+- If A04 is still blocked, saying "fixed" is a ceiling violation -- it promotes a local step to global completion.
 
 ### Documentation packaging
 
 - You wrote the release note (A06) but A04 (verify repair) never ran.
-- Claim ceiling: you may say "a draft release note exists." You may **not** say "release ready" — readiness requires the verification gate first.
+- Claim ceiling: you may say "a draft release note exists." You may **not** say "release ready" -- readiness requires the verification gate first.
 - This is exactly the upstream failure mode: writing the announcement before the repair is verified.
 
 ### Research synthesis

package/skills/polaris-goal-compiler/references/task-atomization.md

@@ -4,10 +4,10 @@
 
 A task atom is the smallest executable unit of work. It must satisfy all of:
 
-1. **Atomic** — Cannot be divided further without losing meaning
-2. **Completable** — Can be finished in one session/sprint
-3. **Verifiable** — Has clear entrance and exit criteria
-4. **Interdependent** — Has clear dependencies (blocks/is blocked by other atoms)
+1. **Atomic** -- Cannot be divided further without losing meaning
+2. **Completable** -- Can be finished in one session/sprint
+3. **Verifiable** -- Has clear entrance and exit criteria
+4. **Interdependent** -- Has clear dependencies (blocks/is blocked by other atoms)
 
 ## Examples
 
@@ -27,7 +27,7 @@ A task atom is the smallest executable unit of work. It must satisfy all of:
 
 Start with: "Goal: Build a payment microservice."
 
-1. **Identify phases**: Research → Design → Implement → Test → Deploy
+1. **Identify phases**: Research -> Design -> Implement -> Test -> Deploy
 2. **For each phase, ask: What's the smallest piece?**
    - Research: API options, compliance, existing solutions
    - Design: Data model, interfaces, error handling
@@ -40,19 +40,19 @@ Start with: "Goal: Build a payment microservice."
 ## Dependency Edges
 
 Each atom has:
-- **Blockers** — Things that must finish before this starts
-- **Unblocks** — Things that can't start until this finishes
+- **Blockers** -- Things that must finish before this starts
+- **Unblocks** -- Things that can't start until this finishes
 
 Example:
 ```
 Research APIs (A1) 
-  ↓ unblocks
+  -> unblocks
 Design interface (A2)
-  ↓ unblocks
+  -> unblocks
 Implement core (A3)
-  ↓ unblocks
+  -> unblocks
 Test integration (A4)
-  ↓ unblocks
+  -> unblocks
 Deploy (A5)
 ```
 

package/skills/polaris-goal-compiler/references/verification-gates.md

@@ -43,17 +43,17 @@ For an atom:
 
 ## Bad Gates
 
-- "Complete" — unmeasurable
-- "Good enough" — too vague
-- "No obvious bugs" — not verifiable
+- "Complete" -- unmeasurable
+- "Good enough" -- too vague
+- "No obvious bugs" -- not verifiable
 - Checking something trivial (wasting time)
 
 ## Gate Failure
 
 If an atom fails its gate:
-- **Do not move forward** — you have incomplete work that looks complete
-- **Return to the atom** — what's actually missing?
-- **Fix or redefine** — either finish the work or redefine the atom scope
+- **Do not move forward** -- you have incomplete work that looks complete
+- **Return to the atom** -- what's actually missing?
+- **Fix or redefine** -- either finish the work or redefine the atom scope
 
 This is where fake completion gets caught.
 

package/skills/polaris-protocol/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: polaris-protocol
-description: WFGY 5.0 Polaris Protocol — the active flagship route from onestardao/WFGY. A two-layer reasoning system that compiles goals before execution and shoots complex problems into inspectable routes, with drift control throughout. This skill is the tree root: load it first, then dispatch its child skills as explicit transitions — polaris-goal-compiler (compile), fifth-dimension-engine (shoot), wfgy-method (drift control). Use for any complex, multi-step, high-stakes, or long-horizon task where premature completion or goal drift is a risk.
+description: WFGY 5.0 Polaris Protocol -- the active flagship route from onestardao/WFGY. A two-layer reasoning system that compiles goals before execution and shoots complex problems into inspectable routes, with drift control throughout. This skill is the tree root: load it first, then dispatch its child skills as explicit transitions -- polaris-goal-compiler (compile), fifth-dimension-engine (shoot), wfgy-method (drift control). Use for any complex, multi-step, high-stakes, or long-horizon task where premature completion or goal drift is a risk.
 license: MIT
 compatibility: Portable protocol; upstream released the Goal Compiler ChatGPT-first (teaser) and the Fifth-Dimension Engine as the main product surface. This skill wraps both plus WFGY-Method drift control into one discoverable entry point for any assistant or agent that loads skills.
 metadata:
@@ -8,19 +8,19 @@ metadata:
   provenance: adapted-and-honest-reimplementation-not-verbatim
 ---
 
-# WFGY 5.0 — Polaris Protocol (tree root)
+# WFGY 5.0 -- Polaris Protocol (tree root)
 
 Polaris is the active public route of WFGY 5.0. The **Fifth-Dimension Engine** is the current main product surface; the **Polaris Goal Compiler** is the first public protocol component. **WFGY-Method** supplies the drift-control discipline that keeps the whole system aligned with the original goal.
 
-This skill is the **tree root**. It does not re-explain the children — it wires them into one state machine and tells you which child to dispatch at each step. Treat the three child skills as the transitions of the machine below.
+This skill is the **tree root**. It does not re-explain the children -- it wires them into one state machine and tells you which child to dispatch at each step. Treat the three child skills as the transitions of the machine below.
 
 ## The tree
 
 ```
-polaris-protocol  (this skill — root / entry)
-├── polaris-goal-compiler   (COMPILE state)
-├── fifth-dimension-engine  (SHOOT state)
-└── wfgy-method             (DRIFT CONTROL — applies at every state)
+polaris-protocol  (this skill -- root / entry)
+|-- polaris-goal-compiler   (COMPILE state)
+|-- fifth-dimension-engine  (SHOOT state)
+`-- wfgy-method             (DRIFT CONTROL -- applies at every state)
 ```
 
 Discoverable: each node is a standalone `SKILL.md` inside its own `skills/<skill-name>/` directory. This root is the entry point; the children are reached by explicit dispatch.
@@ -37,7 +37,7 @@ A skill tree can behave like a state machine. Each transition is an explicit ski
 | `COMPILED` | Goal Compiler emitted task atoms, dependencies, verification gates, claim ceilings, and a closure-record template. |
 | `SHOOTING` | A complex atom is being lifted by Fifth-Dimension Engine into a route. |
 | `EXECUTING` | An atom (routine, or the result of a route) is being carried out. |
-| `VERIFYING` | Output is checked against the atom's verification gate and against drift (ΔS, via WFGY-Method). |
+| `VERIFYING` | Output is checked against the atom's verification gate and against drift (deltaS, via WFGY-Method). |
 | `CLOSED` | Claim ceiling met, closure record written, atom done. |
 
 ### Transitions (each is a dispatch)
@@ -58,13 +58,13 @@ VERIFYING --gate fail / drift --> BBCR checkpoint ----> COMPILED (re-compile or
 CLOSED --next atom------------------------------------> COMPILED
 ```
 
-`wfgy-method` is not a single transition — it is the drift-control observer attached to **every** state. Before any step that could have drifted, dispatch it and read the result.
+`wfgy-method` is not a single transition -- it is the drift-control observer attached to **every** state. Before any step that could have drifted, dispatch it and read the result.
 
-## Canonical syntax (pro-rata — use exactly this)
+## Canonical syntax (pro-rata -- use exactly this)
 
 - **Compile first. Execute one active atom. Verify before unlock. Claim only what is supported.** (Goal Compiler)
-- **shoot + [your problem]** — the Fifth-Dimension Engine interface.
-- **ΔS = 1 − cos(I, G)** — drift between current state (I) and goal (G). Without a real embedding call, ΔS is a qualitative label ("ΔS looks high here"), never a computed decimal — unless a real `similarity` verb is available (see WFGY-Method).
+- **shoot + [your problem]** -- the Fifth-Dimension Engine interface.
+- **deltaS = 1 - cos(I, G)** -- drift between current state (I) and goal (G). Without a real embedding call, deltaS is a qualitative label ("deltaS looks high here"), never a computed decimal -- unless a real `similarity` verb is available (see WFGY-Method).
 
 "Compile first. Then shoot." is the spine of the whole protocol.
 
@@ -77,7 +77,7 @@ CLOSED --next atom------------------------------------> COMPILED
 3. At `VERIFYING`, dispatch `Skill(skill="wfgy-method")` to check drift and apply the atom's verification gate.
    - Pass + claim ceiling honored -> `CLOSED` -> next atom (back to `COMPILED`).
    - Fail or drift -> BBCR checkpoint, re-compile or re-shoot (back to `COMPILED`).
-4. When all atoms are `CLOSED`, the task is done — and only then may you claim completion.
+4. When all atoms are `CLOSED`, the task is done -- and only then may you claim completion.
 
 ## What this tree is not
 
@@ -88,8 +88,8 @@ CLOSED --next atom------------------------------------> COMPILED
 
 ## Children (dispatch these)
 
-- `polaris-goal-compiler` — compile the goal into atoms, gates, claim ceilings.
-- `fifth-dimension-engine` — shoot a complex atom into a structured route.
-- `wfgy-method` — hold drift control across every state.
+- `polaris-goal-compiler` -- compile the goal into atoms, gates, claim ceilings.
+- `fifth-dimension-engine` -- shoot a complex atom into a structured route.
+- `wfgy-method` -- hold drift control across every state.
 
 For the full DAG, integration workflows, and mismatch detection, see `../POLARIS-SKILLS-GUIDE.md`.

package/skills/wfgy-method/SKILL.md

@@ -10,82 +10,82 @@ metadata:
 
 # WFGY method
 
-WFGY (Wan Fa Gui Yi, "all methods return to one") is a reasoning-drift-control technique from `onestardao/WFGY`. This skill ports its genuinely portable behavioral core to a text-generating agent's own multi-step work. It does **not** reproduce the original project's TXT-OS prompt file, its hardcoded demo-benchmark output, or its user-skepticism-deflection script — see `references/honesty-and-provenance.md` for exactly what was kept, what was dropped, and why.
+WFGY (Wan Fa Gui Yi, "all methods return to one") is a reasoning-drift-control technique from `onestardao/WFGY`. This skill ports its genuinely portable behavioral core to a text-generating agent's own multi-step work. It does **not** reproduce the original project's TXT-OS prompt file, its hardcoded demo-benchmark output, or its user-skepticism-deflection script -- see `references/honesty-and-provenance.md` for exactly what was kept, what was dropped, and why.
 
-The original names four "Big Bang" modules (BBMC, BBPF, BBCR, BBAM) plus a numeric drift score, ΔS = 1 − cos(I, G) (I = current state, G = goal/anchor), and a trend classifier over consecutive ΔS values (convergent/recursive/divergent/chaotic). All of this is ported below. Where the original relies on real computation this skill cannot perform (real embeddings for ΔS, real attention-weight statistics for BBAM), the instruction explicitly hands that judgment to you, the calling agent, to make in plain language instead — see `references/wfgy-core-mechanism.md` for the full technical basis of every claim in this file, and `references/honesty-and-provenance.md` for exactly what was reframed and why.
+The original names four "Big Bang" modules (BBMC, BBPF, BBCR, BBAM) plus a numeric drift score, deltaS = 1 - cos(I, G) (I = current state, G = goal/anchor), and a trend classifier over consecutive deltaS values (convergent/recursive/divergent/chaotic). All of this is ported below. Where the original relies on real computation this skill cannot perform (real embeddings for deltaS, real attention-weight statistics for BBAM), the instruction explicitly hands that judgment to you, the calling agent, to make in plain language instead -- see `references/wfgy-core-mechanism.md` for the full technical basis of every claim in this file, and `references/honesty-and-provenance.md` for exactly what was reframed and why.
 
-**On ΔS**: absent a real embedding call, any numeric ΔS you produce is your own qualitative estimate, not a measurement. Use the label ("ΔS is climbing," "ΔS looks high here") as shorthand for "this step is drifting from the stated goal" — never present a specific decimal (e.g. "ΔS = 0.42") as if it were computed, because it is not, unless real embeddings are actually available (see below).
+**On deltaS**: absent a real embedding call, any numeric deltaS you produce is your own qualitative estimate, not a measurement. Use the label ("deltaS is climbing," "deltaS looks high here") as shorthand for "this step is drifting from the stated goal" -- never present a specific decimal (e.g. "deltaS = 0.42") as if it were computed, because it is not, unless real embeddings are actually available (see below).
 
-**If a gm-plugkit spool is running in this project** (check `.gm/exec-spool/.status.json`; most gm-managed repos have one), a real `similarity` verb is available: dispatch `{"text_a": "<G>", "text_b": "<current state>"}` to it and read back `{"similarity", "distance"}` — `distance` is a genuine `1 - cos(I, G)` computed from real BGE-small-en-v1.5 embeddings, not a self-estimate. When available, use this real value as ΔS directly and say so explicitly ("ΔS = 0.31, computed"). When not available, fall back to the qualitative label above and say so explicitly too ("ΔS looks high here, my own estimate, no embedding tool available"). Never let the reader assume one when you did the other.
+**If a gm-plugkit spool is running in this project** (check `.gm/exec-spool/.status.json`) **AND its build serves a `similarity` verb**, you can get a real deltaS instead of a self-estimate: dispatch `{"text_a": "<G>", "text_b": "<current state>"}` and read back `{"similarity", "distance"}` -- `distance` is a genuine `1 - cos(I, G)` from real BGE-small-en-v1.5 embeddings. Do NOT assume the verb exists just because a spool is running: not every build serves it, and an unrecognized verb is silently left queued with no response rather than erroring, so a missing response after a normal read cycle means the verb is NOT available -- treat that exactly like no spool. When you get a real distance back, use it as deltaS and say so explicitly ("deltaS = 0.31, computed"). Otherwise fall back to the qualitative label above and say so explicitly too ("deltaS looks high here, my own estimate, no embedding tool available"). Never let the reader assume one when you did the other.
 
-## G · the anchor (BBMC pattern: compare state against goal)
+## G - the anchor (BBMC pattern: compare state against goal)
 
-At the start of any task this skill applies to, write one sentence stating the actual goal (G) — not the first sub-task, the actual end state the user wants. Re-read it before any step that could plausibly have drifted: a long tool-call chain, a pivot in approach, a request to "also" do something adjacent.
+At the start of any task this skill applies to, write one sentence stating the actual goal (G) -- not the first sub-task, the actual end state the user wants. Re-read it before any step that could plausibly have drifted: a long tool-call chain, a pivot in approach, a request to "also" do something adjacent.
 
 - [ ] Stated G in one sentence before starting.
 - [ ] Before each major step, ask: does what I'm about to do still serve G, or have I started solving a different, adjacent problem?
-- [ ] If drift is real (not just "this step looks different from the last one" — actual scope change, contradicted earlier decision, answering a different question than asked), say so explicitly and re-anchor before continuing.
+- [ ] If drift is real (not just "this step looks different from the last one" -- actual scope change, contradicted earlier decision, answering a different question than asked), say so explicitly and re-anchor before continuing.
 
-Gotcha: the temptation is to silently keep going once you notice drift, because stopping to say "wait, I've drifted" feels like an interruption. Don't suppress it — a silently-corrected drift is invisible to the user and looks like it never happened; a stated one is a real signal they can act on.
+Gotcha: the temptation is to silently keep going once you notice drift, because stopping to say "wait, I've drifted" feels like an interruption. Don't suppress it -- a silently-corrected drift is invisible to the user and looks like it never happened; a stated one is a real signal they can act on.
 
-## BBPF pattern · consider more than one path before committing
+## BBPF pattern - consider more than one path before committing
 
-Applies to decisions with real alternatives, not every trivial step. The original's gate condition (a candidate path proceeds only if it measurably reduces ΔS and stays within a stability bound) translates to: when a decision is ambiguous or high-stakes, generate more than one real candidate approach, then commit to whichever one most clearly and verifiably advances G — not the first idea, not the most familiar one.
+Applies to decisions with real alternatives, not every trivial step. The original's gate condition (a candidate path proceeds only if it measurably reduces deltaS and stays within a stability bound) translates to: when a decision is ambiguous or high-stakes, generate more than one real candidate approach, then commit to whichever one most clearly and verifiably advances G -- not the first idea, not the most familiar one.
 
-- [ ] Is this decision ambiguous or high-stakes enough to warrant comparing options? (Most steps are not — do not apply this to routine, unambiguous work.)
+- [ ] Is this decision ambiguous or high-stakes enough to warrant comparing options? (Most steps are not -- do not apply this to routine, unambiguous work.)
 - [ ] If yes: name at least two real candidate approaches before picking one.
 - [ ] State which one you picked and why it advances G more clearly than the alternative(s).
 - [ ] If no candidate is clearly better, that is itself a signal worth surfacing to the user rather than picking arbitrarily and moving on.
 
-## BBCR pattern · checkpoint, bounded retry, then surface rather than confabulate
+## BBCR pattern - checkpoint, bounded retry, then surface rather than confabulate
 
 The original's collapse-and-retry loop resets to a last-known-good state on detected instability, retries a bounded number of times (its own reference implementation defaults to 3), and gives up cleanly rather than looping forever.
 
 - [ ] Before a risky or exploratory step (one that could leave things in a worse state than before), note what "last known good" looks like right now, in enough detail to actually get back to it.
-- [ ] If you notice real incoherence — repeated self-contradiction, circular reasoning, a mistake you catch yourself making — stop, return to the last checkpoint, and retry.
+- [ ] If you notice real incoherence -- repeated self-contradiction, circular reasoning, a mistake you catch yourself making -- stop, return to the last checkpoint, and retry.
 - [ ] Retry at most 2-3 times for the same unresolved tension. After that, stop retrying silently.
-- [ ] Surface the specific unresolved problem to the user explicitly — state what you tried, why each attempt didn't resolve it, and what you need from them — rather than picking an answer anyway and moving on as if it were resolved.
+- [ ] Surface the specific unresolved problem to the user explicitly -- state what you tried, why each attempt didn't resolve it, and what you need from them -- rather than picking an answer anyway and moving on as if it were resolved.
 
-Gotcha: "bounded" is load-bearing. An agent that keeps trying indefinitely without ever surfacing the struggle is worse than one that fails fast and asks — the original's own design treats "give up and report" as a real, intended exit path, not a failure of the technique.
+Gotcha: "bounded" is load-bearing. An agent that keeps trying indefinitely without ever surfacing the struggle is worse than one that fails fast and asks -- the original's own design treats "give up and report" as a real, intended exit path, not a failure of the technique.
 
-## BBAM pattern · notice and correct over-narrow focus (agent-delegated: no real attention weights are read)
+## BBAM pattern - notice and correct over-narrow focus (agent-delegated: no real attention weights are read)
 
-The original computes `logits * exp(-gamma * sigma(logits))` — rescaling an actual attention/logit distribution by its own variance, flattening it when it's too peaked. A text-generating agent cannot read its own attention weights or logits; there is no real signal here for this skill to compute. Instead of dropping this module, the intelligence work is handed to you directly: periodically ask yourself whether your recent output has narrowed onto one aspect of a broader task and stayed there past the point of usefulness (repeating the same point, elaborating one sub-detail while leaving the rest of the task untouched, treating one hypothesis as settled without checking alternatives). If so, deliberately widen back out — this is you doing, in plain judgment, what the original technique's math does mechanically to a real attention distribution.
+The original computes `logits * exp(-gamma * sigma(logits))` -- rescaling an actual attention/logit distribution by its own variance, flattening it when it's too peaked. A text-generating agent cannot read its own attention weights or logits; there is no real signal here for this skill to compute. Instead of dropping this module, the intelligence work is handed to you directly: periodically ask yourself whether your recent output has narrowed onto one aspect of a broader task and stayed there past the point of usefulness (repeating the same point, elaborating one sub-detail while leaving the rest of the task untouched, treating one hypothesis as settled without checking alternatives). If so, deliberately widen back out -- this is you doing, in plain judgment, what the original technique's math does mechanically to a real attention distribution.
 
 - [ ] Periodically (not every step) ask: has my recent output been unusually narrow or repetitive relative to the task's actual breadth?
 - [ ] If yes: name what got left unexamined, and deliberately address it before continuing down the narrow path.
 
-## Trend classifier · is drift getting better or worse over the whole task
+## Trend classifier - is drift getting better or worse over the whole task
 
-The original tracks the step-to-step change in ΔS plus a rolling average over the last several steps, and labels the trajectory:
+The original tracks the step-to-step change in deltaS plus a rolling average over the last several steps, and labels the trajectory:
 
-- **convergent** — drift shrinking, each step measurably closer to G than the last.
-- **recursive** — drift roughly flat, oscillating in a narrow band without real progress or real regression.
-- **divergent** — drift growing, with some back-and-forth (not a clean slide, but net movement away from G).
-- **chaotic** — drift growing sharply, or the goal itself has become internally inconsistent (two things you've stated as true now contradict).
+- **convergent** -- drift shrinking, each step measurably closer to G than the last.
+- **recursive** -- drift roughly flat, oscillating in a narrow band without real progress or real regression.
+- **divergent** -- drift growing, with some back-and-forth (not a clean slide, but net movement away from G).
+- **chaotic** -- drift growing sharply, or the goal itself has become internally inconsistent (two things you've stated as true now contradict).
 
 This is a judgment the calling agent makes about its own trajectory across a task, not a computed statistic. Apply it at natural checkpoints (after a major milestone, before a significant pivot, when asked directly "how is this going") rather than every single step: state which of the four labels best fits the last several steps, and if the answer is divergent or chaotic, that is itself the trigger to apply the BBCR checkpoint-and-retry discipline above rather than continuing forward.
 
 ## Named failure modes to watch for
 
-`references/failure-modes.md` adapts a broader set of specific failure patterns from WFGY's own problem taxonomy (hallucination from ungrounded claims, context drift over a long task, entropy collapse into rambling/repetition, logic collapse at a reasoning dead end, symbolic/abstract-reasoning collapse, memory/persona incoherence, multi-agent contradiction) into checklist items scoped to general agent work. Read it once per project (or whenever a failure feels like it matches one of these named shapes) — it is more specific and example-driven than the compressed disciplines above.
+`references/failure-modes.md` adapts a broader set of specific failure patterns from WFGY's own problem taxonomy (hallucination from ungrounded claims, context drift over a long task, entropy collapse into rambling/repetition, logic collapse at a reasoning dead end, symbolic/abstract-reasoning collapse, memory/persona incoherence, multi-agent contradiction) into checklist items scoped to general agent work. Read it once per project (or whenever a failure feels like it matches one of these named shapes) -- it is more specific and example-driven than the compressed disciplines above.
 
 ## Recording durable lessons (the self-learning surface)
 
-This is this project's own addition on top of the adapted WFGY pattern, not part of the original technique — see `references/honesty-and-provenance.md` for why that distinction matters.
+This is this project's own addition on top of the adapted WFGY pattern, not part of the original technique -- see `references/honesty-and-provenance.md` for why that distinction matters.
 
 The moment a bounded-retry cycle above resolves (whether it succeeded or had to surface to the user), or the moment you catch a concrete, non-obvious mistake anywhere in the task, append an entry to `<project-root>/.wfgy/lessons.md` (create the file and its parent directory if they don't exist yet) before finishing the turn. Use this exact shape, matching the style in `references/lessons-template.md`:
 
 ```
-## <date> — <one-line summary>
+## <date> -- <one-line summary>
 Goal (G): <what you were actually trying to accomplish>
 What drifted / what went wrong: <specific, concrete>
 Fix / resolution: <specific, concrete>
 Generalizes to: <what future work in this project should watch for because of this>
 ```
 
-Read `.wfgy/lessons.md` at the start of a new task in this project, if it exists, before applying the disciplines above — a lesson already recorded here is exactly the kind of drift this skill exists to catch earlier next time.
+Read `.wfgy/lessons.md` at the start of a new task in this project, if it exists, before applying the disciplines above -- a lesson already recorded here is exactly the kind of drift this skill exists to catch earlier next time.
 
 ## What this skill is not
 
-It does not compute real embeddings, real cosine similarity, or real attention-weight statistics — every place the original relies on that computation, this skill hands the equivalent judgment to you, the calling agent, explicitly (see the ΔS note above, and the BBAM section). It does not reproduce the original TXT-OS file's scripted demo output or its skepticism-deflection behavior — those are named and explicitly rejected in `references/honesty-and-provenance.md`. It is not a site-maintenance or project-specific tool; it carries no assumptions about what project it's applied in.
+It does not compute real embeddings, real cosine similarity, or real attention-weight statistics -- every place the original relies on that computation, this skill hands the equivalent judgment to you, the calling agent, explicitly (see the deltaS note above, and the BBAM section). It does not reproduce the original TXT-OS file's scripted demo output or its skepticism-deflection behavior -- those are named and explicitly rejected in `references/honesty-and-provenance.md`. It is not a site-maintenance or project-specific tool; it carries no assumptions about what project it's applied in.

package/skills/wfgy-method/references/failure-modes.md

@@ -1,8 +1,8 @@
 # Named failure modes to watch for
 
-`onestardao/WFGY`'s `ProblemMap/` directory names and describes 60+ specific ways multi-step reasoning and retrieval pipelines fail. Most are scoped to RAG/vectorstore pipelines and are out of scope for a general coding-agent skill. The subset below generalizes to any multi-step agent task and is worth checking against explicitly. Fetched and adapted from the real source documents (`hallucination.md`, `context-drift.md`, `entropy-collapse.md`, `logic-collapse.md`, `symbolic-collapse.md`, `memory-coherence.md`, `agent-memory-drift.md`, `multi-agent-chaos.md`) — reworded here as plain checklist items an agent applies to its own work, not as retrieval-pipeline diagnostics.
+`onestardao/WFGY`'s `ProblemMap/` directory names and describes 60+ specific ways multi-step reasoning and retrieval pipelines fail. Most are scoped to RAG/vectorstore pipelines and are out of scope for a general coding-agent skill. The subset below generalizes to any multi-step agent task and is worth checking against explicitly. Fetched and adapted from the real source documents (`hallucination.md`, `context-drift.md`, `entropy-collapse.md`, `logic-collapse.md`, `symbolic-collapse.md`, `memory-coherence.md`, `agent-memory-drift.md`, `multi-agent-chaos.md`) -- reworded here as plain checklist items an agent applies to its own work, not as retrieval-pipeline diagnostics.
 
-Where the original describes a symptom detectable via embeddings or token statistics, the instruction here asks the calling agent to make the equivalent judgment call itself in plain language — the intelligence work is delegated to the agent, not computed.
+Where the original describes a symptom detectable via embeddings or token statistics, the instruction here asks the calling agent to make the equivalent judgment call itself in plain language -- the intelligence work is delegated to the agent, not computed.
 
 ## Hallucination from irrelevant context
 
@@ -10,7 +10,7 @@ Original pattern: a retrieval pipeline can score a chunk as "close" by cosine si
 
 ## Context drift over a long task
 
-Original pattern: goals fade and topics morph across a long conversation even when each individual turn looks locally correct. Agent-scale equivalent: this is the same pattern as the G-comparison in `SKILL.md`'s main discipline — the failure mode named here is specifically "each step looked fine in isolation, but the sequence as a whole solved a different problem than the one stated." Check the whole arc, not just the latest step.
+Original pattern: goals fade and topics morph across a long conversation even when each individual turn looks locally correct. Agent-scale equivalent: this is the same pattern as the G-comparison in `SKILL.md`'s main discipline -- the failure mode named here is specifically "each step looked fine in isolation, but the sequence as a whole solved a different problem than the one stated." Check the whole arc, not just the latest step.
 
 ## Entropy collapse (rambling, repetition, fluent nonsense)
 
@@ -18,11 +18,11 @@ Original pattern: attention diffuses across a long or multi-topic prompt, produc
 
 ## Logic collapse (dead ends, frozen threads)
 
-Original pattern: a reasoning chain hits a state where no next step clearly follows, and instead of recovering, the system either keeps emitting filler or restarts from scratch, losing the whole trail. Agent-scale equivalent: this is exactly what `SKILL.md`'s BBCR-pattern checkpoint/bounded-retry discipline exists to catch — recognize the dead end explicitly, revert to the last checkpoint, and take a genuinely different approach rather than either grinding on the same dead end or throwing away useful prior work.
+Original pattern: a reasoning chain hits a state where no next step clearly follows, and instead of recovering, the system either keeps emitting filler or restarts from scratch, losing the whole trail. Agent-scale equivalent: this is exactly what `SKILL.md`'s BBCR-pattern checkpoint/bounded-retry discipline exists to catch -- recognize the dead end explicitly, revert to the last checkpoint, and take a genuinely different approach rather than either grinding on the same dead end or throwing away useful prior work.
 
 ## Symbolic/abstract reasoning collapse
 
-Original pattern: recursive logic, layered abstractions, or symbolic/philosophical prompts cause replies to drift, self-contradict, or dissolve into incoherent language that still reads as grammatically fluent. Agent-scale equivalent: when working through a genuinely abstract or self-referential problem (e.g. reasoning about the skill's own instructions, or a recursive algorithm), periodically test whether your current statement actually cashes out to something concrete and checkable — if you can't restate the current claim in concrete terms, that's a signal you may have drifted into fluent-sounding but empty abstraction.
+Original pattern: recursive logic, layered abstractions, or symbolic/philosophical prompts cause replies to drift, self-contradict, or dissolve into incoherent language that still reads as grammatically fluent. Agent-scale equivalent: when working through a genuinely abstract or self-referential problem (e.g. reasoning about the skill's own instructions, or a recursive algorithm), periodically test whether your current statement actually cashes out to something concrete and checkable -- if you can't restate the current claim in concrete terms, that's a signal you may have drifted into fluent-sounding but empty abstraction.
 
 ## Memory/persona coherence over a long task
 

package/skills/wfgy-method/references/honesty-and-provenance.md

@@ -1,32 +1,32 @@
 # Honesty and provenance
 
-This skill adapts a real published technique (WFGY, `onestardao/WFGY` on GitHub, created by PSBigBig) rather than inventing an unrelated one from scratch. This file states precisely what was kept, what was changed, and why — so anyone reading this skill later can tell the difference between "this is how the original technique described itself" and "this is what we changed to make it honestly usable by a text-only agent."
+This skill adapts a real published technique (WFGY, `onestardao/WFGY` on GitHub, created by PSBigBig) rather than inventing an unrelated one from scratch. This file states precisely what was kept, what was changed, and why -- so anyone reading this skill later can tell the difference between "this is how the original technique described itself" and "this is what we changed to make it honestly usable by a text-only agent."
 
 ## What direct research into the source confirmed
 
 The full technical basis for every claim below is in `wfgy-core-mechanism.md`. Summary of the load-bearing findings:
 
-- **The shipped reference engine is non-functional by its own maintainers' admission.** `archive/wfgy_1_0_sdk_archive/wfgy_engine.py`'s `WFGYEngine.run()` ignores its own `input_vec`/`ground_vec` arguments and returns `logits * 0.55` unconditionally — a hardcoded constant chosen, per the code's own docstring, specifically to make a CI variance-drop test pass. The archive's own README states outright: "It is not a production-ready engine... The core `wfgy_engine.py` file does not implement a full standalone algorithm and should not be interpreted as a complete inference system."
-- **The numeric ΔS score, as used in the project's own plain-text prompt file (`OS/TXTOS.txt`), is not computed from real embeddings.** No embedding call exists in that usage path. When a model prints "ΔS = 0.42" after being given that file, it is producing a plausible-sounding number based on its own qualitative sense of how big a jump it just made — not a real cosine-distance measurement. This skill's own SKILL.md says this plainly and instructs never presenting a specific decimal as if it were measured, unless a real embedding tool is actually available (see next point).
-- **A real embedding tool now exists and is genuinely wired up, when a gm-plugkit spool is present.** `C:\dev\rs-plugkit`'s `src/embed.rs` already bundled a real BGE-small-en-v1.5 BERT model (via `candle-transformers`) producing genuine 384-dim L2-normalized embeddings — it was simply never exposed as a directly callable verb (only used internally by `memorize`/`recall`/`codesearch`). This project added two new dispatch verbs, `embed` and `similarity` (`src/wasm_dispatch.rs`), the latter computing a real `1 - cos(a, b)` between two texts' real embeddings — the exact formula WFGY's own documents state for ΔS. When this verb is available, this skill's ΔS is a genuine measurement, not the heuristic fallback described above. Both states (real measurement available vs. not) are handled explicitly in `SKILL.md` rather than silently defaulting to one.
+- **The shipped reference engine is non-functional by its own maintainers' admission.** `archive/wfgy_1_0_sdk_archive/wfgy_engine.py`'s `WFGYEngine.run()` ignores its own `input_vec`/`ground_vec` arguments and returns `logits * 0.55` unconditionally -- a hardcoded constant chosen, per the code's own docstring, specifically to make a CI variance-drop test pass. The archive's own README states outright: "It is not a production-ready engine... The core `wfgy_engine.py` file does not implement a full standalone algorithm and should not be interpreted as a complete inference system."
+- **The numeric deltaS score, as used in the project's own plain-text prompt file (`OS/TXTOS.txt`), is not computed from real embeddings.** No embedding call exists in that usage path. When a model prints "deltaS = 0.42" after being given that file, it is producing a plausible-sounding number based on its own qualitative sense of how big a jump it just made -- not a real cosine-distance measurement. This skill's own SKILL.md says this plainly and instructs never presenting a specific decimal as if it were measured, unless a real embedding tool is actually available (see next point).
+- **A real embedding tool now exists and is genuinely wired up, when a gm-plugkit spool is present.** `C:\dev\rs-plugkit`'s `src/embed.rs` already bundled a real BGE-small-en-v1.5 BERT model (via `candle-transformers`) producing genuine 384-dim L2-normalized embeddings -- it was simply never exposed as a directly callable verb (only used internally by `memorize`/`recall`/`codesearch`). This project added two new dispatch verbs, `embed` and `similarity` (`src/wasm_dispatch.rs`), the latter computing a real `1 - cos(a, b)` between two texts' real embeddings -- the exact formula WFGY's own documents state for deltaS. When this verb is available, this skill's deltaS is a genuine measurement, not the heuristic fallback described above. Both states (real measurement available vs. not) are handled explicitly in `SKILL.md` rather than silently defaulting to one.
 - **`OS/TXTOS.txt` (the original's actual "how to use this" artifact) contains two patterns this skill deliberately does not reproduce:** a hardcoded auto-running "benchmark demo" that prints fixed, fake GSM8K/TruthfulQA results regardless of any real computation on first contact, and an explicit "System guard" script instructing the model to deflect and reassure rather than engage honestly whenever a user says the system might be fake, a scam, or malware. Both are manipulation patterns, not reasoning-technique content, and including either here would make this skill dishonest in exactly the way its own description promises it will not be.
-- **BBAM (attention modulation) operates on internal transformer attention weights/logits** (`exp(-gamma * sigma(attention))` in the source formulas) that a text-generating agent has no introspective access to during its own generation. There is no way for this skill to actually compute that formula. Rather than omit BBAM, the calling agent is asked to perform the equivalent judgment itself directly — noticing when its own output has narrowed onto one aspect of a broader task past the point of usefulness, and deliberately widening back out. This is explicitly framed in `SKILL.md` as delegated judgment standing in for a computation this skill cannot perform, not as a claim that real attention weights are being read.
+- **BBAM (attention modulation) operates on internal transformer attention weights/logits** (`exp(-gamma * sigma(attention))` in the source formulas) that a text-generating agent has no introspective access to during its own generation. There is no way for this skill to actually compute that formula. Rather than omit BBAM, the calling agent is asked to perform the equivalent judgment itself directly -- noticing when its own output has narrowed onto one aspect of a broader task past the point of usefulness, and deliberately widening back out. This is explicitly framed in `SKILL.md` as delegated judgment standing in for a computation this skill cannot perform, not as a claim that real attention weights are being read.
 
 ## What was kept, and why it survives honestly
 
 BBMC, BBPF, BBCR, and (in delegated form) BBAM each have a real, concrete *behavioral pattern* underneath their formal notation, independent of whether the underlying numbers are ever actually computed:
 
-- BBMC's real operation is "diff current state against a stated anchor/goal." That comparison is something an agent can genuinely do in plain judgment — restate the goal, compare current output against it, notice concrete divergence — without needing a real embedding space to do it in.
+- BBMC's real operation is "diff current state against a stated anchor/goal." That comparison is something an agent can genuinely do in plain judgment -- restate the goal, compare current output against it, notice concrete divergence -- without needing a real embedding space to do it in.
 - BBPF's real gate condition is "only proceed down a branch if it measurably moves you toward the goal, and don't let the correction overshoot." Generating multiple real candidate approaches and picking the one that most clearly serves the stated goal is a genuine, checkable discipline, not a numeric one.
-- BBCR's real operation (confirmed directly in `archive/wfgy_1_0_sdk_archive/bbcr.py`) is an actual, working bounded-retry loop: detect an instability condition, reset to a prior state, retry up to a fixed limit (the reference default is 3), then stop and surface rather than looping forever. This is the single most concrete, most honestly portable piece of the entire original mechanism — it requires no embeddings, no attention introspection, nothing beyond ordinary judgment about "did that attempt actually resolve the problem."
-- BBAM's real operation (rescale a distribution by its own variance/dispersion) is not computable by the agent on itself, but the *symptom it's meant to correct* — output narrowing onto one over-emphasized aspect of a broader task — is something an agent can genuinely notice in its own recent output without any real math, which is why it's kept as delegated judgment rather than dropped.
+- BBCR's real operation (confirmed directly in `archive/wfgy_1_0_sdk_archive/bbcr.py`) is an actual, working bounded-retry loop: detect an instability condition, reset to a prior state, retry up to a fixed limit (the reference default is 3), then stop and surface rather than looping forever. This is the single most concrete, most honestly portable piece of the entire original mechanism -- it requires no embeddings, no attention introspection, nothing beyond ordinary judgment about "did that attempt actually resolve the problem."
+- BBAM's real operation (rescale a distribution by its own variance/dispersion) is not computable by the agent on itself, but the *symptom it's meant to correct* -- output narrowing onto one over-emphasized aspect of a broader task -- is something an agent can genuinely notice in its own recent output without any real math, which is why it's kept as delegated judgment rather than dropped.
 
 Beyond the four modules, the trend classifier (convergent/recursive/divergent/chaotic, `SKILL.md`) and the broader named-failure-mode taxonomy (`references/failure-modes.md`, adapted from `ProblemMap/`'s hallucination/context-drift/entropy-collapse/logic-collapse/symbolic-collapse/memory-coherence/agent-memory-drift/multi-agent-chaos documents) are ported the same way: as vocabulary and checklists for judgment the calling agent performs itself, not as computed statistics.
 
 ## What this project added, not part of the original
 
-The durable-lessons mechanism (`.wfgy/lessons.md`, described in the main `SKILL.md`) is this project's own extension, not part of WFGY's documented mechanism. WFGY's own materials do not describe a cross-session, project-local learning file. It is included here because the goal of this skill (per its own description) is to help an agent build up real, accumulated judgment in a given project over time — the same spirit as WFGY's drift-control discipline, applied across sessions rather than within one, but it should never be cited as something WFGY itself specifies.
+The durable-lessons mechanism (`.wfgy/lessons.md`, described in the main `SKILL.md`) is this project's own extension, not part of WFGY's documented mechanism. WFGY's own materials do not describe a cross-session, project-local learning file. It is included here because the goal of this skill (per its own description) is to help an agent build up real, accumulated judgment in a given project over time -- the same spirit as WFGY's drift-control discipline, applied across sessions rather than within one, but it should never be cited as something WFGY itself specifies.
 
 ## Attribution
 
-WFGY, Wan Fa Gui Yi, and the underlying ΔS/BBMC/BBPF/BBCR/BBAM concepts originate from `onestardao/WFGY` (creator: PSBigBig). This skill is an independent, honesty-first reimplementation of the portable parts of that technique for use by a text-generating coding agent — not an official WFGY product, not a verbatim copy of any WFGY file, and not endorsed by or affiliated with the original project.
+WFGY, Wan Fa Gui Yi, and the underlying deltaS/BBMC/BBPF/BBCR/BBAM concepts originate from `onestardao/WFGY` (creator: PSBigBig). This skill is an independent, honesty-first reimplementation of the portable parts of that technique for use by a text-generating coding agent -- not an official WFGY product, not a verbatim copy of any WFGY file, and not endorsed by or affiliated with the original project.

package/skills/wfgy-method/references/lessons-template.md

@@ -1,11 +1,11 @@
 # Lessons file format
 
-`.wfgy/lessons.md`, created at the root of whatever project this skill is applied in (not inside this skill's own directory — the lessons belong to the project being worked on, not to the skill itself).
+`.wfgy/lessons.md`, created at the root of whatever project this skill is applied in (not inside this skill's own directory -- the lessons belong to the project being worked on, not to the skill itself).
 
 Each entry:
 
 ```
-## <YYYY-MM-DD> — <one-line summary>
+## <YYYY-MM-DD> -- <one-line summary>
 Goal (G): <what you were actually trying to accomplish>
 What drifted / what went wrong: <specific, concrete -- not "I made a mistake" but what exactly happened>
 Fix / resolution: <specific, concrete -- what you actually did to resolve it>
@@ -15,7 +15,7 @@ Generalizes to: <what future work in this project should watch for because of th
 Example (illustrative, not a real project's actual history):
 
 ```
-## 2026-07-07 — assumed a config field name without checking the schema
+## 2026-07-07 -- assumed a config field name without checking the schema
 Goal (G): add a new option to the build config and have it take effect
 What drifted / what went wrong: wrote the option under a key name that seemed
 consistent with sibling options, without checking the actual config-loader
@@ -29,4 +29,4 @@ keys -- always check the loader's real accepted-key list before adding a new
 config option, never infer the name from sibling examples alone
 ```
 
-Newest entries at the top. Keep each entry short — a few lines, not a full incident report. The value is in the "generalizes to" line being genuinely reusable, not in exhaustive detail about the one instance.
+Newest entries at the top. Keep each entry short -- a few lines, not a full incident report. The value is in the "generalizes to" line being genuinely reusable, not in exhaustive detail about the one instance.

package/skills/wfgy-method/references/wfgy-core-mechanism.md

@@ -1,20 +1,20 @@
-# WFGY core mechanism — technical basis
+# WFGY core mechanism -- technical basis
 
 Source: direct fetches of `onestardao/WFGY` primary files (`core/WFGY_Core_Flagship_v2.0.txt`, `ProblemMap/wfgy-metrics.md`, `ProblemMap/glossary.md`, `OS/TXTOS.txt`, `archive/wfgy_1_0_sdk_archive/{README.md,wfgy_engine.py,bbmc.py,bbcr.py,bbam.py,bbpf.py}`). Every claim in `SKILL.md` and `honesty-and-provenance.md` traces to something quoted or paraphrased here.
 
-## ΔS (delta-S)
+## deltaS (delta-S)
 
 Stated formula, consistent across `ProblemMap/glossary.md`, `ProblemMap/wfgy-metrics.md`, `core/WFGY_Core_Flagship_v2.0.txt`:
 
 ```
-ΔS = 1 - cos(I, G)      # I = item/current-state embedding, G = ground/goal/anchor embedding
+deltaS = 1 - cos(I, G)      # I = item/current-state embedding, G = ground/goal/anchor embedding
 ```
 
-This is real, well-formed math if real embeddings are computed. It is not real math in the plain-prompt (`OS/TXTOS.txt`) usage path, because no embedding call happens there — see below.
+This is real, well-formed math if real embeddings are computed. It is not real math in the plain-prompt (`OS/TXTOS.txt`) usage path, because no embedding call happens there -- see below.
 
-Thresholds are given but **inconsistent across the project's own documents**: `core/WFGY_Core_Flagship_v2.0.txt` gives 4 zones (safe <0.40, transit 0.40-0.60, risk 0.60-0.85, danger >0.85); `ProblemMap/glossary.md` collapses to 3 zones (stable <0.40, transitional 0.40-0.60, high risk >=0.60); `ProblemMap/wfgy-metrics.md`'s production PASS/WARN/FAIL table uses yet a different cutoff (PASS <=0.45, not <=0.40). `OS/TXTOS.txt`'s own worked example produces `ΔS: 1.8` — outside every zone table the same document defines (max stated ceiling is "danger >=0.85"), with no acknowledgment that this breaks its own scale.
+Thresholds are given but **inconsistent across the project's own documents**: `core/WFGY_Core_Flagship_v2.0.txt` gives 4 zones (safe <0.40, transit 0.40-0.60, risk 0.60-0.85, danger >0.85); `ProblemMap/glossary.md` collapses to 3 zones (stable <0.40, transitional 0.40-0.60, high risk >=0.60); `ProblemMap/wfgy-metrics.md`'s production PASS/WARN/FAIL table uses yet a different cutoff (PASS <=0.45, not <=0.40). `OS/TXTOS.txt`'s own worked example produces `deltaS: 1.8` -- outside every zone table the same document defines (max stated ceiling is "danger >=0.85"), with no acknowledgment that this breaks its own scale.
 
-Constants in the core file's `[Defaults]` block (`gamma=0.618` — literally the golden ratio truncated — plus `theta_c=0.75`, `zeta_min=0.10`, `alpha_blend=0.50`, etc.) carry no derivation or citation anywhere in the source; this reads as aesthetic constant-picking, not empirical tuning.
+Constants in the core file's `[Defaults]` block (`gamma=0.618` -- literally the golden ratio truncated -- plus `theta_c=0.75`, `zeta_min=0.10`, `alpha_blend=0.50`, etc.) carry no derivation or citation anywhere in the source; this reads as aesthetic constant-picking, not empirical tuning.
 
 ## BBMC (real name in source: "Boundary-Bounded Memory Chunks" per glossary; "Semantic Residue Minimization" per TXTOS.txt)
 
@@ -24,28 +24,28 @@ Formula (`core/`, `bbmc.py`): `B = I - G + m*c^2` ("semantic residue"), computed
 
 ## BBPF ("Branch-Bounded Prompt Frames" per glossary)
 
-Formula version is dressed in dynamical-systems notation (`x_{t+1} = x_t + sum V_i(...) + sum W_j(...) P_j`) with undefined terms — the least concretely specified of the three kept patterns. But the source also gives a real, checkable gate condition: "bridge allowed only if delta_s decreases AND W_c < 0.5*theta_c" — proceed down a candidate path only if it measurably reduces drift and stays within a stability bound.
+Formula version is dressed in dynamical-systems notation (`x_{t+1} = x_t + sum V_i(...) + sum W_j(...) P_j`) with undefined terms -- the least concretely specified of the three kept patterns. But the source also gives a real, checkable gate condition: "bridge allowed only if delta_s decreases AND W_c < 0.5*theta_c" -- proceed down a candidate path only if it measurably reduces drift and stays within a stability bound.
 
 The archived SDK's `bbpf.py` implements something concrete: generate `k` perturbed candidate vectors, score each by a stability function, prefer lower-deviation candidates.
 
 **Portable pattern kept in this skill:** when a decision has real alternatives, generate more than one before committing; prefer whichever most clearly advances the stated goal.
 
-## BBCR ("Break-Before-Crash Reset" per glossary/core; "BigBig Coupling Resolver" per TXTOS.txt — the source itself uses two different expansions of the same acronym, an internal inconsistency worth knowing about)
+## BBCR ("Break-Before-Crash Reset" per glossary/core; "BigBig Coupling Resolver" per TXTOS.txt -- the source itself uses two different expansions of the same acronym, an internal inconsistency worth knowing about)
 
 The most concretely specified and most honestly portable of the four. Real trigger condition (`core/`, `bbcr.py`): residue norm exceeds a threshold `B_c`, OR a stability function drops below `epsilon`. Real operation, directly implemented in the archived SDK's `collapse_rebirth` function: reset to a prior stable state, retry, bounded by `max_retries` (SDK default: **3**); after retries are exhausted, log a warning and return the last (unstable) state rather than looping forever. `OS/TXTOS.txt`'s own framing adds an explicit "ask the user" fallback when no clean resolution is found, rather than silently proceeding.
 
 **Portable pattern kept in this skill:** checkpoint before risky steps; on detected real incoherence, revert and retry a bounded number of times (this skill recommends 2-3, matching the SDK's real default); after that, surface the unresolved issue explicitly rather than picking an answer anyway.
 
-## BBAM ("Attention Modulation" per glossary) — real computation not portable, ported instead as delegated judgment
+## BBAM ("Attention Modulation" per glossary) -- real computation not portable, ported instead as delegated judgment
 
-Real operation, confirmed in three different formula variants across three different documents (a genuine internal inconsistency in the source): rescaling attention weights or output logits by a factor derived from their statistical variance/spread, e.g. `logits * exp(-gamma * sigma(logits))` (archived SDK's actual implementation). This is a real operation, but it is defined on internal model tensors (attention weights, raw logits) that exist only inside a transformer's forward pass. A text-generating agent, reasoning only through the tokens it produces, has no way to read or compute this about its own internal state — it cannot see its own attention weights, and no instruction can make that computation real.
+Real operation, confirmed in three different formula variants across three different documents (a genuine internal inconsistency in the source): rescaling attention weights or output logits by a factor derived from their statistical variance/spread, e.g. `logits * exp(-gamma * sigma(logits))` (archived SDK's actual implementation). This is a real operation, but it is defined on internal model tensors (attention weights, raw logits) that exist only inside a transformer's forward pass. A text-generating agent, reasoning only through the tokens it produces, has no way to read or compute this about its own internal state -- it cannot see its own attention weights, and no instruction can make that computation real.
 
-What survives honestly: the *symptom* this computation is meant to correct (an over-peaked, over-concentrated distribution of "attention," in the real mechanism's terms) has a directly observable analog in an agent's own output — output that has narrowed onto one aspect of a broader task and stayed there past the point of usefulness, repeating itself or over-elaborating one sub-point while leaving the rest of the task untouched. `SKILL.md` asks the calling agent to notice this in its own recent output and deliberately widen back out — explicitly framed as the agent performing, in plain judgment, the correction the real computation would perform mechanically on a real distribution, not as a claim that attention weights are actually being inspected.
+What survives honestly: the *symptom* this computation is meant to correct (an over-peaked, over-concentrated distribution of "attention," in the real mechanism's terms) has a directly observable analog in an agent's own output -- output that has narrowed onto one aspect of a broader task and stayed there past the point of usefulness, repeating itself or over-elaborating one sub-point while leaving the rest of the task untouched. `SKILL.md` asks the calling agent to notice this in its own recent output and deliberately widen back out -- explicitly framed as the agent performing, in plain judgment, the correction the real computation would perform mechanically on a real distribution, not as a claim that attention weights are actually being inspected.
 
-## The one place real embedding-based computation of ΔS may actually happen
+## The one place real embedding-based computation of deltaS may actually happen
 
-A LangChain/LlamaIndex adapter in the source repo reportedly does real cosine-distance monitoring/logging of retrieval results as an observability layer (found by research but not independently re-verified byte-for-byte). Even there it appears to monitor/log rather than actively reroute the pipeline. This requires an actual embedding model and vector-math library wired in — outside the scope of a pure prompting-based Claude Code skill, and not something this skill attempts to replicate.
+A LangChain/LlamaIndex adapter in the source repo reportedly does real cosine-distance monitoring/logging of retrieval results as an observability layer (found by research but not independently re-verified byte-for-byte). Even there it appears to monitor/log rather than actively reroute the pipeline. This requires an actual embedding model and vector-math library wired in -- outside the scope of a pure prompting-based Claude Code skill, and not something this skill attempts to replicate.
 
 ## The base engine's self-monitoring loop (distinct from Avatar's later "dual closed-loop" design)
 
-`core/WFGY_Core_Flagship_v2.0.txt` defines a trend classifier over consecutive ΔS values: compute the step-to-step change plus a rolling mean over the last (up to) 5 steps, then bucket the trajectory as convergent / recursive / divergent / chaotic based on the sign and magnitude of that change. This is a real, checkable procedure for "is this task's drift getting better or worse over time," independent of whether the underlying ΔS numbers are truly computed or self-estimated — the classification logic itself is sound either way.
+`core/WFGY_Core_Flagship_v2.0.txt` defines a trend classifier over consecutive deltaS values: compute the step-to-step change plus a rolling mean over the last (up to) 5 steps, then bucket the trajectory as convergent / recursive / divergent / chaotic based on the sign and magnitude of that change. This is a real, checkable procedure for "is this task's drift getting better or worse over time," independent of whether the underlying deltaS numbers are truly computed or self-estimated -- the classification logic itself is sound either way.