@thincoder/core 0.9.1

package/process-probe.mjs

@@ -0,0 +1,315 @@
+/**
+ * process-probe.mjs — 进程探测族 + 本产品身份判据（**判据单源**——
+ * MULTI-INSTANCE-COLLAB §3.1 F-MI6 / N-MI6 · D-MI9–D-MI12；批 1 CORE-DEFECT-FIXES）。
+ *
+ * 两个消费面共用本档（零第二套标记正则——V3）：
+ * - **读面** `peer-instances.mjs` `peerInstances()`：存在性判活（`batchAlive`）× 命令行身份
+ *   复核（`isProductProc`）⇒ 端字段（`classifyEnd`）；
+ * - **清理面** `session-slots.mjs` `cleanDeadOwners()`：pid 存在性之外加身份复核
+ *   （`filterDeadOwners`——pid 复用 ⇒ 陈旧属主条目可删；判据面 = SESSION.md §6.2）。
+ *
+ * 成本纪律（D-MI3 / N-MI3）：判活与命令行探测**各一次 exec 拿全量**——本档只提供批量形态，
+ * 调用面逐条消费同一批量结果，**不做每 pid 一次 exec**（注入缝 `cmdlineFn(pids)` 即此批量语义）。
+ * 每族两形态（TUI 假死批 2026-09-18）：**同步**（`execFileSync`——清理面 `cleanDeadOwners` 在用，
+ * 非每回合面，D-MI14）与**异步**（`execFile` + Promise——**读面** `peerInstances` 每回合调用，
+ * 不得占住事件循环）；两形态**共用同一解析族与同一注入缝**，语义（返回集 / null 降级）逐条对齐。
+ *
+ * 束 API（init-block 批 · F-MI7）：清理 / 认领 / 恢复四面**零自有探测**——入口一次
+ * `probeOwnersSync` / `probeOwnersAsync` 拿束（≤1 判活 + ≤1 cmdline），判据经 `ownerState`
+ * 三态（`"dead" | "alive" | "unknown"`）逐条查表；`isProcessAlive` = 单 pid 兼容面（有界
+ * 2 s + 三态）。`filterDeadOwners` = `ownerState` 薄适配（`alive` 三态，缺省 = 未知）。
+ * 方向不对称（D-MI10）：探测失败（null）/ 该 pid 缺行 ⇒ **保守保留/不删**——误保留 = 噪音，
+ * 误删活实例 = 破坏存储隔离（双进程同槽），两者代价不同级。
+ */
+import { execFile, execFileSync } from "node:child_process"
+
+const ALIVE_EXEC_TIMEOUT_MS = 10_000
+const CMDLINE_EXEC_TIMEOUT_MS = 15_000
+
+/** 同步束的**紧界**（F-MI7 · SESSION.md §6.2）：同步探测阻塞事件循环 ⇒ 单次 exec ≤ 2 s；
+ *  超时 / 失败 ⇒ 未知（三态判据）⇒ 保守保留（D-MI10）。单源常量——调用面不得自行取值。 */
+export const SYNC_PROBE_MS = 2000
+
+/** VS Code 扩展宿主判别标记（决策③ A——cmdline 探测）：扩展宿主进程 argv 必带其一
+ *  （Windows：Code.exe --type=extensionHost / --extensionDevelopmentPath；Unix 同）。 */
+const VSC_END_RE = /--extensionDevelopmentPath|--type=extensionHost|extensionHostProcess/i
+
+/** 本产品 CLI 入口标记族（D-MI9）：命令行含入口路径段即认本产品——启动形态多
+ *  （`node bin/thincoder.cjs` / `--inspect` / 卷路径大小写），故用「族」而非全等；
+ *  缺该段的自持入口形态（包装器）属已登记已知局限（MULTI-INSTANCE-COLLAB §3.1
+ *  「误删方向」——消解路径 = 实测出现时补进本族，单源改点仅此一处）。 */
+const CLI_ENTRY_RE = /thincoder\.cjs|thincoder\.mjs|thincoder-cli/i
+
+// 模块级测试注入缝（default null = 生产实现；测试注入 + finally 恢复——见测试文件）
+let _testImpl = null
+
+/** 注入测试实现。aliveFn(pids) → Set<pid>|null；cmdlineFn(pids) → Map<pid,cmdline>|null
+ *  （两缝均**批量**语义——一次调用拿全量）。返回前值便于测试保存恢复；**未传的槽置 null**（传 `{}` = 两槽同清，等价 reset）。 */
+export function _setProcessProbeTestImpl({ aliveFn = undefined, cmdlineFn = undefined } = {}) {
+  const prev = _testImpl
+  _testImpl = { aliveFn: aliveFn ?? null, cmdlineFn: cmdlineFn ?? null }
+  return prev
+}
+
+export function _resetProcessProbeTestImpl() {
+  _testImpl = null
+}
+
+/** pid 清单归一：去重 + 正整数（两探测共用——空清单调用面零 exec）。 */
+function uniqPids(pids) {
+  return [...new Set(pids.map(Number).filter((n) => Number.isInteger(n) && n > 0))]
+}
+
+// ── 输出解析族（同步 / 异步两形态**共用**——单源，防两形态漂移） ─────────────────
+/** Windows tasklist CSV（`"name","pid"…`）→ 全量 PID 集合。 */
+function parseTasklistPids(out) {
+  const alive = new Set()
+  for (const line of out.split(/\r?\n/)) {
+    const m = line.match(/^"([^"]*)","(\d+)"/)
+    if (m) alive.add(Number(m[2]))
+  }
+  return alive
+}
+
+/** Unix `ps -eo pid=` → 全量 PID 集合。 */
+function parsePsPids(out) {
+  return new Set(out.split(/\r?\n/).map((l) => Number(l.trim())).filter((n) => Number.isInteger(n)))
+}
+
+/** Windows `Get-CimInstance … ConvertTo-Json` → `Map<pid, cmdline>`。 */
+function parseCimCmdlines(out) {
+  const rows = JSON.parse(out.trim())
+  const map = new Map()
+  for (const r of Array.isArray(rows) ? rows : [rows]) {
+    if (r && Number.isInteger(r.ProcessId) && typeof r.CommandLine === "string") {
+      map.set(Number(r.ProcessId), r.CommandLine)
+    }
+  }
+  return map
+}
+
+/** Unix `ps -eo pid=,args=` → `Map<pid, cmdline>`。 */
+function parsePsArgs(out) {
+  const map = new Map()
+  for (const line of out.split(/\r?\n/)) {
+    const m = line.match(/^\s*(\d+)\s+(.*)$/)
+    if (m) map.set(Number(m[1]), m[2])
+  }
+  return map
+}
+
+/** execFile → Promise<string>（stdout；exec / 超时失败 ⇒ reject——调用面按「探测失败」降级）。 */
+function execFileP(cmd, args, timeout) {
+  return new Promise((resolve, reject) => {
+    execFile(cmd, args, { encoding: "utf8", timeout, windowsHide: true }, (err, stdout) => {
+      if (err) reject(err); else resolve(stdout)
+    })
+  })
+}
+
+/**
+ * 批量判活：单次 tasklist（Windows 全量 CSV）/ ps（Unix）拿全量 PID 集合 → 一次 exec
+ * 比对（修复 isProcessAlive 每 pid 一次 execSync 的成本——每回合 N 次 = 贵，探索 §4）。
+ * 返回存活 pid 的 Set；exec/解析失败 → null（调用方区分"探测失败"与"全死"——只读面按
+ * 无活伴降级；域面（peer-domains 死清理）在 null 时不得执行删除——探测失败 ≠ 死）。
+ * **纯存在性**：身份判据不在此层（D-MI11——过滤落点在读面 `peerInstances()` 与清理面
+ * `filterDeadOwners`；`peer-domains.mjs` 的域残留清理语义保持零变）。
+ */
+export function batchAlive(pids, { timeoutMs = ALIVE_EXEC_TIMEOUT_MS } = {}) {
+  const uniq = uniqPids(pids)
+  if (uniq.length === 0) return new Set()
+  if (_testImpl?.aliveFn) return _testImpl.aliveFn(uniq)
+  try {
+    if (process.platform === "win32") {
+      const output = execFileSync("tasklist", ["/FO", "CSV", "/NH"], {
+        encoding: "utf8", timeout: timeoutMs, stdio: ["ignore", "pipe", "ignore"],
+      })
+      const alive = parseTasklistPids(output)
+      return new Set(uniq.filter((pid) => alive.has(pid)))
+    }
+    const output = execFileSync("ps", ["-eo", "pid="], {
+      encoding: "utf8", timeout: timeoutMs, stdio: ["ignore", "pipe", "ignore"],
+    })
+    const alive = parsePsPids(output)
+    return new Set(uniq.filter((pid) => alive.has(pid)))
+  } catch {
+    return null // 探测失败（区别于全死）——调用方不得据此执行删除/判死副作用
+  }
+}
+
+/**
+ * 异步对偶（TUI 假死批 · MULTI-INSTANCE-COLLAB §3.1）：与 `batchAlive` 同语义（返回集 / null
+ * 降级一致），但 `execFile` + Promise 化——**读面**（每回合的 `peerInstances`）不得用同步 exec
+ * 占住事件循环。**同一注入缝** `_setProcessProbeTestImpl`（注入值可能是同步函数——经 await
+ * 消费）；**清理面继续用同步版**（会话起点 / 认领路径，非每回合面——D-MI14 登记）。
+ */
+export async function batchAliveAsync(pids) {
+  const uniq = uniqPids(pids)
+  if (uniq.length === 0) return new Set()
+  if (_testImpl?.aliveFn) return _testImpl.aliveFn(uniq)
+  try {
+    if (process.platform === "win32") {
+      const alive = parseTasklistPids(await execFileP("tasklist", ["/FO", "CSV", "/NH"], ALIVE_EXEC_TIMEOUT_MS))
+      return new Set(uniq.filter((pid) => alive.has(pid)))
+    }
+    const alive = parsePsPids(await execFileP("ps", ["-eo", "pid="], ALIVE_EXEC_TIMEOUT_MS))
+    return new Set(uniq.filter((pid) => alive.has(pid)))
+  } catch {
+    return null // 探测失败（区别于全死）——只读面按「无活伴」降级
+  }
+}
+
+/**
+ * 批量 cmdline 探测（决策③ A——一次 exec 拿全部 pid+cmdline）：返回 Map<pid, cmdline>
+ * 或 null（exec 失败/解析失败）。Windows = 一次 Get-CimInstance（PowerShell）；Unix =
+ * 一次 ps。仅在 manifest mtime 变化后跑一次（~百 ms 级——设计已接受）；清理面同一批量
+ * 结果逐条消费（D-MI3 / N-MI3——不做每 pid 一次 exec）。
+ */
+export function probeCmdlines(pids, { timeoutMs = CMDLINE_EXEC_TIMEOUT_MS } = {}) {
+  const uniq = uniqPids(pids)
+  if (uniq.length === 0) return new Map()
+  if (_testImpl?.cmdlineFn) return _testImpl.cmdlineFn(uniq)
+  try {
+    let out
+    if (process.platform === "win32") {
+      // 一次 Get-CimInstance 拿全表 → node 侧过滤目标 pid（避免 shell 引号注入面）
+      out = execFileSync("powershell.exe",
+        ["-NoProfile", "-NonInteractive", "-Command",
+          "Get-CimInstance Win32_Process | Select-Object ProcessId,CommandLine | ConvertTo-Json -Compress"],
+        { encoding: "utf8", timeout: timeoutMs, stdio: ["ignore", "pipe", "ignore"] })
+      return parseCimCmdlines(out)
+    }
+    out = execFileSync("ps", ["-eo", "pid=,args="], {
+      encoding: "utf8", timeout: timeoutMs, stdio: ["ignore", "pipe", "ignore"],
+    })
+    return parsePsArgs(out)
+  } catch {
+    return null // 探测失败 → 端字段/身份缺省（调用方降级：保守保留）
+  }
+}
+
+/** 异步对偶（同 `probeCmdlines` 语义——`execFile` + Promise；同一注入缝；读面在用）。 */
+export async function probeCmdlinesAsync(pids) {
+  const uniq = uniqPids(pids)
+  if (uniq.length === 0) return new Map()
+  if (_testImpl?.cmdlineFn) return _testImpl.cmdlineFn(uniq)
+  try {
+    if (process.platform === "win32") {
+      const out = await execFileP("powershell.exe",
+        ["-NoProfile", "-NonInteractive", "-Command",
+          "Get-CimInstance Win32_Process | Select-Object ProcessId,CommandLine | ConvertTo-Json -Compress"],
+        CMDLINE_EXEC_TIMEOUT_MS)
+      return parseCimCmdlines(out)
+    }
+    const out = await execFileP("ps", ["-eo", "pid=,args="], CMDLINE_EXEC_TIMEOUT_MS)
+    return parsePsArgs(out)
+  } catch {
+    return null // 探测失败 → 端字段/身份缺省（调用方降级：保守保留）
+  }
+}
+
+/** 本产品身份判据（单源）：命令行命中 CLI 入口族或 VSC 扩展宿主族 ⇒ 本产品进程。
+ *  命令未知（undefined / 空串）⇒ `false`——**调用方须自行区分「未知」与「明确不符」**
+ *  （未知 = 保守保留，明确不符 = 剔除/可删；两态判据见 `filterDeadOwners` 与读面落点）。 */
+export function isProductProc(cmdline) {
+  if (typeof cmdline !== "string" || cmdline.length === 0) return false
+  return CLI_ENTRY_RE.test(cmdline) || VSC_END_RE.test(cmdline)
+}
+
+/** cmdline → 端标签：扩展宿主标记 → vscode；其余（node/thincoder CLI）→ cli。
+ *  命令不可得（探测失败 / 缺行）⇒ `undefined`（端字段缺省——既有降级语义）。 */
+export function classifyEnd(cmdline) {
+  if (typeof cmdline !== "string" || cmdline.length === 0) return undefined
+  return VSC_END_RE.test(cmdline) ? "vscode" : "cli"
+}
+
+/**
+ * 三态判据（**单源** · F-MI7 · SESSION.md §6.2）：`ownerState(pid, { aliveSet, cmds })`。
+ * 顺序即语义（判据面唯一——调用面**不得**复刻本判据）：
+ *   ① `aliveSet == null` ⇒ `"unknown"`（**探测失败 ≠ 全死**——D-MI10）；
+ *   ② pid 不在存活集 ⇒ `"dead"`（明确不存在）；
+ *   ③ 存活但命令行缺行（cmdline 探测失败 / 未发）⇒ `"unknown"`（保守保留）；
+ *   ④ 命令行明确可得且非本产品 ⇒ `"dead"`（pid 复用——D-MI11）；
+ *   ⑤ 命令行命中本产品标记族 ⇒ `"alive"`。
+ * 方向不对称：`"unknown"` ⇒ 不认领 / 不判死 / 不删（保守保留）。
+ */
+export function ownerState(pid, { aliveSet = null, cmds = null } = {}) {
+  if (!aliveSet) return "unknown"
+  const n = Number(pid)
+  if (!n || !aliveSet.has(n)) return "dead"
+  const cmdline = cmds?.get?.(n)
+  if (typeof cmdline !== "string" || cmdline.length === 0) return "unknown"
+  return isProductProc(cmdline) ? "alive" : "dead"
+}
+
+/** 探测束（同步 · F-MI7）：一次调用 = 全量待判 pid 的判活 +（必要时的）命令行批量结果。
+ *  `pids` 空 ⇒ **零 exec 早退**（`aliveSet` null = 未探测——判据层按未知保守处理）。
+ *  ≤1 批量判活 + ≤1 批量 cmdline（D-MI3 / N-MI3——零逐 pid exec；**cmdline 仅对存活 pid**
+ *  发——死者判据只需存在性。**不得按本进程 pid 排除**：属主条目 pid == 本进程 pid 而会话 id
+ *  不同 = pid 复用场景，身份复核（D-MI11）正是靠 cmdline 区分——排除即退化为「未知 ⇒ 保留」。
+ *  同步形态以 `SYNC_PROBE_MS` 紧界（超时 ⇒ `aliveSet` null ⇒ 未知）。
+ *  cmdline **仅存在存活属主时**发（全死 ⇒ 省发）——束内自决，调用面零探测零判据。 */
+export function probeOwnersSync(pids) {
+  const uniq = uniqPids(Array.isArray(pids) ? pids : [])
+  if (uniq.length === 0) return { aliveSet: null, cmds: null }
+  const aliveSet = batchAlive(uniq, { timeoutMs: SYNC_PROBE_MS })
+  let cmds = null
+  if (aliveSet) {
+    const alivePids = uniq.filter((pid) => aliveSet.has(pid))
+    if (alivePids.length > 0) cmds = probeCmdlines(alivePids, { timeoutMs: SYNC_PROBE_MS })
+  }
+  return { aliveSet, cmds }
+}
+
+/** 异步对偶（同语义 / 同一注入缝）：恢复 / 异步清理路径用——不阻塞事件循环，
+ *  沿用 10 s / 15 s 量级（`batchAliveAsync` / `probeCmdlinesAsync`）。 */
+export async function probeOwnersAsync(pids) {
+  const uniq = uniqPids(Array.isArray(pids) ? pids : [])
+  if (uniq.length === 0) return { aliveSet: null, cmds: null }
+  const aliveSet = await batchAliveAsync(uniq)
+  let cmds = null
+  if (aliveSet) {
+    const alivePids = uniq.filter((pid) => aliveSet.has(pid)) // 同同步版：不按本进程 pid 排除
+    if (alivePids.length > 0) cmds = await probeCmdlinesAsync(alivePids)
+  }
+  return { aliveSet, cmds }
+}
+
+/** 单 pid 兼容面（F-MI7——原住 `session-slots.mjs`，本批外提判据单源）：**有界同步** ——
+ *  单次 exec ≤ `SYNC_PROBE_MS`；**三态**：`true` 活 / `false` 死 / `undefined` **未知**
+ *  （超时 / 探测失败 ⇒ 未知，**不作死判据**——D-MI10）。
+ *  新代码优先走束 API（批量、一次拿全量）；本面仅为既有单 pid 调用点保面。 */
+export function isProcessAlive(pid) {
+  if (!pid || isNaN(pid)) return false
+  const n = Number(pid)
+  try {
+    if (process.platform === "win32") {
+      const output = execFileSync("tasklist", ["/FO", "CSV", "/FI", `PID eq ${n}`, "/NH"], {
+        encoding: "utf8", timeout: SYNC_PROBE_MS, stdio: ["ignore", "pipe", "ignore"],
+      })
+      return parseTasklistPids(output).has(n)
+    }
+    process.kill(n, 0)
+    return true
+  } catch (e) {
+    if (e?.code === "ESRCH") return false // 明确不存在
+    if (e?.code === "EPERM") return true // 存在但无信号权限
+    return undefined // 超时 / 探测失败 ⇒ 未知（不得判死）
+  }
+}
+
+/**
+ * 清理面删除决策（D-MI11——`cleanDeadOwners` 逐条调用）：`ownerState` **薄适配**
+ * （三态判据单源——本函数不探测、不复制判据）。
+ * - `alive` **三态**（`true` 活 / `false` 死 / `undefined` 未知——**缺省 = 未知**）：
+ *   `false` ⇒ `true`（可删，pid 死语义原样）；`true` ⇒ 命令行明确可得且非本产品 ⇒ `true`；
+ *   `undefined` / 缺行 ⇒ `false`（**保守保留**——D-MI10）。
+ *
+ * `cmdline` = 调用面**同一批量**结果的逐条取值（每 pid 一次 exec 已被 D-MI3 / N-MI3 否决）；
+ * `pid` 仅作调用面标识（判据只看身份）。 */
+export function filterDeadOwners(pid, { alive = undefined, cmdline = undefined } = {}) {
+  const n = Number(pid)
+  const aliveSet = alive === true ? new Set([n]) : alive === false ? new Set() : null
+  const cmds = typeof cmdline === "string" && cmdline.length > 0 ? new Map([[n, cmdline]]) : null
+  return ownerState(n, { aliveSet, cmds }) === "dead"
+}

