From b2d992392eacd96e303365494028281e045d1654 Mon Sep 17 00:00:00 2001
From: Pieter Viljoen <ptr727@users.noreply.github.com>
Date: Sun, 11 Oct 2026 08:27:13 -0700
Subject: [PATCH 1/3] Bind the Workspace-Edit Rule Only to an Agent Running
 Inside VS Code

A workspace reload drops only a session that VS Code hosts, so an agent
running in a standalone console now edits a .code-workspace directly,
even while a window has that file loaded.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .agents/skills/agent-conduct/SKILL.md                     | 2 +-
 .claude-plugin/fleet-skills/.source-digests/agent-conduct | 2 +-
 .claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md | 2 +-
 .github/skills/agent-conduct/SKILL.md                     | 2 +-
 GOVERNANCE.md                                             | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/.agents/skills/agent-conduct/SKILL.md b/.agents/skills/agent-conduct/SKILL.md
index c9b9c3960..660bba698 100644
--- a/.agents/skills/agent-conduct/SKILL.md
+++ b/.agents/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **Never edit a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Surface the needed change for the maintainer to apply by hand. The test is whether any window has that file loaded, wherever the editing agent runs. A worktree's copy that no window has opened passes that test, and so does the workspace file of a checkout the maintainer opened as a folder rather than as a workspace. Where the agent cannot tell, it asks the maintainer, and once told that no window has the file loaded it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/.claude-plugin/fleet-skills/.source-digests/agent-conduct b/.claude-plugin/fleet-skills/.source-digests/agent-conduct
index 40562721a..2bd0a788e 100644
--- a/.claude-plugin/fleet-skills/.source-digests/agent-conduct
+++ b/.claude-plugin/fleet-skills/.source-digests/agent-conduct
@@ -1 +1 @@
-e9a00898619e4a7f
+fbf88bb9ae566dae
diff --git a/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md b/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
index c9b9c3960..660bba698 100644
--- a/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
+++ b/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **Never edit a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Surface the needed change for the maintainer to apply by hand. The test is whether any window has that file loaded, wherever the editing agent runs. A worktree's copy that no window has opened passes that test, and so does the workspace file of a checkout the maintainer opened as a folder rather than as a workspace. Where the agent cannot tell, it asks the maintainer, and once told that no window has the file loaded it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/.github/skills/agent-conduct/SKILL.md b/.github/skills/agent-conduct/SKILL.md
index c9b9c3960..660bba698 100644
--- a/.github/skills/agent-conduct/SKILL.md
+++ b/.github/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **Never edit a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Surface the needed change for the maintainer to apply by hand. The test is whether any window has that file loaded, wherever the editing agent runs. A worktree's copy that no window has opened passes that test, and so does the workspace file of a checkout the maintainer opened as a folder rather than as a workspace. Where the agent cannot tell, it asks the maintainer, and once told that no window has the file loaded it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
index 72375ef6b..a1020cd0c 100644
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@@ -197,7 +197,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **Never edit a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Surface the needed change for the maintainer to apply by hand. The test is whether any window has that file loaded, wherever the editing agent runs. A worktree's copy that no window has opened passes that test, and so does the workspace file of a checkout the maintainer opened as a folder rather than as a workspace. Where the agent cannot tell, it asks the maintainer, and once told that no window has the file loaded it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
@@ -342,7 +342,7 @@ Contributors commit to this repo with signed commits. The SSH-signing setup live
 - **VS Code is the primary IDE, and the experience favors it.** Prefer VS Code tasks and launch configurations for building, running, and testing over ad-hoc shell scripts. A script is the fallback, not the default.
 - The `.code-workspace` file carries the shared editor settings and the recommended-extension set. **All VS Code settings and extension recommendations live only here, never in a standalone `.vscode/settings.json` or `.vscode/extensions.json`** (`.vscode/` holds only `tasks.json` and `launch.json`). A **standard set** of extensions applies to every repo (markdownlint, cspell, editorconfig, markdown-all-in-one, better-todo-tree), kept to extensions that work without a separately installed tool. A repo shipping a language adds that language's **defaults** (.NET: csdevkit, csharpier. Python: python, pylance, ruff, mypy. Docker: the Docker extension). **Any repo can add further extensions** of its own on top of both.
 - The Table of Contents is maintained by the Markdown All in One extension, and `markdown.extension.toc.levels` in the workspace sets which heading levels it includes (see the Markdown rules for the authoring convention and the `<!-- omit from toc -->` exclusion marker).
