pi-session-mcp 0.13.1 → 0.14.1

package/dist/writer-lifecycle.js

@@ -344,7 +344,7 @@ export async function inspectWork(ctx, name) {
     });
     return {
         baseline: head === state.base.commit && refs.length === 1 && refs[0].name === state.base.ref && refs[0].commit === state.base.commit && tree === baseTree,
-        dirty: tree !== headTree, branches: refs.filter(({ name }) => name.startsWith("refs/heads/")),
+        dirty: tree !== headTree, head: head, branches: refs.filter(({ name }) => name.startsWith("refs/heads/")),
         digest: `sha256:${createHash("sha256").update(result.stdout).digest("hex")}`,
     };
 }
@@ -412,10 +412,16 @@ if [ "$tree" != "$(${BOUNDARY_GIT} rev-parse 'HEAD^{tree}')" ]; then
   export GIT_COMMITTER_NAME=pi-writer GIT_COMMITTER_EMAIL=pi-writer@example.invalid
   commit=$(printf '%s\\n' 'WIP collected by pi-session-mcp' | ${BOUNDARY_GIT} commit-tree "$tree" -p HEAD)
   branch=$(${BOUNDARY_GIT} symbolic-ref --short HEAD || printf '%s' "$4")
-  if ${BOUNDARY_GIT} --git-dir=/tmp/scratch show-ref --verify --quiet "refs/heads/$branch-wip"; then
+  # A taken name, or one that conflicts with an exported branch path, is refused rather than aborting the export.
+  if ${BOUNDARY_GIT} --git-dir=/tmp/scratch show-ref --verify --quiet "refs/heads/$branch-wip" \\
+    || ! ${BOUNDARY_GIT} --git-dir=/tmp/scratch update-ref "refs/heads/$branch-wip" "$commit" 2>/dev/null; then
+    printf '%s\\n' ref_name_refused
+  fi
+elif ! ${BOUNDARY_GIT} symbolic-ref -q HEAD >/dev/null 2>&1 && [ -n "$(${BOUNDARY_GIT} rev-list -n 1 HEAD --not --branches)" ]; then
+  # Clean detached HEAD that no branch of the clone reaches: export its commit under a derived name (#193).
+  if ${BOUNDARY_GIT} --git-dir=/tmp/scratch show-ref --verify --quiet "refs/heads/$4-detached" \\
+    || ! ${BOUNDARY_GIT} --git-dir=/tmp/scratch update-ref "refs/heads/$4-detached" "$(${BOUNDARY_GIT} rev-parse --verify HEAD)" 2>/dev/null; then
     printf '%s\\n' ref_name_refused
-  else
-    ${BOUNDARY_GIT} --git-dir=/tmp/scratch update-ref "refs/heads/$branch-wip" "$commit"
   fi
 fi
 if [ -z "$(${BOUNDARY_GIT} --git-dir=/tmp/scratch for-each-ref --format='%(refname)')" ]; then
