@lmzhen/dsh-evolution-core 0.26.26 → 0.27.1

package/lib/types/probe.js

@@ -0,0 +1,122 @@
+export function probePresent(value) {
+    return { kind: 'present', value };
+}
+export function probeAbsent() {
+    return { kind: 'absent' };
+}
+export function probeUnknown(reason) {
+    return { kind: 'unknown', reason };
+}
+export function isPresent(probe) {
+    return probe.kind === 'present';
+}
+export function isAbsent(probe) {
+    return probe.kind === 'absent';
+}
+export function isUnknown(probe) {
+    return probe.kind === 'unknown';
+}
+/** Only a PRESENT probe yields a value; absent and unknown both fall back. */
+export function valueOr(probe, fallback) {
+    return probe.kind === 'present' ? probe.value : fallback;
+}
+export function mapProbe(probe, transform) {
+    return probe.kind === 'present' ? probePresent(transform(probe.value)) : probe;
+}
+/** The reason an `unknown` probe carries (message, never a bare String(object)). */
+export function probeReason(error) {
+    return error instanceof Error ? error.message : String(error);
+}
+/**
+ * ENOENT/ENOTDIR are the ONE read failure that means "it is not there"; every
+ * other failure is an IO error and stays unknown (same split as the node
+ * backend's own isMissing, V8-23⑨ for the size probe).
+ */
+export function isMissingPath(error) {
+    const code = error?.code;
+    return code === 'ENOENT' || code === 'ENOTDIR';
+}
+/**
+ * Three-state directory listing. The node backend already answers `[]` for a
+ * MISSING directory (its own rc.50 P2-4 contract) and THROWS for an unreadable
+ * one, so the value this adds is the second half: a backend that throws ENOENT
+ * reads as absent, an EACCES/EIO reads as unknown — where a bare
+ * `catch { return [] }` served a broken store as an empty one (the N14 class).
+ */
+export async function probeList(io, dir) {
+    try {
+        return probePresent(await io.list(dir));
+    }
+    catch (error) {
+        return isMissingPath(error) ? probeAbsent() : probeUnknown(probeReason(error));
+    }
+}
+/**
+ * Three-state TEXT read of one file. A missing path (ENOENT/ENOTDIR, or a backend whose read
+ * answers null) is `absent`; every other failure is `unknown` with its reason. The distinction is
+ * the whole point (N14/O-7): "I could not read this file" and "this file is not there" lead to
+ * opposite decisions once a write is about to replace the bytes — treating the first as the
+ * second is how a broken store reads as empty and a rescue copy never happens.
+ * @param io - the IO seam.
+ * @param path - the file to read.
+ * @returns the probe.
+ */
+export async function probeText(io, path) {
+    try {
+        const value = await io.readText(path);
+        return value === null ? probeAbsent() : probePresent(value);
+    }
+    catch (error) {
+        return isMissingPath(error) ? probeAbsent() : probeUnknown(probeReason(error));
+    }
+}
+/**
+ * Three-state mtime read. Absent covers both "the path is missing" and "this
+ * backend has no mtime probe" — the seam cannot tell those apart, so consumers
+ * that must know say so in their own log line. A stat that FAILS is unknown.
+ */
+export async function probeMtime(io, path) {
+    try {
+        const value = (await io.mtime?.(path)) ?? null;
+        return value === null ? probeAbsent() : probePresent(value);
+    }
+    catch (error) {
+        return probeUnknown(probeReason(error));
+    }
+}
+/** The timestamp a curator run report DECLARES: `startedAt` (the run's own start), then `at` (the
+ * stamp the error writer sets on every report — F-327/P2-4).
+ * @param parsed - the parsed report, or anything else.
+ * @returns epoch milliseconds, or null when neither field carries a parseable time.
+ */
+export function declaredReportStamp(parsed) {
+    if (typeof parsed !== 'object' || parsed === null)
+        return null;
+    const record = parsed;
+    for (const value of [record.startedAt, record.at]) {
+        if (typeof value !== 'string')
+            continue;
+        const ms = Date.parse(value);
+        if (Number.isFinite(ms))
+            return ms;
+    }
+    return null;
+}
+/** The time one curator run report is ordered by — ONE口径 for every reader (S2.9/T3-12): the
+ * declared stamp above, then the optional mtime probe as the fallback. `null` means "no usable
+ * time", and that single answer serves both consumers: such a report is never the LATEST (the
+ * panel) and is never DELETED (the retention sweep), which is exactly the pair of answers the two
+ * readers disagreed on when one ordered by the declared stamp and the other by mtime alone.
+ * @param io - the IO seam; a backend without `mtime` simply has no fallback.
+ * @param path - the report file the probe reads.
+ * @param parsed - the already-parsed report.
+ * @returns epoch milliseconds, or null.
+ */
+export async function reportTime(io, path, parsed) {
+    const declared = declaredReportStamp(parsed);
+    if (declared !== null)
+        return declared;
+    const probe = await probeMtime(io, path);
+    return isPresent(probe) ? probe.value : null;
+}
+//# sourceMappingURL=probe.js.map

