v0.1.40

wtc 0.1.40

This release adds harness-free collections, opt-in services and tunnels,
clearer build/conflict status, and coordinated hosted and local reviews.

Collections without a harness

• wtc init turns an empty folder into an ad-hoc collection. Its local
  registry and optional config/hooks live in .wtc/config/.
• wtc add-repo accepts a clone URL or existing checkout, asks for the
  development branch and PR target, and remembers repositories for later
  ad-hoc collections. Shared bare owners live under the user's data directory.
• wtc new creates an ad-hoc sibling using registered repositories;
  wtc retire . retires it without Herdr. Hand-written local config/hooks
  remain as reported leftovers for inspection.
• Ad-hoc collections currently refuse --all sweeps and sibling-targeting
  commands. Harness-backed workspaces keep their existing behavior.

Opt-in services, tunnels and resources

• wtc svc (alias wtc services) manages collection-owned services, logs,
  tunnels and resource hooks through an independent dekit 0.10.x runner.
  wtc up, down, restart and logs are shortcuts. Closing an agent does
  not stop the runner; builds remain inside the repo's existing launch command.
• Configure [runtime] backend = "dekit" and pin dekit 0.10.0 with mise.
  Enabling it starts nothing automatically. wtc svc add writes a disposable
  collection overlay; --shared writes the optional repo task fragment.
• Services and their tunnel providers appear together in status.
  wtc svc tunnel requires --public when exposure is public or unknown;
  status shows that exposure. Read logs through WTC, including after shutdown.
• Provision/teardown hooks own exact collection resources. down keeps data;
  teardown and retirement stop the runner and clean owned resources. A failed
  stop or teardown retains the worktrees and ownership records.
• Restart waits include readiness probes and finite jobs of running
  dependents, so the service cannot report completion while its tunnel starts.
• Runtime support remains experimental. Preserve standalone repo commands;
  test onboarding, cross-machine connectivity and provider cleanup before
  adopting it. See wtc docs instructions/runtime.md and the wtc-svc skill.

Build and conflict status

• GitHub checks and Bitbucket Pipelines provide build facts without a harness
  hook. TEST follows default_ref; PROD follows production_ref or
  release_ref. Repository rows show ○ when HEAD is not in that build.
• Merged PRs remain followed until the configured branch builds contain the
  merge. Tier progress and failures remain visible in the PR table.
• PR merge conflicts are explicit, independent of check results and local
  working-tree state. Narrow rows retain the warning and aligned click targets
  for long linked PR numbers. TEST/PROD columns appear only with build facts.
• Provider failures affect their cells instead of failing the entire refresh;
  each repo/tier is queried once, with bounded concurrency.

Review coordination and reliability

• wtc review activity shows current-head Copilot/Cursor reports, active
  requests/checks and unresolved threads, including outdated ones. Local runs
  wait for active hosted reviews and open feedback before spending agent time.
  Hosted quota failures allow local fallback; a clean hosted report still
  requires an independent local pass.
• Failed or missing local coverage yields error and keeps the ready gate
  closed. Configured agent chains handle quota responses, including structured
  errors from a CLI that exits successfully. Incomplete retry output is removed.
• GitHub summaries use verdict marks, exact-head source links and folded
  concern/history/stats sections. Open findings remain visible; Bitbucket
  keeps plain Markdown. Whitespace in tracked filenames is preserved.
• Inline findings outside the GitHub diff remain in the summary and are
  recorded as skipped: not in diff, including position-related HTTP 422
  rejections. Real auth/network/validation errors remain pending with forge
  diagnostics. Diff headers preserve space paths and use canonical prefixes.
• A default comments concern produces a Delete / Refactor first / Keep plan:
  prune redundant comments, identify workarounds that need a refactor, and
  preserve rationale, contracts, compatibility notes, directives and API docs.

Harness upgrade

Read wtc release-notes --since <old-pin> using this target binary before
changing a harness pin. Review local instruction and skill overrides,
particularly wtc-local-review, wtc-pr and wtc-svc; preserve project policy.
Update the pin and compatibility range together, regenerate the environment,
install tools and render guidance, then exercise affected hooks in a disposable
collection. An ad-hoc collection is optional and needs no harness migration.

A harness with status.build.sh keeps it as its provider. It may return
{"use_default":true} for individual requests to use the built-in provider;
requests now include forge, and responses may include the build's sha.
When production_ref equals default_ref, the branch has one prod tier
instead of tip; update hooks that key on that tier. To disable the built-in
provider, keep a hook that prints nothing.

wtc retire also removes generated catch-up reports. No new setup starts
services or changes standalone development automatically.