@chainingintention/pi-web-cn 1.202610.1 → 1.202610.3

package/dist/pi-packages/captains-log/dist/store.js

@@ -0,0 +1,75 @@
+// Generated from pi-packages/captains-log/src/store.ts. Do not edit directly.
+import { createHash, randomUUID } from "node:crypto";
+import { constants } from "node:fs";
+import { lstat, mkdir, open, readdir, rename, rm } from "node:fs/promises";
+import { join } from "node:path";
+import { isLogEntry } from "./browser/protocol.js";
+/** Only host-resolved ids enter the scope hash; peer input is never a filesystem path. */
+export function logScope(projectId, workspaceId) {
+    return createHash("sha256").update(JSON.stringify([projectId, workspaceId])).digest("hex");
+}
+export class LogStore {
+    dataDirectory;
+    constructor(dataDirectory) {
+        this.dataDirectory = dataDirectory;
+    }
+    async directory(scope) {
+        if (!/^[a-f0-9]{64}$/.test(scope))
+            throw new Error("Invalid captain scope");
+        const directory = join(this.dataDirectory, scope);
+        await mkdir(directory, { recursive: true, mode: 0o700 });
+        if (!(await lstat(directory)).isDirectory())
+            throw new Error("LogEntry directory must not be a symlink");
+        return directory;
+    }
+    async save(scope, captain) {
+        if (!isLogEntry(captain))
+            throw new Error("Invalid captain record");
+        const directory = await this.directory(scope);
+        const temporary = join(directory, `.${randomUUID()}.tmp`);
+        try {
+            const file = await open(temporary, "wx", 0o600);
+            try {
+                await file.writeFile(JSON.stringify(captain));
+                await file.sync();
+            }
+            finally {
+                await file.close();
+            }
+            await rename(temporary, join(directory, `${captain.id}.json`));
+        }
+        finally {
+            await rm(temporary, { force: true });
+        }
+    }
+    async read(scope, id) {
+        if (typeof id !== "string" || !/^[a-f0-9-]{36}$/.test(id))
+            throw new Error("Invalid captain id");
+        const path = join(await this.directory(scope), `${id}.json`);
+        // O_NOFOLLOW is not enforced on Windows; reject existing links there too.
+        if (!(await lstat(path)).isFile())
+            throw new Error("Invalid captain file");
+        const file = await open(path, constants.O_RDONLY | constants.O_NOFOLLOW);
+        try {
+            const stat = await file.stat();
+            if (!stat.isFile() || stat.size > 300_000)
+                throw new Error("Invalid captain file");
+            const value = JSON.parse(await file.readFile("utf8"));
+            if (!isLogEntry(value) || value.id !== id)
+                throw new Error("Invalid saved captain");
+            return value;
+        }
+        finally {
+            await file.close();
+        }
+    }
+    async list(scope) {
+        const names = await readdir(await this.directory(scope));
+        const captains = [];
+        for (const name of names) {
+            if (/^[a-f0-9-]{36}\.json$/.test(name))
+                captains.push(await this.read(scope, name.slice(0, -5)));
+        }
+        return captains.sort((a, b) => b.createdAt.localeCompare(a.createdAt) || b.id.localeCompare(a.id));
+    }
+}

package/dist/pi-packages/captains-log/docs/usage.md

