Run required server and contract suites in credential-free sandboxes, fail closed on incomplete coverage or test output, and preserve the desktop active-turn permission guard across stale tab interactions.\n\nTested: bun run check:policy (115 pass); bun run check:server (1605 pass before final runner evidence check); bun run check:desktop; bun run check:provider-contract; bun run check:chat-contract\nConfidence: high\nScope-risk: broad
Route required checks by changed surface, add offline provider and chat contracts, and keep fork PRs independent of live credentials. Layer agent guidance by subtree and enforce a compact instruction budget.
Tested: bun run check:policy
Confidence: high
Scope-risk: broad
Prevent repeated update checks from clearing the pending Electron update, recover the UI when relaunch does not exit, and keep public releases draft until all updater assets are uploaded.
Tested: bun test scripts/release-update-metadata.test.ts scripts/pr/release-workflow.test.ts
Tested: cd desktop && bun run test -- src/stores/updateStore.test.ts --run
Tested: cd desktop && bun run test -- electron/services/updater.test.ts --run
Tested: git diff --check
Tested: bun run check:policy
Tested: bun run check:desktop
Not-tested: bun run check:native
Not-tested: bun run check:coverage
Not-tested: bun run verify
Confidence: medium
Scope-risk: moderate
Add Windows ARM64 desktop release packaging, verify architecture-specific sidecar/native files in package smoke, and give the Electron sidecar more startup time plus early diagnostics for slow Windows ARM launches.
Tested: bun test electron/services/sidecarManager.test.ts
Tested: bun test scripts/quality-gate/package-smoke/index.test.ts scripts/release-update-metadata.test.ts scripts/pr/release-workflow.test.ts
Tested: bun run check:native
Tested: bun run check:policy
Not-tested: full bun run verify / coverage; this was a local issue-fix handoff, not PR-ready validation.
Confidence: high
Scope-risk: moderate
Make workflow_dispatch draft handling explicit and add a post-publish guard that edits the release back to draft when manual draft runs upload assets to an existing release.\n\nTested: bun test scripts/pr/release-workflow.test.ts\nTested: git diff --check\nScope-risk: narrow\nConfidence: high
Replace electron-builder's internal macOS notarization wait with an explicit notarytool flow: build a signed app with update config, submit it with a bounded notarytool timeout, staple and validate it, then rebuild dmg/zip from the notarized app via --prepackaged. Keep draft-only signed/no-notary builds available for fast artifact checks.\n\nTested: bun test scripts/pr/release-workflow.test.ts\nTested: git diff --check\nTested: bun run scripts/release.ts 0.4.3 --dry\nTested: local arm64 signed/no-notary build followed by --prepackaged dmg/zip rebuild\nTested: bun run test:package-smoke --platform macos --package-kind release --artifacts-dir desktop/build-artifacts/electron\nTested: codesign --verify --deep --strict --verbose=2 desktop/build-artifacts/electron/mac-arm64/Claude\ Code\ Haha.app\nConfidence: medium\nScope-risk: moderate
Add a workflow_dispatch-only notarize_macos switch so draft release runs can build Developer ID signed macOS artifacts without waiting on Apple notarization when GitHub runner networking is failing. Tag push releases still default to notarization and Gatekeeper release checks.\n\nTested: bun test scripts/pr/release-workflow.test.ts\nTested: git diff --check\nTested: bun run scripts/release.ts 0.4.3 --dry\nConfidence: medium\nScope-risk: moderate
Capture the signed macOS electron-builder exit code before the retry branch so watchdog timeouts and notarization failures fail the signed step directly instead of falling through to package-smoke.\n\nTested: bun test scripts/pr/release-workflow.test.ts\nTested: git diff --check\nTested: bun run scripts/release.ts 0.4.3 --dry\nTested: local bash watchdog timeout returns status 124\nConfidence: high\nScope-risk: narrow
Add an outer watchdog around the signed macOS electron-builder step so hung notarytool waits return control to the retry loop instead of idling until the GitHub step timeout.\n\nTested: bun test scripts/pr/release-workflow.test.ts\nTested: git diff --check\nTested: bun run scripts/release.ts 0.4.3 --dry\nConfidence: medium\nScope-risk: narrow
Tested: bun test scripts/pr/release-workflow.test.ts
Tested: git diff --check
Tested: bun run scripts/release.ts 0.4.3 --dry
Confidence: high
Scope-risk: narrow
Tested: bun test scripts/pr/release-workflow.test.ts
Tested: git diff --check
Tested: bun run scripts/release.ts 0.4.3 --dry
Confidence: high
Scope-risk: narrow
Tested: bun test scripts/pr/release-workflow.test.ts scripts/release-update-metadata.test.ts scripts/quality-gate/package-smoke/index.test.ts
Tested: bun run check:policy
Tested: bun run check:docs
Tested: workflow YAML parse and git diff --check
Scope-risk: moderate
Prevent stale same-version update metadata from surfacing another install prompt, avoid showing a fake desktop version fallback, and configure the Windows NSIS installer to expose install directory selection.
Fixes#801
Tested: bun run verify
Confidence: high
Scope-risk: moderate
When the signing secrets are absent, `CSC_LINK`/`APPLE_*`/`WIN_CSC_*` render
as empty strings. electron-builder treats a present (even empty) CSC_LINK as
"a certificate is configured", tries to load it, resolves the empty path to
the working dir and dies with "<workdir> not a file" — which broke the v0.4.0
release build.
Drop those env vars from the release build step so unsigned builds behave
exactly like the (already-green) dev build, which only sets
CSC_IDENTITY_AUTO_DISCOVERY=false. Add them back once an Apple Developer ID /
Windows cert is available.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Release is gated on the tag only. `bun run verify` runs on PRs and locally,
not at release time, so a failing quality gate no longer blocks publishing.
- release-desktop.yml: remove the quality-preflight job and its `needs`.
- release-workflow.test.ts: assert the release workflow does NOT run verify.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Unsigned builds ship manual downloads only, so the macOS auto-update zip
(~187MB) and the blockmaps just clutter the release page and dev artifacts.
- release-desktop.yml: stop attaching *.zip / *.blockmap to the GitHub
Release; users now see DMG/exe/AppImage/deb + install-macos-unsigned.sh.
- build-desktop-dev.yml: stop collecting *.zip / *.blockmap into the dev
artifact for the same reason.
- electron-builder still produces dmg+zip and the whole updater-metadata
pipeline (latest*.yml merge/validate) is untouched, so auto-update can be
re-enabled later by restoring the two asset globs.
- sync release-workflow.test.ts dev-artifact assertion accordingly.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bump the Electron desktop package version to 0.4.0, publish a macOS unsigned install helper, and let the release workflow continue when Developer ID signing is not configured.
Tested: bash -n desktop/scripts/install-macos-unsigned.sh
Tested: bun test scripts/pr/release-workflow.test.ts
Tested: bun run scripts/release.ts 0.4.0 --dry
Tested: git diff --check
Tested: bun run check:docs
Tested: bun run check:policy
Confidence: high
Scope-risk: moderate
Keep development desktop artifacts limited to distributable archives and update
metadata so macOS workflow downloads do not duplicate the packaged app bundle.
The package smoke step still validates the unpacked app before upload.
Tested: bun test scripts/pr/release-workflow.test.ts
Tested: bun run check:policy
Confidence: high
Scope-risk: narrow
Match Electron Builder Linux output by accepting linux-*-unpacked directories,
treating AppImage blockmaps as optional, and validating release asset names
against the generated x86_64/amd64 and arm64 artifacts.
Tested: bun test scripts/quality-gate/package-smoke/index.test.ts
Tested: bun test scripts/pr/release-workflow.test.ts scripts/quality-gate/package-smoke/index.test.ts
Tested: bun run check:policy
Tested: bun run check:native
Tested: bun run verify
Confidence: high
Scope-risk: moderate
- mac.notarize=true + hardenedRuntime + entitlements so a signed CI release
actually notarizes (gatekeeper smoke + Squirrel.Mac auto-update need it)
- entitlements grant disable-library-validation for the Bun sidecar/node-pty
- local unsigned build passes -c.mac.notarize=false so electron:package still
works without an Apple account
- release signing-preflight now hard-requires only the Apple secrets; Windows
cert is optional (unsigned NSIS still auto-updates, just SmartScreen warning)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Complete the Electron replacement boundary before merging by removing the renderer-side Tauri host fallback, tightening H5/browser access so only desktop navigation is tokenless, and moving desktop release publication to a tag-driven GitHub Actions matrix with a single final publish job.
Constraint: H5/browser capability access must not gain tokenless access through localhost or retired Tauri origins
Constraint: Desktop release artifacts must be built by GitHub Actions from version tags, not treated as local build outputs
Rejected: Keep localhost browser origins trusted for convenience | local browser contexts can access loopback services and must use the H5 token path
Rejected: Publish from each matrix job | partial releases can be created before all platforms finish
Confidence: high
Scope-risk: broad
Directive: Do not reintroduce Tauri origins or localhost browser origins into the trusted desktop origin set without a reviewed security design
Tested: bun test src/server/__tests__/h5-access-policy.test.ts src/server/__tests__/h5-access-auth.test.ts src/server/__tests__/diagnostics-service.test.ts src/server/middleware/cors.test.ts
Tested: bun test scripts/pr/release-workflow.test.ts scripts/release-update-metadata.test.ts
Tested: bun run check:desktop
Tested: bun run check:native
Tested: git diff --check
Not-tested: bun run check:server is blocked by expired quarantine entries server:cron-scheduler, server:providers-real, server:tasks, server:e2e:business-flow, server:e2e:full-flow
Introduce the Electron desktop shell alongside the existing React renderer and local Bun server boundary. The migration keeps the DesktopHost contract explicit across Tauri, Electron, and browser runtimes while adding Electron main/preload services for dialogs, shell, notifications, updates, tray/window lifecycle, terminal, preview WebContentsView, app mode, and release/package validation.
The commit also carries the latest local main desktop command updates, including agent slash entries and hidden-by-default markdown thinking details, so the packaged Electron build matches the current main UX surface.
Constraint: React renderer, local Bun server, REST/WebSocket, and sidecar boundaries must remain reusable during the migration
Constraint: macOS dev packages are ad-hoc signed and cannot prove Developer ID notarization or Gatekeeper release launch
Rejected: Browser-only smoke validation | it cannot exercise native dialogs, keychain prompts, notification behavior, or packaged app startup
Confidence: medium
Scope-risk: broad
Directive: Do not remove Tauri host support until signed Electron release artifacts pass native OS smoke on macOS, Windows, and Linux
Tested: bun run check:desktop
Tested: cd desktop && bun run check:electron
Tested: CSC_IDENTITY_AUTO_DISCOVERY=false bun run electron📦dir
Tested: bun run test:package-smoke --platform macos --package-kind dir --artifacts-dir desktop/build-artifacts/electron
Tested: Computer Use read packaged Electron app window at desktop/build-artifacts/electron/mac-arm64/Claude Code Haha.app
Not-tested: Developer ID signed/notarized Gatekeeper launch
Not-tested: Real OS notification click-to-session action
Not-tested: Windows and Linux packaged app smoke on real hosts
Tauri runs the repository beforeBuildCommand during packaging, which invokes build:sidecars again after the explicit sidecar step has already passed. The Windows runner therefore still needs the same Bun compile cache override inside the packaging step so the repeated baseline runtime extraction stays on the runner work drive.
Constraint: Tauri beforeBuildCommand re-enters the sidecar build under the packaging step environment.
Rejected: Remove beforeBuildCommand from CI | that would diverge CI from normal Tauri packaging behavior.
Confidence: high
Scope-risk: narrow
Directive: Keep explicit sidecar build and Tauri packaging environments in sync when changing desktop workflow target or cache settings.
Tested: bun test scripts/pr/release-workflow.test.ts; bun run check:policy
Not-tested: GitHub Actions Windows runner rerun after push.
Windows GitHub runners keep the checkout and Bun install cache on different drives, which can trip Bun's baseline compile-target extraction before Tauri packaging starts. Point desktop sidecar builds at the runner temp cache so dev and release workflows can still use the Windows x64 baseline runtime needed for older CPUs.
Constraint: Bun upstream still has an open Windows cross-drive extraction issue for compile target downloads.
Rejected: Revert to bun-windows-x64 | would reintroduce the older-CPU Illegal Instruction failure class.
Confidence: high
Scope-risk: narrow
Directive: Keep desktop dev and release sidecar build cache handling aligned until Bun's Windows extraction fix is released and verified in Actions.
Tested: bun test scripts/pr/release-workflow.test.ts; cd desktop && bun run test -- --run scripts/build-sidecars.test.ts; bun run check:policy; cd desktop && BUN_INSTALL_CACHE_DIR=/tmp/cc-haha-bun-install-cache TAURI_ENV_TARGET_TRIPLE=x86_64-pc-windows-msvc bun run build:sidecars
Not-tested: GitHub Actions Windows runner rerun after push.
Contributors and coding agents need one local command that both reports and enforces the quality contract. This change turns the PR gate into the shared verification entrypoint, adds path-selected local lanes, tightens coverage accounting around changed lines, and documents the repair loop in contributor and agent-facing guidance.
Constraint: Ordinary PR verification must stay non-live and runnable without provider credentials
Constraint: Coverage policy updates in this commit require maintainer approval before push/merge
Rejected: Keep quality guidance only in docs | agents need executable scripts and AGENTS.md instructions to follow the loop consistently
Confidence: high
Scope-risk: broad
Directive: Do not bypass `bun run verify` for production changes; fix failed lanes and coverage reports instead of lowering thresholds
Tested: bun run check:policy
Tested: ALLOW_CLI_CORE_CHANGE=1 ALLOW_COVERAGE_BASELINE_CHANGE=1 bun run verify
Not-tested: live provider baseline; no provider credentials were required for this non-live PR gate
The repository now has a measurable PR quality path instead of a loose set of
manual checks. Coverage, quarantine governance, provider smoke, desktop smoke,
and workflow wiring all produce durable reports that contributors and maintainers
can inspect without reconstructing terminal output.
This also fixes the desktop smoke current-runtime path so browser-driven smoke
runs use the desktop default active provider instead of forcing the official
current model, and records that runtime decision as an artifact.
Constraint: Default PR gates must remain non-live and contributor-safe while live model checks stay explicit.
Constraint: Release packaging is still GitHub Actions based, so release preflight must run before the build matrix.
Rejected: Make live provider or desktop smoke mandatory on every PR | secrets, quotas, and model availability are maintainer-controlled.
Rejected: Let PRs lower coverage baselines in the same change | base-branch ratchet comparison must remain authoritative.
Confidence: high
Scope-risk: moderate
Directive: Do not relax coverage or quarantine policy without a maintainer approval label and a fresh quality report.
Tested: ALLOW_CLI_CORE_CHANGE=1 ALLOW_COVERAGE_BASELINE_CHANGE=1 bun run quality:gate --mode pr
Tested: bun run quality:gate --mode baseline --allow-live --only provider-smoke:* --provider-model nvidia-custom:main:nvidia-custom-main --artifacts-dir /tmp/quality-gate-live-smoke
Tested: bun run quality:gate --mode baseline --allow-live --only desktop-smoke:* --provider-model current:current:current-runtime --artifacts-dir /tmp/quality-gate-desktop-smoke-fixed
Tested: git diff --check
Not-tested: Full live release mode with multiple providers in hosted CI; provider credentials and quota remain maintainer-controlled.
Release logs showed two warning classes after the packaging fixes: Linux builds warned about macOS-only menu imports, and tauri-action reported an unknown releaseAssetNamePattern input. Gate the native menu imports to macOS and use the action's supported assetNamePattern input so release logs stay clean and asset naming is actually applied.
Constraint: Linux release builds compile the shared Tauri lib without macOS-only menu usage
Constraint: tauri-action v0 accepts assetNamePattern, not releaseAssetNamePattern
Rejected: Ignore warning-only output | release candidates should not hide real signal behind avoidable warnings
Confidence: high
Scope-risk: narrow
Directive: Keep workflow input names aligned with tauri-action's published action schema
Tested: cargo fmt --check
Tested: cargo check --target aarch64-apple-darwin
Tested: git diff --check
Not-tested: Full GitHub release workflow after retag before pushing
The release workflow shells out through tauri-action but did not pass Tauri's --ci flag, while the desktop development workflow already uses it for the same app,dmg packaging path. Align release builds with the non-interactive CI mode so macOS DMG packaging does not depend on interactive defaults during tag builds.
Constraint: Release assets are produced remotely by .github/workflows/release-desktop.yml on tag push
Constraint: The dev desktop workflow already validates macOS app,dmg packaging through tauri build --ci
Rejected: Drop macOS DMG from release assets | would reduce the expected user-facing installer surface for 0.2.1
Confidence: medium
Scope-risk: narrow
Directive: Keep release and dev desktop Tauri build flags aligned when changing bundle behavior
Tested: bunx tauri build --target aarch64-apple-darwin --bundles app,dmg --ci --config /tmp/tauri-no-updater.json
Tested: git diff --check
Not-tested: Full GitHub release workflow after retag before pushing
The PR triage workflow mentioned Dosu inside inline-code formatting and before the final footer, which did not reliably wake the bot. Move the handoff so the last non-empty comment line is a plain-text @dosubot request, matching the working PR template pattern.
Constraint: GitHub bot mentions can be sensitive to markdown formatting and comment placement.
Rejected: Leave the mention as a copy-paste hint | it does not satisfy the maintainer need for automatic bot triggering.
Confidence: high
Scope-risk: narrow
Directive: Keep the generated triage comment's final non-empty line as a plain-text @dosubot request.
Tested: bun run check:policy
Tested: git diff --check
Tested: bun run check:pr
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
Windows releases were shipping both NSIS exe and MSI bundles, which made the
release page harder to understand and increased the chance that users would
pick the wrong asset. Restricting Windows output to MSI narrows the installer
surface while the release asset naming now spells out platform, architecture,
and bundle type directly in every published filename.
Constraint: Remote desktop packaging is triggered by GitHub Actions releases, not local uploads
Constraint: Updater metadata must keep latest.json stable for existing clients
Rejected: Keep publishing both NSIS and MSI with better docs | still leaves the higher-risk installer on the release page
Rejected: Rename assets manually after upload | easy to drift from workflow output and updater metadata
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: If Windows exe bundles are reintroduced later, reassess SmartScreen and AV impact before publishing them again
Tested: YAML parse for both desktop workflows; git diff --check on modified files; manual review of PowerShell changes
Not-tested: End-to-end GitHub Actions release run; PowerShell parser validation on a Windows host
The main branch push introduced a new root dependency for WebFetch fixes, but
package-lock.json was not refreshed, so the docs workflow's npm ci step failed
before it could even build VitePress. This syncs the lockfile, upgrades the
docs workflow to Node 22 for the current parser dependency requirements, and
includes package-lock.json in the workflow trigger set.
Constraint: The docs pipeline uses npm ci, which requires package.json and package-lock.json to stay exactly in sync
Rejected: Leave the workflow on Node 20 | continues to emit avoidable engine warnings for current docs parser dependencies
Rejected: Switch docs workflow from npm ci to npm install | weakens reproducibility instead of fixing the lockfile contract
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Whenever root dependencies change, keep package-lock.json in the same commit so docs and other npm-based workflows remain green
Tested: npm ci
Not-tested: Remote GitHub Actions rerun after pushing this fix
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
The desktop app already had Tauri updater plumbing, but the
release pipeline was not emitting signed updater artifacts and
the UI exposed only a thin auto-check path. This change restores
a working updater release path, rotates to a new updater public
key, and adds a shared update flow with manual check/install
controls for testing.
Constraint: Original updater private key is unavailable, so a new public key had to be embedded and old installs cannot trust new signatures
Constraint: Must not add new dependencies or require main-branch rollout before validation
Rejected: Keep the old pubkey and skip signing | would leave release builds unable to publish valid updater artifacts
Rejected: Add a manual download fallback flow | user explicitly deferred that work
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Preserve the new updater private key and password outside the repo; losing them again will break future in-app updates for installed builds
Tested: desktop unit test for updater store; desktop TypeScript no-emit; desktop production build
Not-tested: end-to-end updater install against a real GitHub Release on this branch
The current release lane is aimed at manual downloads and command-line usage, not notarized distribution or in-app auto-updates. This change removes Apple certificate import and updater signing from GitHub Actions, and forces release builds to disable updater artifacts so unsigned release bundles can still be produced consistently.
Constraint: Repository does not have working Apple signing certs or updater signing keys
Rejected: Keep signing requirements and document the secrets problem | blocks every release on infra the project does not plan to maintain
Rejected: Remove the GitHub release workflow entirely | still need a repeatable packaging path for downloadable artifacts
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: If signed distribution or in-app updates are added later, restore signing in workflow together with validated secrets and release metadata
Tested: git diff --check; YAML parse of release-desktop workflow; manual inspection that updater artifacts are disabled via tauri.release-ci.json and signing env/steps are removed
Not-tested: Live GitHub Actions run after workflow update
GitHub Actions showed that Linux compilation and .deb packaging succeed on both x64 and ARM64, but AppImage consistently fails inside linuxdeploy. The workflows now ship Linux as .deb only so CI and releases stay reliable while the AppImage path is investigated separately.
Constraint: Current GitHub-hosted Linux packaging fails specifically in linuxdeploy after successful .deb output
Rejected: Keep AppImage enabled and accept red workflows | blocks release confidence for an optional format
Rejected: Drop Linux builds entirely | would remove a working .deb delivery path
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Re-enable AppImage only after capturing linuxdeploy stderr and validating both Linux architectures on GitHub Actions
Tested: git diff --check; YAML parse of both workflow files; inspection of failed GitHub Actions logs showing .deb success before AppImage linuxdeploy failure
Not-tested: Re-run of updated workflows on GitHub Actions
The local desktop build path already proved that AppImage packaging needs libfuse2 and that macOS artifacts may be directories rather than plain files. This commit aligns the GitHub workflows with those realities so remote validation matches the local release path more closely.
Constraint: GitHub-hosted Linux runners do not guarantee AppImage runtime deps unless we install them explicitly
Rejected: Leave release workflow unchanged and trust local macOS build only | would not validate Linux packaging path at all
Rejected: Upload only DMG/installer files in dev workflow | hides the macOS .app artifact users expect for local testing
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep dev and release desktop dependency lists in sync when packaging requirements change
Tested: git diff --check; YAML parse of both workflow files; manual inspection of artifact collection and Linux dependency steps
Not-tested: Live GitHub Actions execution on repository runners
This folds together the desktop-side fixes needed before broader rollout.
Session resume no longer deadlocks waiting on init, Mermaid and inline image
output render inside chat, task and sub-agent state stay visible during
execution, local build/release paths are safer, and Feishu/Telegram now expose
lightweight mobile commands (/help, /status, /clear) without adding a new
adapter-specific protocol.
Constraint: Desktop releases must publish updater artifacts from non-draft GitHub releases
Constraint: IM commands need short, phone-friendly responses and low operational complexity
Rejected: Add a dedicated IM command API surface | re-used existing slash commands and session/task REST endpoints to keep adapters thin
Rejected: Wait for task_update push events in WebUI | added low-risk polling because the current frontend ignores that event path
Confidence: medium
Scope-risk: broad
Reversibility: clean
Directive: Keep IM command replies terse and mobile-first, and merge local fallback slash commands when server-provided lists are partial
Tested: cd desktop && bun x vitest run src/components/chat/MermaidRenderer.test.tsx src/components/markdown/MarkdownRenderer.test.tsx
Tested: cd desktop && bun x vitest run src/components/chat/composerUtils.test.ts src/pages/ActiveSession.test.tsx src/stores/chatStore.test.ts
Tested: cd desktop && bun run lint
Tested: bun test src/server/__tests__/conversations.test.ts --test-name-pattern "SDK init arrives only after the first user turn" --timeout 60000
Tested: cd adapters && bun test common/ feishu/ telegram/
Tested: cd adapters && bunx tsc --noEmit
Not-tested: Full GitHub Actions release run on all three desktop platforms
Not-tested: Local DMG packaging end-to-end on Apple Silicon
Not-tested: Real Feishu/Telegram device sessions against a live adapter process
