skills: SESSION_BUSY is two CLI invocations, not an in-page lock

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

[ayushsingh82]

Fixes#385.

Problem

On a same-session concurrency task, an agent modeled Session occupancy
as a page-level lock: it stayed inside one browser run and overlapped
two page.evaluate calls instead of issuing a second
webcmd --session <id> ... CLI invocation. Both in-page calls
completed, no SESSION_BUSY envelope appeared, and the agent concluded
the structured busy response didn't exist for this case — writing
twice instead of retrying safely.

SESSION_BUSY is produced by the Webcmd runtime arbitrating a second
CLI invocation against a Session another invocation still holds. It
has no relationship to anything that happens inside one run's
page.evaluate calls — the runtime already returns it correctly today
(confirmed against origin/main); the gap is that skill text didn't
make the two-CLI-invocation shape impossible to miss.

Fix

• webcmd-browser: added a worked two-terminal example (Terminal A
  holds the Session with a long run, Terminal B issues a second
  --session command against the same id), a Do Not line against
  implementing occupancy inside the page, and a sharper SESSION_BUSY
  troubleshooting row that says "retry the same command" and "do not
  lock inside page.evaluate."
• webcmd-usage: reworded the SESSION_BUSY explanation to name the
  two-invocation shape explicitly instead of "another holder."

Skill-doc only change; no runtime/CLI behavior touched.

Test plan

• npm run typecheck — clean.
• npm run test — 447 files / 5757 tests pass.
• make verify — skill build (skill-src/ → skills/) in sync.
• Updated src/skills.test.ts to assert the new in-page-lock anti-
  pattern text and the two-invocation wording.

[ayushsingh82]

@ankitranjan7 mind taking a look? This closes #385.

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.