Skip to content

chore: bump version to 0.8.2 - #146

Merged
zhengchaol merged 1 commit into
mainfrom
release/v0.8.2
Aug 11, 2026
Merged

chore: bump version to 0.8.2#146
zhengchaol merged 1 commit into
mainfrom
release/v0.8.2

Conversation

@zhengchaol

Copy link
Copy Markdown
Contributor

Release 0.8.2

Bumps version from 0.8.1 to 0.8.2.

When this PR is merged to main, the release workflow will automatically:

  • Create tag v0.8.2
  • Create a GitHub Release with auto-generated notes
  • Build binaries for all platforms
  • Publish to PyPI
  • Publish to npm
@zhengchaol
zhengchaol merged commit 29bf9b9 into main Aug 11, 2026
7 checks passed
@zhengchaol
zhengchaol deleted the release/v0.8.2 branch August 11, 2026 01:04
zhengchaol added a commit that referenced this pull request Aug 14, 2026
* chore: sync uv.lock with the 0.8.2 version bump

The 0.8.2 bump (#146) updated pyproject.toml, __init__.py, the cloud
function requirements, and npm/package.json, but left uv.lock pinning
the editable parallel-web-tools entry at 0.8.1 — the same slip the
0.8.1 release made (fixed by hand in #145). Any uv sync regenerates the
entry, so the lock has been showing as dirty in working trees since the
release.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: keep uv.lock in sync with release version bumps

Every release bump has left uv.lock stale on main: release.sh rewrites
pyproject.toml but never re-locks, so the lock's own-package entry keeps
the previous version and the first uv sync in any working tree dirties
it. It happened at 0.8.1, was hand-patched in #145, and happened again
at 0.8.2.

Run uv lock as part of update_version_files and stage uv.lock in the
release commit. Add a `uv lock --check` step to the CI lint job so a
stale lock fails the release PR instead of surfacing later — `uv sync`
alone silently re-locks in the runner and can never catch it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: mirror project skill installs into .claude when Claude Code exists

`skills install --project` only wrote `<root>/.claude/skills` when
`<root>/.claude` already existed. A repo that has never stored Claude
settings has no `.claude` directory, so on exactly the machines that do
run Claude Code, project installs landed only in `.agents/skills` — a
location Claude Code never reads — and the skills were silently
invisible.

A missing `<root>/.claude` doesn't mean the user isn't running Claude
Code there; a missing machine-level configuration directory does.
Project installs now create `<root>/.claude/skills` whenever the
machine-level Claude config dir (CLAUDE_CONFIG_DIR or ~/.claude)
exists. The mirror stays project-local — the global config dir is only
consulted as the Claude-Code-is-present signal, never as a target.
Global installs are unchanged.

Also refresh the --project help strings, which still described the
pre-#145 single-directory behavior.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant