Repository navigation
Decide How the Workspace-Edit Rule Reads an Unknown Window Session State #3617
Description
Two hosted reviewers independently flagged the same sentence in the carried GOVERNANCE.md "Verification Discipline" workspace-edit rule, and its copy in the agent-conduct Skill, while reviewing a downstream resync that re-vendored them byte for byte. The carrier cannot edit a verbatim section, so the finding is the hub's.
The sentence
"An agent treats any window other than its own as hosting no session unless it knows otherwise."
The finding
An agent normally cannot observe whether another VS Code window hosts a live agent session. Read literally, the rule turns that lack of knowledge into permission to rewrite a .code-workspace another window has loaded. The rule's own premise is that such a rewrite can reload that window and destroy an unseen session's context with nothing to catch it.
- Copilot: "Do not treat an unknown other-window state as empty", asking for the default to be "assume a session may be live" where the state cannot be established.
- Qodo: "Other agents can lose active work", asking for confirmation when another window's session state cannot be established, with the Skill text kept consistent.
Context
The rule was keyed on the window hosting a session deliberately, in the change titled "Key the Workspace-Edit Rule on the Window Hosting a Session". So this may be a decided trade-off rather than a defect. If it is decided, the sentence could state why an unknown state reads as empty, so the next reviewer does not re-raise it on every carrier.
Raised on ptr727/PlexCleaner#1064 at GOVERNANCE.md:199 and .github/skills/agent-conduct/SKILL.md:53.
🤖 Generated with Claude Code
Activity
ptr727 commentedon Nov 1, 2026
Decision needed (decision triage, 2026-11-01)
Question: Should the GOVERNANCE.md "Verification Discipline" workspace-edit sentence "An agent treats any window other than its own as hosting no session unless it knows otherwise" (restated in "Editor and Tasks", included in agent-conduct) keep its default, flip to "assume a session may be live" (Copilot), or require confirmation when the state is unknown (Qodo)?
Options, recommended first:
.code-workspaceedit goes back to the maintainer, reversing Bind the Workspace-Edit Rule Only to an Agent Running Inside VS Code #2815/Key the Workspace-Edit Rule on the Window Hosting a Session #2927. No work in flight.Evidence: GOVERNANCE.md:208, restated at :356. e2e94e2 (#2927): the default is deliberate "so a standalone-console agent still edits directly by default". #2835: "That trade is the maintainer's to set." #2834: the harmful case "needs a VS Code-hosted session and a console agent on the same workspace at once".
Blocks: none
ptr727 commentedon Nov 1, 2026
Maintainer answer (decision triage, 2026-11-01): Option 1: keep the default, and add a reason clause to both GOVERNANCE.md sentences (Verification Discipline and Editor and Tasks), regenerated into agent-conduct. A resync is owed. This is now work for the next burndown round.
ptr727 commentedon Nov 2, 2026
Released (2026-11-02): PR #3818 merged to develop and its branch is deleted, so this claim holds no files. The issue closes on promotion.
Backlog burndown claim (away run 2026-11-02, round 2, group G3). Branch:
burndown/3617-governance-prose. Issues: #3617, #3757, #3790, #3768.Predicted file set:
GOVERNANCE.md.gitignore.agents/skills/agent-conduct/and its generated trees (.github/skills/agent-conduct/,.claude-plugin/fleet-skills/skills/agent-conduct/,.claude-plugin/fleet-skills/.source-digests/agent-conduct)Out of bounds for this group:
scripts/README.mdandcatalog/snippets/(group G1),.agents/skills/backlog-burndown/and.agents/skills/git-commit-conventions/(group G2),.github/workflows/*and.github/actions/*(open PR #3801),WORKFLOW.md.Scope:
developonly. The feature pull request carriesCloses on promotion:for each issue it fully fixes.Explain the Workspace-Edit Default and Name the Aggregator's Expressi…