@@ -450,6 +456,14 @@ fi`;
                 return { status: "failed", code: "writer_collect_incomplete", refs, refused: findings.length, findings };
             }
             const work = await inspectWork(ctx, name);
+            // Defence in depth (#193): whatever the boundary script exported or reported as nothing to collect,
+            // every commit the clone's work refers to must exist as a commit object in the operator checkout
+            // before a digest is recorded.
+            for (const sha of [work.head, ...work.branches.map((branch) => branch.commit)]) {
+                if (sha === undefined || await git(ctx, ["cat-file", "-e", `${sha}^{commit}`], true) === undefined) {
+                    return { status: "failed", code: "writer_collect_incomplete", refs, refused: findings.length, findings };
+                }
+            }
             await writeWriterState(ctx.home, name, { ...state, collected: { digest: work.digest, at: new Date().toISOString() } });
             return { status: "ok", code: refs.length === 0 ? "nothing_to_collect" : "writer_collected", refs, refused: findings.length, findings };
         }

package/dist/writer-relay.js

@@ -2,6 +2,7 @@ import { constants } from "node:fs";
 import { open } from "node:fs/promises";
 import { Client } from "@modelcontextprotocol/client";
 import { z } from "zod";
+import { projectExecutionProfile } from "./capabilities.js";
 import { ChildStdioTransport } from "./child-stdio-transport.js";
 import { PiSessionCreationError, WriterUnavailableError } from "./pi-adapter.js";
 import { RegistryError } from "./session-registry.js";
@@ -71,6 +72,16 @@ const creationCodes = new Set([
     "extension_not_installed", "extension_version_mismatch", "extension_load_failed", "extension_tool_conflict",
     "extension_tool_missing", "skill_load_failed", "sandbox_unavailable", "pi_session_creation_failed",
 ]);
+const exactFields = ["permissionProfile", "provider", "model", "thinkingLevel", "shell"];
+const setFields = ["skills", "extensions", "grantedExtensionTools"];
+const sameSet = (left, right) => {
+    const a = new Set(left), b = new Set(right);
+    return a.size === left.length && b.size === right.length && a.size === b.size && [...a].every(value => b.has(value));
+};
+/** Admission compares every public capability field; a duplicate on either side is a mismatch. */
+function samePublishedProfile(host, inner) {
+    return exactFields.every(key => host[key] === inner[key]) && setFields.every(key => sameSet(host[key], inner[key]));
+}
 class InnerError extends Error {
     code;
     constructor(code) {
@@ -306,7 +317,7 @@ export class WriterRelayAdapter {
                 const capabilities = await connection.call("pi_capabilities_get", {}, capabilitiesSchema, remaining(), input.signal);
                 const inner = capabilities.executionProfiles.find(profile => profile.alias === input.executionProfile.alias);
                 const host = this.options.executionProfiles.get(input.executionProfile.alias);
-                if (!host || !inner || ["permissionProfile", "provider", "model", "thinkingLevel"].some(key => inner[key] !== host[key])) {
+                if (!host || !inner || !samePublishedProfile(projectExecutionProfile(host), inner)) {
                     counts.settingsChanged++;
                     continue;
                 }

package/docs/acceptance.md

@@ -112,7 +112,9 @@ env -i HOME="$DISPOSABLE_HOME" PATH="$PATH" PI_SESSION_MCP_CONFIG="$ACCEPTANCE_C
   `skill_already_equivalent`, `skill_verified`, `skill_removed`,
   `skill_installed`, `skill_verified`, `skill_removed`); the skill file exists
   after steps 3 and 7 and is gone after steps 6 and 9; a foreign skill placed
-  in the same skill directory stays unchanged throughout.
+  in the same skill directory stays unchanged throughout. From 0.14.0 on
+  (#139), that holds for both controller skills, `pi-session-orchestration`
+  and `pi-session-profiles`, each with its own finding in that order.
 - Steps 1 and 2 leave the client state unchanged.
 - After step 9 the `pi-session-mcp` registration is absent, the sentinel is still
   present, and the ownership record set is empty. The ownership directory has
@@ -2535,6 +2537,316 @@ Not established for `0.13.0`: the sandbox on a host that restricts unprivileged
 user namespaces; Git inside the sandbox on a linked worktree in live use (the
 bubblewrap-gated tests cover it); the macOS upgrade; Level 3.
 
+### v0.13.1 post-release evidence
+
+Recorded on 2026-10-29 for the published release `0.13.1`.
+
+Tag binding: a fresh clone of the annotated tag `v0.13.1` (tag object
+`57c0786f1db3f732db797c8204e338ce17cf7fb2`) peels to the merge commit
+`c25c7687ecb66043a001c689c64e77be3cd25952` of #185, and
+`git describe --tags --exact-match` reports `v0.13.1`. CI on the merge commit
+(run 40832546742) and on the tag (run 40833087074) passed on the first attempt.
+
+- Level 1 on the tag clone after `npm ci`, from 07:32 to 07:34 UTC with
+  Node.js `26.12.1` and npm `12.2.1`: typecheck, `build:cli`, the test run
+  (136 files, 3948 passed, 14 skipped, with
+  `NODE_OPTIONS=--unhandled-rejections=strict`), `build` and
+  `git diff --check` exited with `0`, and the status stayed clean. Doctor
+  reported `packageVersion` `0.13.1` and exited with `2` because no
+  configuration was set (`config_missing`). The manifests were unchanged
+  afterwards.
+- `pi-session-mcp@0.13.1` on npm: 922 files, shasum
+  `e2e0e2652a2cab6bf891e61bcfa14754258eb59b`, `gitHead` `c25c768` (the merge
+  commit). It was staged and approved by the maintainer; `npm pack` of the tag
+  clone and the dry run of the publishing clone give the same shasum and file
+  count.
+- Published npm package, Level 2 from a fresh prefix, 07:34 to 07:36 UTC:
+  160 of 160 with delivery off and 228 of 228 with `--events spool`; real
+  registrations and built files unchanged, no process left, leak check passed.
+  Clients: Codex CLI `0.162.1` and Claude Code `2.1.312`. The install smoke on
+  the published package reported `smoke_passed` with version `0.13.1`.
+- The GitHub release `v0.13.1` was published the same day.
+
+Operator upgrade of the workstation from `0.13.0` to `0.13.1` on 2026-10-29
+from 09:35 UTC, following
+[Installation](installation.md#container-writers): no writer container ran at
+the start; controller sessions without a coding session stayed open and need a
+reconnect. Both client targets were removed with `0.13.0`, then
+`npm install -g pi-session-mcp@0.13.1`. Doctor reported only
+`writer_not_ready` for the 18 writers. A dry run of each provisioning command
+with unchanged settings reported `mode_unchanged` and `writer_planned`; with
+`--apply`, five container repositories with 18 writers (2 with
+`--tags reachable`, 4, 4 with `--cache go`, 4 with base `dev`, 4 with
+`--cache uv`, three of them with operator images) reported `writer_accepted`
+from 09:36 to 09:39 UTC. Client-target `--apply` and `--verify` passed for
+`claude-code:user` and `codex:user` (`mcp_verified`, `skill_verified`, and
+`hook_verified` for the wake hook); `--writer <name> --verify` passed for all
+18 writers. Doctor reported no error, only the known `workspace_gitfile` and
+`workspace_mode_unset` warnings of the worktree aliases.
+
+Operator upgrade of the second machine (Linux) from `0.13.0` to `0.13.1` on
+2026-10-29 from 09:47 UTC, with Node.js `24.22.0` and the same steps: no
+writer container and no server process of a client session ran at the start.
+Both client targets were removed with `0.13.0`, then
+`npm install -g pi-session-mcp@0.13.1`; Doctor reported only
+`writer_not_ready` for the 14 writers. The dry runs reported `mode_unchanged`
+and `writer_planned`; with `--apply`, four container repositories with 14
+writers (4, 2, 4 with an operator image and `--cache go`, 4 with an operator
+image) reported `writer_accepted` from 09:48 to 09:51 UTC. Client-target
+`--apply` and `--verify` passed for `claude-code:user` and `codex:user`
+(`mcp_verified`, `skill_verified`), and `--writer <name> --verify` passed for
+all 14 writers. Doctor reported no error, only `workspace_mode_unset` for one
+workspace without a mode.
+
+### v0.14.1 pre-release acceptance
+
+`v0.14.1` was accepted on 2026-10-30 from 06:04 to 06:15 UTC on its release
+candidate `a239610`, on Linux (`x64`) with Node.js `26.12.1`, npm `12.2.1`,
+Codex CLI `0.162.1` and Claude Code `2.1.314`. Level 2 passed in the working
+tree and for the packed tarball, each with delivery off and with delivery on.
+Level 1 passed except `npm audit`. Later commits on the release pull request
+change only this record.
+
+The patch release ships Sprint 12 (#192, #193, #194) from `main` at `d9a47f5`;
+the candidate adds only the version, the changelog heading and the roadmap
+line. The MCP tool contract, result codes and configuration schema are
+unchanged. The source changes were accepted on the branch before the merge, see
+[Sprint 12 candidate acceptance](#sprint-12-candidate-acceptance-2026-10-30),
+including Level 3.
+
+- Level 1 in the checkout of the candidate after `npm ci`: every command exited
+  with `0`, except `npm audit`; `git status --short` printed nothing.
+  - The test run, with `NODE_OPTIONS=--unhandled-rejections=strict`, reported
+    141 files, 4044 passed and 14 skipped, and no unhandled error.
+  - `npm audit` and `npm audit --omit=dev` exited with `1` and name only the
+    known `undici` 8.10.2 finding through `@earendil-works/pi-coding-agent`
+    1.4.0, the latest SDK release, with eight advisories
+    ([#120](https://github.com/plagor44-ux/pi-session-mcp/issues/120)).
+  - `npm pack` listed 933 files (tarball shasum
+    `47cf66a3856530112c11095d07cb05b7ab9892f4`, identical in three packs). A
+    scan of the unpacked files for private names, hosts and the maintainer's
+    home path found none.
+  - Doctor reported `packageVersion` `0.14.1`. It exited with `2` because no
+    configuration was set (`config_missing`).
+- Level 2 in the working tree: 160 of 160 checks passed with delivery off and
+  228 of 228 with `--events spool`.
+- Packed-tarball Level 2 from a fresh prefix: 160 of 160 with delivery off and
+  228 of 228 with `--events spool`. The install smoke from another fresh prefix
+  reported `smoke_passed` with version `0.14.1`.
+- In every Level 2 run the real client registrations were unchanged, no process
+  remained, the leak check passed and the disposable directories were removed.
+- Podman-gated writer tests on the candidate (Podman `6.1.4`): 8 of 8 passed
+  (7 lifecycle tests, including the detached-`HEAD` export of #193, and 1
+  boundary test).
+- Bubblewrap-gated sandbox tests (`test/sandbox-shell.bwrap.test.ts`, bubblewrap
+  `0.13.1`): 12 of 12 passed, none skipped.
+
+Not established for `0.14.1` beyond the Sprint 12 record: a Level 3 cycle on
+the release candidate itself, and the published-release Level 2 and upgrades,
+which follow after publishing.
+
+### Sprint 12 candidate acceptance (2026-10-30)
+
+Recorded on 2026-10-29 and 2026-10-30 for the unreleased branch
+`fix/s12-audit-findings` ([Sprint 12](sprints/2026-10-29-s12-audit-fixes.md),
+#192, #193, #194). No release, tag or npm publish.
+
+- Level 1 on the final source `9426682` in a separate detached worktree with
+  Node.js `26.12.1`: `npm ci`, typecheck, `build:cli`, the test run (530 files,
+  4044 passed, 14 skipped, 0 failed, no unhandled error, with
+  `NODE_OPTIONS=--unhandled-rejections=strict`), `build` and
+  `git diff --check 9d9cf8c..HEAD` exited with `0`. The same on the earlier
+  candidate `896e29d`: 4043 passed, 0 failed.
+- Real rootless Podman with the pinned Node image (git `2.39.5`):
+  `test/writer-lifecycle.podman.test.ts` 7 of 7, including the new clean
+  detached-HEAD case, which fails against the source of `9d9cf8c`. In the image,
+  `core.useReplaceRefs=false` makes a graft-hidden detached commit visible
+  again.
+- Level 2 on `npm pack` of `896e29d`, installed into a fresh prefix below the
+  home directory: 160 of 160 with delivery off and 228 of 228 with
+  `--events spool`; real registrations and built files unchanged, no process
+  left, path-leak scan 0 hits. Clients: Codex CLI `0.162.1` and Claude Code
+  `2.1.312`. The two later commits change the guard's Git arguments and a
+  regular-expression spelling; Level 2 was not repeated for them.
+- Live profile change (item D), on an expendable test configuration: a
+  candidate with the new read-only profile `review-sonnet`
+  (`anthropic/claude-sonnet-5-5`), Doctor without error, probe dry run, one
+  probe turn (`probe_passed`), timestamped backup and atomic replacement,
+  Doctor, then real use by a fresh server for the R1 and final reviews; rolled
+  back to the backup afterwards, Doctor without error. No production
+  configuration or writer was touched.
+- Live container writer (items B and C), with the packed candidate, an
+  expendable configuration and a synthetic repository: profile `s12-code`
+  (`deepseek/deepseek-flash`, coding, skill `pi-session-implementation`),
+  one probe turn (`probe_passed`); `--repo s12-probe --mode container
+  --profiles s12-code --writers 1 --apply` reported `writer_provisioned` and
+  `writer_accepted`, `--writer s12-probe-w1 --verify` `mcp_verified`. A real
+  relayed coding session completed its task; `--collect --apply` imported
+  `refs/remotes/writer-s12-probe-w1/s12-live-c`, whose commit passed the
+  oracle (4 of 4 tests), and `--finish --apply` reported `writer_reset`. With
+  the host profile's skills then changed, a start failed with
+  `writer_unavailable`, reason `none_admitted`, counts
+  `settingsChanged: 1`, and collection afterwards found `nothing_to_collect`.
+  After `--writer s12-probe-w1 --remove` and the provisioning request again,
+  the writer was accepted and verified and a start succeeded. Rolled back:
+  writer removed, configuration, repository and prefix deleted.
+- Level 3, ten-task cycle, on the final source `9426682` (`dist/main.js`
+  SHA-256 `ab93e3a932b1d5147dcbb48bbb85d9442c2214e486101f8d427360b99672cfdb`)
+  from a separate detached checkout, with a temporary credential-free
+  configuration (`l3-read` read-only and `l3-code` coding, both
+  `deepseek/deepseek-flash`), synthetic fixtures, events off, one probe turn
+  per profile as preflight. Claude Code `2.1.312` ran as `claude -p` with a
+  per-invocation `--mcp-config`, `--strict-mcp-config` and
+  `--model claude-sonnet-5-5`; Codex CLI `0.162.1` as `codex exec
+  --ignore-user-config` with `-c mcp_servers.*` overrides. Both clients could
+  wait with `sleep` between polls.
+  - Cycle 1 was not accepted: 5 of 10. The worker ignored a requested
+    ordering in both follow-ups (T2), refused the abort task's essay prompt
+    within about 1.5 seconds so that nothing was left to abort (T5), and the
+    Codex coding snapshot could not be written from the Codex sandbox (T3). A
+    path hit came from the worker's `assistantText`, not from server
+    metadata. No Pi Session MCP defect was found; the cycle is kept unchanged
+    with its own pre-registration.
+  - Cycle 2, with a new pre-registration before its first task (order-free
+    LOW oracle, a long deterministic listing as the abort prompt, snapshots
+    inside the controller directory, the leak scan separating server metadata
+    from `assistantText`): 10 of 10. Read-only fixture digests unchanged; both
+    coding snapshots pass their oracle and the fixture tests and show only the
+    allowed files; both abort tasks show running, abort, `aborted`, close, an
+    empty `pi_session_list` and a fresh `idle` session. Zero leak hits, also in
+    `assistantText`; no server or client process before or 10 seconds after any
+    invocation. Polls per turn: Claude Code 1 to 2, Codex 2 to 4. Deviation:
+    the Codex sandbox refused to spawn `git`, so the Codex snapshots' status
+    lists were derived from the barrier snapshot trees against `HEAD`.
+  The cycle-2 gate holds.
+
+Not established: a release of these fixes, the operator rollout on either
+machine, macOS, and #120.
+
+### v0.14.0 post-release evidence
+
+Recorded on 2026-10-29 for the published release `0.14.0`.
+
+Tag binding: a fresh clone of the annotated tag `v0.14.0` (tag object
+`f3a8b088a85fd5825c3256f4a7950ba051cbf388`) peels to the merge commit
+`fd4fdeacf9d02c04b6fd89314f7ec819b5506ed9` of #190, and
+`git describe --tags --exact-match` reports `v0.14.0`. CI on the merge commit
+(run 40928709705) and on the tag (run 40929602738) passed on the first attempt.
+The tag was created after the npm package had been published; the package
+records `gitHead` `d904fed`, the head of #190, whose tree (`3ae966b`) is
+identical to the merge commit's.
+
+- Level 1 on the tag clone after `npm ci`, from 18:18 to 18:20 UTC with
+  Node.js `26.12.1` and npm `12.2.1`: typecheck, `build:cli`, the test run
+  (139 files, 4005 passed, 14 skipped, with
+  `NODE_OPTIONS=--unhandled-rejections=strict`), `build` and
+  `git diff --check` exited with `0`, and the status stayed clean. Doctor
+  reported `packageVersion` `0.14.0` and exited with `2` because no
+  configuration was set (`config_missing`).
+- `pi-session-mcp@0.14.0` on npm: 932 files, shasum
+  `579cc111a7aa62987b5f35e79b34b69853c8a0e3`. It was published by the
+  maintainer; `npm pack` of the tag clone gives the same shasum and file count.
+- Published npm package, Level 2 from a fresh prefix, 18:19 to 18:21 UTC:
+  160 of 160 with delivery off and 228 of 228 with `--events spool`; real
+  registrations and built files unchanged, no process left, leak check passed.
+  Clients: Codex CLI `0.162.1` and Claude Code `2.1.312`. The install smoke on
+  the published package reported `smoke_passed` with version `0.14.0`.
+- The GitHub release `v0.14.0` was published the same day.
+
+Operator upgrade of the workstation from `0.13.1` to `0.14.0` on 2026-10-29
+from 18:33 UTC, following
+[Installation](installation.md#container-writers): no Pi session of this
+controller was open; other controller sessions without a coding session stayed
+open and need a reconnect. Both client targets were removed with `0.13.1`, then
+`npm install -g pi-session-mcp@0.14.0`. Doctor reported only
+`writer_not_ready` for the 18 writers. A dry run of the first provisioning
+command with unchanged settings reported `mode_unchanged` and
+`writer_planned`; with `--apply`, five container repositories with 18 writers
+(2 with `--tags reachable`, 4, 4 with `--cache go`, 4 with base `dev`, 4 with
+`--cache uv`, three of them with operator images) reported `writer_accepted`
+from 18:34 to 18:37 UTC. Client-target `--apply` and `--verify` passed for
+`claude-code:user` and `codex:user` (`mcp_verified`, `skill_verified` for both
+controller skills, and `hook_verified` for the wake hook); `--writer <name>
+--verify` passed for all 18 writers. Doctor reported no error, only the known
+`workspace_gitfile` and `workspace_mode_unset` warnings of the worktree
+aliases.
+
+Operator upgrade of the second machine (Linux) from `0.13.1` to `0.14.0` on
+2026-10-29 from 18:38 UTC, with Node.js `24.22.0` and the same steps; one
+controller session's server process stayed open and needs a reconnect. Both
+client targets were removed with `0.13.1`, then
+`npm install -g pi-session-mcp@0.14.0`; Doctor reported only
+`writer_not_ready` for the 14 writers. With `--apply`, four container
+repositories with 14 writers (4, 2, 4 with an operator image and `--cache go`,
+4 with an operator image) reported `writer_accepted` from 18:39 to 18:42 UTC.
+Client-target `--apply` and `--verify` passed for `claude-code:user` and
+`codex:user` (`mcp_verified`, `skill_verified` for both controller skills), and
+`--writer <name> --verify` passed for all 14 writers. Doctor reported no
+error, only `workspace_mode_unset` for one workspace without a mode.
+
+Not established for `0.14.0` after the upgrade: a coding session through a
+re-accepted writer, an agent-driven profile change end to end, and Level 3.
+
+### v0.14.0 pre-release acceptance
+
+`v0.14.0` was accepted on 2026-10-29 from 17:56 to 18:01 UTC on its release
+candidate `6e18659`, on Linux (`x64`) with Node.js `26.12.1`, npm `12.2.1`,
+Codex CLI `0.162.1` and Claude Code `2.1.312`. Level 2 passed in the working
+tree and for the packed tarball, each with delivery off and with delivery on.
+Level 1 passed except `npm audit`. Later commits on the release pull request
+change only this record.
+
+The minor release ships #139 ([ADR 0014](adr/0014-profile-probe-and-model-catalog.md))
+and #188. The MCP tool contract is unchanged. Setup gains `--list-models` and
+`--probe-profile`, installs a second controller skill (`pi-session-profiles`)
+and so reports one more skill finding per client target; Doctor gains the
+check `skill_controller_selected`.
+
+The first working-tree run on the earlier candidate `08fc620` failed 36 of 160
+checks: the Level 2 harness still expected one controller skill finding, so
+every step saw one finding too many. Setup itself reported the expected
+findings. The candidate `6e18659` teaches the harness both controller skills
+with the same number of checks; every result below is from that candidate.
+
+- Level 1 in a clean worktree of the candidate after `npm ci`: every command
+  exited with `0`, except `npm audit`; `git status --short` printed nothing.
+  - The test run, with `NODE_OPTIONS=--unhandled-rejections=strict`, reported
+    139 files, 4005 passed and 14 skipped, and no unhandled error.
+  - `npm audit` and `npm audit --omit=dev` exited with `1` and name only the
+    known `undici` 8.10.2 finding through `@earendil-works/pi-coding-agent`
+    1.4.0, the latest SDK release, with eight advisories
+    ([#120](https://github.com/plagor44-ux/pi-session-mcp/issues/120)).
+  - `npm pack` listed 932 files (tarball shasum
+    `4eb9b77c9484292a8533c6be0fda44ac18656787`, identical in three packs). A
+    scan of the unpacked files for private names, hosts and the maintainer's
+    home path found none.
+  - Doctor reported `packageVersion` `0.14.0`. It exited with `2` because no
+    configuration was set (`config_missing`).
+- Level 2 in the working tree: 160 of 160 checks passed with delivery off and
+  228 of 228 with `--events spool`.
+- Packed-tarball Level 2 from a fresh prefix: 160 of 160 with delivery off and
+  228 of 228 with `--events spool`. The install smoke from another fresh prefix
+  reported `smoke_passed` with version `0.14.0`.
+- In every Level 2 run the real client registrations were unchanged, no process
+  remained, the leak check passed and the disposable directories were removed.
+- Podman-gated writer tests on the candidate (Podman `6.1.4`): 7 of 7 passed.
+- Bubblewrap-gated sandbox tests (`test/sandbox-shell.bwrap.test.ts`, bubblewrap
+  `0.13.1`): 12 of 12 passed, none skipped.
+- Live checks before the candidate, on the merged #139 code: `--list-models`
+  against a real local Pi installation reported authentication for the
+  configured providers, the probe dry run planned two profiles, and one
+  `--probe-profile <alias> --apply` returned `probe_passed` with one provider
+  turn.
+- Review: #139 had three cross-family reviews (author family OpenAI and
+  Anthropic, reviewer family GLM) and #188 one, each without blocking findings;
+  their findings were fixed or declined with a reason in #187 and #189. The
+  harness fix in this release was checked by its live run above.
+
+Not established for `0.14.0`: an agent-driven profile change end to end with
+the `pi-session-profiles` skill, a container writer acceptance of a newly
+created profile, client-target `--verify` through the installed package, which
+follows the upgrade; Level 3.
+
 ### v0.13.1 pre-release acceptance
 
 `v0.13.1` was accepted on 2026-10-29 from 06:40 to 06:48 UTC on its release

package/docs/adr/0012-leased-writer-pool.md

@@ -161,12 +161,16 @@ base.
   In both cases the host server closes that launcher and tries the next
   candidate. The inner writer guard stays the authority for baseline admission
   inside the boundary.
-- Before the inner start the relay compares the requested profile's entry in
-  the writer's validated `pi_capabilities_get` (permission profile, provider,
-  model, thinking level) with the host's configured profile and moves on with
-  `writer_settings_changed` on any difference, so a writer never runs an
-  outdated version of a host profile. The launcher cannot do this check: it
-  starts before the profile is known.
+- Before the inner start the relay compares every public capability field of
+  the requested profile's entry in the writer's validated `pi_capabilities_get`
+  with the host's configured profile: `permissionProfile`, `provider`, `model`,
+  `thinkingLevel` and `shell` exactly, and `skills`, `extensions` and
+  `grantedExtensionTools` as sets. A mismatch or a missing entry counts as
+  `settingsChanged`, starts no inner session and moves on to the next
+  candidate, so a writer never runs an outdated version of a host profile. The
+  launcher cannot do this check: it starts before the profile is known.
+  (Amended 2026-10-29, #194: the comparison covers every public capability
+  field, not only permission profile, provider, model and thinking level.)
 - If no candidate is admitted, the start fails with `writer_unavailable`, a
   content-free reason and content-free counts. `none_ready`: no writer of the
   workspace is ready, migrated and has a recorded acceptance (whether that

package/docs/adr/0013-hardened-read-only-profiles.md

@@ -145,6 +145,36 @@ directly after `grantedExtensionTools`. This is configured intent only.
   MCP tools and the granted extension tools. A profile with granted extension
   tools cannot have a sandboxed shell.
 
+### Amendment 2026-10-29: context files
+
+Issue #192. Previously every resource loader kept the SDK behaviour: Pi
+context files (`AGENTS.override.md`, `AGENTS.md`, `AGENTS.MD`, `CLAUDE.md`,
+`CLAUDE.MD`) were loaded from the session directory and every ancestor
+directory, and a context file reached through a symlink was followed to its
+target, so a read-only session also loaded context from outside the workspace.
+
+New rule: for **read-only profiles** every resource loader keeps only context
+files whose real path lies inside the workspace's real path, on every reload
+and before the first provider request. A symlinked context file that resolves
+outside the workspace, a dangling one, and the context files of ancestor
+directories above the workspace (including a main repository above a linked
+worktree) are not loaded for read-only profiles; the linked worktree's own file
+inside the workspace is. Coding profiles keep the SDK behaviour (the working
+directory and its ancestors).
+
+The filter runs on the SDK's result, after the SDK has picked the first
+existing name per directory. If that file is dropped, the directory contributes
+no context file: an `AGENTS.override.md` that resolves outside the workspace
+also hides an `AGENTS.md` beside it. This fails closed. A kept file's content
+is read again from its verified real path, so a link swapped after the SDK
+read cannot bring in outside content.
+
+Why: the read roots of this ADR. Section 1 confines the read tools of
+read-only profiles to the workspace and the skill directories; context files
+are model input rather than tool reads, and before this amendment they were the
+one channel through which content from outside those roots still reached a
+read-only session.
+
 ## Contract change and versioning
 
 The capabilities field `shell`, the start error `sandbox_unavailable` and the

package/docs/adr/0014-profile-probe-and-model-catalog.md

@@ -0,0 +1,89 @@
+# ADR 0014: Profile probe and offline model catalog
+
+**Status:** Accepted (2026-10-29); released in 0.14.0. Issue #139.
+
+## Context
+
+The running MCP server reads its configuration once at startup. A controlling
+agent cannot reconnect its own server to prove a changed execution profile.
+Asking for a manual reconnect prevents autonomous profile setup; starting a
+nested controller would add another agent without testing a different boundary.
+The agent also needs an authoritative offline catalog rather than guessing
+provider and model ids or inspecting credential files.
+
+## Decision
+
+### 1. Offline model catalog
+
+`pi-session-mcp-setup --list-models` reports provider ids, model ids and only
+whether authentication is configured. Package-root `ModelRuntime` access sits
+behind injectable `ModelCatalog`. Creation disables model network access and
+refresh (`allowModelNetwork: false`, `refreshOnCreate: false`); the catalog
+uses only `getProviders`, `getModels` and `checkAuth`. `checkAuth` reads the
+local auth configuration offline and returns only its source and kind; the
+catalog reduces that to a boolean and bounds each lookup. `hasConfiguredAuth`
+is not used because it reads a snapshot that only an online availability
+refresh fills, so offline it always reports no authentication. The catalog
+never calls `getAuth` or `getAvailable`. This is a second narrow exception
+next to the writer wrapper's credential refresh (#142), not general permission
+to bypass `PiSessionAdapter`.
+
+Providers registered only by extensions are not listed; every catalog report
+states this limitation. Invalid catalog ids are omitted, never echoed.
+
+### 2. Opt-in profile probe
+
+`--probe-profile review,code` runs Doctor and offline profile, provider, model
+and authentication-presence checks. Only adding `--apply` authorizes one fixed
+PONG turn per passing profile, sequentially, through `PiSessionAdapter`. The
+production dependency is `SdkPiSessionAdapter`, resolving the profile as the
+server does and protecting both the named and canonical configuration
+directories from read-root expansion through skills.
+
+Doctor blocks on global configuration/build/version errors and errors about
+the requested profiles. Other errors and warnings are reported by check id
+without blocking this request. Tests inject a fake catalog, adapter and Doctor;
+no provider credentials are needed.
+
+The session uses a private empty temporary directory, mode 0700, created
+internally and removed after bounded session cleanup. This is a narrow
+exception to the configured-workspace rule: the directory is not a workspace
+alias and is never supplied as a tool or CLI argument. It avoids exposing a
+real repository as the probe's working directory; it does not sandbox trusted
+extensions or change coding profiles' existing authority.
+
+Start, turn and cleanup deadlines are 60, 120 and 10 seconds respectively.
+Interrupts abort and dispose the current session and skip remaining profiles.
+The fixed prompt is not configurable, the reply text is never reported, usage
+is `unknown`, and each finding records whether a provider turn was accepted.
+No event spool is enabled.
+
+### 3. Guarded, lazy CLI entry
+
+Ordinary setup requests never import the probe entry or install its stdout
+guard. The catalog and probe load it dynamically after the platform gate;
+the catalog needs no configuration. Its first import installs the same stdout
+guard as the server before SDK evaluation. Only the guard's transport writer
+emits reports; foreign stdout, including extension `console.log`, is dropped.
+Adapter diagnostics are structured JSON on stderr without prompts or secrets.
+Operational exceptions produce fixed refusal codes rather than raw errors.
+
+## Contract change and versioning
+
+The new setup flags and report schemas are additive public CLI contract
+changes under [ADR 0003](0003-post-mvp-maintenance.md#versioning). This decision
+does not itself bump the version or authorize publication.
+
+## Consequences
+
+- Doctor and `--verify` remain provider-free. Only
+  `--probe-profile … --apply` uses a provider among setup operations.
+- Catalog and probe run on Linux and macOS without acquiring the setup lock
+  or changing registrations or configuration.
+- The probe proves the profile on the host using the host Pi agent directory.
+  Container acceptance remains Doctor's `container_profile_refused` check and
+  writer provisioning, not this probe.
+- A successful probe does not reload any running controller's configuration;
+  an MCP server restart or reconnect is still required.
+- Reports expose only sanitized findings, durations and provider-turn presence,
+  not paths, credential values, environment values, prompts or reply text.

package/docs/client-setup.md

@@ -53,6 +53,9 @@ npm run --silent setup -- --apply --target codex:user:pi-session-mcp
 npm run --silent setup -- --verify --target codex:user:pi-session-mcp
 npm run --silent setup -- --rollback --target codex:user:pi-session-mcp
 npm run --silent setup -- --remove --target codex:user:pi-session-mcp
+npm run --silent setup -- --list-models --json
+npm run --silent setup -- --probe-profile review,code --json
+npm run --silent setup -- --probe-profile review,code --apply --json
 ```
 
 Setup runs the previously built `dist/setup-main.js`. The dry-run operation