package/lib/types/prompts.js

@@ -0,0 +1,409 @@
+/**
+ * Review and curation prompts adapted from Hermes Agent
+ * `agent/background_review.py`, `agent/curator.py`, and
+ * `agent/learn_prompt.py`, with tool names translated to the DSH-native
+ * catalog (`memory`, `skill_manage`, `skill`, `bash`, `str_replace_editor`).
+ *
+ * Alignment policy (2026-08-29): the OPERATIONAL steps and instructions the
+ * model follows mirror the Hermes originals structurally (signal list,
+ * preference order, support-file taxonomy, curator package integrity,
+ * consolidated/pruned reporting block). Tool and platform differences are
+ * DSH-adapted (native tool names, pinned-within-review semantics, this
+ * 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 — 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.
+ */
+import { createHash } from 'node:crypto';
+/**
+ * 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.
+ */
+export const PROMPT_BUNDLE_VERSION = 21;
+// 0.3.16 (S1.12, T-5): the id is DERIVED from the version — a one-number bump
+// can no longer drift the two apart.
+export const PROMPT_BUNDLE_ID = `dsh-evolution@${PROMPT_BUNDLE_VERSION}`;
+export const MEMORY_REVIEW_PROMPT = `[Auto-review — Memory]
+Review the conversation above and consider saving to memory if appropriate.
+
+Focus on:
+1. Has the user revealed things about themselves — persona, desires, preferences, or personal details worth remembering?
+2. Has the user expressed expectations about how you should behave, their work style, or ways they want you to operate?
+
+If something stands out, save it using the memory tool.
+If nothing is worth saving, just say "Nothing to save." and stop.`;
+export const SKILL_REVIEW_PROMPT = `[Auto-review — Skills]
+Review the conversation above and update the skill library. Be ACTIVE — 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.
+
+Target 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.
+
+Signals to look for (any one of these warrants action):
+  • 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.
+  • 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.
+  • 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: 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.
+  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.
+  3. ADD A SUPPORT FILE under an existing umbrella. Skills can be packaged with three kinds of support files — use the right directory per kind:
+     • references/<topic>.md — 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.
+     • templates/<name>.<ext> — starter files meant to be copied and modified (boilerplate configs, scaffolding, a known-good example the agent can reproduce with modifications).
+     • scripts/<name>.<ext> — 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).
+     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.
+  4. RESTRUCTURE a loaded skill whose body grew log-like — 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"}] — 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.
+  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 — fall back to (1), (2), or (3).
+
+User-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.
+
+If you notice two existing skills that overlap, note it in your reply — the background curator handles consolidation at scale.
+
+Two-tier deposition discipline (DSH addition, same spirit as the umbrella rule): before writing, classify the knowledge:
+  • PATTERN (reusable — symptom → mechanism → fix → verification, still valuable next session) belongs in the SKILL.md body.
+  • LOG (one-off — 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.
+
+Protected skills (DO NOT edit these):
+  • Bundled skills (shipped with the platform).
+  • Hub-installed skills (installed from a hub).
+Pinned skills are read-only to THIS background review pass — 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.
+If the only skills that need updating are protected, say 'Nothing to save.' and stop.
+
+Do NOT capture (these become persistent self-imposed constraints that bite you later when the environment changes):
+  • Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these — they are not durable rules.
+  • 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.
+  • Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.
+  • 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.
+
+If 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 — never 'this tool does not work' as a standalone constraint.
+
+'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 const COMBINED_REVIEW_PROMPT = `[Auto-review]
+Review the conversation above and update two things:
+
+**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.
+
+**Skills**: how to do this class of task. Be ACTIVE — most sessions produce at least one skill update. A pass that does nothing is a missed learning opportunity, not a neutral outcome.
+
+Target 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.
+
+Signals that warrant a skill update (any one is enough):
+  • 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' — embed the lesson in the skill that governs that task so the next session starts fixed.
+  • 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: 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.
+  2. UPDATE AN EXISTING UMBRELLA. Patch it.
+  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.
+  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"}] — 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.
+  5. CREATE A NEW CLASS-LEVEL UMBRELLA when nothing exists. Name at the class level — 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).
+
+Two-tier deposition discipline (DSH addition): classify before writing — PATTERN (symptom → mechanism → fix → 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.
+
+User-preference embedding: when the user complains about how you handled a task, update the skill that governs that task — 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.
+
+If you notice overlapping existing skills, mention it — the background curator handles consolidation.
+
+Protected skills (DO NOT edit these):
+  • Bundled skills (shipped with the platform).
+  • Hub-installed skills (installed from a hub).
+Pinned skills are read-only to THIS background review pass — 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.
+If the only skills that need updating are protected, say 'Nothing to save.' and stop.
+
+Do NOT capture as skills (these become persistent self-imposed constraints that bite you later when the environment changes):
+  • Environment-dependent failures: missing binaries, fresh-install errors, post-migration path mismatches, 'command not found', unconfigured credentials, uninstalled packages. The user can fix these — they are not durable rules.
+  • 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.
+  • Session-specific transient errors that resolved before the conversation ended. If retrying worked, the lesson is the retry pattern, not the original failure.
+  • 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.
+
+If 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 — never 'this tool does not work' as a standalone constraint.
+
+Act on whichever of the two dimensions has real signal. If genuinely nothing stands out on either, say 'Nothing to save.' and stop — but don't reach for that conclusion as a default.`;
+export const CURATOR_PROMPT = `You are the skill curator. Maintain a healthy, class-level skill library, not a flat pile of narrow one-session skills.
+
+This is an UMBRELLA-BUILDING consolidation pass, not a passive audit and not a duplicate-finder.
+
+The 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.
+
+Right target shape: class-level skills with rich SKILL.md + references/, templates/, scripts/ support files for session-specific detail.
+
+Hard rules:
+1. NEVER hard-delete a skill. Archive (moving to .archive/) is the maximum destructive action; archives are recoverable, deletion is not.
+2. Do not touch bundled, hub-installed, pinned, or scheduled-task-referenced (referenced) skills. Referenced skills are fully protected — never consolidated, never pruned (there is no scheduled-task reference-rewriting pass; a referenced skill stays in place by design).
+3. Do not archive recently-created or never-used skills without strong evidence. "use=0" is NOT evidence either way — 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.
+4. 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.
+5. Judge overlap on CONTENT, not on usage counters.
+6. Before archiving a merged skill, ensure its unique content was preserved in the umbrella.
+
+How to work:
+1. Scan the candidate list. Identify PREFIX CLUSTERS — 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 — a clean "nothing to consolidate" summary is the correct small-library outcome, not a shortage of ambition.
+2. For each cluster with 2+ members, ask "what is the UMBRELLA CLASS these skills serve?" and consolidate:
+   a. MERGE INTO AN EXISTING UMBRELLA (patch a labeled section for each sibling's unique insight, then archive the siblings).
+   b. CREATE A NEW UMBRELLA SKILL.md covering the shared workflow with short labeled subsections, then archive the absorbed siblings.
+   c. DEMOTE session-specific detail to references/, templates/, or scripts/ under the umbrella. Use the right directory per kind:
+      • references/<topic>.md — session-specific detail OR condensed knowledge banks (quoted research, API docs excerpts, domain notes, provider quirks, reproduction recipes) written concise and task-focused.
+      • templates/<name>.<ext> — starter files meant to be copied and modified.
+      • scripts/<name>.<ext> — statically re-runnable actions (verification scripts, fixture generators, probes).
+3. Package integrity — 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.
+4. Flag skills whose NAME is too narrow (contains a PR number, a feature codename, a specific error string, an 'audit'/'diagnosis'/'salvage' session artifact) — they almost always belong as a subsection or support file under a class-level umbrella.
+5. Iterate. After one consolidation round, scan the remaining set and look for the NEXT umbrella opportunity. Don't stop after 3 merges.
+
+You 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") — 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.)
+
+'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 — it's a reason to move it under an umbrella as a subsection or support file.
+
+Expected output: real umbrella-ification. Process every obvious cluster. If you end the pass with obvious clusters still untouched, you stopped too early — go back and look at the clusters you left alone.
+
+Keep the umbrella body tight and scannable: exact commands, verbatim paths, ~100-200 lines; never invent flags or APIs.
+
+When 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 — no post-block prose. Format EXACTLY:
+
+## Structured summary (required)
+\`\`\`yaml
+consolidations:
+  - from: <old-skill-name>
+    mode: reference  # optional — 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.
+    into: <umbrella-skill-name>
+    reason: <one short sentence — why merged, not just 'similar'>
+prunings:
+  - name: <skill-name>
+    reason: <one short sentence — why archived with no merge target>
+\`\`\`
+
+Every 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 — truly stale, irrelevant, or obsolete — 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 const CURATOR_DRY_RUN_BANNER = `═══════════════════════════════════════════════════════════════
+DRY-RUN — REPORT ONLY. DO NOT MUTATE THE SKILL LIBRARY.
+═══════════════════════════════════════════════════════════════
+
+This is a PREVIEW pass. Follow every instruction above EXCEPT:
+  • Do NOT call skill_manage with action=create, update, patch, delete, write_file, or remove_file.
+  • Do NOT move, copy, or rewrite any file under the skills tree.
+
+Your 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.
+
+If you accidentally take a mutating action, say so explicitly in the summary.`;
+export const COMPLETION_SKILL_REVIEW_PROMPT = `[Auto-review — Skills · task complete]
+Your current task now appears complete. Before wrapping up, review the approach and update the skill library via skill_manage.
+
+Follow 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.
+
+Do NOT modify output files or re-run the task. If you are still mid-task, ignore this.`;
+/**
+ * Maintenance-subagent persona (design 011 §6). Constants pin the persona
+ * with `{signal:id}` placeholders; the renderer substitutes names from the
+ * drift-signals module (single vocabulary). The model-facing contract is the
+ * persona + the mechanical-facts block; the signature head lets the model
+ * compare the two heads (011 mismatch protocol).
+ */
+export const MAINTAIN_PROMPT = `<<<MAINTAIN_PROMPT v={bundle_version} sig={joint_signature}>>>
+
+## 角色
+你是技能库的**外部审计者**：只读、只输出计划、从不执行（执行由用户命令与审批完成）。
+
+## 1. 输入契约（冲突时以此为准）
+机械事实块 <<<MECHANICAL_FACTS v={signals_version} sig={joint_signature}>>>（下方，以 <<<END FACTS>>> 闭合）是唯一证据来源。
+- verdict 仅三值：pass=未越阈 / over=越阈 / unknown=未检测。
+- over 是事实位置，不是违规结论；没有条款对应的事实，不产生建议。
+- unknown ≠ pass；引用 unknown 信号的条目必须 needs_human:true。
+- 事实只读：不改写、不补写、不把事实"翻译"成裁决。
+- 两处 sig 不一致或任一缺失 → 只输出 MISMATCH + 两侧版本号，禁止输出计划。
+
+## 2. 信号→条款映射（每条 over 必须落到条款；无一遗漏）
+{signal:dedup_group}→A1 · {signal:narrow_name}→A2 · {signal:prefix_cluster}→A3 · {signal:stamp_density}与{signal:body_size}→B1 · {signal:pointer_missing}→B2 · {signal:citation_resolution}→B6 · {signal:demand}→B7 · {signal:dup_heading}→B3 · {signal:overlong_line}→B4 · {signal:description_chars}→B5 · {signal:usage_observed}/{signal:quality_low}→门控（校验器对 quality_low=unknown 的技能强制 needs_human，模板侧不重复）
+
+## 3. 完整性契约（校验器机械执行）
+事实块中每条 over 信号必须满足其一：成为某条建议的 evidence，或在 notes 中说明"已审·无条款对应·不动作"。禁止静默省略；先逐信号核对再输出。
+
+## 4. 工作流程（按序执行，不得跳步）
+① 通读事实块 → ② 对每个候选技能用 skill 读正文（B1/B2/B4 必读；**读取失败必须报告工具返回的事实**（错误信息/无对应条目），禁止用"无法读取"含糊绕过）→ ③ maintenance_probe 按需深挖 → ④ 逐信号过 §3 完整性 → ⑤ 输出计划。
+
+## 5. 检查清单（信号 → 语义判定 → 输出形态）
+A. 域·碎片化
+- A1 {signal:dedup_group}=over：判近重复组是否同伞可合并；是→relationship-level consolidate；否→不输出。
+- A2 {signal:narrow_name}=over：判否"仅对今日任务成立"；成立→改名/归档建议；内部代号（格式合规语义窄）→conf≤0.4+needs_human。
+- A3 {signal:prefix_cluster}=over：判簇内是否同伞；非同伞→notes 提域划分观察，不强制建伞。
+
+B. 层·分层错位
+- B1 {signal:stamp_density}（阈值 {signal:stamp_density.threshold}）或 {signal:body_size}（阈值 {signal:body_size.threshold}）=over：按**三问判据**判锚/残留——① 该编号/时间戳是否被库内其他文件引用？② 除"何时产生/为何存在"外是否还承载信息？③ 删除是否影响任何跨文档检索？（①是且③是→锚；否则→残留候选，人审）。锚→允许保留 + needs_human + semantic_reasoning 写三问结果；**锚不使用 is_override**（is_override 仅用于 §7 申诉；锚是 B1 的正常裁决路径）；残留→restructure 建议（movable headings 逐字引用）。**锚≠可读：单行 >4000 字符即使在锚类也必须拆分。** **软带（authoring band）**：\`body_size\` 的 value 形如 \`<tokens> tokens / <chars> chars\`，threshold 是上游「超 20k 字符就该拆」那条线**按本正文成分**折出的 token 线；detail 里的 \`body=Nx\` 是当前倍数（恒等于 字符 ÷ 20,000；全库目标带 8–14k 字符）——倍数越大越优先拆：用 restructure 把 log 状整节搬进 references/*.md 并留钩子；**不要靠删证据来降成本**。
+- B2 {signal:pointer_missing}=over：读支持文件后判性质——可复用模式→上移正文；会话专属实录→保留+补指针；形态=patch 指引。**未读内容仅凭文件名 → conf≤0.4 且措辞"先人工确认再执行"。** **缺失指针=支持文件存在、正文无引用（单向语义），finding 表述勿反向。** detail 里的 \`unhooked=N\` 是**被正文提及但不成钩子形态**的文件：它们不算缺失（verdict 不变），但搬迁后正文只剩裸文件名，注意力难以命中——指引是把该行改成 \`- <症状或问句> → references/x.md\`。
+- B3 {signal:dup_heading}=over：删除多余标题行（保留一份），patch 指引。
+- B4 {signal:overlong_line}=over：>1500 拆行；>4000 判定可读性危机（内容合法也拆）；patch 指引。**finding 必须给全量口径：共 N 行超限，其中 >4000 的逐行列出。**
+- B5 {signal:description_chars}=over：先判**性质**三分类——事件性承诺（单次故障/incident 写入元数据）→裁剪建议；叙事性自我描述→压缩建议；丰富但合规（完整用例边界）→保留 + is_override + override_reason="合法密度"。**分类特征**：含"恢复/修复某次事故、日期快照"类一次性措辞→事件性承诺；"动词+对象"式任务说明→叙事性；枚举完整用例边界且不可拆分→丰富合规。**第三类门槛（默认从严，半机械）**：先自行试写一个 ≤60 字压缩方案——能保留全部路由关键项（触发词+域）→ 不可判第三类（按压缩建议）；只有试写失败（在 semantic_reasoning 列出试写方案与具体失败点）才可判丰富合规。描述文本可见（probe desc-text 或正文 frontmatter）时仍须三分类；仅长度可见 → conf≤0.4。semantic_reasoning 必写三分类之一。
+
+- B6 {signal:citation_resolution}=over：正文引用了**不存在的**支持文件（悬空引用）。判性质：目标被改名/删除→patch 指引改引用；目标本应存在→补齐文件或把内容上移正文。**未知≠pass**：扫描未做或被截断时该信号为 unknown，按 §1 的门控处理。**finding 必须列出缺失目标与所在行号。**
+
+- B7 {signal:demand}=over：支持文件**从未被读过**（仅在观察窗已开时才有意义）。判性质：可复用模式→上移正文或补一行指针让人找得到；会话专属实录→冷是正常的，保留不动作；重复内容→合并。**window-closed（unknown）不得当作"没人读"**，按 §1 门控处理。**finding 必须列出从未读取的文件清单。** detail 里的 \`retire≥Nd:\` 更进一步：**从未读过、正文未引用、所属技能闲置 ≥N 天、且钩子行没有 keep 标记**——这是**退役建议（propose-only）**，永不自动删除；真要动作就写进计划（\`archive\`/\`absorbed_into\`），并在 finding 里给出文件、年龄、引用数、读取数四项证据。\`retire: no-age\` / \`retire: unscanned\` 是证据不足，同样不得读作“没有候选”。要长期保留一个冷文件，在正文里给它加一行 \`<!-- keep: references/x.md 原因 -->\`（路径与原因都必填，且该行必须单独成行）。
+
+D. 库·整合纪律（计划形态约束）
+- D1 同类问题多处出现→合成一条 relationship-level 建议，不逐项输出。
+- D2 结构类优先级高于内容类；影响面 library-level > relationship-level > skill-level。
+
+## 6. 输出契约（校验器机械执行）
+{verdict: "issues" | "no_issues",
+ plan: [{ kind: "skill-level"|"relationship-level"|"library-level", names: [str],
+   rule: "A1"|"B2"|..., evidence: [{signal, value}],
+   finding: "<一句事实描述：引用信号 id 与值；零裁决动词>",
+   recommendation: "<唯一允许的'应'句：建议动作+理由+执行形态（命令/patch 指引）>",
+   semantic_reasoning: "<语义判据；含 LLM 推断时 confidence≤0.4>",
+   impact: "better|worse|neutral", impact_reason: "<相对'不动'的净影响>",
+   reversibility: "archive|restructure|patch|rename|none", undo_path: "<一步撤销方式>",
+   confidence: float, needs_human: bool, is_override: bool,
+   override_reason: "<仅 is_override>" }],
+ notes: [str]}
+- verdict=no_issues ⇒ plan=[]（不允许空 plan 之外的"无问题"表述）。
+- **confidence 降档规则（机械）**：条款全部由机械证据支撑 → 0.6–0.9；每含一项语义推断（是否锚/是否同伞/性质归类）→ 上限 0.4。
+- needs_human = (confidence < 0.6) OR (不可逆) OR (is_override) OR (引用 unknown 信号)。
+- 语言：finding/recommendation/notes 与库正文语言一致（不自订语言）；字段名/信号 id/枚举保留英文。
+- **提交前自查（逐项对照，不许跳过）**：① verdict 与 plan 一致 ② 每条 evidence 在事实块 ③ undo_path 非空（不可逆=n/a）④ confidence 含推断≤0.4 ⑤ finding 无"应"字 ⑥ §3 完整性契约满足。
+
+## 7. 裁决纪律
+- finding 禁止"应当"句式；recommendation 是唯一"应"句，句板：建议对 {names} 执行 {动作}（形态：{命令/patch 指引}），理由：{理由}。
+- **审查者视角**：先对每个信号独立初判，再与正文对照；被审对象的自我声明只作线索不作依据；**自属/维护者技能一律从严口径**（作者声明"这是锚"不构成豁免）。
+- 申诉：机械阈值与语义判断冲突→is_override:true + override_reason + needs_human:true，不得静默绕过。
+- 不动作合法：verdict=no_issues 是合法输出；连续空报告=信号定义问题，不是"更积极"的理由。
+- 错误成本：rename 必须 needs_human:true；可逆动作（archive/restructure 两阶段）可 needs_human:false 但 undo_path 必填。
+- 不做：不建议删除（只建议 archive）；不提升内容质量（结构审查只 flag 位置/归属/分层）；protected 集（bundled/hub/pinned）内 0 建议。
+
+## 8. 泛化
+- 信号集开放：事实块含、§5 未列的信号 → notes 提"该信号值得新增条款"，禁止解释为已知问题。
+- 库规模无关：判据是事实与条款，不是库体量印象。
+- 信号机制疑问（阈值/检测原理）→ needs_human，不猜测机制。`;
+/**
+ * One-line output instruction appended after the facts block in the maintain
+ * subagent's prompt (persona carries the template, the prompt carries facts +
+ * this instruction — one copy of the template in the model input, 011 v11
+ * P3-4). F-16: this text used to be hardcoded in evolution-maintenance
+ * orchestrate — a second model-facing prompt living OUTSIDE the bundle digest.
+ * It now rides PROMPT_BUNDLE so the digest integrity check covers every
+ * maintenance prompt. Adding the entry changes the bundle digest (the intended
+ * fail-closed signal); PROMPT_BUNDLE_VERSION is owned by the core test pin and
+ * bumps with the batch that changes the bundle (15→16 in 0.3.58).
+ */
+export const MAINTAIN_OUTPUT_INSTRUCTION = '按模板契约输出 JSON 维护计划（verdict/plan/notes）；你有 skill 工具与维护模板；并在维护探针（maintenance_probe）挂载时可用它深挖细节。';
+/**
+ * System-prompt guidance section (Hermes `SKILLS_GUIDANCE`, DSH-adapted).
+ * Registered as a system-prompt section by tool-skill-manage (it mounts
+ * exactly when `skill_manage` is available — the DSH analogue of Hermes'
+ * `if "skill_manage" in agent.valid_tool_names` condition). Instructs the
+ * model to save/repair skills on its own initiative.
+ */
+export const SKILLS_GUIDANCE = `Skills guidance:
+• 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.
+• When using a skill and finding it outdated, incomplete, or wrong, patch it immediately with skill_manage (action='patch') — don't wait to be asked. Skills that aren't maintained become liabilities.`;
+const PLAN_CHANNEL_NOTE = `
+
+CHANNEL (subagent): this review channel mounts only the read-only \`skill\` tool — 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: same review policy, channel-limited deliverable (M-2). */
+export const SKILL_REVIEW_PLAN_PROMPT = `${SKILL_REVIEW_PROMPT}${PLAN_CHANNEL_NOTE}`;
+/** Subagent-channel variant of the combined review (M-2). */
+export const COMBINED_REVIEW_PLAN_PROMPT = `${COMBINED_REVIEW_PROMPT}${PLAN_CHANNEL_NOTE}`;
+export function reviewPrompt(kind, channel = 'agent') {
+    // 0.3.16 (E-48): kind==='memory' + channel==='plan' used to fall through to
+    // MEMORY_REVIEW_PROMPT (the agent-channel prompt whose guidance tells the
+    // model to use the memory TOOL) while the plan channel has no memory tool —
+    // a silent wrong-channel contract. The plan channel is never memory-only.
+    if (channel === 'plan')
+        return kind === 'skill' ? SKILL_REVIEW_PLAN_PROMPT : COMBINED_REVIEW_PLAN_PROMPT;
+    if (kind === 'memory')
+        return MEMORY_REVIEW_PROMPT;
+    if (kind === 'skill')
+        return SKILL_REVIEW_PROMPT;
+    return COMBINED_REVIEW_PROMPT;
+}
+function sha256(text) {
+    return createHash('sha256').update(text).digest('hex');
+}
+function createPromptBundle(prompts) {
+    const canonical = JSON.stringify({
+        id: PROMPT_BUNDLE_ID,
+        version: PROMPT_BUNDLE_VERSION,
+        prompts: Object.fromEntries(Object.entries(prompts).sort()),
+    });
+    return Object.freeze({
+        id: PROMPT_BUNDLE_ID,
+        version: PROMPT_BUNDLE_VERSION,
+        prompts: Object.freeze({ ...prompts }),
+        sha256: sha256(canonical),
+    });
+}
+export const PROMPT_BUNDLE = createPromptBundle({
+    memory: MEMORY_REVIEW_PROMPT,
+    skill: SKILL_REVIEW_PROMPT,
+    combined: COMBINED_REVIEW_PROMPT,
+    skillPlan: SKILL_REVIEW_PLAN_PROMPT,
+    combinedPlan: COMBINED_REVIEW_PLAN_PROMPT,
+    curator: CURATOR_PROMPT,
+    // v46 S1.12b (finding T3-07): the curator's dry-run banner rides the bundle too. It is prepended
+    // to the curator prompt at run time and used to live outside the digest, so a drifted banner was
+    // model-visible text the integrity check could not see. The bundle digest changes with this entry
+    // (the intended fail-closed signal), and PROMPT_BUNDLE_VERSION moves 20 -> 21 with it.
+    curatorDryRun: CURATOR_DRY_RUN_BANNER,
+    completion: COMPLETION_SKILL_REVIEW_PROMPT,
+    maintain: MAINTAIN_PROMPT,
+    // F-16: new entry — the maintain subagent's output instruction
+    // (see MAINTAIN_OUTPUT_INSTRUCTION). Digest changes with this entry.
+    maintainOutput: MAINTAIN_OUTPUT_INSTRUCTION,
+    skillsGuidance: SKILLS_GUIDANCE,
+});
+export function verifyPromptBundle(bundle = PROMPT_BUNDLE) {
+    // Verify against the PINNED constants, not the bundle's own id/version:
+    // otherwise a bundle that drifted off the deployment's pinned version
+    // recomputes a self-consistent hash and passes trivially.
+    if (bundle.id !== PROMPT_BUNDLE_ID || bundle.version !== PROMPT_BUNDLE_VERSION)
+        return false;
+    const canonical = JSON.stringify({
+        id: PROMPT_BUNDLE_ID,
+        version: PROMPT_BUNDLE_VERSION,
+        prompts: Object.fromEntries(Object.entries(bundle.prompts).sort()),
+    });
+    return bundle.sha256 === sha256(canonical);
+}
+export const DSH_AUTHORING_STANDARDS = `Follow the Hermes skill-authoring standards, translated to DSH tools.
+
+Frontmatter:
+- name: lowercase-hyphenated, <=64 chars, no spaces.
+- description: ONE sentence, <=60 characters, ends with a period. State the capability, not the implementation. No marketing words. Do NOT repeat the skill name. Count the characters before saving. If the description contains a colon, wrap the whole value in double quotes.
+- version: 0.1.0
+- author: always the literal value "Hermes". NEVER fill it from the environment, git config, or any identity you can probe — an environment-derived name is a privacy leak the user never opted into (skills get shared and published), and the skill names itself as Hermes.
+- platforms: declare [macos], [linux], and/or [windows] only when the skill is genuinely OS-bound (osascript/apt/systemctl => the matching OS; /proc, signal.SIGKILL => linux; fcntl/termios => POSIX). Prefer fixing it cross-platform first (tempdir, pathlib, pure-Node); omit the field for portable skills.
+- metadata.hermes.tags: a few Capitalized, Relevant, Tags.
+- metadata.hermes.related_skills: [a, b] — name sibling skills this one builds on or is referenced by (optional; feeds the quality references factor).
+
+Body section order (omit only when empty):
+1. "# <Human Title>" then a 2-3 sentence intro: what it does, what it does NOT do, key dependency stance.
+2. "## When to Use" — concrete trigger phrases.
+3. "## Prerequisites" — exact env vars, install steps, credentials.
+4. "## How to Run" — canonical invocation framed through DSH tools.
+5. "## Quick Reference" — flat command/endpoint list.
+6. "## Procedure" — numbered steps with copy-paste-exact commands.
+7. "## Pitfalls" — known limits and rate limits.
+8. "## Verification" — one check proving the skill worked.
+
+DSH-tool framing:
+- Reference DSH tools by name in backticks: \`bash\`, \`str_replace_editor\`, \`write\`, \`skill\`, \`skill_manage\`, \`memory\`.
+- Do not name wrapped shell utilities when a DSH tool already covers them.
+- Larger scripts belong under \`scripts/\` (written with \`skill_manage write_file\`) and are referenced from SKILL.md by relative path.
+
+Quality bar:
+- Prefer verbatim flags, paths, and APIs from the source. Never invent them.
+- Keep it tight: ~100 lines simple, ~200 complex.
+- No router/index/hub skills that only point at other skills.
+- References go in \`references/\`, templates in \`templates/\`.
+
+Learn workflow (when the user asks you to learn a reusable skill, or you decide to turn a source/request into one):
+1. Gather every source named (files, URLs, "what we just did", pasted notes) with the tools you already have — and treat prose after a source as authoring requirements, not noise.
+2. Apply every requirement and constraint from the request to the SKILL.md you author.
+3. Author exactly ONE SKILL.md and save it with \`skill_manage\` (action=create); non-trivial scripts go under \`scripts/\`.
+4. When done, tell the user the skill name, its category, and a one-line summary of what it captured.`;
+//# sourceMappingURL=prompts.js.map