docs: plan for #308 — Workbench sign-out, AI defaults, runtime extension install

[posit-vip-triage]

Closes #308

This plan breaks down the three Workbench test coverage gaps from the customer UAT:

1. Sign-out flow — can land immediately (uses Playwright UI automation)
2. AI defaults — blocked on session-exec primitive (needs terminal access)
3. Runtime extension install — blocked on session-exec primitive

Merging this PR will trigger an implementation PR — comment to iterate on the plan first.

Generated by Triage open issues on posit-dev/vip for issue #308 · ● 4.1M · ◷

[github-actions]

Preview Links

Website	Validation Report
https://posit-dev.github.io/vip/pr-preview-site/pr-310/	https://posit-dev.github.io/vip/pr-preview/pr-310/

[ian-flores]

@copilot please resolve the three UNCONFIRMED items in this plan with the following decisions. These are grounded in the actual codebase and the session-exec plan (#317 / issue #301), which delivers a Playwright-based src/vip_tests/workbench/exec.py (ide_terminal_run, vscode_eval, …) — terminal/console automation inside a session, not a new API. That distinction matters below.

1. Defer Gaps 2 & 3, do not add placeholder steps — but the dependency is per-gap, not all-or-nothing.

Placeholder scenarios committed to the suite either fail or skip misleadingly, violating VIP's "tests are real or absent" convention. Split the plan as:

• Gap 1 (sign-out) — no dependency (Playwright UI only). Land now as its own PR.
• Gap 2 (AI defaults) — likely not actually blocked; see item 2. Investigate the API first before deferring.
• Gap 3 (runtime extension install) — genuinely blocked on feat(workbench): add an in-session execution primitive #301's ide_terminal_run (code-server --install-extension). Defer until feat(workbench): add an in-session execution primitive #301 lands and cross-link it (See #301).

Update the Architecture/Components sections so the "blocked" framing is per-gap rather than lumping Gaps 2 and 3 together.

2. AI-default-off source of truth = server-level config via the API, not user/workspace settings.

The requirement is a deployment default set by an admin, not a user preference — checking user/workspace settings gives false readings. WorkbenchClient.server_settings() already hits /api/server/settings. Make "check whether AI/Copilot flags surface in the server settings API" an explicit first step. If they do, Gap 2 becomes a pure API check (like other server_settings() tests) with no session-exec and no Playwright — unblocked independent of #301. Only fall back to in-session server-config inspection (which needs #301) if the flag is absent from the API.

3. Runtime-extension test subject = config-driven, and explicitly NOT ms-python.python.

Gap 3 validates OpenVSX-backed deployments, and ms-python.python is license-restricted to Microsoft's marketplace — it is not redistributable on OpenVSX, so it would fail on exactly the deployments this test targets. Instead, add a test_extension (or test_extensions: list[str]) field to WorkbenchConfig, mirroring the test_packages: list[str] field the #301 plan already introduces, so the deployment owner names an extension known to be in their OpenVSX mirror. Default to a small, verified-on-open-vsx.org extension (e.g. redhat.vscode-yaml or vscodevim.vim), never an MS-marketplace-only one.

Also add just check to the Verification section as an explicit numbered step (per CLAUDE.md), and add a selftests/test_config.py case for the new [workbench.ai_features] config block.

[Copilot]

@ian-flores I've opened a new pull request, #346, to work on those changes. Once the pull request is ready, I'll request review from you.