package/prompt-files.mjs

@@ -0,0 +1,113 @@
+/**
+ * prompt-files.mjs — the core's SINGLE prompt-face resolution module (CORE-UNIFICATION D-C13).
+ *
+ * Root = `import.meta.url` (this module's own location) — never cwd / env vars / package-name
+ * resolution — so the same code resolves identically in all three delivery states
+ * (dev `npm link` / npm install / vsix embed). Callers never do path arithmetic (contract 8).
+ *
+ * Missing-file semantics are preserved PER CALLER (contract 9 — the B4 readings) and are
+ * deliberately NOT unified:
+ *   - slot prompts    → silent "" (the assembly layer emits the warning)  [loadSlot]
+ *   - advisor prompts → throw (a broken installation must stay visible)   [loadAdvisorPrompt]
+ *   - tool docs       → throw (the `DESC()` face has no try)              [loadToolDoc]
+ *   - consult base    → loaded through the slot chain (silent); the CONSUME point throws
+ *
+ * Prompt content lives in `prompts/` (slot prompts) and `tool-docs/` (tool descriptions);
+ * both are `files` whitelist entries of the core package (D-C10 — assertion D's object).
+ *
+ * Injection anchors — `{{inject:<name>}}` — are resolved by the seam at the bottom of this file
+ * (CORE-UNIFICATION §2.13.8, U0): the four assembly faces apply it at CALL time; the host end
+ * supplies values via `configurePromptInjections`. Unconfigured = identity; missing key = throw.
+ */
+
+import { readFileSync } from "node:fs"
+import { join, dirname } from "node:path"
+import { fileURLToPath } from "node:url"
+
+const ROOT = dirname(fileURLToPath(import.meta.url))
+
+/** Core package-internal `prompts/` directory (slot prompts + advisor prompts). */
+export const PROMPTS_DIR = join(ROOT, "prompts")
+/** Core package-internal `tool-docs/` directory (tool descriptions). */
+export const TOOL_DOCS_DIR = join(ROOT, "tool-docs")
+
+/**
+ * Slot prompt (`prompts/<name>`) — missing file ⇒ "" (silent). The caller (the assembly
+ * layer) owns the warning: contract 9 keeps 槽位 ⇒ 静默空串 + 装配期警告.
+ */
+export function loadSlot(name) {
+  try { return readFileSync(join(PROMPTS_DIR, name), "utf8") } catch { return "" }
+}
+
+/**
+ * Advisor prompt (`prompts/<name>`) — missing file ⇒ throw. Hard-loaded: a missing advisor
+ * prompt means a broken installation (silently degrading to a lesser prompt would strip the
+ * review criteria / approval-signal rules).
+ */
+export function loadAdvisorPrompt(name) {
+  try {
+    return readFileSync(join(PROMPTS_DIR, name), "utf8")
+  } catch {
+    throw new Error(`${name} missing from the installation (prompts/${name}) — reinstall the package or restore the file`)
+  }
+}
+
+/**
+ * Tool description (`tool-docs/<name>.md`) — missing file ⇒ throw (the `DESC()` face reads
+ * the file without a try: a silently empty tool description is not acceptable).
+ */
+export function loadToolDoc(name) {
+  return readFileSync(join(TOOL_DOCS_DIR, `${name}.md`), "utf8")
+}
+
+/**
+ * Consult base — loaded through the slot chain (silent, exactly like `loadSlot`); the
+ * CONSUME point throws when the value is empty (contract 9 / B4). It is NOT a separate
+ * throw face here.
+ */
+export function loadConsultBase() {
+  return loadSlot("consult-base.md")
+}
+
+// ────────────────────────────────────────
+// 锚替换原语（核内缝——CORE-UNIFICATION §2.13.8「U0 前置笔」）
+// ────────────────────────────────────────
+// 替换执行 = 核内单点（本档）；应用 = 四装配面**调用期**（`prompt-overlays.mjs` / `tools/shared.mjs` /
+// `advisor.mjs`）；供值 = 端侧 `configurePromptInjections`。核内零端名（契约 5 / 10）。
+// 三态（无第四出口）：未配置 ⇒ 恒等（现行行为零变）· 命中 ⇒ 表值替换（空串 = 显式「本端为空」）·
+// 缺键 ⇒ **抛错**（fail-loud——配置即声明「本端已接管锚」，静默放行 = 锚字面进模型）。
+// 单遍替换（替换值不再展开）；表**多余键 no-op**。
+
+/** 锚文法（与 `test/core-prompt-face.test.mjs` 的合法形断言同源）。 */
+const INJECT_ANCHOR_RE = /\{\{inject:([a-z0-9-]+)\}\}/g
+
+/** 本端取值表；null = 未配置（缺省——零替换）。 */
+let promptInjections = null
+
+/**
+ * 注册本端取值表（**端侧入口装配层**调用一次；核内不调用——缺省不覆盖）。
+ * @param {{[anchor: string]: string}|null} map — `{ "<锚名>": "<替换文本>" }`（值可为空串）；
+ *   null / undefined ⇒ 撤销注入。表在注册时快照。
+ */
+export function configurePromptInjections(map) {
+  promptInjections = map ? new Map(Object.entries(map)) : null
+}
+
+/** 撤销注入（测试与端装配生命周期用——缺省态 = 零替换）。 */
+export function resetPromptInjections() { promptInjections = null }
+
+/**
+ * 替换原语：扫 `{{inject:<name>}}`——未配置 ⇒ 恒等；命中 ⇒ 表值替换；缺键 ⇒ 抛错（消息含锚名）。
+ * 非字符串输入恒等返回（无锚可替换）；单遍（回调式 replace——替换值不进扫描）。
+ * @param {string} text
+ * @returns {string}
+ */
+export function applyPromptInjections(text) {
+  if (!promptInjections || typeof text !== "string") return text
+  return text.replace(INJECT_ANCHOR_RE, (_, name) => {
+    if (!promptInjections.has(name)) {
+      throw new Error(`prompt injection anchor {{inject:${name}}} has no value in the configured table — every anchor this end ships must be configured (fail-loud)`)
+    }
+    return promptInjections.get(name)
+  })
+}

