@lmzhen/dsh-evolution-core 0.3.68 → 0.3.70

package/lib/index.js

@@ -511,7 +511,7 @@ function nodeEvolutionIo(lockAttempts = 40) {
 					const holder = Number(body.split(":")[0] ?? "");
 					const st = await stat(ticketPath);
 					const dead = !Number.isInteger(holder) || holder <= 0 || !isAlive(holder);
-					const old = Date.now() - st.mtimeMs > 1e3;
+					const old = Date.now() - st.mtimeMs > TICKET_STALE_MS;
 					if (dead || old) await rm(ticketPath, { force: true });
 				} catch {}
 				continue;
@@ -673,6 +673,7 @@ function normalizeUsageRecord(record) {
 	const num = (value, fallback) => typeof value === "number" && Number.isFinite(value) && value >= 0 ? value : fallback;
 	const bool = (value, fallback) => typeof value === "boolean" ? value : fallback;
 	return {
+		...raw,
 		created_by: typeof raw.created_by === "string" ? raw.created_by : null,
 		use_count: num(raw.use_count, base.use_count),
 		view_count: num(raw.view_count, base.view_count),
@@ -1044,6 +1045,10 @@ const MAX_TIMER_DELAY_MS = 2147483647;
 const DEFAULT_MEMORY_REVIEW_MODEL = "deepseek-v4-flash";
 const DEFAULT_SKILL_REVIEW_MODEL = "deepseek-v4-pro";
 const DEFAULT_CURATOR_MODEL = "deepseek-v4-pro";
+/** Order of the `evolution:memory-guidance` section (before the skills one). */
+const MEMORY_GUIDANCE_SECTION_ORDER = 11e3;
+/** Order of the `evolution-skills-guidance` section (last of the two). */
+const SKILLS_GUIDANCE_SECTION_ORDER = 11100;
 //#endregion
 //#region lib/types/gates.js
 /**
@@ -1528,9 +1533,28 @@ async function rotateIfDue(io, path, events, rotateAt) {
 	if (tail.length === 0) return events;
 	const anchor = tail[0]?.seq ?? 0;
 	const archivePath = join(dirname(path), `${EVENT_ARCHIVE_PREFIX}${anchor - 1}.json`);
+	let archived = head;
+	const existing = await io.readText(archivePath).catch(() => null);
+	if (existing !== null) try {
+		const parsed = JSON.parse(existing);
+		const usablePrior = (Array.isArray(parsed.events) ? parsed.events : []).filter(isEventRecord);
+		const bySeq = new Map(usablePrior.map((event) => [event.seq, event]));
+		for (const event of head) bySeq.set(event.seq, event);
+		archived = [...bySeq.values()].sort((a, b) => a.seq - b.seq);
+	} catch {
+		const shiftPath = `${archivePath}.${Date.now()}.collide`;
+		await io.writeText(shiftPath, JSON.stringify({
+			version: 1,
+			events: head
+		}, null, 2));
+		console.warn(`evolution-events: rotation hit an unparsable archive collision — the rotated head band was preserved at ${shiftPath} but is OUTSIDE the logical timeline; inspect and merge it manually`);
+		await retainEventArchives(io, path);
+		await pruneCollideArchives(io, path);
+		return tail;
+	}
 	await io.writeText(archivePath, JSON.stringify({
 		version: 1,
-		events: head
+		events: archived
 	}, null, 2));
 	await retainEventArchives(io, path);
 	return tail;
@@ -1548,6 +1572,34 @@ async function retainEventArchives(io, path) {
 	const excess = names.slice(0, Math.max(0, names.length - 10));
 	for (const name of excess) await io.remove(join(dir, name)).catch(() => {});
 }
+/** v31 EVENTS-02: prune shift-aside collision files (`events-*.json.<ts>.collide`)
+* after the same 7-day window the `.corrupt` sweep uses. They are write-once
+* recovery artifacts no reader accepts; without a sweep they accumulated
+* without bound across rollback episodes. No mtime probe → keep (fail-safe). */
+const COLLIDE_AGE_MS = 10080 * 60 * 1e3;
+async function pruneCollideArchives(io, path) {
+	const dir = dirname(path);
+	let names;
+	try {
+		names = await io.list(dir);
+	} catch {
+		return;
+	}
+	const now = Date.now();
+	for (const name of names) {
+		if (!name.endsWith(".collide") || !name.startsWith("events-")) continue;
+		const full = join(dir, name);
+		const stamp = name.match(/\.(\d{13})\.collide$/);
+		if (stamp && now - Number(stamp[1]) < COLLIDE_AGE_MS) continue;
+		if (!stamp) try {
+			const mtime = await io.mtime?.(full);
+			if (typeof mtime === "number" && now - mtime < COLLIDE_AGE_MS) continue;
+		} catch {
+			continue;
+		}
+		await io.remove(full).catch(() => {});
+	}
+}
 /** Read the event log; a missing/whitespace-only file reads as empty,
 * corrupt content is flagged (and refused on append). A well-formed future-
 * version body is v1-incompatible and reads as empty, NOT malformed (F-338:
@@ -1654,16 +1706,21 @@ function allowRowCollisions(env = process.env) {
 * platform's index cap), and DSH-only additions are marked as such.
 *
 * Every prompt is pinned in a versioned bundle. Review workers verify the
-* bundle digest before spending a model call, so a partially-patched
-* deployment fails closed instead of silently running a truncated prompt.
+* bundle digest before spending a model call — v31 PROMPT-01, stated
+* precisely: THAT check proves internal coherence (id/version/digest agree)
+* for a bundle assembled OUT of process and handed to `verifyPromptBundle`
+* explicitly. It CANNOT detect in-process tampering (the digest is recomputed
+* from the same module state it verifies) — catching a stale or partially
+* patched default bundle is CI's version pin (tests/prompts.spec.ts), not
+* this runtime gate.
 */
 /**
 * Prompt bundle identity. Bump both id and version whenever a prompt's text
 * changes semantically: the bundle digest is the fail-closed signal for
 * review workers, so a stale id across deployments must be distinguishable.
 */
-const PROMPT_BUNDLE_VERSION = 16;
-const PROMPT_BUNDLE_ID = `dsh-evolution@16`;
+const PROMPT_BUNDLE_VERSION = 17;
+const PROMPT_BUNDLE_ID = `dsh-evolution@17`;
 const MEMORY_REVIEW_PROMPT = `[Auto-review — Memory]
 Review the conversation above and consider saving to memory if appropriate.
 
@@ -1684,7 +1741,7 @@ Signals to look for (any one of these warrants action):
   • Non-trivial technique, fix, workaround, debugging path, or tool-usage pattern emerged that a future session would benefit from. Capture it.
   • A skill that got loaded or consulted this session turned out to be wrong, missing a step, or outdated. Patch it NOW.
 
-Read-before-write (enforced by this channel): update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session — ops on unread skills are dropped; CREATE of a brand-new umbrella is the only exception.
+Read-before-write: update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session. On the plan channel ops on unread skills are rejected; direct writes have no such guard, so treat the rule as binding. CREATE of a brand-new umbrella is the only exception.
 
 Preference order — prefer the earliest action that fits, but do pick one when a signal above fired:
   1. UPDATE A CURRENTLY-LOADED SKILL. Look back through the conversation for skills the user loaded or you read. If any of them covers the territory of the new learning, PATCH that one first. It is the skill that was in play, so it's the right one to extend.
@@ -1734,7 +1791,7 @@ Signals that warrant a skill update (any one is enough):
   • Non-trivial technique, fix, workaround, or debugging path emerged.
   • A skill that was loaded or consulted turned out wrong, missing, or outdated — patch it now.
 
-Read-before-write (enforced by this channel): update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session — ops on unread skills are dropped; CREATE of a brand-new umbrella is the only exception.
+Read-before-write: update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session. On the plan channel ops on unread skills are rejected; direct writes have no such guard, so treat the rule as binding. CREATE of a brand-new umbrella is the only exception.
 
 Preference order for skills — pick the earliest that fits:
   1. UPDATE A CURRENTLY-LOADED SKILL. Check what skills were loaded or read in the conversation. If one of them covers the learning, PATCH it first. It was in play; it's the right place.
@@ -1950,12 +2007,12 @@ function sha256(text) {
 function createPromptBundle(prompts) {
 	const canonical = JSON.stringify({
 		id: PROMPT_BUNDLE_ID,
-		version: 16,
+		version: 17,
 		prompts: Object.fromEntries(Object.entries(prompts).sort())
 	});
 	return Object.freeze({
 		id: PROMPT_BUNDLE_ID,
-		version: 16,
+		version: 17,
 		prompts: Object.freeze({ ...prompts }),
 		sha256: sha256(canonical)
 	});
@@ -1973,10 +2030,10 @@ const PROMPT_BUNDLE = createPromptBundle({
 	skillsGuidance: SKILLS_GUIDANCE
 });
 function verifyPromptBundle(bundle = PROMPT_BUNDLE) {
-	if (bundle.id !== PROMPT_BUNDLE_ID || bundle.version !== 16) return false;
+	if (bundle.id !== PROMPT_BUNDLE_ID || bundle.version !== 17) return false;
 	const canonical = JSON.stringify({
 		id: PROMPT_BUNDLE_ID,
-		version: 16,
+		version: 17,
 		prompts: Object.fromEntries(Object.entries(bundle.prompts).sort())
 	});
 	return bundle.sha256 === sha256(canonical);
@@ -2691,11 +2748,30 @@ var MemoryStore = class {
 	*
 	* @param target - memory target being written
 	* @param core - the in-transaction read-modify-write for the locked body
+	* @param shrinkOnly - v29 MEM-02: every queued operation REMOVES an entry
+	*   (the recovery path for a limit lowered under existing content). The
+	*   oversized read-guard is skipped for these batches: a canonical file
+	*   written under a ≥10× higher limit trips the `limit × 10` byte bound, and
+	*   the guard's "fix the file manually" refusal would pre-empt exactly the
+	*   shrink recovery MEM-01 advertises. The load is bounded by what the store
+	*   itself wrote under the old limit.
 	* @returns the core's result, or the oversized / contract-violation refusal
 	*/
-	async chainedWrite(target, core) {
-		const refusal = await this.oversizedRefusal(target);
-		if (refusal) return refusal;
+	async chainedWrite(target, core, shrinkOnly = false) {
+		const SHRINK_LOAD_CEILING = 64 * 1024 * 1024;
+		if (!shrinkOnly) {
+			const refusal = await this.oversizedRefusal(target);
+			if (refusal) return refusal;
+		} else {
+			const size = await this.io.size?.(fileFor(this.root, target));
+			if (typeof size === "number" && size > SHRINK_LOAD_CEILING) return {
+				ok: false,
+				message: `Memory file is ${size} bytes - too large to load even for a remove-only batch. Fix the file manually, then retry.`,
+				entries: [],
+				chars: 0,
+				limit: this.limitFor(target)
+			};
+		}
 		let outcome;
 		await transactIo(this.io, fileFor(this.root, target), async (current) => {
 			const step = await core(current ?? "");
@@ -2801,7 +2877,7 @@ var MemoryStore = class {
 		};
 	}
 	/**
-	* The single drift predicate. `raw` is in canonical form when it byte-matches
+	* The single drift evaluation. `raw` is in canonical form when it byte-matches
 	* `render(normalizeEntries(raw))`; anything else means it was edited outside
 	* MemoryStore (empty/`§`-only entries, stray blank lines, leading or trailing
 	* delimiters — structural anomalies the writer would quietly normalize away).
@@ -2815,28 +2891,69 @@ var MemoryStore = class {
 	* every write path — including the repairs the model would need to make.
 	* Such files are adopted instead of flagged.
 	*
+	* Returns one of:
+	* - `'external'` — non-canonical body, i.e. real external modification. This
+	*   includes the Hermes-parity signal #2 (an entry larger than the whole-file
+	*   limit): that shape is only meaningful as external evidence on a
+	*   NON-canonical body, because free-form external appends never render
+	*   canonically.
+	* - `'over-limit'` — v28 MEM-01: a CANONICAL body whose entries exceed the
+	*   CURRENT configured limit. Those bytes were written by this store under a
+	*   previous (higher) limit, so they are not external drift; treating them as
+	*   such misattributed a config change to an "external editor" and bricked
+	*   every write path (the advertised recovery — remove/consolidate — is
+	*   exactly what the drift gate refused). Callers route this state to a
+	*   config-naming refusal and let shrink-only batches through.
+	* - `null` — no drift: writable as-is.
+	*
 	* @param target - memory target whose char limit bounds one parsed entry
 	* @param raw - on-disk body, or `null` when the file does not exist
-	* @returns whether these bytes count as externally drifted
 	*/
-	drifted(target, raw) {
-		if (raw === null || raw.trim() === "") return false;
+	driftKind(target, raw) {
+		if (raw === null || raw.trim() === "") return null;
 		const entries = normalizeEntries(raw);
+		if (render(entries) !== raw) return "external";
 		const limit = this.limitFor(target);
-		if (limit > 0 && entries.some((entry) => entry.length > limit)) return true;
-		return render(entries) !== raw;
+		if (limit > 0 && entries.some((entry) => entry.length > limit)) return "over-limit";
+		return null;
+	}
+	/** External-drift predicate: canonical-form violations only (see
+	* {@link driftKind}). `detectDrift` and the write paths share it, so a write
+	* and a later read never disagree about the same bytes. */
+	drifted(target, raw) {
+		return this.driftKind(target, raw) === "external";
 	}
 	/**
 	* Drift refusal for a body already read under the write lock, or `null` when
-	* the body is canonical. Both write paths return this unchanged, so their
+	* writing may proceed. Both write paths return this unchanged, so their
 	* refusals stay byte-identical and each carries the same backup.
 	*
+	* The `'over-limit'` state never refuses shrink-only batches (`shrinkOnly`):
+	* removing entries is the advertised recovery for a limit lowered under
+	* existing content, and the batch's own final limit check still gates the
+	* result.
+	*
 	* @param target - memory target that owns the drifted file
 	* @param raw - locked file body
+	* @param shrinkOnly - every queued operation removes an entry (no growth)
 	* @returns the refusal to hand back, or `null` to continue writing
 	*/
-	async driftRefusal(target, raw) {
-		if (!this.drifted(target, raw)) return null;
+	async driftRefusal(target, raw, shrinkOnly = false) {
+		const kind = this.driftKind(target, raw);
+		if (kind === null) return null;
+		if (kind === "over-limit") {
+			if (shrinkOnly) return null;
+			const limit = this.limitFor(target);
+			const entries = normalizeEntries(raw);
+			const over = entries.filter((entry) => entry.length > limit).length;
+			return {
+				ok: false,
+				message: `${over} memory ${over === 1 ? "entry exceeds" : "entries exceed"} the configured ${target}CharLimit (${limit}); they were written under a higher limit. Raise the limit or remove entries — remove operations stay available.`,
+				entries,
+				chars: entries.join(ENTRY_DELIMITER).length,
+				limit
+			};
+		}
 		const backup = await this.backupFile(target);
 		return {
 			ok: false,
@@ -2857,11 +2974,12 @@ var MemoryStore = class {
 			chars: 0,
 			limit: this.limitFor(target)
 		};
-		return await this.chainedWrite(target, async (raw) => await this.applyBatchCore(target, operations, raw));
+		const shrinkOnly = operations.every((op) => op.action === "remove");
+		return await this.chainedWrite(target, async (raw) => await this.applyBatchCore(target, operations, raw, shrinkOnly), shrinkOnly);
 	}
 	/** Batch RMW inside the transaction. `write: null` = failure/no-op, disk untouched. */
-	async applyBatchCore(target, operations, raw) {
-		const refusal = await this.driftRefusal(target, raw);
+	async applyBatchCore(target, operations, raw, shrinkOnly = false) {
+		const refusal = await this.driftRefusal(target, raw, shrinkOnly);
 		if (refusal) return {
 			result: refusal,
 			write: null
@@ -3389,6 +3507,8 @@ const SECRET_PATTERNS = [
 ];
 const INLINE_ASSIGNMENT_PATTERN = /* @__PURE__ */ new RegExp("(^|[^\\w-])([\\w-]{0,64}[_\\-])?((?:token|api[_-]?key|secret|password|passwd)(?:[_\\-][\\w-]{0,64})?)\\b([\"\\']?[\\t ]*[:=][\\t ]*)([^\\r\\n]+)", "gi");
 const URL_CREDENTIALS_PATTERN = /([a-z][a-z0-9+.-]*:\/\/[^\s:/@]+:)([^\s/@]+)@/gi;
+const PEM_PRIVATE_KEY_PATTERN = new RegExp(`-----BEGIN\\s+(?:(?:RSA|EC|DSA|OPENSSH|ENCRYPTED|PGP)\\s+)?PRIVATE\\s+KEY(?:\\s+BLOCK)?-----[\\s\\S]*?-----END\\s+(?:(?:RSA|EC|DSA|OPENSSH|ENCRYPTED|PGP)\\s+)?PRIVATE\\s+KEY(?:\\s+BLOCK)?-----`, "g");
+const BLOCK_KEY_ONLY_LINE = /(?:^|\s)([\w-]{0,64}[_\-])?((?:token|api[_-]?key|secret|password|passwd)(?:[_\-][\w-]{0,64})?)\s*:\s*$/i;
 /**
 * Mask credential-shaped text before it crosses a session boundary.
 * @param text - the text about to be sent to a model outside this session.
@@ -3396,9 +3516,21 @@ const URL_CREDENTIALS_PATTERN = /([a-z][a-z0-9+.-]*:\/\/[^\s:/@]+:)([^\s/@]+)@/g
 */
 function redactSecrets(text) {
 	let out = text;
+	out = out.replace(PEM_PRIVATE_KEY_PATTERN, "<redacted-private-key>");
 	for (const [, pattern] of SECRET_PATTERNS) out = out.replace(pattern, "<redacted>");
 	out = out.replace(URL_CREDENTIALS_PATTERN, (_match, lead) => `${lead ?? ""}<redacted>@`);
 	out = out.replace(INLINE_ASSIGNMENT_PATTERN, (_match, lead, prefix, key, separator) => `${lead ?? ""}${prefix ?? ""}${key ?? ""}${separator ?? ""}<redacted>`);
+	const lines = out.split("\n");
+	for (let i = 0; i < lines.length - 1; i++) {
+		const line = lines[i];
+		if (line === void 0 || !BLOCK_KEY_ONLY_LINE.test(line)) continue;
+		const next = lines[i + 1] ?? "";
+		const [, indent, value, tail] = /^([ \t]+)(\S.*?)([ \t]*)$/.exec(next) ?? [];
+		if (indent === void 0 || value === void 0) continue;
+		if (value.includes("<redacted>")) continue;
+		lines[i + 1] = `${indent}<redacted>${tail ?? ""}`;
+	}
+	out = lines.join("\n");
 	out = out.split("\n").map((line) => {
 		if (!/<redacted>/.test(line) && !/\baws\b|\bAKIA\b|\bsecret\b/i.test(line)) return line;
 		return line.replace(/(?<![A-Za-z0-9/+=])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=])/g, "<redacted>");
@@ -3570,8 +3702,9 @@ function foldTurn(session, fromSeq) {
 		memorySignal: false,
 		skillSignal: false
 	};
-	for (let index = Math.max(0, fromSeq); index < session.events.length; index += 1) {
-		const event = session.events[index];
+	const events = session.snapshotEvents();
+	for (let index = Math.max(0, fromSeq); index < events.length; index += 1) {
+		const event = events[index];
 		if (event) observeEvent(signal, event);
 	}
 	return signal;
@@ -3859,7 +3992,7 @@ function markerPath(dir, marker) {
 /**
 * Shared frontmatter block detection (P3-3 single owner): opening line `---`
 * and closing line exactly `---`. Used by `parseFrontmatter`,
-* `frontmatterYamlUnsafeValues` and `normalizeFrontmatter` so the three can
+* `frontmatterCatalogInvalid` and `normalizeFrontmatter` so the three can
 * never disagree about where the block ends (the loose `indexOf('\n---')`
 * form matched `\n----` and was replaced by this strict line rule).
 *
@@ -3894,7 +4027,7 @@ function frontmatterBlock(content) {
 }
 /**
 * Raw-line scan of a frontmatter block: the single owner of "which entries the
-* strict catalog cannot load". `frontmatterYamlUnsafeValues` publishes it and
+* strict catalog cannot load". `frontmatterCatalogInvalid` publishes it and
 * `normalizeFrontmatter` decides each rewrite with the same predicate
 * (`yamlPlainScalarNeedsQuotes`), so the audit verdict and the write path can
 * never disagree. Only single-line `key: value` entries are judged; a line with
@@ -4060,7 +4193,8 @@ function parseFrontmatter(content) {
 */
 function frontmatterCatalogInvalid(content) {
 	const read = readFrontmatterBlock(content);
-	return read === null ? false : read.strictFailed || read.unsafeValues.length > 0;
+	if (read !== null) return read.strictFailed || read.unsafeValues.length > 0;
+	return frontmatterBlock(content.replace(/^\uFEFF/, "").replace(/\r\n/g, "\n")) !== null;
 }
 /** YAML plain-scalar hazards that make an UNQUOTED frontmatter value
 * unloadable to the platform catalog (strict YAML parser): `: ` (mapping
@@ -4084,22 +4218,14 @@ function yamlPlainScalarNeedsQuotes(value) {
 	if (value.includes(": ")) return true;
 	if (value.includes(" #")) return true;
 	if (value.endsWith(":")) return true;
-	if (/^(?:null|true|false|~|[-+]?\d+(?:\.\d+)?)$/i.test(value)) return true;
+	if (/^(?:null|true|false|~)$/i.test(value)) return true;
+	if (/^[-+]?(?:\d+(?:\.\d*)?|\.\d+)(?:[eE][-+]?\d+)?$/.test(value)) return true;
+	if (/^0x[0-9a-f]+$/i.test(value)) return true;
+	if (/^0o[0-7]+$/.test(value)) return true;
+	if (/^\.(?:inf|nan)$/i.test(value)) return true;
 	if (/^[-?:,[\]{}#&*!|>'\"%@`\s]/.test(value)) return true;
 	return false;
 }
