The live baseline previously accepted provider UUIDs, which made the gate hard to run on another contributor's machine. Add a local provider listing command and resolve quality-gate targets from stable provider-name selectors while keeping UUIDs and current runtime support.
Constraint: Provider configuration is local machine state under CLAUDE_CONFIG_DIR and must not expose API keys.
Rejected: Require contributors to inspect providers.json manually | too error-prone and leaks implementation detail into the workflow
Confidence: high
Scope-risk: narrow
Directive: Keep live-provider baseline selection copyable from quality:providers before adding more live test lanes.
Tested: bun test scripts/quality-gate/providerTargets.test.ts
Tested: bun test scripts/quality-gate/*.test.ts scripts/quality-gate/baseline/*.test.ts
Tested: bun run quality:providers
Tested: bun run quality:gate --mode baseline --dry-run --provider-model codingplan:main --provider-model minimax:main
Tested: bun run quality:gate --mode baseline --dry-run --provider-model custom:haiku
Tested: bun run quality:gate --mode pr --dry-run
Tested: bun run check:server
The live baseline covered the server WebSocket path, but it still did not prove the desktop app can open a session, apply a selected provider/model, send a chat turn, and surface model/tool progress through the UI. This adds an agent-browser driven smoke lane that starts the local server and Vite desktop app, restores an isolated session tab with the requested runtime selection, submits a small coding task through the composer, and accepts the run only when the fixture diff and tests pass.
Constraint: Desktop smoke must stay behind --allow-live because it launches browsers and real models.
Constraint: The smoke temporarily enables bypassPermissions for the isolated run and restores the previous mode afterward.
Rejected: Wait for a final marker phrase | model reasoning and echoed prompts can contain the same marker before the work is actually done.
Rejected: Use only DOM text as success proof | the browser can show progress while the project files are still unchanged.
Confidence: high
Scope-risk: moderate
Directive: Future desktop smoke cases should verify project state and artifacts, not only UI copy.
Tested: bun test scripts/quality-gate/*.test.ts scripts/quality-gate/baseline/*.test.ts
Tested: bun run quality:gate --mode baseline --dry-run --provider-model minimax-m2.7
Tested: bun run quality:gate --mode baseline --allow-live --provider-model minimax-m2.7 (9 passed, 0 failed)
Tested: bun run check:server
Not-tested: Kimi desktop smoke completion because the provider returned AccountQuotaExceeded / API Error 429 until its reset window.
The first quality gate proved the execution path, but two tiny fixtures were not enough to reveal regressions in real agent behavior. This expands the maintained baseline with deeper failure recovery, workspace search, artifact creation, and cross-module refactor cases, and records per-case diffs so reviewers can see exactly what each model changed.
Constraint: Baseline runs must remain explicit maintainer-controlled live checks, not default PR checks.
Rejected: Require models to edit tests in every contract-change case | correct fixes can satisfy prewritten acceptance tests without modifying tests.
Rejected: Trust only command exit codes | passing tests alone does not show whether the agent edited forbidden or unrelated files.
Confidence: high
Scope-risk: moderate
Directive: Keep live baseline cases product-shaped and inspect both verification output and diff.patch before accepting future fixture changes.
Tested: bun test scripts/quality-gate/*.test.ts scripts/quality-gate/baseline/*.test.ts
Tested: bun run quality:gate --mode baseline --dry-run --provider-model volc-kimi-k2.6 --provider-model minimax-m2.7
Tested: bun run quality:gate --mode baseline --allow-live --provider-model volc-kimi-k2.6 --provider-model minimax-m2.7 (14 passed, 0 failed)
Not-tested: Desktop UI browser smoke and native Tauri release packaging remain outside this baseline expansion.
The desktop product needs a repeatable local gate that can prove the core Coding Agent loop still works after changes, not only that unit tests pass. This adds a quality-gate runner with PR, baseline, and release modes, structured reports, explicit quarantine metadata, and fixture-based live baseline cases that can run across provider/model targets.
Constraint: Existing check:pr and CI policy behavior must remain usable while the stronger baseline grows around it
Constraint: Default PR gates must not require real model credentials or provider quota
Rejected: Build a standalone QA platform first | too heavy before the baseline task shape is proven
Rejected: Keep unstable server exclusions hardcoded in run-server-tests | hides quarantine policy from reports and future review
Confidence: medium
Scope-risk: moderate
Directive: Expand baseline cases by adding focused fixtures and verifiers; do not make normal PR checks depend on live providers
Tested: bun test scripts/quality-gate/*.test.ts scripts/quality-gate/baseline/*.test.ts
Tested: bun run check:server
Tested: bun run quality:gate --mode baseline --allow-live --provider-model 2944f963-ce75-45b7-bac1-6e4f57df0970:kimi-k2.6:volc-kimi-k2.6 --provider-model 9c78d3df-7fb5-44c7-8436-3a41c3a59231:MiniMax-M2.7-highspeed:minimax-m2.7
Not-tested: desktop UI browser smoke and native release mode in this commit
Pull requests need a deterministic way to show changed areas, required checks, missing-test signals, and CLI-core risk before review. This adds a path-based policy gate, local impact reporting, PR triage labels/comments, and reusable check scripts so reviewers can evaluate blast radius without trusting contributor claims.
Constraint: CLI core should remain effectively frozen unless a maintainer explicitly overrides it.
Constraint: Default PR checks must be safe for external forks and avoid live model/provider calls.
Rejected: Run live provider tests on every PR | secrets, cost, network, and vendor instability would make the gate noisy and unsafe.
Rejected: Use Dosu as the merge gate | AI review is useful for risk explanation, but deterministic Actions must own blocking checks.
Confidence: high
Scope-risk: moderate
Directive: Keep real model/provider smoke tests in maintainer-controlled workflows; do not make them required for untrusted PRs.
Tested: bun run check:impact
Tested: bun run check:policy
Tested: ruby YAML parse for PR workflows
Tested: git diff --check
Tested: bun run check:native
Tested: npm run docs:build
Tested: bun run scripts/pr/run-server-tests.ts
Tested: bun run check:adapters
Tested: bun run check:desktop
Not-tested: GitHub-hosted pull_request_target label/comment execution before opening this PR
The release workflow was still publishing a hard-coded GitHub Release body,
which forced manual copy-paste of each version's markdown after the build
finished. This change makes tagged releases load release-notes/vX.Y.Z.md
from the tagged commit and fail fast when the file or version/tag alignment
is missing. The local release script now enforces the same contract and
stages the matching markdown file into the release commit automatically.
Constraint: GitHub Releases must be generated from the tagged commit so the workflow can only read files already present at that revision
Rejected: Keep a hard-coded releaseBody in workflow | still requires manual release-page editing every version
Rejected: Store release notes only outside git state | workflow cannot read local-only markdown during tag-triggered builds
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep release-notes/vX.Y.Z.md as the canonical source for GitHub Release bodies and preserve the tag/version validation gate
Tested: ruby -e 'require "yaml"; YAML.load_file(".github/workflows/release-desktop.yml"); puts "YAML OK"'
Tested: bun run scripts/release.ts 0.1.5 --dry
Tested: git diff --check
Not-tested: End-to-end GitHub Actions release run against a pushed tag