@@ -109,27 +112,30 @@ inspected:
 None of the failure rows changes a registration or starts the handshake, and
 each exits with `1`.
 
-### Controller skill
+### Controller skills
 
-Besides the registration, `--apply` installs the controller skill
-`pi-session-orchestration` for each target, as a real copy of the effective
-skill: your override in the skill library if you have one, else the skill
-shipped in the package ([Pi skills](skills.md)). Clients discover it without
-further steps.
+Besides the registration, `--apply` installs the controller skills
+`pi-session-orchestration` (delegating work to Pi workers) and
+`pi-session-profiles` (creating, changing and retiring execution profiles) for
+each target, each as a real copy of the effective skill: your override in the
+skill library if you have one, else the skill shipped in the package
+([Pi skills](skills.md)). Clients discover them without further steps.
 
-| Target | Where the skill goes |
+| Target | Where the skills go |
 | --- | --- |
-| `codex:user:pi-session-mcp` | `~/.agents/skills/pi-session-orchestration` |
-| `claude-code:user:pi-session-mcp`, `claude-code:local:pi-session-mcp` | `~/.claude/skills/pi-session-orchestration` (one shared directory) |
-| `claude-code:project:pi-session-mcp` | `<project>/.claude/skills/pi-session-orchestration`, where `<project>` is the directory in which setup runs |
+| `codex:user:pi-session-mcp` | `~/.agents/skills/<skill>` |
+| `claude-code:user:pi-session-mcp`, `claude-code:local:pi-session-mcp` | `~/.claude/skills/<skill>` (one shared directory per skill) |
+| `claude-code:project:pi-session-mcp` | `<project>/.claude/skills/<skill>`, where `<project>` is the directory in which setup runs |
 