-/** Raw-line scan of the frontmatter block: entries whose UNQUOTED value is
-* YAML-unsafe for the strict platform catalog. Operates on the ORIGINAL line
-* value (quotes included), so a value already wrapped by
-* `normalizeFrontmatter` is never re-flagged — one source with the write
-* path. V27 G2.1: delegates to the shared scan, which
-* `parseFrontmatter(...).catalogInvalid` also uses, so the audit view and the
-* read view of one file can never disagree. Independent of the body: a
-* body-less file is still reported here. */
-function frontmatterYamlUnsafeValues(content) {
-	const block = frontmatterBlock(content);
-	return block === null ? [] : unsafeFrontmatterEntries(block.block, block.nl);
-}
 /**
 * Normalize a SKILL.md frontmatter block into catalog-loadable YAML: values
 * that YAML forbids unquoted get quotes — double quotes normally, single
@@ -4243,9 +4369,18 @@ function authoringFeedback(frontmatter) {
 /** A1-15 (v18) / P2-2 (v19): the io layer marks an error `committed: true` when
 * the rename landed and only the directory fsync failed. Every single-file
 * writer must treat that as "written, durability unconfirmed" — never as a
-* plain failure (which a caller would retry, or a two-phase caller roll back). */
+* plain failure (which a caller would retry, or a two-phase caller roll back).
+* v28 G2.1 (EVO-IO-05): this is a delegation to the seam's own
+* `isCommittedWarning` — the marker predicate has exactly one definition. */
 function isCommittedOnly(error) {
-	return error?.committed === true;
+	return isCommittedWarning(error);
+}
+/** v28 G2.5 (CORE-SK-03): every pre-clear refusal in restoreSnapshotIntoRoot
+* says "refus…" (manifest / traversal / live-writer gates) or "is incomplete"
+* (completeness gate). Anything else thrown from that method means the
+* destructive clear already happened and a rollback is load-bearing. */
+function isPreClearRefusal(message) {
+	return message.includes("refus") || message.includes("is incomplete");
 }
 async function listNames(root, io) {
 	const entries = await io.list(root);
@@ -4516,11 +4651,14 @@ var SkillLibrary = class {
 		let outcome;
 		const run = async (current) => {
 			const o = await task(current ?? null);
-			outcome = o;
+			outcome = {
+				...o,
+				ghostDir: current === null && o.write === null
+			};
 			return o.write ?? current ?? null;
 		};
 		let durabilityWarning = "";
-		const committedOnly = (error) => error?.committed === true;
+		const committedOnly = isCommittedOnly;
 		if (this.transact) try {
 			await this.transact(this.io, path, run);
 		} catch (error) {
@@ -4542,6 +4680,7 @@ var SkillLibrary = class {
 			ok: false,
 			message: "internal error: the write transaction did not invoke the task; no write was performed"
 		};
+		if (o.ghostDir === true) await this.cleanupGhostDir(path);
 		if (o.write !== null && o.audit) await this.audit(o.audit.skillName, o.audit.action, o.audit.before, o.audit.after, o.audit.summary);
 		if (o.write !== null && o.event) this.notifyMutation(o.event);
 		return durabilityWarning === "" || !o.result.ok ? o.result : {
@@ -4549,6 +4688,24 @@ var SkillLibrary = class {
 			message: `${o.result.message} (warning: the write landed but the directory fsync failed — durability unconfirmed: ${durabilityWarning})`
 		};
 	}
+	/**
+	* v28 G1.1 (EVO-IO-02): shared compensating cleanup for a locked write that
+	* found no SKILL.md — remove the possibly-resurrected directory ONLY when it
+	* holds nothing but this path's own write-lock file. The BR-5 rule from
+	* setPinnedCore/createCore applies unchanged: a concurrent mover can land a
+	* full directory between the list probe and the remove, so anything beyond
+	* the lock file (support files, a fresh restore) must never be recursed
+	* away. Best-effort: a failed cleanup leaves the "not found" result
+	* unchanged (the operator-facing ghost-dir refusal is fail-loud already).
+	*/
+	async cleanupGhostDir(skillFilePath) {
+		const dir = dirname(skillFilePath);
+		const lockName = `${basename(skillFilePath)}${LOCK_SUFFIX}`;
+		try {
+			if ((await this.io.list(dir)).some((entry) => entry !== lockName)) return;
+			await this.io.remove(dir);
+		} catch {}
+	}
 	/** Notify the mutation observer after a successful write; observers must never fail the mutation. */
 	notifyMutation(event) {
 		try {
@@ -4566,11 +4723,39 @@ var SkillLibrary = class {
 	contentThreatBlock(content) {
 		return scanContentThreats(content, void 0, this.threatScanOptions());
 	}
+	/**
+	* v30 REV-03: read a support file's bytes for staleness anchoring (the
+	* write/remove replay guard). Same validation as writeSupportFile; a
+	* missing file (or a directory squatting on the path) reads as `null`, any
+	* other failure RETHROWS — the callers are the staging/replay anchors, and
+	* a swallowed error would silently downgrade the anchor to
+	* last-writer-wins.
+	*/
+	async readSupportFile(name, filePath) {
+		const bad = this.badName(name, { allowReserved: true });
+		if (bad) throw new Error(bad);
+		const validation = validateSupportPath(filePath);
+		if (validation) throw new Error(validation);
+		const target = join(this.dirOf(name), ...filePath.replace(/\\/g, "/").split("/").filter(Boolean));
+		try {
+			return await this.io.readText(target);
+		} catch (error) {
+			const code = error?.code;
+			if (code === "ENOENT" || code === "EISDIR") return null;
+			throw error;
+		}
+	}
 	async list() {
 		const summaries = [];
 		for (const name of await listNames(this.root, this.io)) {
 			const dir = this.dirOf(name);
-			const md = await this.io.readText(join(dir, "SKILL.md"));
+			let md;
+			try {
+				md = await this.io.readText(join(dir, "SKILL.md"));
+			} catch (error) {
+				if (error?.code === "EISDIR") continue;
+				throw error;
+			}
 			if (md === null) continue;
 			const parsed = parseFrontmatter(md);
 			let entries = null;
@@ -4830,7 +5015,7 @@ var SkillLibrary = class {
 			}
 			if (!await this.io.exists(join(dir, "SKILL.md"))) {
 				await this.io.remove(marker).catch(() => {});
-				if ((await this.io.list(dir).catch(() => [])).length === 0) await this.io.remove(dir).catch(() => {});
+				await this.cleanupGhostDir(join(dir, "SKILL.md"));
 				return {
 					ok: false,
 					message: `Skill "${normalized}" was archived concurrently while pinning; the partial marker was removed — retry after the mover settles.`
@@ -4930,15 +5115,22 @@ var SkillLibrary = class {
 			message: `Skill "${normalized}" already exists.`
 		};
 		if (origin !== "foreground") {
-			await this.io.writeText(markerPath(dir, "hermes-managed"), "");
+			let markerDurabilityWarning = "";
+			try {
+				await this.io.writeText(markerPath(dir, "hermes-managed"), "");
+			} catch (error) {
+				if (!isCommittedOnly(error)) throw error;
+				markerDurabilityWarning = error instanceof Error ? error.message : String(error);
+			}
 			if (!await this.io.exists(createPath)) {
 				await this.io.remove(markerPath(dir, "hermes-managed")).catch(() => {});
-				if ((await this.io.list(dir).catch(() => [])).length === 0) await this.io.remove(dir).catch(() => {});
+				await this.cleanupGhostDir(createPath);
 				return {
 					ok: false,
 					message: `Skill "${normalized}" was archived concurrently while being created; the partial marker was removed — retry once the mover settles.`
 				};
 			}
+			if (markerDurabilityWarning !== "") createDurabilityWarning = createDurabilityWarning === "" ? markerDurabilityWarning : `${createDurabilityWarning}; marker: ${markerDurabilityWarning}`;
 		}
 		await this.audit(normalized, "create", null, onDisk, "created");
 		this.notifyMutation({
@@ -5765,7 +5957,7 @@ var SkillLibrary = class {
 						if (drift.seen) throw new Error(`concurrent modification detected: ${entry.target} changed after the plan was computed (a concurrent writer won the race); no further writes were performed`);
 					} else await this.io.writeText(entry.target, entry.content);
 				} catch (error) {
-					if (error?.committed !== true) throw error;
+					if (!isCommittedOnly(error)) throw error;
 					durabilityWarning = error instanceof Error ? error.message : String(error);
 				}
 				written.push({
@@ -6071,7 +6263,9 @@ var SkillLibrary = class {
 				await this.io.copy(archiveRoot, join(dest, ".archive"));
 				hasArchive = true;
 			}
-			const validExtras = extras.filter((extra) => SNAPSHOT_EXTRA_NAME_RE.test(extra.name));
+			const rejectedExtras = extras.filter((extra) => typeof extra?.name !== "string" || !SNAPSHOT_EXTRA_NAME_RE.test(extra.name)).map((extra) => JSON.stringify(extra?.name ?? extra));
+			if (rejectedExtras.length > 0) throw new Error(`snapshotAll: refusing invalid snapshot extras (name must match ${SNAPSHOT_EXTRA_NAME_RE.source}): ${rejectedExtras.join(", ")}`);
+			const validExtras = extras;
 			const extraNames = validExtras.map((extra) => extra.name);
 			const extraFailure = (await Promise.allSettled(validExtras.map(async (extra) => {
 				await this.io.writeText(join(dest, "extras", extra.name), extra.content);
@@ -6219,7 +6413,15 @@ var SkillLibrary = class {
 			ok: false,
 			message: "No skill snapshot available."
 		};
-		const preRollbackPath = await this.snapshotAll("pre-rollback", extras);
+		let preRollbackPath;
+		try {
+			preRollbackPath = await this.snapshotAll("pre-rollback", extras);
+		} catch (error) {
+			return {
+				ok: false,
+				message: `Snapshot restore was refused before anything was cleared: taking the pre-rollback snapshot failed (${error instanceof Error ? error.message : String(error)}) — the active tree is UNCHANGED. Resolve the snapshot write failure and retry.`
+			};
+		}
 		const snapshotExtras = await this.readSnapshotExtras(latest.path);
 		try {
 			await this.restoreSnapshotIntoRoot(latest.path);
@@ -6232,9 +6434,14 @@ var SkillLibrary = class {
 					message: `Snapshot restore failed (${reason}); the active tree was rolled back to the pre-rollback snapshot.`
 				};
 			} catch (rollbackError) {
+				const rb = rollbackError instanceof Error ? rollbackError.message : String(rollbackError);
+				if (isPreClearRefusal(reason) && isPreClearRefusal(rb)) return {
+					ok: false,
+					message: `Snapshot restore was refused before anything was cleared; the active tree is UNCHANGED.\n- target: ${reason}\n- pre-rollback: ${rb}\nResolve the cause (a live skill write, or an incomplete snapshot) and retry — no manual rescue is needed.`
+				};
 				return {
 					ok: false,
-					message: `Snapshot restore failed (${reason}) AND pre-rollback restore failed (${rollbackError instanceof Error ? rollbackError.message : String(rollbackError)}). Rescue manually from: ${preRollbackPath} (pre-rollback), ${latest.path} (target).`
+					message: `Snapshot restore failed (${reason}) AND pre-rollback restore failed (${rb}). Rescue manually from: ${preRollbackPath} (pre-rollback), ${latest.path} (target).`
 				};
 			}
 		}
@@ -6313,4 +6520,4 @@ var SkillLibrary = class {
 	}
 };
 //#endregion
-export { AUTHORING_DESCRIPTION_BAR, COMBINED_REVIEW_PLAN_PROMPT, COMBINED_REVIEW_PROMPT, COMPLETION_SKILL_REVIEW_PROMPT, CURATOR_DRY_RUN_BANNER, CURATOR_PROMPT, DEAD_LOCK_TAKEOVER_MS, DEFAULT_ARCHIVE_AFTER_DAYS, DEFAULT_CONSOLIDATION_FAILURES, DEFAULT_CURATOR_BOOT_GRACE_SECONDS, DEFAULT_CURATOR_INTERVAL_HOURS, DEFAULT_CURATOR_MODEL, DEFAULT_CURATOR_REVIEW_MAX_TOKENS, DEFAULT_HEALTH_THRESHOLDS, DEFAULT_MAX_OPS_PER_PLAN, DEFAULT_MEMORY_CHAR_LIMIT, DEFAULT_MEMORY_REVIEW_MODEL, DEFAULT_MIN_IDLE_HOURS, DEFAULT_MUTATION_CAP, DEFAULT_REVIEW_CONTEXT_MESSAGES, DEFAULT_REVIEW_MEMORY_INTERVAL, DEFAULT_REVIEW_MESSAGE_CHARS, DEFAULT_REVIEW_SKILL_INTERVAL, DEFAULT_REVIEW_TIMEOUT_MS, DEFAULT_SKILL_CONTENT_CHARS, DEFAULT_SKILL_LIMITS, DEFAULT_SKILL_REVIEW_COMPLETION_MIN_TOOL_CALLS, DEFAULT_SKILL_REVIEW_MODEL, DEFAULT_SKILL_REVIEW_TRIGGER, DEFAULT_STALE_AFTER_DAYS, DEFAULT_SUBSTANTIVE_MIN_AGENT_CHARS, DEFAULT_SUBSTANTIVE_MIN_TOOL_CALLS, DEFAULT_SUBSTANTIVE_MIN_USER_CHARS, DEFAULT_USER_CHAR_LIMIT, DRIFT_MAX_LINE_CHARS, DRIFT_SIGNALS_VERSION, DRIFT_SIGNAL_NOUNS, DSH_AUTHORING_STANDARDS, EMPTY_LOCK_TAKEOVER_MS, ENTRY_DELIMITER, EVENT_ARCHIVE_PREFIX, EVENT_LOG_RETAIN_ARCHIVES, EVENT_LOG_ROTATE_AT, EVENT_LOG_VERSION, EVOLUTION_WRITE_TOOLS, EvolutionGateSet, FORBIDDEN_CONTROL_KEYS, HEALTH_STAMP_RE, LOCK_BODY_RE, LOCK_SUFFIX, LOCK_TEAR_TAKEOVER_MS, LOW_QUALITY_THRESHOLD, LostWriteLock, MAINTAIN_OUTPUT_INSTRUCTION, MAINTAIN_PROMPT, MAX_DESCRIPTION_LENGTH, MAX_RESTRUCTURE_MOVES, MAX_SKILL_CONTENT_CHARS, MAX_SKILL_FILE_BYTES, MAX_SKILL_NAME_LENGTH, MAX_TIMER_DELAY_MS, MEMORY_REVIEW_PROMPT, MIN_STAMP_BODY_CHARS, MUTATIONS_FILE_VERSION, MemoryStore, PATTERN_OVERLAP, PROMPT_BUNDLE, PROMPT_BUNDLE_ID, PROMPT_BUNDLE_VERSION, PROTECTED_BUILTIN_SKILLS, QUALITY_WEIGHTS, RESTRUCTURE_TARGET_RE, SKILLS_GUIDANCE, SKILL_NAME_RE, SKILL_REVIEW_PLAN_PROMPT, SKILL_REVIEW_PROMPT, SNAPSHOT_EXTRA_NAME_RE, SUPPORT_DIRS, SUPPRESSED_FILE_VERSION, SkillLibrary, THREAT_EXEMPTION_HINT, advanceReview, allowRowCollisions, appendEvolutionEvent, applyCuratorFields, applyCuratorLifecycleFields, applyCuratorMetaFields, assertSkillsRootAliasRetired, assessStructureHealth, authoringFeedback, buildCuratorRunReport, buildLearnPrompt, bumpPatch, bumpUse, bumpView, clampedNumber, composePresetComposition, computeDedupGroups, computeDriftSignals, computeLifecycleTransitions, computePrefixClusters, computeQualityScores, computeScopeView, contentHash, createGateSet, decideTakeover, duplicateHeadings, emptyRecord, evaluateThreat, eventsFile, evolutionEventPayloadIssue, evolutionHome, evolutionIoAdapter, evolutionRoot, findDriftSignal, foldCuratorFields, foldTurn, frontmatterBlock, frontmatterCatalogInvalid, frontmatterYamlUnsafeValues, getRecord, isCommittedWarning, isProcessAlive, latestActivityAt, lifecycleCandidate, listEventArchives, loadMutations, loadSuppressedNames, loadUsage, makeSerialQueue, markAgentCreated, markerEntryName, memoryRoot, missingSupportPointers, mutateUsage, mutationsFile, narrowNameMatches, nodeEvolutionIo, normalizeFrontmatter, normalizeUsageRecord, observeEvent, overlongLines, parseCuratorNominations, parseEvolutionEvents, parseFrontmatter, parseLockBody, pendingSelfCleanup, readEvolutionEvents, readEvolutionTimeline, recordMutation, redactSecrets, relatedSkillNames, renameWithRetry, renderCuratorReportMarkdown, resolveOrigins, resolveRootConfig, resolveSkillsRoot, retainEventArchives, reviewPrompt, saveSuppressedNames, saveUsage, scanContentThreats, scanMemoryThreats, scanThreats, skillsRoot, suppressedFile, transactIo, updateSuppressedNames, usageFile, usageObserved, validateFrontmatter, validateRestructureTarget, verifyPromptBundle, writeDurableTmp, yamlPlainScalarNeedsQuotes };
+export { AUTHORING_DESCRIPTION_BAR, COMBINED_REVIEW_PLAN_PROMPT, COMBINED_REVIEW_PROMPT, COMPLETION_SKILL_REVIEW_PROMPT, CURATOR_DRY_RUN_BANNER, CURATOR_PROMPT, DEAD_LOCK_TAKEOVER_MS, DEFAULT_ARCHIVE_AFTER_DAYS, DEFAULT_CONSOLIDATION_FAILURES, DEFAULT_CURATOR_BOOT_GRACE_SECONDS, DEFAULT_CURATOR_INTERVAL_HOURS, DEFAULT_CURATOR_MODEL, DEFAULT_CURATOR_REVIEW_MAX_TOKENS, DEFAULT_HEALTH_THRESHOLDS, DEFAULT_MAX_OPS_PER_PLAN, DEFAULT_MEMORY_CHAR_LIMIT, DEFAULT_MEMORY_REVIEW_MODEL, DEFAULT_MIN_IDLE_HOURS, DEFAULT_MUTATION_CAP, DEFAULT_REVIEW_CONTEXT_MESSAGES, DEFAULT_REVIEW_MEMORY_INTERVAL, DEFAULT_REVIEW_MESSAGE_CHARS, DEFAULT_REVIEW_SKILL_INTERVAL, DEFAULT_REVIEW_TIMEOUT_MS, DEFAULT_SKILL_CONTENT_CHARS, DEFAULT_SKILL_LIMITS, DEFAULT_SKILL_REVIEW_COMPLETION_MIN_TOOL_CALLS, DEFAULT_SKILL_REVIEW_MODEL, DEFAULT_SKILL_REVIEW_TRIGGER, DEFAULT_STALE_AFTER_DAYS, DEFAULT_SUBSTANTIVE_MIN_AGENT_CHARS, DEFAULT_SUBSTANTIVE_MIN_TOOL_CALLS, DEFAULT_SUBSTANTIVE_MIN_USER_CHARS, DEFAULT_USER_CHAR_LIMIT, DRIFT_MAX_LINE_CHARS, DRIFT_SIGNALS_VERSION, DRIFT_SIGNAL_NOUNS, DSH_AUTHORING_STANDARDS, EMPTY_LOCK_TAKEOVER_MS, ENTRY_DELIMITER, EVENT_ARCHIVE_PREFIX, EVENT_LOG_RETAIN_ARCHIVES, EVENT_LOG_ROTATE_AT, EVENT_LOG_VERSION, EVOLUTION_WRITE_TOOLS, EvolutionGateSet, FORBIDDEN_CONTROL_KEYS, HEALTH_STAMP_RE, LOCK_BODY_RE, LOCK_SUFFIX, LOCK_TEAR_TAKEOVER_MS, LOW_QUALITY_THRESHOLD, LostWriteLock, MAINTAIN_OUTPUT_INSTRUCTION, MAINTAIN_PROMPT, MAX_DESCRIPTION_LENGTH, MAX_RESTRUCTURE_MOVES, MAX_SKILL_CONTENT_CHARS, MAX_SKILL_FILE_BYTES, MAX_SKILL_NAME_LENGTH, MAX_TIMER_DELAY_MS, MEMORY_GUIDANCE_SECTION_ORDER, MEMORY_REVIEW_PROMPT, MIN_STAMP_BODY_CHARS, MUTATIONS_FILE_VERSION, MemoryStore, PATTERN_OVERLAP, PROMPT_BUNDLE, PROMPT_BUNDLE_ID, PROMPT_BUNDLE_VERSION, PROTECTED_BUILTIN_SKILLS, QUALITY_WEIGHTS, RESTRUCTURE_TARGET_RE, SKILLS_GUIDANCE, SKILLS_GUIDANCE_SECTION_ORDER, SKILL_NAME_RE, SKILL_REVIEW_PLAN_PROMPT, SKILL_REVIEW_PROMPT, SNAPSHOT_EXTRA_NAME_RE, SUPPORT_DIRS, SUPPRESSED_FILE_VERSION, SkillLibrary, THREAT_EXEMPTION_HINT, advanceReview, allowRowCollisions, appendEvolutionEvent, applyCuratorFields, applyCuratorLifecycleFields, applyCuratorMetaFields, assertSkillsRootAliasRetired, assessStructureHealth, authoringFeedback, buildCuratorRunReport, buildLearnPrompt, bumpPatch, bumpUse, bumpView, clampedNumber, composePresetComposition, computeDedupGroups, computeDriftSignals, computeLifecycleTransitions, computePrefixClusters, computeQualityScores, computeScopeView, contentHash, createGateSet, decideTakeover, duplicateHeadings, emptyRecord, evaluateThreat, eventsFile, evolutionEventPayloadIssue, evolutionHome, evolutionIoAdapter, evolutionRoot, findDriftSignal, foldCuratorFields, foldTurn, frontmatterBlock, frontmatterCatalogInvalid, getRecord, isCommittedWarning, isProcessAlive, latestActivityAt, lifecycleCandidate, listEventArchives, loadMutations, loadSuppressedNames, loadUsage, makeSerialQueue, markAgentCreated, markerEntryName, memoryRoot, missingSupportPointers, mutateUsage, mutationsFile, narrowNameMatches, nodeEvolutionIo, normalizeFrontmatter, normalizeUsageRecord, observeEvent, overlongLines, parseCuratorNominations, parseEvolutionEvents, parseFrontmatter, parseLockBody, pendingSelfCleanup, readEvolutionEvents, readEvolutionTimeline, recordMutation, redactSecrets, relatedSkillNames, renameWithRetry, renderCuratorReportMarkdown, resolveOrigins, resolveRootConfig, resolveSkillsRoot, retainEventArchives, reviewPrompt, saveSuppressedNames, saveUsage, scanContentThreats, scanMemoryThreats, scanThreats, skillsRoot, suppressedFile, transactIo, updateSuppressedNames, usageFile, usageObserved, validateFrontmatter, validateRestructureTarget, verifyPromptBundle, writeDurableTmp, yamlPlainScalarNeedsQuotes };

package/lib/types/constants.d.ts

@@ -97,4 +97,8 @@ export declare const MAX_TIMER_DELAY_MS = 2147483647;
 export declare const DEFAULT_MEMORY_REVIEW_MODEL = "deepseek-v4-flash";
 export declare const DEFAULT_SKILL_REVIEW_MODEL = "deepseek-v4-pro";
 export declare const DEFAULT_CURATOR_MODEL = "deepseek-v4-pro";
+/** Order of the `evolution:memory-guidance` section (before the skills one). */
+export declare const MEMORY_GUIDANCE_SECTION_ORDER = 11000;
+/** Order of the `evolution-skills-guidance` section (last of the two). */
+export declare const SKILLS_GUIDANCE_SECTION_ORDER = 11100;
 //# sourceMappingURL=constants.d.ts.map

package/lib/types/curator.d.ts

@@ -40,7 +40,13 @@ export interface CuratorResult {
 }
 export interface CuratorArchivedSkill {
     name: string;
-    path: string;
+    /** v28 G4.3 (CUR-03): the on-disk archive destination. OMITTED when the run
+     * only knows the nominal `.archive/<name>` location — consolidation sources
+     * archive through SkillLibrary.archive(), which stamps a
+     * `<name>-<stamp>[-<rand>]` suffix on collision. A synthesized path sent
+     * operators to a directory that may not exist; the real destination is on
+     * the `evolution/skill-mutated` event (`archivedPath`). */
+    path?: string;
     reason: string;
 }
 export interface CuratorFailedSkill {

package/lib/types/memory-store.d.ts

@@ -109,6 +109,13 @@ export declare class MemoryStore {
      *
      * @param target - memory target being written
      * @param core - the in-transaction read-modify-write for the locked body
+     * @param shrinkOnly - v29 MEM-02: every queued operation REMOVES an entry
+     *   (the recovery path for a limit lowered under existing content). The
+     *   oversized read-guard is skipped for these batches: a canonical file
+     *   written under a ≥10× higher limit trips the `limit × 10` byte bound, and
+     *   the guard's "fix the file manually" refusal would pre-empt exactly the
+     *   shrink recovery MEM-01 advertises. The load is bounded by what the store
+     *   itself wrote under the old limit.
      * @returns the core's result, or the oversized / contract-violation refusal
      */
     private chainedWrite;
@@ -121,7 +128,7 @@ export declare class MemoryStore {
      */
     private addCore;
     /**
-     * The single drift predicate. `raw` is in canonical form when it byte-matches
+     * The single drift evaluation. `raw` is in canonical form when it byte-matches
      * `render(normalizeEntries(raw))`; anything else means it was edited outside
      * MemoryStore (empty/`§`-only entries, stray blank lines, leading or trailing
      * delimiters — structural anomalies the writer would quietly normalize away).
@@ -135,18 +142,42 @@ export declare class MemoryStore {
      * every write path — including the repairs the model would need to make.
      * Such files are adopted instead of flagged.
      *
+     * Returns one of:
+     * - `'external'` — non-canonical body, i.e. real external modification. This
+     *   includes the Hermes-parity signal #2 (an entry larger than the whole-file
+     *   limit): that shape is only meaningful as external evidence on a
+     *   NON-canonical body, because free-form external appends never render
+     *   canonically.
+     * - `'over-limit'` — v28 MEM-01: a CANONICAL body whose entries exceed the
+     *   CURRENT configured limit. Those bytes were written by this store under a
+     *   previous (higher) limit, so they are not external drift; treating them as
+     *   such misattributed a config change to an "external editor" and bricked
+     *   every write path (the advertised recovery — remove/consolidate — is
+     *   exactly what the drift gate refused). Callers route this state to a
+     *   config-naming refusal and let shrink-only batches through.
+     * - `null` — no drift: writable as-is.
+     *
      * @param target - memory target whose char limit bounds one parsed entry
      * @param raw - on-disk body, or `null` when the file does not exist
-     * @returns whether these bytes count as externally drifted
      */
+    private driftKind;
+    /** External-drift predicate: canonical-form violations only (see
+     * {@link driftKind}). `detectDrift` and the write paths share it, so a write
+     * and a later read never disagree about the same bytes. */
     private drifted;
     /**
      * Drift refusal for a body already read under the write lock, or `null` when
-     * the body is canonical. Both write paths return this unchanged, so their
+     * writing may proceed. Both write paths return this unchanged, so their
      * refusals stay byte-identical and each carries the same backup.
      *
+     * The `'over-limit'` state never refuses shrink-only batches (`shrinkOnly`):
+     * removing entries is the advertised recovery for a limit lowered under
+     * existing content, and the batch's own final limit check still gates the
+     * result.
+     *
      * @param target - memory target that owns the drifted file
      * @param raw - locked file body
+     * @param shrinkOnly - every queued operation removes an entry (no growth)
      * @returns the refusal to hand back, or `null` to continue writing
      */
     private driftRefusal;

package/lib/types/prompts.d.ts

@@ -3,11 +3,11 @@
  * changes semantically: the bundle digest is the fail-closed signal for
  * review workers, so a stale id across deployments must be distinguishable.
  */
-export declare const PROMPT_BUNDLE_VERSION = 16;
-export declare const PROMPT_BUNDLE_ID = "dsh-evolution@16";
+export declare const PROMPT_BUNDLE_VERSION = 17;
+export declare const PROMPT_BUNDLE_ID = "dsh-evolution@17";
 export declare const MEMORY_REVIEW_PROMPT = "[Auto-review \u2014 Memory]\nReview the conversation above and consider saving to memory if appropriate.\n\nFocus on:\n1. Has the user revealed things about themselves \u2014 persona, desires, preferences, or personal details worth remembering?\n2. Has the user expressed expectations about how you should behave, their work style, or ways they want you to operate?\n\nIf something stands out, save it using the memory tool.\nIf nothing is worth saving, just say \"Nothing to save.\" and stop.";
-export declare const SKILL_REVIEW_PROMPT = "[Auto-review \u2014 Skills]\nReview the conversation above and update the skill library. Be ACTIVE \u2014 most sessions produce at least one skill update, even if small. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the library: CLASS-LEVEL skills, each with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries. This shapes HOW you update, not WHETHER you update.\n\nSignals to look for (any one of these warrants action):\n  \u2022 User corrected your style, tone, format, legibility, or verbosity. Frustration signals like 'stop doing X', 'this is too verbose', 'don't format like this', 'why are you explaining', 'just give me the answer', 'you always do Y and I hate it', or an explicit 'remember this' are FIRST-CLASS skill signals, not just memory signals. Update the relevant skill(s) to embed the preference so the next session starts already knowing.\n  \u2022 User corrected your workflow, approach, or sequence of steps. Encode the correction as a pitfall or explicit step in the skill that governs that class of task.\n  \u2022 Non-trivial technique, fix, workaround, debugging path, or tool-usage pattern emerged that a future session would benefit from. Capture it.\n  \u2022 A skill that got loaded or consulted this session turned out to be wrong, missing a step, or outdated. Patch it NOW.\n\nRead-before-write (enforced by this channel): update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session \u2014 ops on unread skills are dropped; CREATE of a brand-new umbrella is the only exception.\n\nPreference order \u2014 prefer the earliest action that fits, but do pick one when a signal above fired:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Look back through the conversation for skills the user loaded or you read. If any of them covers the territory of the new learning, PATCH that one first. It is the skill that was in play, so it's the right one to extend.\n  2. UPDATE AN EXISTING UMBRELLA. If no loaded skill fits but an existing class-level skill does, patch it. Add a subsection, a pitfall, or broaden a trigger.\n  3. ADD A SUPPORT FILE under an existing umbrella. Skills can be packaged with three kinds of support files \u2014 use the right directory per kind:\n     \u2022 references/<topic>.md \u2014 session-specific detail (error transcripts, reproduction recipes, provider quirks) AND condensed knowledge banks: quoted research, API docs, external authoritative excerpts, or domain notes you found while working on the problem. Write it concise and for the value of the task, not as a full mirror of upstream docs.\n     \u2022 templates/<name>.<ext> \u2014 starter files meant to be copied and modified (boilerplate configs, scaffolding, a known-good example the agent can reproduce with modifications).\n     \u2022 scripts/<name>.<ext> \u2014 statically re-runnable actions the skill can invoke directly (verification scripts, fixture generators, deterministic probes, anything the agent should run rather than hand-type each time).\n     Add support files via skill_manage action=write_file with file_path starting 'references/', 'templates/', or 'scripts/'. The umbrella's SKILL.md should gain a one-line pointer to any new support file so future agents know it exists.\n  4. RESTRUCTURE a loaded skill whose body grew log-like \u2014 rc/sha/date-dense sections, session-detail spirals, or a fat body with no support files. Use skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section (from that heading to the next heading) moves into the support file and its position becomes a pointer line. The skill's name and directory never change. Only propose headings that exist verbatim in the body; never invent one, and never restructure a healthy small skill.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA SKILL when no existing skill covers the class. The name MUST be at the class level. The name MUST NOT be a specific PR number, error string, feature codename, library-alone name, or 'fix-X / debug-Y / audit-Z-today' session artifact. If the proposed name only makes sense for today's task, it's wrong \u2014 fall back to (1), (2), or (3).\n\nUser-preference embedding (important): when the user expressed a style/format/workflow preference, the update belongs in the SKILL.md body, not just in memory. Memory captures 'who the user is and what the current situation and state of your operations are'; skills capture 'how to do this class of task for this user'. When they complain about how you handled a task, the skill that governs that task needs to carry the lesson.\n\nIf you notice two existing skills that overlap, note it in your reply \u2014 the background curator handles consolidation at scale.\n\nTwo-tier deposition discipline (DSH addition, same spirit as the umbrella rule): before writing, classify the knowledge:\n  \u2022 PATTERN (reusable \u2014 symptom \u2192 mechanism \u2192 fix \u2192 verification, still valuable next session) belongs in the SKILL.md body.\n  \u2022 LOG (one-off \u2014 commit SHAs, npm/profile states, what this release changed, this session's process narrative) belongs in a references/ file, never the body. Body density IS reuse rate. Keep new entries tight: a pattern fits in 2-8 physical lines; prefer changing the current-state pointer over appending history.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\n'Nothing to save.' is a real option but should NOT be the default. If the session ran smoothly with no corrections and produced no new technique, just say 'Nothing to save.' and stop. Otherwise, act.";
-export declare const COMBINED_REVIEW_PROMPT = "[Auto-review]\nReview the conversation above and update two things:\n\n**Memory**: who the user is. Did the user reveal persona, desires, preferences, personal details, or expectations about how you should behave? Save facts about the user and durable preferences with the memory tool.\n\n**Skills**: how to do this class of task. Be ACTIVE \u2014 most sessions produce at least one skill update. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the skill library: CLASS-LEVEL skills with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries.\n\nSignals that warrant a skill update (any one is enough):\n  \u2022 User corrected your style, tone, format, legibility, verbosity, or approach. Frustration is a FIRST-CLASS skill signal, not just a memory signal. 'stop doing X', 'don't format like this', 'I hate when you Y' \u2014 embed the lesson in the skill that governs that task so the next session starts fixed.\n  \u2022 Non-trivial technique, fix, workaround, or debugging path emerged.\n  \u2022 A skill that was loaded or consulted turned out wrong, missing, or outdated \u2014 patch it now.\n\nRead-before-write (enforced by this channel): update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session \u2014 ops on unread skills are dropped; CREATE of a brand-new umbrella is the only exception.\n\nPreference order for skills \u2014 pick the earliest that fits:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Check what skills were loaded or read in the conversation. If one of them covers the learning, PATCH it first. It was in play; it's the right place.\n  2. UPDATE AN EXISTING UMBRELLA. Patch it.\n  3. ADD A SUPPORT FILE under an existing umbrella via skill_manage action=write_file. Three kinds: references/<topic>.md for session-specific detail OR condensed knowledge banks (quoted research, API docs excerpts, domain notes) written concise and task-focused; templates/<name>.<ext> for starter files meant to be copied and modified; scripts/<name>.<ext> for statically re-runnable actions (verification, fixture generators, probes). Add a one-line pointer in SKILL.md so future agents find them.\n  4. RESTRUCTURE a loaded skill whose body grew log-like (rc/sha/date-dense sections, session-detail spirals, fat body with no support files) via skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section moves into the support file and its position becomes a pointer line; the skill's name and directory never change. Only propose headings that exist verbatim in the body.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA when nothing exists. Name at the class level \u2014 NOT a PR number, error string, codename, library-alone name, or 'fix-X / debug-Y' session artifact. If the name only fits today's task, fall back to (1), (2), or (3).\n\nTwo-tier deposition discipline (DSH addition): classify before writing \u2014 PATTERN (symptom \u2192 mechanism \u2192 fix \u2192 verification) goes in the SKILL.md body; LOG (commit SHAs, npm/profile states, this release's change list, this session's narrative) goes in a references/ file. Body density IS reuse rate; a pattern fits in 2-8 physical lines.\n\nUser-preference embedding: when the user complains about how you handled a task, update the skill that governs that task \u2014 memory alone isn't enough. Memory says 'who the user is and what the current situation and state of your operations are'; skills say 'how to do this class of task for this user'. Both should carry user-preference lessons when relevant.\n\nIf you notice overlapping existing skills, mention it \u2014 the background curator handles consolidation.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture as skills (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\nAct on whichever of the two dimensions has real signal. If genuinely nothing stands out on either, say 'Nothing to save.' and stop \u2014 but don't reach for that conclusion as a default.";
+export declare const SKILL_REVIEW_PROMPT = "[Auto-review \u2014 Skills]\nReview the conversation above and update the skill library. Be ACTIVE \u2014 most sessions produce at least one skill update, even if small. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the library: CLASS-LEVEL skills, each with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries. This shapes HOW you update, not WHETHER you update.\n\nSignals to look for (any one of these warrants action):\n  \u2022 User corrected your style, tone, format, legibility, or verbosity. Frustration signals like 'stop doing X', 'this is too verbose', 'don't format like this', 'why are you explaining', 'just give me the answer', 'you always do Y and I hate it', or an explicit 'remember this' are FIRST-CLASS skill signals, not just memory signals. Update the relevant skill(s) to embed the preference so the next session starts already knowing.\n  \u2022 User corrected your workflow, approach, or sequence of steps. Encode the correction as a pitfall or explicit step in the skill that governs that class of task.\n  \u2022 Non-trivial technique, fix, workaround, debugging path, or tool-usage pattern emerged that a future session would benefit from. Capture it.\n  \u2022 A skill that got loaded or consulted this session turned out to be wrong, missing a step, or outdated. Patch it NOW.\n\nRead-before-write: update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session. On the plan channel ops on unread skills are rejected; direct writes have no such guard, so treat the rule as binding. CREATE of a brand-new umbrella is the only exception.\n\nPreference order \u2014 prefer the earliest action that fits, but do pick one when a signal above fired:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Look back through the conversation for skills the user loaded or you read. If any of them covers the territory of the new learning, PATCH that one first. It is the skill that was in play, so it's the right one to extend.\n  2. UPDATE AN EXISTING UMBRELLA. If no loaded skill fits but an existing class-level skill does, patch it. Add a subsection, a pitfall, or broaden a trigger.\n  3. ADD A SUPPORT FILE under an existing umbrella. Skills can be packaged with three kinds of support files \u2014 use the right directory per kind:\n     \u2022 references/<topic>.md \u2014 session-specific detail (error transcripts, reproduction recipes, provider quirks) AND condensed knowledge banks: quoted research, API docs, external authoritative excerpts, or domain notes you found while working on the problem. Write it concise and for the value of the task, not as a full mirror of upstream docs.\n     \u2022 templates/<name>.<ext> \u2014 starter files meant to be copied and modified (boilerplate configs, scaffolding, a known-good example the agent can reproduce with modifications).\n     \u2022 scripts/<name>.<ext> \u2014 statically re-runnable actions the skill can invoke directly (verification scripts, fixture generators, deterministic probes, anything the agent should run rather than hand-type each time).\n     Add support files via skill_manage action=write_file with file_path starting 'references/', 'templates/', or 'scripts/'. The umbrella's SKILL.md should gain a one-line pointer to any new support file so future agents know it exists.\n  4. RESTRUCTURE a loaded skill whose body grew log-like \u2014 rc/sha/date-dense sections, session-detail spirals, or a fat body with no support files. Use skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section (from that heading to the next heading) moves into the support file and its position becomes a pointer line. The skill's name and directory never change. Only propose headings that exist verbatim in the body; never invent one, and never restructure a healthy small skill.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA SKILL when no existing skill covers the class. The name MUST be at the class level. The name MUST NOT be a specific PR number, error string, feature codename, library-alone name, or 'fix-X / debug-Y / audit-Z-today' session artifact. If the proposed name only makes sense for today's task, it's wrong \u2014 fall back to (1), (2), or (3).\n\nUser-preference embedding (important): when the user expressed a style/format/workflow preference, the update belongs in the SKILL.md body, not just in memory. Memory captures 'who the user is and what the current situation and state of your operations are'; skills capture 'how to do this class of task for this user'. When they complain about how you handled a task, the skill that governs that task needs to carry the lesson.\n\nIf you notice two existing skills that overlap, note it in your reply \u2014 the background curator handles consolidation at scale.\n\nTwo-tier deposition discipline (DSH addition, same spirit as the umbrella rule): before writing, classify the knowledge:\n  \u2022 PATTERN (reusable \u2014 symptom \u2192 mechanism \u2192 fix \u2192 verification, still valuable next session) belongs in the SKILL.md body.\n  \u2022 LOG (one-off \u2014 commit SHAs, npm/profile states, what this release changed, this session's process narrative) belongs in a references/ file, never the body. Body density IS reuse rate. Keep new entries tight: a pattern fits in 2-8 physical lines; prefer changing the current-state pointer over appending history.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\n'Nothing to save.' is a real option but should NOT be the default. If the session ran smoothly with no corrections and produced no new technique, just say 'Nothing to save.' and stop. Otherwise, act.";
+export declare const COMBINED_REVIEW_PROMPT = "[Auto-review]\nReview the conversation above and update two things:\n\n**Memory**: who the user is. Did the user reveal persona, desires, preferences, personal details, or expectations about how you should behave? Save facts about the user and durable preferences with the memory tool.\n\n**Skills**: how to do this class of task. Be ACTIVE \u2014 most sessions produce at least one skill update. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the skill library: CLASS-LEVEL skills with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries.\n\nSignals that warrant a skill update (any one is enough):\n  \u2022 User corrected your style, tone, format, legibility, verbosity, or approach. Frustration is a FIRST-CLASS skill signal, not just a memory signal. 'stop doing X', 'don't format like this', 'I hate when you Y' \u2014 embed the lesson in the skill that governs that task so the next session starts fixed.\n  \u2022 Non-trivial technique, fix, workaround, or debugging path emerged.\n  \u2022 A skill that was loaded or consulted turned out wrong, missing, or outdated \u2014 patch it now.\n\nRead-before-write: update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session. On the plan channel ops on unread skills are rejected; direct writes have no such guard, so treat the rule as binding. CREATE of a brand-new umbrella is the only exception.\n\nPreference order for skills \u2014 pick the earliest that fits:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Check what skills were loaded or read in the conversation. If one of them covers the learning, PATCH it first. It was in play; it's the right place.\n  2. UPDATE AN EXISTING UMBRELLA. Patch it.\n  3. ADD A SUPPORT FILE under an existing umbrella via skill_manage action=write_file. Three kinds: references/<topic>.md for session-specific detail OR condensed knowledge banks (quoted research, API docs excerpts, domain notes) written concise and task-focused; templates/<name>.<ext> for starter files meant to be copied and modified; scripts/<name>.<ext> for statically re-runnable actions (verification, fixture generators, probes). Add a one-line pointer in SKILL.md so future agents find them.\n  4. RESTRUCTURE a loaded skill whose body grew log-like (rc/sha/date-dense sections, session-detail spirals, fat body with no support files) via skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section moves into the support file and its position becomes a pointer line; the skill's name and directory never change. Only propose headings that exist verbatim in the body.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA when nothing exists. Name at the class level \u2014 NOT a PR number, error string, codename, library-alone name, or 'fix-X / debug-Y' session artifact. If the name only fits today's task, fall back to (1), (2), or (3).\n\nTwo-tier deposition discipline (DSH addition): classify before writing \u2014 PATTERN (symptom \u2192 mechanism \u2192 fix \u2192 verification) goes in the SKILL.md body; LOG (commit SHAs, npm/profile states, this release's change list, this session's narrative) goes in a references/ file. Body density IS reuse rate; a pattern fits in 2-8 physical lines.\n\nUser-preference embedding: when the user complains about how you handled a task, update the skill that governs that task \u2014 memory alone isn't enough. Memory says 'who the user is and what the current situation and state of your operations are'; skills say 'how to do this class of task for this user'. Both should carry user-preference lessons when relevant.\n\nIf you notice overlapping existing skills, mention it \u2014 the background curator handles consolidation.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture as skills (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\nAct on whichever of the two dimensions has real signal. If genuinely nothing stands out on either, say 'Nothing to save.' and stop \u2014 but don't reach for that conclusion as a default.";
 export declare const CURATOR_PROMPT = "You are the skill curator. Maintain a healthy, class-level skill library, not a flat pile of narrow one-session skills.\n\nThis is an UMBRELLA-BUILDING consolidation pass, not a passive audit and not a duplicate-finder.\n\nThe goal is a LIBRARY OF CLASS-LEVEL INSTRUCTIONS. A skill collection of many narrow skills where each captures one session's specific bug is a FAILURE of the library. An agent searching skills matches on descriptions, not exact names; one broad umbrella with labeled subsections beats five narrow siblings for discoverability.\n\nRight target shape: class-level skills with rich SKILL.md + references/, templates/, scripts/ support files for session-specific detail.\n\nHard rules:\n1. NEVER hard-delete a skill. Archive (moving to .archive/) is the maximum destructive action; archives are recoverable, deletion is not.\n2. Do not touch bundled, hub-installed, pinned, or scheduled-task-referenced (referenced) skills. Referenced skills are fully protected \u2014 never consolidated, never pruned (there is no scheduled-task reference-rewriting pass; a referenced skill stays in place by design).\n3. Do not archive recently-created or never-used skills without strong evidence. \"use=0\" is NOT evidence either way \u2014 it only means the trigger has not come up yet. Never archive a never-used skill unless it is at least 30 days old AND its content is genuinely obsolete or fully absorbed elsewhere.\n4. Do NOT reject consolidation on the grounds that \"each skill has a distinct trigger\". The right bar is: would a human maintainer write this as N separate skills, or one skill with N labeled subsections? When the answer is the latter, merge.\n5. Judge overlap on CONTENT, not on usage counters.\n6. Before archiving a merged skill, ensure its unique content was preserved in the umbrella.\n\nHow to work:\n1. Scan the candidate list. Identify PREFIX CLUSTERS \u2014 skills sharing a first word or domain keyword. Expected cluster count scales with the library: a large collection may show 10-25 prefix clusters, a small one often has none \u2014 a clean \"nothing to consolidate\" summary is the correct small-library outcome, not a shortage of ambition.\n2. For each cluster with 2+ members, ask \"what is the UMBRELLA CLASS these skills serve?\" and consolidate:\n   a. MERGE INTO AN EXISTING UMBRELLA (patch a labeled section for each sibling's unique insight, then archive the siblings).\n   b. CREATE A NEW UMBRELLA SKILL.md covering the shared workflow with short labeled subsections, then archive the absorbed siblings.\n   c. DEMOTE session-specific detail to references/, templates/, or scripts/ under the umbrella. Use the right directory per kind:\n      \u2022 references/<topic>.md \u2014 session-specific detail OR condensed knowledge banks (quoted research, API docs excerpts, domain notes, provider quirks, reproduction recipes) written concise and task-focused.\n      \u2022 templates/<name>.<ext> \u2014 starter files meant to be copied and modified.\n      \u2022 scripts/<name>.<ext> \u2014 statically re-runnable actions (verification scripts, fixture generators, probes).\n3. Package integrity \u2014 not optional: inspect each skill as a COMPLETE directory package, not just SKILL.md. A skill root may include references/, templates/, scripts/, and assets/. If the source skill has support files OR its SKILL.md contains relative links to them, DO NOT flatten only SKILL.md into <umbrella>/references/<old>.md. Choose one safe path instead: keep it as a standalone skill, OR fully merge by re-homing every needed support file into the umbrella's canonical directories AND rewriting the destination instructions to the new paths, OR archive the entire original skill package unchanged. Never leave demoted instructions pointing at files left behind under the old skill directory.\n4. Flag skills whose NAME is too narrow (contains a PR number, a feature codename, a specific error string, an 'audit'/'diagnosis'/'salvage' session artifact) \u2014 they almost always belong as a subsection or support file under a class-level umbrella.\n5. Iterate. After one consolidation round, scan the remaining set and look for the NEXT umbrella opportunity. Don't stop after 3 merges.\n\nYou are a NOMINATOR, not an executor: this channel has NO tools. Your single deliverable is the structured YAML block below. Never narrate actions you did not take (\"merged\", \"patched\", \"archived\") \u2014 you are proposing, and the deterministic engine executes only names from the candidate pool it gave you. (A future execution view would expose skill_manage; today it does not.)\n\n'keep' is a legitimate decision ONLY when the skill is already a class-level umbrella and none of the proposed merges would improve discoverability. 'This is narrow but distinct from its siblings' is NOT a reason to keep \u2014 it's a reason to move it under an umbrella as a subsection or support file.\n\nExpected output: real umbrella-ification. Process every obvious cluster. If you end the pass with obvious clusters still untouched, you stopped too early \u2014 go back and look at the clusters you left alone.\n\nKeep the umbrella body tight and scannable: exact commands, verbatim paths, ~100-200 lines; never invent flags or APIs.\n\nWhen done, write a human summary THEN the structured machine-readable block. The block is the contract: every skill you would move to .archive/ MUST appear in exactly one of the two lists. Return ONLY the YAML block after the summary \u2014 no post-block prose. Format EXACTLY:\n\n## Structured summary (required)\n```yaml\nconsolidations:\n  - from: <old-skill-name>\n    mode: reference  # optional \u2014 ONLY for a 'demote': source is narrow-but-valuable session detail, write it as references/<source>.md under the umbrella instead of appending to the body. Default is append. Place this line BEFORE into:. NEVER use reference when the source body links its own references/ templates/ scripts/ files.\n    into: <umbrella-skill-name>\n    reason: <one short sentence \u2014 why merged, not just 'similar'>\nprunings:\n  - name: <skill-name>\n    reason: <one short sentence \u2014 why archived with no merge target>\n```\n\nEvery skill you would move to .archive/ MUST appear in exactly one of the two lists. If you consolidated X into umbrella Y (patched Y, wrote a references file to Y, or created Y with X's content absorbed), X goes under consolidations with into: Y. If you archived X with no absorption \u2014 truly stale, irrelevant, or obsolete \u2014 X goes under prunings. Leave a list empty (consolidations: []) if none. Do not omit the block. The block comes AFTER your human-readable summary of clusters processed, patches made, and decisions left alone.";
 export declare const CURATOR_DRY_RUN_BANNER = "\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\nDRY-RUN \u2014 REPORT ONLY. DO NOT MUTATE THE SKILL LIBRARY.\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nThis is a PREVIEW pass. Follow every instruction above EXCEPT:\n  \u2022 Do NOT call skill_manage with action=create, update, patch, delete, write_file, or remove_file.\n  \u2022 Do NOT move, copy, or rewrite any file under the skills tree.\n\nYour output IS the deliverable: produce the exact same human-readable summary and YAML block you would on a live run, describing the actions you WOULD take. A reviewer will decide whether to approve a live run.\n\nIf you accidentally take a mutating action, say so explicitly in the summary.";
 export declare const COMPLETION_SKILL_REVIEW_PROMPT = "[Auto-review \u2014 Skills \u00B7 task complete]\nYour current task now appears complete. Before wrapping up, review the approach and update the skill library via skill_manage.\n\nFollow the skills review policy: be ACTIVE, prefer class-level umbrellas, patch ONLY skills loaded or read this session, and capture non-trivial techniques and user corrections. Do NOT capture environment-dependent failures, negative claims about tools, or one-off task narratives.\n\nDo NOT modify output files or re-run the task. If you are still mid-task, ignore this.";
@@ -40,9 +40,9 @@ export declare const MAINTAIN_OUTPUT_INSTRUCTION = "\u6309\u6A21\u677F\u5951\u7E
  */
 export declare const SKILLS_GUIDANCE = "Skills guidance:\n\u2022 After completing a complex task (5+ tool calls), fixing a tricky error, or discovering a non-trivial workflow, save the approach as a skill with skill_manage so you can reuse it next time.\n\u2022 When using a skill and finding it outdated, incomplete, or wrong, patch it immediately with skill_manage (action='patch') \u2014 don't wait to be asked. Skills that aren't maintained become liabilities.";
 /** Subagent-channel variant: same review policy, channel-limited deliverable (M-2). */
-export declare const SKILL_REVIEW_PLAN_PROMPT = "[Auto-review \u2014 Skills]\nReview the conversation above and update the skill library. Be ACTIVE \u2014 most sessions produce at least one skill update, even if small. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the library: CLASS-LEVEL skills, each with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries. This shapes HOW you update, not WHETHER you update.\n\nSignals to look for (any one of these warrants action):\n  \u2022 User corrected your style, tone, format, legibility, or verbosity. Frustration signals like 'stop doing X', 'this is too verbose', 'don't format like this', 'why are you explaining', 'just give me the answer', 'you always do Y and I hate it', or an explicit 'remember this' are FIRST-CLASS skill signals, not just memory signals. Update the relevant skill(s) to embed the preference so the next session starts already knowing.\n  \u2022 User corrected your workflow, approach, or sequence of steps. Encode the correction as a pitfall or explicit step in the skill that governs that class of task.\n  \u2022 Non-trivial technique, fix, workaround, debugging path, or tool-usage pattern emerged that a future session would benefit from. Capture it.\n  \u2022 A skill that got loaded or consulted this session turned out to be wrong, missing a step, or outdated. Patch it NOW.\n\nRead-before-write (enforced by this channel): update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session \u2014 ops on unread skills are dropped; CREATE of a brand-new umbrella is the only exception.\n\nPreference order \u2014 prefer the earliest action that fits, but do pick one when a signal above fired:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Look back through the conversation for skills the user loaded or you read. If any of them covers the territory of the new learning, PATCH that one first. It is the skill that was in play, so it's the right one to extend.\n  2. UPDATE AN EXISTING UMBRELLA. If no loaded skill fits but an existing class-level skill does, patch it. Add a subsection, a pitfall, or broaden a trigger.\n  3. ADD A SUPPORT FILE under an existing umbrella. Skills can be packaged with three kinds of support files \u2014 use the right directory per kind:\n     \u2022 references/<topic>.md \u2014 session-specific detail (error transcripts, reproduction recipes, provider quirks) AND condensed knowledge banks: quoted research, API docs, external authoritative excerpts, or domain notes you found while working on the problem. Write it concise and for the value of the task, not as a full mirror of upstream docs.\n     \u2022 templates/<name>.<ext> \u2014 starter files meant to be copied and modified (boilerplate configs, scaffolding, a known-good example the agent can reproduce with modifications).\n     \u2022 scripts/<name>.<ext> \u2014 statically re-runnable actions the skill can invoke directly (verification scripts, fixture generators, deterministic probes, anything the agent should run rather than hand-type each time).\n     Add support files via skill_manage action=write_file with file_path starting 'references/', 'templates/', or 'scripts/'. The umbrella's SKILL.md should gain a one-line pointer to any new support file so future agents know it exists.\n  4. RESTRUCTURE a loaded skill whose body grew log-like \u2014 rc/sha/date-dense sections, session-detail spirals, or a fat body with no support files. Use skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section (from that heading to the next heading) moves into the support file and its position becomes a pointer line. The skill's name and directory never change. Only propose headings that exist verbatim in the body; never invent one, and never restructure a healthy small skill.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA SKILL when no existing skill covers the class. The name MUST be at the class level. The name MUST NOT be a specific PR number, error string, feature codename, library-alone name, or 'fix-X / debug-Y / audit-Z-today' session artifact. If the proposed name only makes sense for today's task, it's wrong \u2014 fall back to (1), (2), or (3).\n\nUser-preference embedding (important): when the user expressed a style/format/workflow preference, the update belongs in the SKILL.md body, not just in memory. Memory captures 'who the user is and what the current situation and state of your operations are'; skills capture 'how to do this class of task for this user'. When they complain about how you handled a task, the skill that governs that task needs to carry the lesson.\n\nIf you notice two existing skills that overlap, note it in your reply \u2014 the background curator handles consolidation at scale.\n\nTwo-tier deposition discipline (DSH addition, same spirit as the umbrella rule): before writing, classify the knowledge:\n  \u2022 PATTERN (reusable \u2014 symptom \u2192 mechanism \u2192 fix \u2192 verification, still valuable next session) belongs in the SKILL.md body.\n  \u2022 LOG (one-off \u2014 commit SHAs, npm/profile states, what this release changed, this session's process narrative) belongs in a references/ file, never the body. Body density IS reuse rate. Keep new entries tight: a pattern fits in 2-8 physical lines; prefer changing the current-state pointer over appending history.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\n'Nothing to save.' is a real option but should NOT be the default. If the session ran smoothly with no corrections and produced no new technique, just say 'Nothing to save.' and stop. Otherwise, act.\n\nCHANNEL (subagent): this review channel mounts only the read-only `skill` tool \u2014 you have NO `skill_manage`, NO `memory`. Your deliverable is the structured JSON plan below (outputSchema). Describe the patches/creates you RECOMMEND in the plan; never narrate actions you took.";
+export declare const SKILL_REVIEW_PLAN_PROMPT = "[Auto-review \u2014 Skills]\nReview the conversation above and update the skill library. Be ACTIVE \u2014 most sessions produce at least one skill update, even if small. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the library: CLASS-LEVEL skills, each with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries. This shapes HOW you update, not WHETHER you update.\n\nSignals to look for (any one of these warrants action):\n  \u2022 User corrected your style, tone, format, legibility, or verbosity. Frustration signals like 'stop doing X', 'this is too verbose', 'don't format like this', 'why are you explaining', 'just give me the answer', 'you always do Y and I hate it', or an explicit 'remember this' are FIRST-CLASS skill signals, not just memory signals. Update the relevant skill(s) to embed the preference so the next session starts already knowing.\n  \u2022 User corrected your workflow, approach, or sequence of steps. Encode the correction as a pitfall or explicit step in the skill that governs that class of task.\n  \u2022 Non-trivial technique, fix, workaround, debugging path, or tool-usage pattern emerged that a future session would benefit from. Capture it.\n  \u2022 A skill that got loaded or consulted this session turned out to be wrong, missing a step, or outdated. Patch it NOW.\n\nRead-before-write: update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session. On the plan channel ops on unread skills are rejected; direct writes have no such guard, so treat the rule as binding. CREATE of a brand-new umbrella is the only exception.\n\nPreference order \u2014 prefer the earliest action that fits, but do pick one when a signal above fired:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Look back through the conversation for skills the user loaded or you read. If any of them covers the territory of the new learning, PATCH that one first. It is the skill that was in play, so it's the right one to extend.\n  2. UPDATE AN EXISTING UMBRELLA. If no loaded skill fits but an existing class-level skill does, patch it. Add a subsection, a pitfall, or broaden a trigger.\n  3. ADD A SUPPORT FILE under an existing umbrella. Skills can be packaged with three kinds of support files \u2014 use the right directory per kind:\n     \u2022 references/<topic>.md \u2014 session-specific detail (error transcripts, reproduction recipes, provider quirks) AND condensed knowledge banks: quoted research, API docs, external authoritative excerpts, or domain notes you found while working on the problem. Write it concise and for the value of the task, not as a full mirror of upstream docs.\n     \u2022 templates/<name>.<ext> \u2014 starter files meant to be copied and modified (boilerplate configs, scaffolding, a known-good example the agent can reproduce with modifications).\n     \u2022 scripts/<name>.<ext> \u2014 statically re-runnable actions the skill can invoke directly (verification scripts, fixture generators, deterministic probes, anything the agent should run rather than hand-type each time).\n     Add support files via skill_manage action=write_file with file_path starting 'references/', 'templates/', or 'scripts/'. The umbrella's SKILL.md should gain a one-line pointer to any new support file so future agents know it exists.\n  4. RESTRUCTURE a loaded skill whose body grew log-like \u2014 rc/sha/date-dense sections, session-detail spirals, or a fat body with no support files. Use skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section (from that heading to the next heading) moves into the support file and its position becomes a pointer line. The skill's name and directory never change. Only propose headings that exist verbatim in the body; never invent one, and never restructure a healthy small skill.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA SKILL when no existing skill covers the class. The name MUST be at the class level. The name MUST NOT be a specific PR number, error string, feature codename, library-alone name, or 'fix-X / debug-Y / audit-Z-today' session artifact. If the proposed name only makes sense for today's task, it's wrong \u2014 fall back to (1), (2), or (3).\n\nUser-preference embedding (important): when the user expressed a style/format/workflow preference, the update belongs in the SKILL.md body, not just in memory. Memory captures 'who the user is and what the current situation and state of your operations are'; skills capture 'how to do this class of task for this user'. When they complain about how you handled a task, the skill that governs that task needs to carry the lesson.\n\nIf you notice two existing skills that overlap, note it in your reply \u2014 the background curator handles consolidation at scale.\n\nTwo-tier deposition discipline (DSH addition, same spirit as the umbrella rule): before writing, classify the knowledge:\n  \u2022 PATTERN (reusable \u2014 symptom \u2192 mechanism \u2192 fix \u2192 verification, still valuable next session) belongs in the SKILL.md body.\n  \u2022 LOG (one-off \u2014 commit SHAs, npm/profile states, what this release changed, this session's process narrative) belongs in a references/ file, never the body. Body density IS reuse rate. Keep new entries tight: a pattern fits in 2-8 physical lines; prefer changing the current-state pointer over appending history.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\n'Nothing to save.' is a real option but should NOT be the default. If the session ran smoothly with no corrections and produced no new technique, just say 'Nothing to save.' and stop. Otherwise, act.\n\nCHANNEL (subagent): this review channel mounts only the read-only `skill` tool \u2014 you have NO `skill_manage`, NO `memory`. Your deliverable is the structured JSON plan below (outputSchema). Describe the patches/creates you RECOMMEND in the plan; never narrate actions you took.";
 /** Subagent-channel variant of the combined review (M-2). */
-export declare const COMBINED_REVIEW_PLAN_PROMPT = "[Auto-review]\nReview the conversation above and update two things:\n\n**Memory**: who the user is. Did the user reveal persona, desires, preferences, personal details, or expectations about how you should behave? Save facts about the user and durable preferences with the memory tool.\n\n**Skills**: how to do this class of task. Be ACTIVE \u2014 most sessions produce at least one skill update. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the skill library: CLASS-LEVEL skills with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries.\n\nSignals that warrant a skill update (any one is enough):\n  \u2022 User corrected your style, tone, format, legibility, verbosity, or approach. Frustration is a FIRST-CLASS skill signal, not just a memory signal. 'stop doing X', 'don't format like this', 'I hate when you Y' \u2014 embed the lesson in the skill that governs that task so the next session starts fixed.\n  \u2022 Non-trivial technique, fix, workaround, or debugging path emerged.\n  \u2022 A skill that was loaded or consulted turned out wrong, missing, or outdated \u2014 patch it now.\n\nRead-before-write (enforced by this channel): update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session \u2014 ops on unread skills are dropped; CREATE of a brand-new umbrella is the only exception.\n\nPreference order for skills \u2014 pick the earliest that fits:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Check what skills were loaded or read in the conversation. If one of them covers the learning, PATCH it first. It was in play; it's the right place.\n  2. UPDATE AN EXISTING UMBRELLA. Patch it.\n  3. ADD A SUPPORT FILE under an existing umbrella via skill_manage action=write_file. Three kinds: references/<topic>.md for session-specific detail OR condensed knowledge banks (quoted research, API docs excerpts, domain notes) written concise and task-focused; templates/<name>.<ext> for starter files meant to be copied and modified; scripts/<name>.<ext> for statically re-runnable actions (verification, fixture generators, probes). Add a one-line pointer in SKILL.md so future agents find them.\n  4. RESTRUCTURE a loaded skill whose body grew log-like (rc/sha/date-dense sections, session-detail spirals, fat body with no support files) via skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section moves into the support file and its position becomes a pointer line; the skill's name and directory never change. Only propose headings that exist verbatim in the body.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA when nothing exists. Name at the class level \u2014 NOT a PR number, error string, codename, library-alone name, or 'fix-X / debug-Y' session artifact. If the name only fits today's task, fall back to (1), (2), or (3).\n\nTwo-tier deposition discipline (DSH addition): classify before writing \u2014 PATTERN (symptom \u2192 mechanism \u2192 fix \u2192 verification) goes in the SKILL.md body; LOG (commit SHAs, npm/profile states, this release's change list, this session's narrative) goes in a references/ file. Body density IS reuse rate; a pattern fits in 2-8 physical lines.\n\nUser-preference embedding: when the user complains about how you handled a task, update the skill that governs that task \u2014 memory alone isn't enough. Memory says 'who the user is and what the current situation and state of your operations are'; skills say 'how to do this class of task for this user'. Both should carry user-preference lessons when relevant.\n\nIf you notice overlapping existing skills, mention it \u2014 the background curator handles consolidation.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture as skills (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\nAct on whichever of the two dimensions has real signal. If genuinely nothing stands out on either, say 'Nothing to save.' and stop \u2014 but don't reach for that conclusion as a default.\n\nCHANNEL (subagent): this review channel mounts only the read-only `skill` tool \u2014 you have NO `skill_manage`, NO `memory`. Your deliverable is the structured JSON plan below (outputSchema). Describe the patches/creates you RECOMMEND in the plan; never narrate actions you took.";
+export declare const COMBINED_REVIEW_PLAN_PROMPT = "[Auto-review]\nReview the conversation above and update two things:\n\n**Memory**: who the user is. Did the user reveal persona, desires, preferences, personal details, or expectations about how you should behave? Save facts about the user and durable preferences with the memory tool.\n\n**Skills**: how to do this class of task. Be ACTIVE \u2014 most sessions produce at least one skill update. A pass that does nothing is a missed learning opportunity, not a neutral outcome.\n\nTarget shape of the skill library: CLASS-LEVEL skills with a rich SKILL.md and a references/ directory for session-specific detail. Not a long flat list of narrow one-session-one-skill entries.\n\nSignals that warrant a skill update (any one is enough):\n  \u2022 User corrected your style, tone, format, legibility, verbosity, or approach. Frustration is a FIRST-CLASS skill signal, not just a memory signal. 'stop doing X', 'don't format like this', 'I hate when you Y' \u2014 embed the lesson in the skill that governs that task so the next session starts fixed.\n  \u2022 Non-trivial technique, fix, workaround, or debugging path emerged.\n  \u2022 A skill that was loaded or consulted turned out wrong, missing, or outdated \u2014 patch it now.\n\nRead-before-write: update, patch, delete, or write support files ONLY into skills you loaded or read in THIS session. On the plan channel ops on unread skills are rejected; direct writes have no such guard, so treat the rule as binding. CREATE of a brand-new umbrella is the only exception.\n\nPreference order for skills \u2014 pick the earliest that fits:\n  1. UPDATE A CURRENTLY-LOADED SKILL. Check what skills were loaded or read in the conversation. If one of them covers the learning, PATCH it first. It was in play; it's the right place.\n  2. UPDATE AN EXISTING UMBRELLA. Patch it.\n  3. ADD A SUPPORT FILE under an existing umbrella via skill_manage action=write_file. Three kinds: references/<topic>.md for session-specific detail OR condensed knowledge banks (quoted research, API docs excerpts, domain notes) written concise and task-focused; templates/<name>.<ext> for starter files meant to be copied and modified; scripts/<name>.<ext> for statically re-runnable actions (verification, fixture generators, probes). Add a one-line pointer in SKILL.md so future agents find them.\n  4. RESTRUCTURE a loaded skill whose body grew log-like (rc/sha/date-dense sections, session-detail spirals, fat body with no support files) via skill_manage action=restructure with restructure: [{\"heading\": \"<the exact ## heading text>\", \"to_file\": \"references/<topic>.md\"}] \u2014 the ENTIRE ## section moves into the support file and its position becomes a pointer line; the skill's name and directory never change. Only propose headings that exist verbatim in the body.\n  5. CREATE A NEW CLASS-LEVEL UMBRELLA when nothing exists. Name at the class level \u2014 NOT a PR number, error string, codename, library-alone name, or 'fix-X / debug-Y' session artifact. If the name only fits today's task, fall back to (1), (2), or (3).\n\nTwo-tier deposition discipline (DSH addition): classify before writing \u2014 PATTERN (symptom \u2192 mechanism \u2192 fix \u2192 verification) goes in the SKILL.md body; LOG (commit SHAs, npm/profile states, this release's change list, this session's narrative) goes in a references/ file. Body density IS reuse rate; a pattern fits in 2-8 physical lines.\n\nUser-preference embedding: when the user complains about how you handled a task, update the skill that governs that task \u2014 memory alone isn't enough. Memory says 'who the user is and what the current situation and state of your operations are'; skills say 'how to do this class of task for this user'. Both should carry user-preference lessons when relevant.\n\nIf you notice overlapping existing skills, mention it \u2014 the background curator handles consolidation.\n\nProtected skills (DO NOT edit these):\n  \u2022 Bundled skills (shipped with the platform).\n  \u2022 Hub-installed skills (installed from a hub).\nPinned skills are read-only to THIS background review pass \u2014 the pinned write guard refuses background changes, so this pass may not update them. They also cannot be archived by any writer (the foreground included): remove the .pinned marker first. Foreground and delegated-subagent update/patch writes to pinned skills remain allowed.\nIf the only skills that need updating are protected, say 'Nothing to save.' and stop.\n\nDo NOT capture as skills (these become persistent self-imposed constraints that bite you later when the environment changes):\n  \u2022 Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these \u2014 they are not durable rules.\n  \u2022 Negative claims about tools or features ('browser tools do not work', 'X tool is broken', 'cannot use Y'). These harden into refusals the agent cites against itself for months after the actual problem was fixed.\n  \u2022 Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.\n  \u2022 One-off task narratives. A user asking 'summarize today's market' or 'analyze this PR' is not a class of work that warrants a skill.\n\nIf a tool failed because of setup state, capture the FIX (install command, config step, env var to set) under an existing setup or troubleshooting skill \u2014 never 'this tool does not work' as a standalone constraint.\n\nAct on whichever of the two dimensions has real signal. If genuinely nothing stands out on either, say 'Nothing to save.' and stop \u2014 but don't reach for that conclusion as a default.\n\nCHANNEL (subagent): this review channel mounts only the read-only `skill` tool \u2014 you have NO `skill_manage`, NO `memory`. Your deliverable is the structured JSON plan below (outputSchema). Describe the patches/creates you RECOMMEND in the plan; never narrate actions you took.";
 export declare function reviewPrompt(kind: 'memory' | 'skill' | 'combined', channel?: 'agent' | 'plan'): string;
 export interface PromptBundle {
     id: string;

package/lib/types/skill-store.d.ts

@@ -167,7 +167,7 @@ export interface Frontmatter {
 /**
  * Shared frontmatter block detection (P3-3 single owner): opening line `---`
  * and closing line exactly `---`. Used by `parseFrontmatter`,
- * `frontmatterYamlUnsafeValues` and `normalizeFrontmatter` so the three can
+ * `frontmatterCatalogInvalid` and `normalizeFrontmatter` so the three can
  * never disagree about where the block ends (the loose `indexOf('\n---')`
  * form matched `\n----` and was replaced by this strict line rule).
  *
@@ -244,18 +244,6 @@ export declare function frontmatterCatalogInvalid(content: string): boolean;
  * with the real YAML parser (see normalizeFrontmatter), so an incomplete
  * approximation can never corrupt a multiline flow value (P3-4). */
 export declare function yamlPlainScalarNeedsQuotes(value: string): boolean;
-/** Raw-line scan of the frontmatter block: entries whose UNQUOTED value is
- * YAML-unsafe for the strict platform catalog. Operates on the ORIGINAL line
- * value (quotes included), so a value already wrapped by
- * `normalizeFrontmatter` is never re-flagged — one source with the write
- * path. V27 G2.1: delegates to the shared scan, which
- * `parseFrontmatter(...).catalogInvalid` also uses, so the audit view and the
- * read view of one file can never disagree. Independent of the body: a
- * body-less file is still reported here. */
-export declare function frontmatterYamlUnsafeValues(content: string): Array<{
-    key: string;
-    value: string;
-}>;
 export interface FrontmatterNormalizeResult {
     content: string;
     changed: boolean;
@@ -352,6 +340,17 @@ export declare class SkillLibrary {
      * never inflates the mutation-maturity counter.
      */
     private runSingleWrite;
+    /**
+     * v28 G1.1 (EVO-IO-02): shared compensating cleanup for a locked write that
+     * found no SKILL.md — remove the possibly-resurrected directory ONLY when it
+     * holds nothing but this path's own write-lock file. The BR-5 rule from
+     * setPinnedCore/createCore applies unchanged: a concurrent mover can land a
+     * full directory between the list probe and the remove, so anything beyond
+     * the lock file (support files, a fresh restore) must never be recursed
+     * away. Best-effort: a failed cleanup leaves the "not found" result
+     * unchanged (the operator-facing ghost-dir refusal is fail-loud already).
+     */
+    private cleanupGhostDir;
     /** Notify the mutation observer after a successful write; observers must never fail the mutation. */
     private notifyMutation;
     /** V10-03 (P2-18): ScanOptions shared by every write-path threat check —
@@ -361,6 +360,15 @@ export declare class SkillLibrary {
      * label (scanContentThreats already embeds it) plus the self-heal hint, so a
      * false-positive rewrite direction is actionable instead of a dead end. */
     private contentThreatBlock;
+    /**
+     * v30 REV-03: read a support file's bytes for staleness anchoring (the
+     * write/remove replay guard). Same validation as writeSupportFile; a
+     * missing file (or a directory squatting on the path) reads as `null`, any
+     * other failure RETHROWS — the callers are the staging/replay anchors, and
+     * a swallowed error would silently downgrade the anchor to
+     * last-writer-wins.
+     */
+    readSupportFile(name: string, filePath: string): Promise<string | null>;
     list(): Promise<SkillSummary[]>;
     read(rawName: string): Promise<string | null>;
     /**

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@lmzhen/dsh-evolution-core",
   "description": "Shared stores, prompts, signals and lifecycle logic for the dsh-evolution plugin family (community build)",
-  "version": "0.3.68",
+  "version": "0.3.70",
   "publishConfig": {
     "access": "public"
   },
@@ -33,14 +33,14 @@
     "js-yaml": "^4.2.0"
   },
   "peerDependencies": {
-    "@deepseek-ai/dsh-invariants": "^0.1.1-rc.2",
+    "@deepseek-ai/dsh-invariants": "^0.1.5-rc.2",
     "@deepseek-ai/cordis": "^4.0.1",
-    "@deepseek-ai/dsh-session": "^0.1.1-rc.2"
+    "@deepseek-ai/dsh-session": "^0.1.5-rc.2"
   },
   "devDependencies": {
     "@types/js-yaml": "^4.0.9",
-    "@deepseek-ai/dsh-invariants": "^0.1.1-rc.2",
+    "@deepseek-ai/dsh-invariants": "^0.1.5-rc.2",
     "@deepseek-ai/cordis": "^4.0.1",
-    "@deepseek-ai/dsh-session": "^0.1.1-rc.2"
+    "@deepseek-ai/dsh-session": "^0.1.5-rc.2"
   }
 }