-- **Agents: editing a `.code-workspace` that a VS Code window has loaded as its workspace can reload that window and drop an agent session running in it.** "Verification Discipline" holds the rule: leave that edit to the maintainer (a maintainer edit does not reload), and edit directly a workspace file that no window has loaded. Opening the folder rather than the workspace is what keeps a checkout's own file editable.
+- **Agents: editing a `.code-workspace` that a VS Code window has loaded as its workspace can reload that window and drop an agent session running in it.** "Verification Discipline" holds the rule: an agent running inside VS Code leaves that edit to the maintainer (a maintainer edit does not reload), and an agent running in a standalone console edits the file directly.
 
 ## Repository Details
 

From c76bf74bd94eb067a8f6f7d171b80928dc4e309a Mon Sep 17 00:00:00 2001
From: Pieter Viljoen <ptr727@users.noreply.github.com>
Date: Sun, 11 Oct 2026 08:29:40 -0700
Subject: [PATCH 2/3] Keep the Not-Loaded Exemption and Its Fallback in the
 Workspace-Edit Rule

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .agents/skills/agent-conduct/SKILL.md                     | 2 +-
 .claude-plugin/fleet-skills/.source-digests/agent-conduct | 2 +-
 .claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md | 2 +-
 .github/skills/agent-conduct/SKILL.md                     | 2 +-
 GOVERNANCE.md                                             | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/.agents/skills/agent-conduct/SKILL.md b/.agents/skills/agent-conduct/SKILL.md
index 660bba698..7df11e318 100644
--- a/.agents/skills/agent-conduct/SKILL.md
+++ b/.agents/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/.claude-plugin/fleet-skills/.source-digests/agent-conduct b/.claude-plugin/fleet-skills/.source-digests/agent-conduct
index 2bd0a788e..1e7c601ce 100644
--- a/.claude-plugin/fleet-skills/.source-digests/agent-conduct
+++ b/.claude-plugin/fleet-skills/.source-digests/agent-conduct
@@ -1 +1 @@
-fbf88bb9ae566dae
+bb812d28a718dfa3
diff --git a/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md b/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
index 660bba698..7df11e318 100644
--- a/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
+++ b/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/.github/skills/agent-conduct/SKILL.md b/.github/skills/agent-conduct/SKILL.md
index 660bba698..7df11e318 100644
--- a/.github/skills/agent-conduct/SKILL.md
+++ b/.github/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
index a1020cd0c..978dfc1b2 100644
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@@ -197,7 +197,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The test is where the editing agent runs. The rule binds a session hosted by VS Code, in its extension or its integrated terminal, and a `TERM_PROGRAM` of `vscode` in the environment is one sign of that. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. Where the agent cannot tell where it runs, it asks the maintainer.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
@@ -342,7 +342,7 @@ Contributors commit to this repo with signed commits. The SSH-signing setup live
 - **VS Code is the primary IDE, and the experience favors it.** Prefer VS Code tasks and launch configurations for building, running, and testing over ad-hoc shell scripts. A script is the fallback, not the default.
 - The `.code-workspace` file carries the shared editor settings and the recommended-extension set. **All VS Code settings and extension recommendations live only here, never in a standalone `.vscode/settings.json` or `.vscode/extensions.json`** (`.vscode/` holds only `tasks.json` and `launch.json`). A **standard set** of extensions applies to every repo (markdownlint, cspell, editorconfig, markdown-all-in-one, better-todo-tree), kept to extensions that work without a separately installed tool. A repo shipping a language adds that language's **defaults** (.NET: csdevkit, csharpier. Python: python, pylance, ruff, mypy. Docker: the Docker extension). **Any repo can add further extensions** of its own on top of both.
 - The Table of Contents is maintained by the Markdown All in One extension, and `markdown.extension.toc.levels` in the workspace sets which heading levels it includes (see the Markdown rules for the authoring convention and the `<!-- omit from toc -->` exclusion marker).