@@ -0,0 +1,29 @@
+# 使用船长日志
+
+在当前机器和工作区选择普通会话，打开“船长日志”，点击“让船长转述”。伴随扩展读取源会话当前分支最新已完成的助手文本回复，不发送提示、不修改源转录。独立的船长会话使用你配置的模型转述文本，以海盗船长的风格保留事实、警告、下一步以及原始代码和命令。
+
+船长首次收到角色介绍；后续请求复用仍由 daemon 承载的船长会话。只有在发送请求前明确确认旧船长未被承载时才自动创建新会话，不因超时或任意连接失败重试、重发或替换会话。daemon 重启后，如需保留旧船长的上下文，先在会话列表打开最近的船长日志会话，等待加载完成，再选择需要转述的源会话。
+
+## 结果与连接
+
+- “打开源会话”按照记录的机器、项目、工作区和源会话 ID 返回聊天。目标不可用时显示常规错误，不自动创建替代会话。
+- 结果支持 Markdown 标题、列表、强调、链接、表格和代码块。内嵌 HTML 按文本显示，危险链接不可点击，图片不会自动加载。“历史转述”和“诊断”默认折叠。
+- 打开面板或选择“打开船长转述”不会消耗模型令牌。只有点击转述按钮才提交任务。
+- 浏览器使用双向 peer 通道接收后端进度，无轮询。连接或重连会读取快照；进度不是逐令牌输出，船长完成后才收到最终转述。
+- 关闭面板或浏览器不会取消已被后端接收的工作。重新连接可恢复结果；接收状态不确定时绝不自动重发。
+
+## 无法运行时
+
+源会话必须属于当前机器和工作区，未归档、非临时会话，且不是船长本身。等待源会话空闲，并确保当前分支存在已完成的助手文本回复；未完成、中止、失败及仅包含工具调用的回复不能转述。现有会话缺少伴随扩展时，执行 `/reload` 后重试。
+
+每个工作区同时只运行一个面板转述任务。船长忙碌、转述时直接向其发送其他消息、提供方错误、中止或截断回复、运行时替换均报告失败，不当作成功。接收超时或完成超时仅移除监听，不停止 Pi；不确定请求须先检查船长会话再手动重试。过大的源回复或结果会被拒绝，不静默截断。
+
+转述和元数据保存在宿主提供的插件数据目录，按项目和工作区隔离。会话转录仍由 Pi 管理。中断记录保留，但没有持久任务恢复或自动清理策略。源文本会发送给船长使用的模型提供方；此代码受信任，不提供工具沙箱。
+
+## 安装与激活
+
+在目标机器“设置 → Pi 包 → 可用包”中安装，再到“设置 → PI WEB 插件”显式启用。本包已编译；手动安装可用 `pi install /absolute/path/to/dist/pi-packages/captains-log`。
+
+从承载会话之外手动重启目标 session daemon，再刷新浏览器。仅重启 Web/API 不能激活后端。现有会话执行 `/reload` 加载或更新伴随扩展；项目级包仍须经过正常的项目信任流程。
+
+禁用 PI WEB 插件仅控制面板和后端，不移除原生扩展。移除 Pi 包会移除两种资源声明，但保留会话与插件数据。旧 Workspace Reviews 示例拥有独立插件 ID，须另外禁用或移除。

package/dist/pi-packages/captains-log/package.json

@@ -0,0 +1,35 @@
+{
+  "name": "@chainingintention/pi-captains-log",
+  "version": "0.1.0",
+  "description": "可选船长日志：通过原生 Pi 伴随扩展和 PI WEB 面板转述选中会话的最后一条回复",
+  "private": true,
+  "type": "module",
+  "keywords": ["pi-package"],
+  "files": ["dist", "src", "docs", "test", "tsconfig.json", "vite.config.mjs"],
+  "scripts": { "build": "tsc -p tsconfig.json && vite build", "test": "node --test test/*.test.mjs" },
+  "dependencies": {
+    "marked": "^18.0.6"
+  },
+  "devDependencies": {
+    "@chainingintention/pi-web-cn": "^1.202609.1",
+    "@earendil-works/pi-coding-agent": "^0.87.0",
+    "@types/node": "^24.13.3",
+    "typescript": "^6.0.3",
+    "vite": "^8.1.4"
+  },
+  "peerDependencies": {
+    "@earendil-works/pi-coding-agent": "*",
+    "@chainingintention/pi-web-cn": "^1.202609.1"
+  },
+  "pi": { "extensions": ["./dist/companion.js"] },
+  "piWeb": {
+    "plugins": [{
+      "id": "captains-log",
+      "defaultEnabled": false,
+      "browserRoot": "dist/browser",
+      "module": "dist/browser/index.js",
+      "serverModule": "dist/server.js",
+      "machineSpecific": true
+    }]
+  }
+}