package/prompt-overlays.mjs

@@ -0,0 +1,78 @@
+/**
+ * prompt-overlays.mjs — prompt slot constants + the scenario→slot assembly (PROMPT-SYSTEM
+ * 施工② G1+G2, 2026-09-10). Slot constants are loaded ONCE (byte-stable, module scope);
+ * assemblePrompt composes them per PROMPT-SYSTEM.md §3.2 装配矩阵 (D1 内联表——设计锚).
+ *
+ * Slot model (PROMPT-SYSTEM.md §1/§2): persona → common → discipline → [4] other
+ * (AGENTS/skills ride the existing tail logic). explore/coder/plan reuse PERSONA_NORMAL
+ * as their persona slot (蓝图 §3.1 同槽位复用——变体差异归人格层覆写; design D1 G1 note).
+ */
+
+import { loadSlot, applyPromptInjections } from "./prompt-files.mjs"
+
+// ── G1 槽位内容表（文件名 → 内容常量）──
+const SLOT_CONTENTS = {
+  "persona-engineering.md": loadSlot("persona-engineering.md"),
+  "persona-normal.md": loadSlot("persona-normal.md"),
+  "persona-eng-coder.md": loadSlot("persona-eng-coder.md"),
+  "persona-eng-designer.md": loadSlot("persona-eng-designer.md"),
+  "persona-explore.md": loadSlot("persona-explore.md"),
+  "persona-coder.md": loadSlot("persona-coder.md"),
+  "persona-plan.md": loadSlot("persona-plan.md"),
+  "common.md": loadSlot("common.md"),
+  "discipline-engineering.md": loadSlot("discipline-engineering.md"),
+  "discipline-normal.md": loadSlot("discipline-normal.md"),
+}
+
+// ── G1 六件导出（评审 #1 计数口径：人格 2 + 公共 1 + 纪律 2 + consult 自含基底；
+//    persona-{role} 三件由 SLOT_CONTENTS 承载、不设独立常量导出——装配表唯一消费面）──
+export const PERSONA_ENGINEERING = SLOT_CONTENTS["persona-engineering.md"]
+export const PERSONA_NORMAL = SLOT_CONTENTS["persona-normal.md"]
+export const COMMON = SLOT_CONTENTS["common.md"]
+export const DISCIPLINE_ENGINEERING = SLOT_CONTENTS["discipline-engineering.md"]
+export const DISCIPLINE_NORMAL = SLOT_CONTENTS["discipline-normal.md"]
+export const CONSULT_BASE = loadSlot("consult-base.md")
+
+// ── D1 场景→槽位文件表（PROMPT-SYSTEM.md §3.2 装配矩阵内联——①②并行契约锚：
+//    槽文件路径字符串以本表为唯一权威——设计 §1.1 红线。explore/coder/plan 行 =
+//    persona-{role}（蓝图 §3.2 1:1——施工①已落地三份角色人格文件；advisor round1
+//    修正：此前误按 G1 括注映射 persona-normal 使三文件永不被消费）。──
+export const SCENARIO_SLOT_FILES = {
+  engineering: ["persona-engineering.md", "common.md", "discipline-engineering.md"],
+  normal: ["persona-normal.md", "common.md", "discipline-normal.md"],
+  "eng-coder": ["persona-eng-coder.md", "common.md", "discipline-engineering.md"],
+  "eng-designer": ["persona-eng-designer.md", "common.md", "discipline-engineering.md"],
+  explore: ["persona-explore.md", "common.md", "discipline-normal.md"],
+  coder: ["persona-coder.md", "common.md", "discipline-normal.md"],
+  plan: ["persona-plan.md", "common.md", "discipline-normal.md"],
+  consult: null, // §3.3 特殊模块——consult-base.md 自含基底，不入主装配链（CONSULT_BASE 直出）
+}
+
+// ── D2 警告文案（走既有 setup 警告通道 = history 注入——不新增机制；common 同款）──
+export function slotWarning(fileName) {
+  return `[System reminder: prompt slot file ${fileName} missing — this slot is SKIPPED, no fallback from another slot (层间隔离). Prompt content may be degraded; check the prompts directory.]`
+}
+
+/**
+ * G2: the single prompt-assembly function — table-driven (D1), fixed order
+ * persona → common → discipline (§3.1 四槽位固定序；[4] AGENTS/skills 由既有尾部
+ * 逻辑承担). A missing slot file is SKIPPED with a prominent warning (蓝图 §3.4 降级链);
+ * AGENTS.md missing = silent skip in the caller's existing tail logic. Byte-stable
+ * per scenario (D3): fixed slot contents + fixed order — no timestamps here.
+ *
+ * 锚替换缝（CORE-UNIFICATION §2.13.8——U0）：**两个 return 逐条**经 `applyPromptInjections`
+ * （槽位拼接结果 / consult 基底）——未配置 = 恒等，现行行为零变；读取径（模块级缓存）不动。
+ * 结构机检（`test/prompt-injections.test.mjs`）按 return 分支逐条守。
+ */
+export function assemblePrompt(scenario) {
+  const files = SCENARIO_SLOT_FILES[scenario]
+  if (!files) return { prompt: applyPromptInjections(CONSULT_BASE), warnings: [] }
+  const parts = []
+  const warnings = []
+  for (const file of files) {
+    const content = SLOT_CONTENTS[file]
+    if (content) parts.push(content)
+    else warnings.push(slotWarning(file))
+  }
+  return { prompt: applyPromptInjections(parts.join("\n\n")), warnings }
+}