-- **Agents: editing a `.code-workspace` that a VS Code window has loaded as its workspace can reload that window and drop an agent session running in it.** "Verification Discipline" holds the rule: an agent running inside VS Code leaves that edit to the maintainer (a maintainer edit does not reload), and an agent running in a standalone console edits the file directly.
+- **Agents: editing a `.code-workspace` that a VS Code window has loaded as its workspace can reload that window and drop an agent session running in it.** "Verification Discipline" holds the rule. An agent running inside VS Code leaves that edit to the maintainer (a maintainer edit does not reload). An agent in a standalone console edits the file directly, and so does any agent editing a workspace file that no window has loaded. Opening the folder rather than the workspace is what keeps a checkout's own file editable.
 
 ## Repository Details
 

From c9e1d29c99c355accbd561739f5f230d82622c4b Mon Sep 17 00:00:00 2001
From: Pieter Viljoen <ptr727@users.noreply.github.com>
Date: Sun, 11 Oct 2026 08:30:26 -0700
Subject: [PATCH 3/3] Ask About the Workspace-Edit Rule Only When Its Scope Is
 Unclear

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .agents/skills/agent-conduct/SKILL.md                     | 2 +-
 .claude-plugin/fleet-skills/.source-digests/agent-conduct | 2 +-
 .claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md | 2 +-
 .github/skills/agent-conduct/SKILL.md                     | 2 +-
 GOVERNANCE.md                                             | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/.agents/skills/agent-conduct/SKILL.md b/.agents/skills/agent-conduct/SKILL.md
index 7df11e318..a47e480e0 100644
--- a/.agents/skills/agent-conduct/SKILL.md
+++ b/.agents/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell whether the rule binds it, it asks the maintainer. Once told that it does not, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/.claude-plugin/fleet-skills/.source-digests/agent-conduct b/.claude-plugin/fleet-skills/.source-digests/agent-conduct
index 1e7c601ce..c883d65e7 100644
--- a/.claude-plugin/fleet-skills/.source-digests/agent-conduct
+++ b/.claude-plugin/fleet-skills/.source-digests/agent-conduct
@@ -1 +1 @@
-bb812d28a718dfa3
+4114f1b580c74b92
diff --git a/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md b/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
index 7df11e318..a47e480e0 100644
--- a/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
+++ b/.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell whether the rule binds it, it asks the maintainer. Once told that it does not, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/.github/skills/agent-conduct/SKILL.md b/.github/skills/agent-conduct/SKILL.md
index 7df11e318..a47e480e0 100644
--- a/.github/skills/agent-conduct/SKILL.md
+++ b/.github/skills/agent-conduct/SKILL.md
@@ -50,7 +50,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell whether the rule binds it, it asks the maintainer. Once told that it does not, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
index 978dfc1b2..a636aa969 100644
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@@ -197,7 +197,7 @@ The checks that separate work actually done from work that merely reports succes
 - **Editing CRLF files programmatically: `.` matches `\r` in a regex**, so a captured line keeps its carriage return and rejoining with `\r\n` yields `CRCRLF`. Prefer literal replacement over regex reassembly. In Python the *default* path is a text-mode rewrite, which has the mirror failure: `Path.read_text()` decodes through universal newlines and `write_text()` translates each `\n` back to `os.linesep`, so a read-edit-write round trip rewrites every line ending in the file to the host's own while the edit itself looks correct. Work in bytes, or open the file explicitly with `newline=''` on both the read and the write, since a read that preserves the endings still hands them to a write that translates them. Use `open()` rather than `Path.read_text()`, which accepts that argument only on Python 3.13 and newer and raises `TypeError` below it. The corruption is worth naming because it is invisible in a rendered diff.
 - **Scope a check by what the project declares, not by the file that prompted it.** A check written while editing one file tends to cover that file's language and stop, and then reports success on every other surface the rule governs. Read the declared types, or the config that enumerates them, and cover each one, then assert a floor per surface so a table that narrows fails loudly instead of passing quietly. A rule about comments means every comment syntax the project ships, and a format that carries comments in practice counts even where its specification says otherwise.
 - **Never write source text carrying backslash escapes through a shell construct that interprets them.** A `printf` format string, a `printf` argument consumed by `%b`, `echo -e`, POSIX `sh`'s builtin `echo`, and `$'...'` each consume the escape and write an invisible control character in its place, so a `\b` inside a regex becomes a backspace and the pattern silently matches nothing while every test still passes. A quoted heredoc, `<<"EOF"`, is not one of those constructs and writes every backslash literally. An unquoted `<<EOF` is one of them, because it collapses `\\` to `\`, so source carrying `"\\bword\\b"` reaches the file as `"\bword\b"` and the pattern compiles to a backspace. Use a file-editing tool for such text where one is available, and a quoted heredoc where the work has to happen in a shell. When a check inspects text for control characters, use `str.isprintable()` rather than a codepoint floor, since DEL and the Unicode format characters sit above 32 and are equally invisible in a diff. That test calls `\n` and `\t` unprintable too, so apply it to the tokens the text is made of, or exempt the whitespace it legitimately carries, rather than running it over whole lines.
-- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell where it runs or whether a window has the file loaded, it asks the maintainer. Once told that either condition does not hold, it edits the file directly rather than handing the edit off.
+- **An agent running inside VS Code never edits a `.code-workspace` file that a VS Code window has loaded as its workspace.** A workspace file rewritten on disk can make VS Code reload that window, and a reload destroys the context of an agent session running in it, so the work in flight is lost with nothing to catch it, and the trigger is not fully characterized (an agent's edit has caused the reload where a human's identical edit did not). Such an agent surfaces the needed change for the maintainer to apply by hand. The rule binds a session hosted by VS Code, in its extension or its integrated terminal. An agent running in a standalone console is outside the rule and edits the file directly, even while a window has that file loaded. A file no window has loaded is outside it too. A worktree's copy no window has opened is one, as is the workspace file of a checkout opened as a folder. Where the agent cannot tell whether the rule binds it, it asks the maintainer. Once told that it does not, it edits the file directly rather than handing the edit off.
 - **A green check is not evidence the work happened.** A skipped job and a passing job are indistinguishable in the aggregated required check. When a job exists to exercise something, confirm from its log that it ran and produced the output it promises.
 - **A local clone is not the branch it names, it is whatever that clone last fetched.** Reading a checkout on disk answers what that clone last saw, so a finding taken from one carries a date nobody stated, and two failures of exactly that shape are on record from one session: a repository reported as still drifted on a file whose fix had already merged, and a repository reported as missing a file it carries because the checkout sat on an older branch. Read the live ref through the API where the claim will be acted on, or fetch immediately before reading, and name the ref and the commit in any finding a local read produced. A clone stays the right tool for anything needing history or a build, which an API read cannot give.
 - **A checkout already sitting on disk is not yours to trust for being there.** A clone or worktree this session did not create, found while looking around a machine, may belong to another concurrent session's task, sit on a stale fetch or a branch nobody expects, or hold uncommitted edits nobody has reviewed, and none of that is visible from the directory listing that found it. Running `git status`, `git remote -v`, or `git branch --show-current` against it, or reading a file inside it, answers for whatever that checkout happens to hold at that moment, not for the repository, and the found checkout is not the "local clone" the bullet above means, since this session never fetched it and has no basis for trusting what it last saw. Clone the repository fresh into a location this session controls, or read the live state through the GitHub API, rather than adopting a pre-existing checkout as ground truth.