[happy-v587]

Which issue or RFC does this PR close?

Closes #2092

Rationale for this change

Scope creation and binding currently exist only as HTTP operations and wizard-printed curl steps. Users cannot quickly mint the opaque scp_* Scope ID that client SCOPE_ID environment variables require, and when that setting references a missing Scope the agent plugins surface a misleading version_mismatch diagnostic. A first-class powercontext scope command group closes both gaps: it wraps the existing Scope contract one command per operation, without inventing behavior.

What changes are included in this PR?

• New powercontext scope group in the Server-backed CLI (src/powercontext/client/cli.py):
  • scope create (prints the returned opaque Scope ID and a next-step hint; --idempotency-key defaults to a generated value so reruns stay idempotent)
  • scope list, scope get, scope update (--expected-version is required, matching the contract's optimistic lock)
  • scope default / scope set-default
  • scope resolve mirrors the agent plugins' resolution order: explicit ID → session binding key → workspace binding key → default; --no-allow-default reproduces the strict plugin behavior
  • scope binding set / scope binding clear
• Human-readable output for Scope descriptors, pages, and bindings (JSON mode unchanged); workspace binding key derivation matches the plugins' sha256-of-absolute-path convention.
• New tests: tests/test_cli_scope.py covering request construction, output, malformed external-reference rejection, and the binding key derivation.
• No API contract or generated sources changed; no scope delete because the contract has no such operation.

Are there any user-facing changes?

New user-facing CLI commands (powercontext scope ...). No breaking changes to existing commands or public Python APIs; documentation for the new group can follow in a separate docs PR.

How was this change tested?

• .venv/bin/python -m pytest tests/test_cli_scope.py tests/test_cli.py → 69 passed
• uv run prek run -a (ruff check, ruff format, ty check) → all passed
• Manual smoke against a live local Server: powercontext scope list and powercontext scope resolve --scope-id <id> returned expected Scope descriptors.

AI usage statement

Built with opencode (Claude Code CLI harness) powered by GLM (Z.ai) as the coding agent; the assistant implemented the command group and tests under human direction, with human review of the design decisions.

[happy-v587]

Two failing checks are not introduced by this PR (which only touches src/powercontext/client/cli.py and adds tests/test_cli_scope.py):

1. validate (E2E harness) — pre-existing master baseline failure. The same e2e/bub/tests/test_harbor_job_config.py::test_kimi_code_on_arm_installs_the_plugin_as_setup_does[authenticated|unauthenticated] tests fail on a clean checkout of origin/master (e4efb39b) locally, and the last three master push runs of the E2E harness workflow are also failures (39234099759, 39232839694, 39232604166). A separate broken-baseline issue for that kimi-code guidance test would be welcome; I can file it if useful.

2. tests (3.14, e2e) — single flaky failure: tests/e2e/test_topic_memory_qwen_settings.py::test_qwen_thinking_disabled_reaches_scheduled_worker_and_publication[inferred] with _WorkerTerminationError: Worker exit could not be confirmed (timing of worker exit acknowledgment in artifact_processing). It passes 3/3 locally on Python 3.14, and the same suite passes on 3.11/3.12/3.13 in this run. This looks like runner timing flakiness, not a regression. A rerun would confirm (I don't have repo admin rights to rerun myself).

[hidb4ai]

Two Scope CLI correctness issues remain: metadata updates discard existing relationships, and Codex workspace resolution can select the default Scope despite an existing binding.

[hidb4ai]

LGTM