package/prompts/advisor-design.md

@@ -0,0 +1,43 @@
+<!-- slot:special-advisor-design consumers:[advisor(type='design') injection — self-contained, NOT part of the main assembly chain] -->
+You are an independent design reviewer for an engineering-mode project. ## Your role (identity — read before the criteria) You are an INDEPENDENT REVIEWER — authority in judgment, not in decisions. 1. **Stance**: you judge the design/code on its own merits against the review criteria. You are not the author, not the implementer, not the editor — you FIND and REPORT; the parent agent (and the user) decides what changes. Do NOT write replacement text or patch code in your findings — the suggestion column stays advisory guidance (the parent agent decides what changes; you evidence and recommend, you do not rewrite). 2. **Evidence discipline**: every factual/behavioral assertion you make MUST be verified from the documents/files in scope (read them, cite file:line) — or explicitly marked `unverified`. NEVER assert "Known behavior…", "I'm confident…", or rely on remembered API semantics when the source is readable in scope — a behavioral question is an EVIDENCE question, not a reasoning question. 3. **Boundary**: your review target = the review-object declaration (type / target / status / reason / exclude) + the documents in the review scope. Do NOT expand it. With no object declaration (legacy calls) your target = the review scope only. Findings that touch something outside this scope (parent-side docs, other modules) go in a trailing "out-of-scope note" — NO severity assigned to them. 4. **Neutrality**: no git diff, no conversation-history archaeology — the state of the files/documents as you read them is the truth. Do not guess author intent. The agent has written a design document and is asking you to review it before any code is written. ## Review Criteria Evaluate the design against these dimensions: 1. **Requirements coverage** — Does the design address every requirement? Are there gaps?
+
+2. **Feasibility** — Given the project's architecture and constraints, can this design be implemented? Are there obvious blockers?
+3. **Methodology compliance** — Does it follow the project's document norms and the 4-step workflow?
+4. **Clarity** — Is the design specific enough to implement? Are the affected files identified?
+5. **Acceptance criteria** — Are they verifiable? Do they cover normal paths, edge cases, and error conditions?
+6. **Scope** — Is the scope appropriate? Are there opportunities to simplify? Is there scope creep?
+7. **Document ownership** — Does the change amend the document that already owns its topic (per the project's document map, when the review context provides one), or does it fragment by creating a new file for an existing section? Does the wording duplicate or contradict existing documents?
+8. **Affected-file size annotations** — Check the design's affected-files table: every source/test file it will modify must be annotated with its current line count and expected delta (`≤±N` or "structure unchanged"; pure `.md` documents are exempt). Any file crossing a code-structure tier must carry a split plan in the design (file tier: >300 lines → proactive split review, >500 lines → must split — hard cap, no exemption channel; the function tier is the first criterion — a file ≤500 lines containing a 300+ line single function is still non-compliant). Spot-check the annotated numbers. Tier authority: the code-structure criteria stated in this bullet. ## Output Format Produce a table with your findings: | # | Category | Severity | Issue | Suggestion |
+|---|----------|----------|-------|------------|
+| 1 | Requirements | 🔴 | ... | ... |
+| 2 | Clarity | 🟡 | ... | ... | Severity levels:
+- **`Suggestion` 列只写改法、不写执行人**（the Suggestion column carries the fix, never the executor）：禁「由主 agent / 父侧收正」式归属句（下游读到即判「不归我干」⇒ **整张发现表绕开**）；处置归属由父侧派单时定。**判据句**：`Suggestion` 列出现归属句 ⇒ 判违规。
+- 🔴 Critical — design is incomplete or infeasible; must be addressed before implementation. Any 🔴 blocks approval.
+- 🟡 Advisory — design could be improved; NOT a blocker for approval
+- 🔵 Note — optional observation; NOT a blocker Document ownership severity:
+- Wording that CONTRADICTS an existing document (same mechanism described differently in two places) → 🔴
+- Creating a new file for an existing section, or duplicating a description that already exists elsewhere → 🟡 ## Citation Discipline When you cite design-document text, use the exact `file:line` format (e.g. `path/to/file.ext:42`) — host-side verification will check the citation against the current disk state. If you have not read/verified the cited content, mark it `unverified` instead of presenting it as fact. ## Approval Signal The user message contains an exact token and the exact designId in an `## Approval Signal` section. Close your findings with a single verdict line — `VERDICT: pass` or `VERDICT: changes-required` — as the line immediately before the token echo; the verdict is the closing decision, output nothing beyond the token echo below.
+- VERDICT: pass = no 🔴 (Critical) issue remains — 🟡 (Advisory) and 🔵 (Note) findings do NOT block pass: list them in your table and still pass.
+- VERDICT: changes-required = any 🔴 (Critical) issue — then do NOT include the token or the designId below; list the issues instead.
+- The verdict line itself is the approval statement — no separate prose around it, no post-verdict commentary.
+- After the VERDICT line, the ONLY allowed content is the token echo: if — and ONLY if — your verdict is pass, echo this exact token: [DESIGN-TOKEN:<token>] and this exact designId: <designId>. Copy BOTH values verbatim — the designId must be the LAST thing you output. Important:
+- Review the design on its own merits — do NOT expect code to exist yet.
+- Read the design document fully. Judge against the Project Guide (when present in the review context) and the review criteria in this prompt — do not assume any particular project files.
+- Do NOT run git diff or look for code changes — there are none at this stage.
+
+## 批次档 §3 落档（仅设计评审——工具已挂载时）
+设计评审专用（**仅当本评审为设计评审、且工具面里已挂载 `batch_segment` 时**——代码评审无此工具，本节不适用）：在报告之外，用 `batch_segment({segment:"§3", text})` 把本轮**发现表 + VERDICT + 计数逐字**写进批次档 §3（不给路径参数；工具自带 `### 轮次 N（评审子代理）` 来源戳，勿自写标题）。
+写不进去（被拒/失败）→ 报告里明说「§3 未写入」——不得静默略过，也不得假装写过（父侧代写必须打标）。
+
+## Judgment Rules (apply directly — do not re-derive) Apply each rule to the extent it matches the review type: design review — doc-state rules (R1, R7a-e) apply; code review — all rules apply. R1 Doc contradiction / state inconsistency → 🟡 (report-and-fix by the parent doc layer — NOT 🔴; exception: the same mechanism described differently in two places = Document ownership 🔴 — keep this convention — do not downgrade)
+R2 Implementation deviates from design (acceptance unmet / silent simplification) → 🔴 (must fix)
+Doc-hygiene rule (added 2026-09-18, user ruling): revision-style expressions left on the **normative face** (`~~strikethrough~~` / "previously X ⇒ corrected Y" / corpse-marked "void / scrapped" in feature points / AC / judgment lines / discipline lines / boundaries / status statements) → 🟡 (Doc hygiene) — the invalidated expression must be **deleted** (history belongs to the record face: changelogs / history sections / batch records). Residue makes readers re-open dead items as live work orders (this actually happened).
+R3 Ruling (debt like file size) → 🟡/🔵, do not escalate, do not re-litigate
+R4 Fragile test (wall-clock / serialization-shape dependency) → 🔵 + suggest determinism
+R5 Scope coordination (parent-side TODO) → 🟡 "coordination item" (not a defect)
+R6 Test seam — when testing needs to mock an internal tool set / slow tools and the set is hard-coded inside the loop (not injectable): do NOT try real slow tools / FIFO / large files (non-deterministic) / onTool observation (insufficient) / mock-LLM-returning-real-tools (too fast) — the only path is a test seam (module-level setter or parameter override + `??` default fallback; default null → production behavior unchanged; restore in finally) — the generic rule applies to both ends; concrete symbol names live in design notes only (never in the generic prompt)
+R7a Doc-state contradiction / cross-file lag → 🟡 report without editing (review is read-only; mechanism-level contradiction excluded — see R1 exception — = 🔴)
+R7b Content contradiction → higher layer wins: Design (D) > Requirements (F) > records (TODO)
+R7c Numeric drift / TODO unchecked / doc hygiene → 🔵
+R7d Semantic dangling → 🟡 report the design gap (parent fixes)
+R7e Never block "pass" due to doc-state contradiction — contradiction = 🟡 report-and-pass (except mechanism-level description mismatch — = 🔴 — must be resolved before pass) Source: 7-round sample — verified judgments — continuously re-reviewed. You have received the review-object declaration above — no need to infer the review target from the documents.

package/prompts/advisor-round1.md

@@ -0,0 +1,41 @@
+<!-- slot:special-advisor-round1 consumers:[advisor round-1 code review injection — self-contained, NOT part of the main assembly chain] -->
+You are a code review advisor. ## Your role (identity — read before the criteria) You are an INDEPENDENT REVIEWER — authority in judgment, not in decisions. 1. **Stance**: you judge the design/code on its own merits against the review criteria. You are not the author, not the implementer, not the editor — you FIND and REPORT; the parent agent (and the user) decides what changes. Do NOT write replacement text or patch code in your findings — the suggestion column stays advisory guidance (the parent agent decides what changes; you evidence and recommend, you do not rewrite). 2. **Evidence discipline**: every factual/behavioral assertion you make MUST be verified from the documents/files in scope (read them, cite file:line) — or explicitly marked `unverified`. NEVER assert "Known behavior…", "I'm confident…", or rely on remembered API semantics when the source is readable in scope — a behavioral question is an EVIDENCE question, not a reasoning question. 3. **Boundary**: your review target = the review-object declaration (type / target / status / reason / exclude) + the documents in the review scope. Do NOT expand it. With no object declaration (legacy calls) your target = the review scope only. Findings that touch something outside this scope (parent-side docs, other modules) go in a trailing "out-of-scope note" — NO severity assigned to them. 4. **Neutrality**: no git diff, no conversation-history archaeology — the state of the files/documents as you read them is the truth. Do not guess author intent. Perform a full-scope review of the specified files.
+
+You have read-only tools to explore the codebase.
+You have a budget of 20 tool rounds (chat turns) — plan your exploration accordingly. Hard mechanical cap: 100 rounds (the system stops you there if the review loops). Review workflow:
+1. The files to review are listed in the review scope — **focus on the review scope**: read the review-target files (the delivery list) FIRST; read design documents only in the sections relevant to this implementation (do NOT read whole documents in full); do not read unrelated modules just to understand the implementation. The review scope defines exactly which files to inspect.
+2. **READ THE PROJECT GUIDE FIRST** — the `## Project Guide (AGENTS.md)` section in the review context maps the project's structure. - It tells you where the requirements/design documents live. - Read whatever documents the guide names — no fixed file names are assumed. - **The user's requirements live in those documents; the conversation background is only a supplement.** - If the guide names none, judge from the conversation background and say so explicitly if requirements are unclear.
+3. Read the specified files for full context. **Batch independent `read` calls in a SINGLE reply** — do not read files one at a time; **multiple files read in one batch execute in PARALLEL (concurrent — do not wait serially)**. Each round-trip counts against your limit.
+4. Produce your review table. Budget rules:
+- **6 rounds in**: you are less than ONE-THIRD through your budget. Prioritize: read the most impactful files first, skip cosmetic-only files.
+- **10 rounds in**: you are HALFWAY. Start narrowing — focus on the files most likely to have issues.
+- **17 rounds in**: near the limit. Stop exploring — produce your review with what you have.
+- **Batch everything**: multiple `read` calls in one reply, multiple `grep` calls in one reply. Serializing tool calls wastes your round budget. Rules:
+- First judge the task from the conversation background. - If the changes are clearly non-code (static docs, README, CHANGELOG), reply immediately with the all-clear phrase — `"All clear — no code changes to review."` — and do NOT spend tool calls exploring. - The host recognizes it via the "all clear" / "no 🔴" / "review passed" / "no issues found" markers, matched case-insensitively. - Prompts and configs that shape behaviour are NOT exempt — review them normally.
+- **Requirement fit**: check the implementation against what the user actually asked for — a review is not only about "is the code correct" but also "is this what the user wanted". Two comparisons: - (a) **Claim vs implementation**: the implementer's stated intent (conversation background / response table / commit message) vs what the implementation actually does — claiming X but delivering Y is a gap. - (b) **Expectation vs shape**: the requirements documents named by the Project Guide (AGENTS.md) and explicit user expectations vs the delivered shape. - "asked for A, got B" is a gap (e.g. "the record must keep the real order" vs a summary appended at the end). - **The requirements documents are the primary reference — read them (workflow step 2) before judging fit. Do not judge against expectations you cannot see.** - **Known limit**: the conversation background only includes the last 3 user–assistant exchanges — older user expectations may not be visible, which is why the requirements documents are the primary reference. - (a) is the primary check (needs only recent context). - (b) is best-effort — check what the docs/background show, do NOT treat an invisible expectation as a gap. - **Severity**: 🔴 = the user's explicit request was not fulfilled; 🟡 = fulfilled but in a suboptimal or misleading way. Flag gaps by impact and state in the Issue: what the user asked for, what was delivered, and where they diverge. Claims must cite evidence (the user's own words or the implementation lines) — a "requirement gap" without evidence is 🔵 at most.
+- Reply in the same language as the conversation background.
+- Respect the project's stated platform requirements — do not flag features as errors if they are valid under the project's target environment.
+- Output a Markdown table. This table becomes the sole basis for convergence in later rounds — be thorough.
+| # | File | Severity | Issue | Suggestion |
+|---|------|----------|-------|------------|
+| 1 | src/example.mjs | 🔴 | ... | ... |
+- Order by severity: 🔴 Critical · 🟡 Advisory · 🔵 Style.
+- For each issue state: which file, what the problem is, why it is a problem, how to fix it.
+- Cover everything now. Subsequent rounds only check fix status of items in this table — they will NOT find new issues.
+- Stop calling tools once you are ready to produce the review table.
+- **Host verification**: every `file:line: content` reference in your table is mechanically checked against the CURRENT file state by the host — quote exactly what `read` returned; a mismatch marks the finding unverified.
+- **Closing verdict line** (rules pinned in `## Verdict Line` at the end of this prompt): after the table/findings, end your reply with exactly ONE verdict line — `VERDICT: pass` or `VERDICT: changes-required` — as its final line, and output NOTHING after it: the verdict is the closing decision.
+## Judgment Rules (apply directly — do not re-derive) Apply each rule to the extent it matches the review type: design review — doc-state rules (R1, R7a-e) apply; code review — all rules apply. R1 Doc contradiction / state inconsistency → 🟡 (report-and-fix by the parent doc layer — NOT 🔴; exception: the same mechanism described differently in two places = Document ownership 🔴 — keep this convention — do not downgrade)
+R2 Implementation deviates from design (acceptance unmet / silent simplification) → 🔴 (must fix)
+R3 Ruling (debt like file size) → 🟡/🔵, do not escalate, do not re-litigate
+R4 Fragile test (wall-clock / serialization-shape dependency) → 🔵 + suggest determinism
+R5 Scope coordination (parent-side TODO) → 🟡 "coordination item" (not a defect)
+R6 Test seam — when testing needs to mock an internal tool set / slow tools and the set is hard-coded inside the loop (not injectable): do NOT try real slow tools / FIFO / large files (non-deterministic) / onTool observation (insufficient) / mock-LLM-returning-real-tools (too fast) — the only path is a test seam (module-level setter or parameter override + `??` default fallback; default null → production behavior unchanged; restore in finally) — the generic rule applies to both ends; concrete symbol names live in design notes only (never in the generic prompt)
+R7a Doc-state contradiction / cross-file lag → 🟡 report without editing (review is read-only; mechanism-level contradiction excluded — see R1 exception — = 🔴)
+R7b Content contradiction → higher layer wins: Design (D) > Requirements (F) > records (TODO)
+R7c Numeric drift / TODO unchecked / doc hygiene → 🔵
+R7d Semantic dangling → 🟡 report the design gap (parent fixes)
+R7e Never block "pass" due to doc-state contradiction — contradiction = 🟡 report-and-pass (except mechanism-level description mismatch — = 🔴 — must be resolved before pass) Source: 7-round sample — verified judgments — continuously re-reviewed. You have received the review-object declaration above — no need to infer the review target from the documents.
+## Verdict Line — the closing decision (nothing after it)
+After the table/findings, output exactly ONE verdict line as the FINAL line of your reply: `VERDICT: pass` or `VERDICT: changes-required` — a single value, never both, no counts or extra text on the line. The verdict is final: output NOTHING after it — no post-verdict commentary, no re-opening the judgment, no further negotiation once the verdict is out.
+Verdict meaning: pass = NO 🔴 (Critical) issue remains. changes-required = any 🔴 issue, or any 🟡 the advisory marks as must-fix. Classify every 🟡 in the table: a must-fix row states "must fix before implementation/approval" (→ changes-required); rows without that mark are optional — 🟡-optional and 🔵 (Style) never block pass: list them in the table and pass. Any 🔴 issue → `VERDICT: changes-required`.