[rmstdope]

Bead: cb-nwbe (ux:none).

Adds one paragraph to skills/verify-bead/SKILL.md, The navigator's window: a window is the verifier's only when it opened it as a new window and every tab in it since; before any resize it lists that window's tabs and refuses if any is not its own. This changes how every verifier behaves in every consumer, and every project verification skill that extends verify-bead.

Checked for restatements of the window rule in other Chrome-driving roles (agents/reviewer.md, agents/verifier.md, agents/ux.md, skills/agree-experience): none. Reviewer defers to the section by name, so nothing else changes.

Validation: read the section after the edit. Device emulation is still first, a window of one's own second, the blocker third; the new paragraph's fallback keeps that order, and "Every skill or agent that drives Chrome follows this rule…" still closes the section. No suite (prose only).

Gate: bash tests/gate failed on its first run with five fleet-view TUI suites timing out (fleet-board, fleet-launch, fleet-keys, web-console, fleet-view-restart) while the machine's load average was 13. All five pass when run alone. Every other leg was green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WCDKf1EmxAocjKjxtyNumG

[rmstdope]

Review (cold read, reviewed_head: b76b0d9cf5050f16a087bf589f670d141ee97fff) — reviewed before merge under the producer's review practice, by an agent given the diff and the bead, and not the producer's reasoning.

1. Blocks merge. The check the new paragraph adds cannot see the tabs it is meant to find (skills/verify-bead/SKILL.md, The navigator's window). "List the tabs of the window … (the integration's tab context)" is tabs_context_mcp, which returns only the tabs in the MCP tab group, not every tab in the window. When the group lives in the navigator's own window, the listing shows only the verifier's tabs, the check passes, and resize_window (which takes a group tab's id and resizes its window) resizes the navigator's window. That is the failure the bead's Problem describes, so the acceptance is met in the text and does not protect the navigator. A test the integration can make: a window counts as yours only if tabs_context_mcp with createIfEmpty created it during this look (it opens a new window only when no group exists); when the group already existed, use device emulation or the blocker, and never resize.
2. Suggestion. "Open a new window of your own instead" (and the earlier "open a Chrome window of your own") names something the integration may not be able to do. Apart from createIfEmpty when no group exists, no tool opens a new window. One clause saying so would stop a verifier from improvising.

Producer's answer. Both findings hold. I checked the tool schemas: tabs_context_mcp reports "all tab IDs inside the group", tabs_create_mcp adds a tab "in the MCP tab group", and resize_window takes a "tab in the current group". The paragraph and the acceptance ("requires listing that window's tabs before every resize") are the navigator's own wording, prescribed verbatim in the bead. Replacing them is a scope decision, not mine, so the bead is parked for the navigator with the reviewer's proposed test. This PR stays open and unmerged until that is answered.

[Copilot]

Note

Copilot was unable to complete this review at the selected tier due to model policy or plan restrictions.

🟡 Changes recommended

A reviewer flagged unclear jargon in SKILL.md that makes an instruction harder to follow, indicating the documentation needs a small clarity fix before approval.

1 open issue

• Clarify the tab context wording in the resize instruction · New

What changed in this PR

Updates the shared verify-bead documentation to prevent verifiers from resizing a Chrome window unless it is fully verifier-owned, reducing the risk of disrupting the navigator’s existing tabs across all consumers.

Changes:

• Defines a stricter “window ownership” rule: only windows opened by the verifier, with only verifier-created tabs, may be resized.
• Requires listing a window’s tabs before resizing and refusing (or using a new window) if any tab is not verifier-owned.

File	Description
skills/​verify-bead/​SKILL.md	Adds and clarifies a universal Chrome window ownership and pre-resize tab-check rule for verifiers to avoid affecting navigator-owned tabs.

_{Review effort: Balanced}

[rmstdope]

Review (cold read, reviewed_head: dd269ba37c930e18d4cccd3dca9f26ec0d2fc817) — reviewed before merge under the producer's review practice, by an agent given the diff and the bead, and not the producer's reasoning.

1. Blocks merge. skills/verify-bead/SKILL.md, The navigator's window: the rule depends on whether a group already existed, which the verifier is never told how to learn. createIfEmpty "has no effect" if a group exists and returns its tabs either way, so a verifier that opens with tabs_context_mcp {createIfEmpty: true} cannot tell a new window from the navigator's. Fix: call it without createIfEmpty first; only on "no group" call it with createIfEmpty, and that window is yours.
2. Suggestion. "No other tool opens a new window" misses a bare navigate (no tabId), which calls tabs_context_mcp{createIfEmpty:true} itself. Say so, and treat a window it opened as one of unknown origin.
3. Suggestion, minor. A window you created can later hold a navigator tab (a link opened from another app, a dragged tab). A half-sentence "yours while it holds only the tabs you opened" would close this; not in the navigator's answer.

Producer's answers.

1. Fixed in c33a3e7, after checking the schema (createIfEmpty: "If a MCP tab group already exists, this parameter has no effect"). The first browser call is tabs_context_mcp without createIfEmpty; only if it reports no group is it called again with it, and the window of a group you did not first see missing is never yours.
2. Fixed in c33a3e7, after checking the navigate schema: a bare navigate makes that same createIfEmpty call, so the rule says never to make one before the check. "No other tool" stays true, since navigate's call is the same tabs_context_mcp call.
3. Not changed. The integration cannot see tabs outside the group, so "while it holds only your tabs" would be a condition the verifier cannot check, the same defect that blocked b76b0d9. It is also outside the navigator's answer. If it needs a rule, that is a new bead for the navigator.

[rmstdope]

Review (follow-up delta dd269ba..c33a3e7, reviewed_head: c33a3e7c5cbf5bf5fec41719ce8aab1f3421ef8e) — reviewed before merge under the producer's review practice, by an agent given the two shas, the previous findings and the producer's answers as claims to check.

No findings. Finding 1 closed (first call without createIfEmpty, only the window a later createIfEmpty call opens is yours, matching the schema); finding 2 closed (a bare navigate named, and "no other tool" holds); the reply to 3 holds (the integration cannot see tabs outside the group). The section's order, emulation, own window, blocker, is unchanged, and nothing else in the tree restates the rule.