workspace-config

workspace-config

Every command below is ${CLAUDE_PLUGIN_ROOT}/bin/harness <verb> … — run it yourself via Bash. Never ask the user to type a harness command; the user only answers the questions below.

Not this skill's job: registering a brand-new repo (that's /add-repo — discovery, duplicate-name/path refusal, permission-allowlist refresh; this skill only changes an already-registered repo's path/name/test_cmd), and first-time setup (/init-workspace's interview).

0 · Confirm the workspace is actually bootstrapped

Resolve the plugin root if not already set (native Qwen first run — each Bash call is a fresh subprocess, so the probe prints the path for textual substitution). Same resolution logic as /init-workspace step 0:

R="${CLAUDE_PLUGIN_ROOT:-}"; [ -z "$R" ] && {
  for p in "$HOME/.qwen/extensions/ai-sdlc-harness/bin/harness" \
           "$HOME/.qwen/extensions/ai-sdlc-harness/.qwen-extension-install.json"; do
    [ -e "$p" ] && { case "$p" in *install.json)
      R=$(python3 -c "import json,sys;print(json.load(open(sys.argv[1])).get('source',''))" "$p");;
      *) R=$(cd "$(dirname "$p")/.." && pwd);; esac
      [ -x "$R/bin/harness" ] && break; }; done; }
[ -x "$R/bin/harness" ] || { echo "ERROR: set CLAUDE_PLUGIN_ROOT to the dir with bin/harness" >&2; exit 1; }
echo "PLUGIN_ROOT=$R"

Use the printed path in place of ${CLAUDE_PLUGIN_ROOT} below.

Read .claude/context/overrides.yaml. Missing, or no bootstrap_completed key: /init-workspace never finished — stop and send the user there. Proceeding anyway reports "the change is live," and the user only learns otherwise later, at a confusing bootstrap incomplete refusal the next time /dev-workflow runs.

1 · Ask which section, and what's changing

• overrides — any top-level key in config/defaults/*.yaml other than provider/repos/language (status_mapping, subagent_models, quick_mode, naming + change_types, review_rounds, stall, repo_map staleness N, review_policy, security.scan_cmd/ severity_order, …). Most single-setting changes land here.
• provider — work-item/git provider + specifics (stories_dir, github_repo, github_project + github_project_owner (+ github_project_repo, which keeps board ids bare issue numbers), ado_org, ado_project, …).
• language — per-repo test_cmd / coverage_cmd / quarantine, under language.repos.<name> (not the whole-workspace test_paths/ test_closure). Quarantine drops a known-failing spec unrelated to any run from every test + coverage command (reason + since required, init-verify gates the shape, each run flags the exclusions): {"language": {"repos": {"fe": {"test_cmd": "npx vitest run", "quarantine": {"exclude_template": "--exclude {test}", "tests": [{"test": "t/a.spec.ts", "reason": "fails on main", "since": "2026-07-22"}]}}}}} — language is a full REPLACE (§2): re-send every repo's existing keys.
• repos — repointing or renaming an existing entry's path. A path may be a checkout root or a subtree of one (<checkout>/frontend) — that's how a monorepo's logical repos are registered, one entry per root.