package/dist/pi-packages/captains-log/tsconfig.json

@@ -0,0 +1,21 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "NodeNext",
+    "moduleResolution": "NodeNext",
+    "lib": ["ES2022", "DOM"],
+    "types": ["node"],
+    "rootDir": "src",
+    "outDir": "dist",
+    "strict": true,
+    "exactOptionalPropertyTypes": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitReturns": true,
+    "noFallthroughCasesInSwitch": true,
+    "forceConsistentCasingInFileNames": true,
+    "verbatimModuleSyntax": true,
+    "skipLibCheck": true,
+    "noEmitOnError": true
+  },
+  "include": ["src/**/*.ts"]
+}

package/dist/pi-packages/captains-log/vite.config.mjs

@@ -0,0 +1,28 @@
+import { fileURLToPath } from "node:url";
+import { defineConfig } from "vite";
+
+const packageDir = fileURLToPath(new URL(".", import.meta.url));
+
+export default defineConfig({
+  root: packageDir,
+  base: "./",
+  publicDir: false,
+  build: {
+    outDir: "dist/browser",
+    // Retain the transpiled filenames for existing package/install consumers.
+    emptyOutDir: false,
+    copyPublicDir: false,
+    target: "es2022",
+    sourcemap: false,
+    rollupOptions: {
+      input: fileURLToPath(new URL("src/browser/index.ts", import.meta.url)),
+      preserveEntrySignatures: "strict",
+      output: {
+        format: "es",
+        entryFileNames: "index.js",
+        chunkFileNames: "assets/[name]-[hash].js",
+        assetFileNames: "assets/[name]-[hash][extname]",
+      },
+    },
+  },
+});

package/dist/pi-packages/relays/pi-web-plugin.js

@@ -2,9 +2,9 @@
 import { RELAYS_ROOT } from "./relayDiscovery.js";
 import { defineRelaysPanelElement } from "./relaysPanelElement.js";
 const plugin = {
-    apiVersion: 2,
+    apiVersion: 4,
     name: "中继",
-    activate: ({ pluginId, html, svg }) => {
+    activate: ({ runtimePluginId, html, svg }) => {
         defineRelaysPanelElement();
         return {
             contributions: {
@@ -18,7 +18,7 @@ const plugin = {
                         run: (context) => {
                             if (context.state.selectedWorkspace === undefined)
                                 return;
-                            context.selectWorkspaceTool(`${pluginId}:workspace.relays`);
+                            context.selectWorkspaceTool(`${runtimePluginId}:workspace.relays`);
                         },
                     },
                 ],
@@ -26,12 +26,12 @@ const plugin = {
                     {
                         id: "workspace.relays",
                         title: "中继",
-                        icon: svg `
-              <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
-                <path d="M9 17H7A5 5 0 0 1 7 7h2"></path>
-                <path d="M15 7h2a5 5 0 1 1 0 10h-2"></path>
-                <line x1="8" y1="12" x2="16" y2="12"></line>
-              </svg>
+                        icon: svg `
+              <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+                <path d="M9 17H7A5 5 0 0 1 7 7h2"></path>
+                <path d="M15 7h2a5 5 0 1 1 0 10h-2"></path>
+                <line x1="8" y1="12" x2="16" y2="12"></line>
+              </svg>
             `,
                         order: 50,
                         render: (context) => html `<pi-web-relays-panel .context=${context}></pi-web-relays-panel>`,

package/dist/pi-packages/relays/prompts/relay.md

@@ -19,7 +19,7 @@ The quality of the Relay depends on a clear shared understanding of its destinat
 1. **Start a reviewable draft packet.** Choose a clear Relay name and create `.pi-web/relays/<name>/` in the current drafting checkout. Seed draft `charter.md`, `operations.md`, `status.md`, and `log.md`; mark status **Draft — awaiting approval; not dispatched**. Update these documents as understanding improves so the human can review them through the Relays UI. Draft creation is not dispatch authorization.
 2. **Understand the request and baseline.** Read the repository's canonical agent/contributor instructions and task-relevant project material. Inspect enough current behavior, repository state, and delivery context to distinguish the user's intended outcome from an assumed solution. Keep this bounded to facts that affect the goal, scope edges, feasibility, working location, or first leg; leave implementation archaeology to the Relay.
 3. **Capture understanding without making a roadmap.** Keep `charter.md` to the plain-language goal and observable finish line, minimum outcome acceptance, in-scope edges, explicit non-goals, directly affected behavior to preserve, and material assumptions or human decisions. Put packet/profile identity, proposed operating mode/base, canonical project-guidance pointers, verification/delivery mechanics, and packet isolation in `operations.md`. Put only the proposed first bounded leg and current approval state in `status.md`.
-4. **Do not pre-plan the chain.** Do not create a fixed leg count, work-package hierarchy, exhaustive stage list, expected file/layer map, `plan.md`, or technical design merely to make the Relay look prepared. The route is adaptive. If implementation uncertainty does not change the destination or edges, make the first leg a bounded discovery slice or let its runner resolve it.
+4. **Do not pre-plan the chain.** Do not create a fixed leg count, work-package hierarchy, exhaustive stage list, expected file/layer map, `plan.md`, or technical design merely to make the Relay look prepared. The route is adaptive. Select an implementation-first leg under the runner profile. Reserve research-only work for a concrete unanswered question blocking implementation; routine investigation belongs inside the implementation leg.
 5. **Discuss and refine.** Point the user at the draft packet, summarize the current understanding, ask related material questions together with `ask_user`, and incorporate the answers into the drafts. Do not hide assumptions or settle product, destructive-data, target, base, or delivery choices by guesswork.
 6. **Request approval against the final drafts.** After the user has had a chance to review the final document purposes and content, provide the packet path plus a concise goal/edges, operating-setup, and first-leg summary. Use `ask_user` to offer **Approve and dispatch**, **Revise**, or **Do not dispatch**. The initial request, a clear task, prior general enthusiasm, silence, or permission to create drafts is not dispatch approval. If goal, edges, operating target, or first leg changes materially after approval, update the drafts and obtain fresh approval.
 

package/dist/pi-packages/relays/relaysPanelElement.js

@@ -351,8 +351,8 @@ class PiWebRelaysPanel extends HTMLElement {
         if (documents.documentCount === 0) {
             return `${partialNotice}
         <div class="empty-state">
-          <strong>此中继还没有文档。</strong>
-          <p>Relay Runner 包通常包含 <code>status.md</code>、<code>charter.md</code>、<code>operations.md</code> 和 <code>log.md</code>。</p>
+          <strong>此中继还没有文档。</strong>
+          <p>Relay Runner 包通常包含 <code>status.md</code>、<code>charter.md</code>、<code>operations.md</code> 和 <code>log.md</code>。</p>
         </div>
       `;
         }
@@ -466,12 +466,12 @@ function relaysStyles() {
       select { min-width: 0; max-width: 240px; padding: 5px 6px; }
       .document-tab { flex: 0 0 auto; white-space: nowrap; font-size: 12px; padding: 4px 10px; }
       .document-tab.active { border-color: var(--pi-accent-border); background: var(--pi-accent); color: var(--pi-bg); }
-      .directory-group { flex: 0 0 auto; display: inline-flex; align-items: center; gap: 6px; min-width: 0; border: 1px solid var(--pi-border-muted); border-radius: 10px; background: var(--pi-bg-overlay-soft); padding: 0; margin: -1px 0; }
-      .directory-tab { display: inline-flex; align-items: center; gap: 5px; }
-      .directory-tab .chevron { flex: 0 0 auto; width: 9px; height: 9px; fill: none; stroke: currentColor; stroke-width: 2; stroke-linecap: round; stroke-linejoin: round; transition: transform 0.12s ease; }
-      .directory-tab[aria-expanded="true"] .chevron { transform: rotate(90deg); }
-      .directory-tab.contains-active { border-color: var(--pi-accent-border); color: var(--pi-accent); }
-      .directory-tab.contains-active::after { content: ""; width: 5px; height: 5px; border-radius: 50%; background: var(--pi-accent); }
+      .directory-group { flex: 0 0 auto; display: inline-flex; align-items: center; gap: 6px; min-width: 0; border: 1px solid var(--pi-border-muted); border-radius: 10px; background: var(--pi-bg-overlay-soft); padding: 0; margin: -1px 0; }
+      .directory-tab { display: inline-flex; align-items: center; gap: 5px; }
+      .directory-tab .chevron { flex: 0 0 auto; width: 9px; height: 9px; fill: none; stroke: currentColor; stroke-width: 2; stroke-linecap: round; stroke-linejoin: round; transition: transform 0.12s ease; }
+      .directory-tab[aria-expanded="true"] .chevron { transform: rotate(90deg); }
+      .directory-tab.contains-active { border-color: var(--pi-accent-border); color: var(--pi-accent); }
+      .directory-tab.contains-active::after { content: ""; width: 5px; height: 5px; border-radius: 50%; background: var(--pi-accent); }
       code, pre { border: 1px solid var(--pi-border-muted); border-radius: 6px; background: var(--pi-bg); color: var(--pi-text-secondary); font: 12px ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; }
       code { padding: 2px 5px; }
       pre { margin: 0; overflow: auto; padding: 8px; white-space: pre-wrap; overflow-wrap: anywhere; }

package/dist/pi-packages/relays/skills/relay-runner/SKILL.md

@@ -15,6 +15,7 @@ For a Relay using this profile:
 
 - Have the preparation prompt select `relay-runner` before drafting the packet. Record it immediately in draft `operations.md` and retain it as required for every active leg, including implementation, review, remediation, and delivery.
 - Name both `relay` and `relay-runner` in every handoff prompt. Fresh sessions cannot inherit a prior runner's loaded skills.
+- Keep every Relay handoff on the current runner's model by omitting the `model` argument, unless instructed to use a specific model or to choose an appropriate one. Record any Relay-wide model instruction in `operations.md` so it remains available to later runners.
 - Treat the charter as destination and scope edges, `operations.md` as this profile's repository and execution bindings, `status.md` as current position and next work, and repository instructions as the quality and implementation authority.
 - Follow canonical repository policy when it conflicts with a profile default. Record a material operational adaptation in `operations.md`, not the charter. Stop for human intervention when reconciling the conflict would change the finish line or an edge, weaken a protected invariant, or require a product or business decision.
 
@@ -53,19 +54,26 @@ Relay intentionally does not predict the chain. Before dispatch, establish the d
 
 Expected files, subsystems, dependencies, architecture, and sequencing are route assumptions. Keep only what the current or next leg needs in status or a targeted temporary artifact; do not turn route assumptions into stable agreement.
 
-A leg is one context-contained, reviewable slice that leaves coherent durable progress toward the finish line. Prefer a functional, locally verifiable checkpoint. Keep directly coupled implementation, tests or manual checks, contracts, generated outputs, documentation, and integration glue together. Split independent responsibilities rather than splitting mechanically by file or repository layer.
+A leg is one context-contained, reviewable slice that advances the finish line. Development legs implement and verify by default: optimize for the smallest useful behaviour, not the smallest independently testable artifact. A functional checkpoint makes an observable charter outcome available and verifies it through the relevant application boundary. A tested but unused module is a prerequisite, not a functional outcome. Setup, required verification, review and delivery remain legitimate lifecycle legs.
+
+Slice by supported cases across the necessary layers. When a journey is too large, choose a narrower case or a safe partial capability with explicit limitations, keeping the full charter outstanding. Keep directly coupled implementation, checks, contracts, generated outputs, documentation and integration together.
 
 Before substantial work, state the leg's:
 
-- bounded outcome;
-- primary responsibility and expected change surface;
-- coupled verification;
-- deferred dependencies; and
-- checkpoint type: functional or profile-authorized transitional.
+- observable outcome and application boundary;
+- bounded change surface and coupled verification;
+- remaining connection to usable behaviour, if any; and
+- checkpoint type: functional, necessary prerequisite or profile-authorized transitional.
+
+An unconnected prerequisite must name the behaviour it enables and why a connected slice cannot reasonably fit. Its successor prioritizes that connection. Before adding another prerequisite-only leg, reassess the slice and simplify the route; continue only when a concrete dependency still prevents connection.
+
+Routine reading, design, sizing and test investigation belong inside implementation. A research-only leg requires a specific unanswered question blocking responsible implementation: record the blocked behaviour, why available evidence is insufficient and the result needed to proceed. Answer that question and hand off to implementation; intervene if it remains unresolved. Size or complexity alone calls for a smaller implementation slice.
+
+Choose the simplest design satisfying the charter, canonical project rules and concrete risks introduced by the change. Justify additional safeguards against those obligations; keep speculative recovery systems and future-use abstractions outside the slice. Preserve safety when narrowing behaviour.
 
-Persist only conclusions useful to the next runner. If uncertainty prevents responsible sizing, run a bounded discovery leg with a concrete question and durable result instead of mixing broad archaeology with implementation.
+Persist only conclusions useful to the next runner. Keep leg history in the packet log and project documentation focused on current behaviour and contracts.
 
-If a leg grows beyond its context-contained slice, stop broadening before context exhaustion. Finish or revert to a functional checkpoint, or use an already authorized transition. Record the next bounded slice. Do not promise a fixed total leg count.
+If a leg grows beyond its context-contained slice, stop broadening before context exhaustion. Finish or revert to a coherent functional or justified prerequisite checkpoint, or use an already authorized transition. Record the next bounded slice. Do not promise a fixed total leg count.
 
 When status does not name the next task, choose the smallest coherent slice that advances the critical path or unblocks an agreed outcome. Do not invent cleanup or speculative follow-up merely to fill a leg.
 
@@ -130,7 +138,7 @@ Do **not** put a quality bar, technical design, expected files or subsystems, ve
 Write the profile's mechanics to `operations.md` instead:
 
 - packet identity and `relay-runner` as the profile required in every leg and handoff;
-- adaptive leg sizing and critical-path task selection, with route assumptions provisional and no fixed leg count;
+- implementation-first leg sizing and outcome-led task selection under this profile, with route assumptions provisional and no fixed leg count;
 - pointers to canonical repository instructions and applicable project skills;
 - checkpoint and transition policy;
 - packet root, working location, branch, immutable base commit, initial HEAD, pre-existing state, packet isolation, and exact review range;
@@ -158,11 +166,11 @@ Use this loop:
 
 1. Read `charter.md`, `operations.md`, `status.md`, and only targeted context they reference. Then load canonical project skills applicable to this leg.
 2. Confirm that the prompt's leg identifier, status baton, working location, branch, and blockers are consistent. Resolve small baton defects with targeted inspection; intervene instead of broad archaeology or guessing about intent.
-3. Choose the explicit next task from status when it fits the charter and leg size. Otherwise apply the operations record's critical-path task-selection policy. If the task remains ambiguous or falls outside the finish line, intervene.
+3. Use status's next outcome as the starting point. Revise inherited sequencing or design when a simpler connected slice better advances it. Safe implementation splits within the charter are runner decisions, not approval requests. If the intended outcome remains ambiguous or falls outside the finish line, intervene.
 4. Re-anchor to the finish line and perform the containment check. Do exactly one bounded slice. Do not audit unrelated code, execute the next nominal leg too, or expand scope under the guise of quality.
 5. Run every focused check meaningful for the slice and report exact results. Before whole review, run the full verification named by `operations.md`. Never describe failed, skipped, or incomplete verification as passing.
 6. Make delivery changes durable under the operations record's commit policy without absorbing unrelated state. Keep packet-only writes out of delivery commits.
-7. Update status with the new position, completed and next leg identifiers, next task or selection pointer, targeted context, verification state, blockers, and active transition/review pointers. Append the concise leg entry to the log before stopping or handing off.
+7. Update status with the observable progress, completed and next leg identifiers, next outcome, existing seam to connect, concrete constraints, remaining unconnected work, targeted context, verification state, blockers and active transition/review pointers. Keep route choices provisional. Append the concise leg entry to the log before stopping or handing off.
 8. Stop without spawning when Relay completion is recorded, the leg is blocked, or an intervention trigger fires. When the chartered outcome is implemented but required review, approval, or delivery remains, name that lifecycle work as the next leg instead of stopping. Surface the intervention signal clearly. Otherwise hand off exactly once at the end with `spawn_session`.
 
 Use this handoff shape, substituting the actual paths and next identifier:
@@ -177,7 +185,7 @@ Load the `relay` and `relay-runner` skills, then read:
 - .pi-web/relays/<name>/status.md
 
 Do not read log.md end-to-end. Use only targeted entries referenced by charter.md, operations.md, or status.md.
-Run exactly one leg, make its work and packet updates durable, then either hand off once or stop with the recorded intervention signal.
+Run exactly one outcome-led leg under the profile's implementation-first rules. Use status's next outcome and connection priority; adapt the route within the charter. Make work and packet updates durable, then either hand off once or stop with the recorded intervention signal.
 ```
 
 ## Whole-work review and remediation
@@ -200,7 +208,7 @@ For each attempt:
 - When attempt 2 has a blocking finding, do not automatically consume attempt 3. Invoke the remediation contingency only when concrete evidence shows that an attempted remediation reasonably expected to resolve a blocker did not, remediation introduced an in-scope regression, or materially new evidence reveals a blocker that could not reasonably have been assessed earlier—and one bounded remediation is likely to resolve it. Record that justification, mark the contingency invoked, and dispatch one coherent remediation leg followed by attempt 3. Expanded scrutiny, a changed standard, deferred already-available evidence, or speculative possibility does not qualify. If a genuine blocker remains but the contingency is not justified or bounded, intervene.
 - When exceptional attempt 3 still has any blocking finding, stop the automatic loop. Record the unresolved findings and exact decision needed, raise the human intervention signal, and do **not** dispatch remediation or a fourth review. A human may accept an authorized risk, change the agreement, stop the Relay, or explicitly grant a bounded additional remediation/review attempt.
 
-The reviewer chooses proportionate independent review and records that decision. Independent subreviews are optional; use them only when a specific changed surface benefits from focused expertise, not to create review theater or increase the chance of finding something. The reviewer may use `spawn_subsession` for report-only focused reviews, then `yield_to_subsessions` and consolidate. Subreview prompts must identify repository, base and exact diff, the charter's goal and edges, canonical quality instructions, and the prohibition on all writes including packet changes. The consolidating reviewer is the sole packet writer. Do not assume a particular model is available. The Relay handoff still uses one `spawn_session` only at the end of the leg.
+The reviewer chooses proportionate independent review and records that decision. Independent subreviews are optional; use them only when a specific changed surface benefits from focused expertise, not to create review theater or increase the chance of finding something. The reviewer may use `spawn_subsession` for report-only focused reviews, then `yield_to_subsessions` and consolidate. Subreview prompts must identify repository, base and exact diff, the charter's goal and edges, canonical quality instructions, and the prohibition on all writes including packet changes. The consolidating reviewer is the sole packet writer. The Relay handoff still uses one `spawn_session` only at the end of the leg.
 
 A blocking finding needs concrete evidence of an in-scope defect: for example a reproduced failure, a failing relevant check, a specific execution path that violates the approved outcome, or a clear breach of a material contract, invariant, security, authorization, or data-integrity boundary. Mere possibility, stylistic preference, optional hardening, hypothetical future requirements, or “there could be an edge case” is not blocking. If proportionate targeted inspection cannot establish applicability and impact, classify the concern as non-blocking or omit it rather than forcing remediation.
 

package/dist/pi-web-plugins/files/browser/assets/files-icon-DZObYhxb.svg

@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
+  <path d="M3 6.5A2.5 2.5 0 0 1 5.5 4H10l2 2h6.5A2.5 2.5 0 0 1 21 8.5v8A2.5 2.5 0 0 1 18.5 19h-13A2.5 2.5 0 0 1 3 16.5z"/>
+</svg>