release: 0.7.1 - #62
Merged
Merged
Conversation
chore: back-merge main into develop
Bumps the cargo-minor-and-patch group with 1 update: [toml](https://github.com/toml-rs/toml). Updates `toml` from 1.1.4+spec-1.1.0 to 1.1.5+spec-1.1.0 - [Commits](toml-rs/toml@toml-v1.1.4...toml-v1.1.5) --- updated-dependencies: - dependency-name: toml dependency-version: 1.1.5+spec-1.1.0 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: cargo-minor-and-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [actions/checkout](https://github.com/actions/checkout) from 5 to 7. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v5...v7) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 6 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v6...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) from 7.6.0 to 10.0.1. - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@37802ad...20cfd1b) --- updated-dependencies: - dependency-name: astral-sh/setup-uv dependency-version: 10.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Lorem Dev <158839528+lorem-dev@users.noreply.github.com>
download-artifact v7 -> v8 and tauri-action v0.6.2 -> v1.0.0, landed in one commit because they only ever run together and each one's Dependabot pull request went stale the moment the other merged. upload-artifact v6 -> v7 went ahead of them in #54. Neither is exercised by any pull request: release.yml runs on a tag and nothing else. What follows is the compatibility review that stands in for a check, per change. download-artifact v8 has the one real breaking change of the three. A digest mismatch is now an error rather than a warning, and the action no longer unzips a download whose Content-Type says it is not a zip. Both exist to support v7's direct (unzipped) uploads; this pipeline uploads ordinary zipped artifacts and downloads them in the same run, so the second is inert and the first is a straight gain -- a corrupted transfer now fails the release instead of publishing a damaged asset. tauri-action v1.0.0 carries eight breaking changes and none of them reach this workflow: - The step passes `projectPath` and `args`, nothing else. The renamed inputs (assetNamePattern, includeUpdaterJson) and the removed ones (includeRelease, includeDebug, updaterJsonKeepUniversal, project auto-init) are all unused. - No `tagName`, so this is the build-only path and the new "update the name and body of an existing release" behaviour cannot fire. The publish job still owns the release and its CHANGES.md notes. - `.app.tar.gz` and its signature now carry the version. Nothing here reads them: "Stage release assets" collects an explicit extension allowlist (dmg, deb, rpm, AppImage, msi, exe, msix, and the two skillkeeper-cli archives), which never included the updater bundles. - Tauri v1 and unstable v2 support is dropped; this app is on 2.11.5. Two v1 changes do land on this layout, and the workflow already satisfies both. Runner detection now fails loudly when a lockfile is present but its package manager is not installed -- corepack and `pnpm install --frozen-lockfile` both run before this step. And lockfile detection now walks up the tree, so with `projectPath: apps/desktop` and the only pnpm-lock.yaml at the repository root, v1 finds a lockfile where v0.6.2 found none. The worst case there is a redundant install. The real check is a release candidate: RC tags are cut from develop, publish as a pre-release, and releases/latest/download never resolves to a pre-release, so one cannot reach install.sh users.
The updates were all chore/ci commits, which CONTRIBUTING reserves from the changelog, so Development stood empty. It cannot stay that way through a release: bump-version promotes that section verbatim and release-notes.mjs exits non-zero on an empty one, which would fail the publish job after all six matrix legs had already built and signed. The bullet is also true on its own terms. A patch release whose entire content is a dependency refresh should say so, and say what did not change with it.
The Version column of LICENSE's Third-Party Notices table names what a release actually ships, and today's updates left nine rows behind: aes, argon2, interprocess, toml, uuid and the two tauri plugins on the cargo side, plus motion and the clipboard plugin on the npm side. Only the versions moved. Every one of these is still MIT OR Apache-2.0, 0BSD OR Apache-2.0, or plain MIT, so the licence and copyright columns are unchanged and nothing about the policy check changed with them. Checked the whole direct set rather than only the rows that moved: 30 direct cargo dependencies and 8 npm production dependencies, none carrying a licence on CONTRIBUTING's disallowed list.
release: 0.7.1-rc.1
Scenario now carries every field the renderer's bridge types define (imported straight from the generated/hand-written sources instead of hand-rolled approximations), and withScenario/the app fixture let a spec declare one and drive it through a scripted backend. defaultScenario answers terminal_start and app_update_check so a boot is complete, and the fixture fails loudly if any command ever reaches the backend unmocked again.
Move the animation-zeroing stylesheet into a page.addInitScript so it lands before the app's own scripts on every navigation instead of after page.goto resolves, closing a window where an entrance animation could start and finish before the zeroing style arrived. Add self-tests that drive app.emit and app.clipboard through the same wire shapes the real event and clipboard-manager plugins use, so their wiring is proven rather than only reasoned about.
Adds the data-testid convention later tasks reuse (repositories-page, repo-add-*, repo-row/data-repo-name, repo-row-branch), the two flow-1/ flow-9 specs, and their scenario fixtures. RepoAddButton now awaits the add-then-clone chain to tell an add-level failure from success and surfaces it inline instead of closing blind. Repositories is not the default view, so a nav-<view> testid was added to the sidebar (App.tsx, SidebarItem.tsx) for the spec to reach it; the row's name/branch testids landed on RepositoryCard, the only place that content actually renders. harness.spec.ts's placeholder assertion is tightened onto the now-real repo-row.
The add form inferred success from any repository row matching the submitted URL, which a pre-existing duplicate satisfies just as well as a genuine new row -- so the backend's "duplicate" error (the most reachable real failure) closed the modal silently instead of showing repo-add-error. Require the matched row's id to be new since the submit started; add a regression spec and its duplicateFails scenario.
Add an expectUnmocked fixture option so one spec can name exactly which commands the harness's "nothing went unmocked" guard should record instead of failing the test outright, then write the spec that uses it: an add-repository flow with repositories_add left genuinely unmocked, asserting both the on-screen error and the recorded message carry UNKNOWN_COMMAND_PREFIX plus the command name. Every other spec keeps asserting emptiness unchanged, and the hatch requires an exact match (wrong count or an empty recording both still fail), so it cannot become a place future silence hides.
Add a desktop-e2e job that installs Chromium and runs the Playwright suite, add a prettier check to the existing ci job (never run in CI before), and widen test:e2e to chain the CLI and desktop suites. Document both suites under the end-to-end section.
The e2e job ran the widened `pnpm test:e2e`, which now also drives Playwright, but that job never installs Chromium -- only the new desktop-e2e job does. Run `pnpm test:e2e:cli` there instead, so the desktop half runs exactly once, in the job that sets it up. Also fix a comment on the Playwright browser cache key: it says the key is scoped to the Playwright version, but it hashes the whole lockfile on purpose, to avoid a version-parsing gap silently reusing a stale browser binary.
check-fixture-repo/SKILL.md still told the pre-release gate to run the widened `pnpm test:e2e`, which now also drives Playwright -- not what a fixture-repo check needs. Point it at `pnpm test:e2e:cli`, fix its stale "51 tests" expectation to the current 67, and add the two mcp-oauth/mcp-parameters specs missing from its per-spec table. AGENTS.md and the CLI harness's build-check error carried the same stale command; repoint those too, and note the desktop suite's existence in AGENTS.md where the CLI suite is documented.
Reset submitting on cancel so dismissing an in-flight add no longer leaves the Add button disabled forever, and key the post-submit error lookup by the last notification's id instead of the log's length so a full, capped log no longer swallows a genuine failure.
Toasts is generic cross-cutting UI, so its testid should name the kind
("toast"), not one caller's identity -- rename data-mcp-update-error
to data-testid=toast and let assertions scope by text instead. Give
skill-tree leaves and groups their own unique node id as the identity
attribute value, matching mcpTree.tsx's rule, instead of a bare name
or repo-relative path that two repositories (or Global vs. a project)
can legitimately share.
Assert mcp_apply's payload carries the chosen "Europe" option instead of only counting the call, so a Select that always submitted its first option would fail. Assert the agent-count badge's actual text so agentCount: 2 is read back, not just its visibility. Rewrite a comment that claimed proof of the instance surviving mcp_update: the scenario's fixed mcp_installs answer cannot falsify that; the row being visible only proves the skip message and call count, and the survival claim is covered by update_inner's own Rust tests instead.
Post-split, "only pnpm test:e2e needs it" misleads: test:e2e:desktop does not touch the fixture submodule at all.
Ten fixture and spec headers cited paths under `.superpowers/`, which is git-ignored. For anyone but the author those references resolve to nothing, so they were a dead end sitting at the top of the files a reader opens first. The prose around them was already self-contained: which flows the file covers, why a command carries no default answer, how row identity works, which sidebar shape the page has. Only the pointers are gone; nothing that explained a decision was removed. Where a reference carried real content -- why flow 12 is not a preflight refusal -- that content is now stated inline instead of cited. The remaining `.superpowers` mentions are deliberate and predate this branch: the entries in .gitignore, .dockerignore and .prettierignore are load-bearing, and AGENTS.md documents the workflow.
test: cover the desktop UI with end-to-end flows
The rules for this file lived in three places that had drifted apart: CONTRIBUTING carried a word cap, check-changes asked for a bullet per feat/fix/refactor/perf commit, and nothing anywhere said what does not belong. So refactors, CI work and bugs that never shipped all got entries, and the file drifted from a reason to upgrade toward a commit log with worse formatting. The rules now sit at the top of CHANGES.md, where someone about to add a bullet is already looking, and everything else defers to them rather than restating them. The one that changes most in practice: a fix earns an entry only when the bug was BROKEN IN A RELEASED VERSION. A defect introduced and fixed on the same branch never reached a user, so the changelog has nothing to say about it -- which is most fixes on a long branch, and the case check-changes was most likely to report as a gap. check-docs learns that `## Development` is no longer the first line: the block sits above it because release-notes.mjs extracts from a `## Version` heading to the next `## `, so anything above the first one cannot reach a GitHub release. Verified both ways.
release: 0.7.1-rc.2
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotes the second release candidate to the final 0.7.1 and carries the release branch into
main. The final tag is cut from here afterwards --scripts/check-tag-branch.mjsenforces that as the release pipeline's first job.The release commit
Every manifest moves from
0.7.1-rc.2to0.7.1.CHANGES.md's section heading is renamed rather than promoted: the release candidate contained exactly this content, and one section per shipped version is what the rest of the file does.## Developmentstays empty.Twelve
## Versionsections, one heading for 0.7.1, no duplicate;## Developmentstill parses wherebump-versionexpects it.What the release contains
One changelog bullet, and that is accurate -- it is the only thing in this release a user can see. Behind it:
security-and-quality) and Dependabot, both aimed atdevelop. Every workflow job now declares its own token scope, and third-party actions are pinned to commit SHAs --dtolnay/rust-toolchain@1.97.1turned out to be an unprotected branch, so the job that signs and publishes releases had been running whatever its head happened to be.sha20.11,argon20.6,toml1.1 andaesmajors. Each was checked against the golden vectors that guard skill content hashes and PPK key derivation, so existing hashes and keys read exactly as before. Two updates were closed rather than merged, with reasons on the pull requests.--repeat-each=10withretries: 0.pnpm format:checkexisted as a script that no workflow ran, which is why eight files had drifted unnoticed. It now runs in CI.Two candidates, both retired
v0.7.1-rc.1andv0.7.1-rc.2were cut, published as pre-releases, and deleted. Each earned its keep.rc.1exercisedtauri-actionv1.0.0 across all six targets,upload-artifactv7,download-artifactv8 under its new strict digest checking, and theX.Y.Z-rc.NtoX.Y.Z.Nmapping the MSIX packaging does by hand -- a code path that never executes on a final tag, so a release candidate is the only way to test it.rc.2confirmed the changelog rules block cannot leak into release notes.What tagging will do
A final tag triggers
docs.ymlas well asrelease.yml: it publishes the versioned documentation and moves thelatestalias. Release candidates skip that by tag filter; this one will not. It also makes 0.7.1 the release thatreleases/latest/download/...resolves to, which is what both one-line installers read.