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.

v0.1.39

wtc 0.1.39

This release makes WTC easier to adopt with a small harness scaffold, clearer
guides and TUI recordings, and offline release notes for harness upgrades.

Features

• wtc harness init scaffolds six project-owned files. Generic collection
  instructions come from the CLI, and wtc docs exposes them outside a collection.
• The public README has collection, environment, secrets, and harness recordings
  using real commands against synthetic repositories.
• wtc open detects unstacked narrow layouts and repairs pane geometry.
  Narrow/wide transitions preserve running pane processes. A previously broken
  wide layout may still be classified as wide; switching to narrow and back repairs it.
• wtc release-notes reads the embedded release archive offline. Use
  wtc release-notes --since 0.1.35 to read newer releases in upgrade order,
  or wtc release-notes 0.1.39 to read this release.
• Release publishing requires a committed version-specific note and uses that
  same Markdown for the GitHub release body.

Harness upgrade

Pin 0.1.39 or newer for a config-only harness: 0.1.38 does not contain the
complete embedded instruction fallback or scaffold commands. Existing populated
harnesses keep their configuration and hooks. The small scaffold
is optional: it does not replace local policy or copy over an existing harness.
Review local instruction and skill overrides before moving duplicated generic
guidance to CLI defaults. Read wtc docs, inspect wtc skills diff, and retain
project-specific sections in overlays or harness-owned instructions.

For each CLI upgrade, run the target binary with
release-notes --since <old-pin> before changing the harness pin. Older installed
binaries cannot describe future releases. Review the changed commands, hooks,
and compatibility notes; update the pin and compatibility range together, then
regenerate the collection environment, install its tools, and render guidance.
Test the harness's affected hooks and workflows in a disposable collection.

v0.1.38

Fixed

• wtc new and wtc add-repo now invoke the harness env.pre and env.post hooks before secrets linking and repository initialization. Custom collection aliases and tool routing are available when init hooks first run.
• Environment pre-hook failures stop initialization. Post-hook failures retain the existing warning behavior.

Compatibility

Harnesses that customize generated environments should use 0.1.38 or later for native collection creation and repository enlistment. Existing command syntax and the explicit wtc env setup workflow are unchanged.

Synthetic regression tests cover native creation, enlistment with stale or missing generated environments, preservation of local overrides, and pre-hook vetoes.

See #61 and #62.

Known issue

Bitbucket review posting/resolution can hit command and JSON-output incompatibilities with @pilatos/bitbucket-cli 1.8.3. This lifecycle release does not change that integration; #60 tracks the correction.

v0.1.37

Direct CLI entry points

wtc open starts the status and browse panes with wtc status --tui and wtc browse --here. Catch-up recognizes and restarts a native status pane. Collection instructions and embedded skills now use direct wtc commands for routine collection work.

Native catch-up maintenance

Catch-up refreshes collection environment, skills, MCP configuration, and secret links through native CLI actions. It reports a target collection that cannot be opened as a failed maintenance action. The environment step validates the mise configuration before replacing generated files, and skips an environment rewrite when the rendered content is unchanged.

Agent toolchain setup

wtc agent-env --wrap injects the computed toolchain exports directly into agent commands. Workspace creation no longer points BASH_ENV at a harness script. Generated .envrc files remain replaceable, while a local override that only mentions the generated marker is preserved.

Verification

The PR's checks and the exact merge commit's main CI passed. go test ./... and go vet ./... passed locally. Tests cover direct pane commands, native catch-up actions, agent environment wrapping, generated-file ownership, and failure reporting.

v0.1.36

Status PR ordering

wtc status now shows open pull requests above drafts in the interactive TUI and Markdown output. It keeps enlistment order within each group. Checked-out merged work still appears with its catch-up warning, and completed PRs remain muted below active work. The ordering also applies when rendering a cached snapshot.

Verification

go test ./..., go vet ./..., the PR check, and the exact main CI run passed. Tests cover both renderers and the existing catch-up and merged-row layout.

v0.1.35

Workspace-scoped control root

When no WTC_CONFIG_ROOT is set and a collection has no generated root, the CLI now uses <workspace-root>/.config. Separate workspaces therefore have separate default locations for secrets and tool configuration. An explicit WTC_CONFIG_ROOT still takes precedence, followed by the value already recorded in .env.collection.

Existing collections keep their recorded root. This release does not move or copy credentials. To migrate a collection, set WTC_CONFIG_ROOT to the intended workspace .config directory and run wtc env setup; reload any already-open panes afterward.

wtc secrets list and wtc env list describe control-root files and wtc.env as shared by collections using that root, without displaying values.

Catch-up secrets hook

wtc catch-up now skips secrets linking for selected external siblings that are not registered repositories. Registered repositories and the harness still run the hook. The decision uses the target's current registry after a harness update, and the report records a skipped hook for unmanaged siblings.

Verification

The CLI test suite, vet, PR checks, and exact main builds passed for both changes. Regression tests cover default and explicit control-root precedence, inventory scope labels, and mixed registered/unmanaged catch-up targets.

v0.1.34

Responsive inventory views

wtc secrets list and wtc env list now open a scrollable terminal view when run interactively. Each row stays on one line and adapts to the pane width. Short scope and state labels keep the list readable; the selected row shows additional metadata below it. Use arrow keys or j and k to move, Page Up and Page Down for larger moves, and q to exit.

Use --no-tui for a compact one-shot table, or --json for the full structured inventory. An explicit --tui=false also selects one-shot output. Redirected and piped output remains one-shot automatically. The commands continue to show names and paths only, never secret or environment values.

Verification

The CLI test suite passed, including layout checks at narrow and wide terminal sizes, resize backfill, and column alignment. Pseudo-terminal checks verified both interactive views at 42 columns, keyboard exit, and explicit one-shot behavior.

v0.1.33

Secret and environment inventories

wtc secrets list shows the paths available in the control root, whether each file is shared with collections that check out its repository, and its state in the selected collection. States include linked, available, locally overridden, not gitignored, and excluded by the production-path guard. The inventory also identifies the collection-local variable file. Use --repo to narrow the list and --json for scripts.

wtc env list shows variable names and their source: machine defaults, generated collection environment, or collection-local overrides. It never prints variable values. Both inventory commands are read-only.

Explicit environment setup

wtc env now shows its subcommands. Run wtc env setup to regenerate the collection environment and mise configuration. Existing flagged calls such as wtc env --collection DIR remain compatible with the setup behavior.

Verification

The CLI test suite and synthetic inventory fixtures passed. The fixtures cover shared and local scope, link states, production exclusions, repository filtering, and JSON that contains no secret values. The exact merge commit passed main CI.

v0.1.32

Interactive status by default

wtc status now opens the live TUI when both stdin and stdout are terminals. The live view keeps the table visible while refreshing and offers a refresh log with l or a click on “refreshing”. Use q to leave it.

For a single terminal snapshot, use wtc status --no-watch. JSON, Markdown, ANSI, cached, preview, and redirected output remain one-shot. Interactive one-shot collection reports progress on stderr unless --silent is set, including when the configured watch interval is zero.

The bundled status skill and command help describe the new default. No configuration change is needed for status panes that already pass --tui.

Verification

The exact merge commit passed the main branch CLI test and build workflow. The command test suite and a pseudo-terminal smoke run verified that bare interactive status enters the TUI and exits on q.

v0.1.31

Catch-up follows the PR target

wtc catch-up now reads the merge target of each open or draft pull request on GitHub and Bitbucket. It merges the fetched target into the PR branch and pushes the result. Live branches without a PR continue to use the repository's configured development ref. If a PR target is missing, invalid, or inconsistent across PRs on one branch, catch-up leaves the branch untouched and reports an owner handoff.

The catch-up report now includes the target ref, conflicted paths when a merge fails, and a concrete next action for the owning agent. The bundled catch-up skill starts with the tool run and uses its report to guide conflict resolution.

Conflict signals in status

Status snapshots now record unfinished local Git operations and unresolved conflicts. The TUI shows a red conflict symbol for unresolved local merges and for GitHub PRs whose merge state reports a conflict. Incoming commit counts turn red for conflicted PRs; the PR table also labels the conflict. Status colors use the terminal's configurable palette and continue to honor NO_COLOR.

Verification

The exact merge commit passed the CLI's main branch test and build workflow. Synthetic tests cover missing PR targets, unfinished merges, catch-up reports, and TUI conflict rendering.