Cause: 30 days of Studio UI changes landed without screenshots or review, and a visible control was hidden without a linked issue or a release note.
The PR template had no UI requirement and no table tracked 1.x features.
The repository now describes the two lines the version roadmap announced
(discussions/10748): 2.x on studio, 1.x on main-v2 in maintenance.
- README (en, zh-CN): a Versions section and a Studio 2.x release badge.
Install leads with Reasonix Studio 2.x from the studio-v* pre-releases,
with the 1.x CLI and desktop app beside it as the stable line. The
zh-CN build-from-source section gains the Studio build it lacked.
- Issue forms offer 2.x / 1.x / 0.x, and the labeler maps them to v3 /
v2 / v1, with the pasted version still overriding the dropdown. The
forms link the roadmap. The PR template and CONTRIBUTING say which
branch takes which changes.
Issue forms, schedules and Dependabot are read from the default branch
only, so these take effect when studio becomes it:
- CodeQL scans pushes and PRs on both lines, and the weekly scan checks
out each line and files results under its own ref, so 1.x keeps its
security scanning.
- v1-maintenance-schedule starts main-v2's nightly app-memory and
diagnostic-overhead monitors, which measure the 1.x desktop app, on
main-v2.
- Dependabot drops /desktop/frontend and /site, which do not exist on
studio, and covers /desktop/frontend-next and /desktop/electron. It
also names main-v2 as a target for patch updates only.
Cache-impact, Cache-guard, System-prompt-review and Documentation-impact were
enforced by reading text out of the pull request description. Both workflows,
their checkers and the template fields go.
What they were protecting stays: scripts/cache-guard.sh is a test run, not a
body field, and remains the release-level cache-hit check. CONTRIBUTING still
asks that a cache-sensitive change say what it does to the provider-visible
prefix — as prose in review, not as a parsed line.
Problem: The independent cross-boundary review status created recurring red PR statuses and forced every qualifying head through another manual approval cycle.\n\nRoot cause: Protected review workflows published a failing commit status until a non-author maintainer approved the exact head.\n\nFix: Remove the evaluator, workflows, tests, PR template guidance, and CI invocation while retaining a negative contract against stale references.\n\nVerification: Full pull-request CI passed on Linux, macOS, and Windows, including lint, race, CodeQL, desktop builds, and WebView2 smoke.
* test(desktop): enforce native motion release gates
Problem:
Native motion regressions could pass aggregate CI even when Element.animate was never exercised, and Windows release builds were signed without a real approval interaction in WebView2.
Root cause:
The focused motion suites were not part of a required check, legacy GSAP easing tokens had no source-level contract guard, and the release workflow never launched the built Wails executable.
Fix:
Add WAAPI contract scanning, required motion CI, a real Wails/WebView2 approval smoke before signing, protected release verification, and an independent review check for large or cross-boundary pull requests.
Verification:
- pnpm test:motion
- pnpm typecheck
- pnpm build
- go test ./... (desktop)
- bash scripts/release-workflows.test.sh
- actionlint for changed workflows
- go run ./tools/repolint
* fix(ci): close native motion release gate gaps
Problem:
- Windows rejected the shared WAAPI easing constants and the required lint job failed ShellCheck.
- Large-PR approval could be stale or evaluated from candidate-controlled workflow code.
- Pull requests did not exercise the real Wails approval flow in WebView2.
Root cause:
- The WAAPI contract matched only POSIX paths, the cross-platform lint loop split an unquoted value, and the review policy was bound to pull_request events without checking review.commit_id.
- The WebView2 smoke existed only in the release workflow.
Fix:
- Normalize contract paths and add a Windows regression fixture.
- Quote the lint target parsing, move review decisions into a protected control plane with current-head status publication, and add policy tests.
- Build and smoke-test the Windows Wails executable in PR CI.
Verification:
- pnpm --dir desktop/frontend test:motion
- pnpm --dir desktop/frontend build
- node --test .github/scripts/cross-boundary-review.test.cjs
- bash scripts/release-workflows.test.sh
- actionlint for all changed workflows
- cd desktop && go test ./...
- go run ./tools/repolint
Co-authored-by: Ray-lyy <[email protected]>
* fix(ci): isolate transcript virtualization from motion gate
Problem:
The native motion gate ran the transcript virtualization suite in three jobs. Its prepend assertion could execute before the virtualizer remounted the anchor, producing a false Windows failure and skipping the real WebView2 smoke.
Root cause:
The suite was grouped by historical proximity rather than ownership, and the assertion waited for one fixed render flush instead of the DOM condition it required.
Fix:
Give transcript virtualization its own test command, run it once in the Linux desktop job, and make the motion contract reject future coupling. Wait for the anchor to remount before asserting, and cover the transcript entrance reset-key contract directly.
Verification:
- pnpm --dir desktop/frontend test:motion
- pnpm --dir desktop/frontend test:transcript (6 consecutive passes)
- pnpm --dir desktop/frontend typecheck
- pnpm --dir desktop/frontend build
- go run ./tools/repolint
- actionlint for changed workflows
- bash scripts/release-workflows.test.sh
* fix(ci): defer WebView2 smoke instrumentation
Problem:
The latest-base Linux Desktop build exceeded the 2,200 KiB raw startup budget by about 0.1 KiB.
Root cause:
The Windows-only approval smoke instrumentation was statically linked into every normal desktop startup while the latest base had little budget headroom.
Fix:
Lazy-load the smoke component only when the native harness injects its flag, and make the motion contract reject a future static App import.
Verification:
- pnpm --dir desktop/frontend test:motion
- pnpm --dir desktop/frontend test:transcript
- pnpm --dir desktop/frontend typecheck
- pnpm --dir desktop/frontend build
- go run ./tools/repolint
- git diff --check
---------
Co-authored-by: Ray-lyy <[email protected]>
Problem:
Reasonix installations could not reliably search the exact documentation and release notes shipped with their build, and dynamic slash-menu filtering could leave stale virtual row gaps.
Root cause:
Documentation lived only as source files without a compiled retrieval identity or deterministic slash-command path. The shared virtual menu also let TanStack Virtual cache rows by numeric index while React used different keys.
Fix:
Embed docs and reviewed release notes, add the read-only docs tool and /docs command across CLI and Desktop, stamp and verify corpus identity in release builds, enforce documentation-impact declarations, and align virtual-list semantic keys across slash and file menus.
Verification:
- go test ./...
- go test -race ./internal/productdocs ./internal/boot ./internal/control ./internal/cli
- cd desktop && go test ./...
- pnpm --dir desktop/frontend build
- ./scripts/cache-guard.sh
- bash scripts/release-workflows.test.sh
- bash scripts/verify-embedded-docs.sh v0.0.0 e67b2aa824
A PR writing "Fixes #N" auto-closes its issue on merge. One writing "Refs",
"Related" or "Addresses" does not, so the report stays open waiting for a
follow-up after the release that nobody sends. Auditing the last 400 merged
PRs found 33 open issues referenced by shipped work; only three could be
closed on the evidence, and most of the rest were blocked on nothing but an
unanswered "please re-test".
On every published release this now diffs against the previous tag in the
same series, collects the issues those PRs referenced, and asks each still-open
reporter to verify. It never closes anything — deciding a report is resolved
stays human.
Two traps the audit hit are pinned by tests rather than left to be rediscovered:
- "owner/repo#123" is an upstream reference. Matching it once pulled a
wailsapp/wails issue number in as if it were ours.
- GitHub's issues API answers for pull requests too, so a consolidation PR
listing "PR #5576 by @x" reads as a perfectly good open issue. A dry run
against desktop-v1.18.0 showed 26 of 40 references were pull requests; without
the check the bot would have asked their authors to re-test.
The PR template now says where to put the keyword, since a "- Fixes#123" list
item is exactly the silent no-op that produced this backlog.
esengine