-Every result therefore has a second finding per target, with the same client
-and scope and the alias `pi-session-orchestration`:
+`<skill>` is `pi-session-orchestration` or `pi-session-profiles`. Every result
+therefore has one more finding per skill and target, with the same client and
+scope and the skill name as alias:
 
 ```text
 apply: ok
 claude-code/user/pi-session-mcp: ok (applied)
 claude-code/user/pi-session-orchestration: ok (skill_installed)
+claude-code/user/pi-session-profiles: ok (skill_installed)
 ```
 
 Skill findings per operation:

package/docs/doctor-design.md

@@ -28,6 +28,7 @@ and owners are:
 | `config_missing` | `PI_SESSION_MCP_CONFIG` is not set, or the file it names is absent | `configuration` |
 | `config_unreadable` | The supported configuration path cannot be read | `configuration` |
 | `config_invalid` | Production `loadConfig` rejects the configuration. One check per schema issue location, at most five, sorted | `configuration:<location>`, a dotted path of schema field names, aliases and array indexes such as `configuration:executionProfiles.review.default`; an unknown key that is not a schema field name, and any other key that is not a valid alias, is shown as `<key>`, because it could be a path or a secret. `configuration` when the error has no location |
+| `skill_controller_selected` | Production `loadConfig` rejects the configuration because a `skillCatalog` value names a controller skill (`builtin:pi-session-orchestration` or `builtin:pi-session-profiles`). Reported instead of `config_invalid` for that location and blocks like it | `configuration:skillCatalog.<alias>` |
 | `workspace_missing` | A resolved configured workspace does not exist | validated workspace alias |
 | `workspace_not_directory` | A resolved workspace is not a directory | validated workspace alias |
 | `workspace_unreadable` | A resolved workspace cannot be read | validated workspace alias |