.github/workflows/test-desktop.yml (currently disabled — branches: [none]).

.github/workflows/dev-desktop.yml, release-desktop.yml (depend on test-frontend-parallel.yml before their own matrix builds).

.github/workflows/build-performance-dashboard.yml, .github/workflows/release-docker-images.yml, lint-go.yml, test-go.yml, security-audit.yml, landing-deployment.yml.

@shm/web — app/ssr-document.integration.test.ts times out on one test.

@shm/shared — one xstate snapshot assertion fails.

Baseline delta is the estimated CI wall-clock savings of the change on the unit-tests job, derived from local timings.

"Kept" means the change is on disk and committed on the branch.

Hypothesis: The unit-tests job in test-frontend-parallel.yml installed pnpm (pnpm/action-setup@v4) but never ran actions/setup-node@v4 with cache: "pnpm". The other jobs in the same file do. That meant the pnpm store was re-downloaded from the registry on every run, instead of being restored from the GitHub Actions cache. Adding the setup-node step should cut warm-cache install from ~127 s (cold) to ~15 s.

Implementation: Added the missing actions/setup-node@v4 step (Node 22, cache: "pnpm") and switched pnpm install to pnpm install --frozen-lockfile --prefer-offline. Frozen-lockfile is also a correctness win — previously CI could silently mutate pnpm-lock.yaml.

Measurement: Local warm install = 15 s vs cold = 127 s. On CI's first run on a branch the pnpm store is restored from the most-recent main cache, so the new number will be close to 15 s in practice.

Result: kept. Saves ~110 s per run on warm cache; also a correctness improvement (frozen lockfile).

Hypothesis: The old unit-tests job ran seven sequential steps (check-ts-directives → install → format:check → typecheck → web test → shared test → desktop test). Two of those (format:check, typecheck) have no data dependency on the vitest suites and the three vitest suites don't depend on each other. Splitting into two parallel jobs — one for lint-and-typecheck, one matrix job with legs for web/shared/desktop — should cut the critical path to max(lint-and-typecheck, slowest vitest leg).

Implementation:

Measurement (local warm, using the numbers in the baseline table):

Result: kept. Saves ~72 s of wall-clock per run once cache is warm. Cost: three runners instead of one. Worth it — ubuntu-latest minutes are cheap compared to engineer wait time on PR signal.

Hypothesis: The root typecheck script ran pnpm --filter @shm/shared build:types before the parallel typecheck. Since all workspace packages resolve @shm/shared via tsconfig.*.json paths (or via pnpm's workspace symlinks to src/index.ts), the pre-built .d.ts emit is redundant for typecheck.

Experiment: Deleted frontend/packages/shared/dist and all *.tsbuildinfo files, then ran pnpm -r --parallel run typecheck cold.

Implementation: package.json — replaced the multi-step typecheck script with pnpm -r --parallel run typecheck.

Result: kept. Saves ~14 s on the typecheck step. Already reflected in iteration-2 maths (typecheck = 33 s).

Hypothesis: Splitting typecheck into a matrix of one-package-per-runner might beat the current pnpm -r --parallel approach.

Measurement (single-threaded, cold tsbuildinfo, per package):

Analysis: The slowest leg (desktop = 39 s) plus an install (~15 s) = 54 s. The current single-job parallel approach is 33 s. Matrix-splitting would be strictly slower because every matrix leg pays the install tax.

Result: discarded — current parallel approach is already optimal.

Hypothesis: format:check (16 s) and typecheck (33 s) are both CPU-bound but have no data dependency. Running them in sequence on one runner makes the critical path install + 16 + 33 = 64 s. Running them on two separate runners drops the critical path to max(install+16, install+33) = 48 s.

Alternative considered: concurrently in the same shell. Tested locally — combined wall-clock = 41 s (vs 49 s serial). Only saved ~8 s because both phases saturate cores and contend. Split-jobs is strictly better and keeps CI logs clean.

Implementation: Renamed the single lint-and-typecheck job to lint (format:check + ts-directive scan) and added a separate typecheck job. Both pay the 15 s install tax but run on independent runners. Updated all-tests-passed to gate on both.

Measurement: Expected CI wall-clock drops from 64 s to ~48 s, a 16 s saving per PR.

Result: kept. Cost is one additional runner for ~30 s.

Hypothesis: Several workflows still ran bare pnpm install, which (a) can mutate pnpm-lock.yaml on CI and (b) re-resolves from the registry even when the pnpm store cache is populated. Standardising on --frozen-lockfile --prefer-offline makes CI cache-friendly and fails fast on accidental lockfile drift.

Additional finding: .github/workflows/security-audit.yml ran pnpm install before pnpm audit. Measured locally — pnpm audit on an empty directory with only pnpm-lock.yaml + package.json takes ~2 s, produces identical results. The install step is pure waste here (15 s on warm cache, up to 127 s cold).

Implementation:

Measurement: Security-audit saves ~15–127 s per run. The other workflows gain cache hits on subsequent runs once the pnpm store is warm.

Result: kept.

Hypothesis: lint-go.yml downloads the ~100 MB GGUF model before running golangci-lint. Linting doesn't run tests, so it shouldn't need the weights.

Finding: backend/llm/backends/llamacpp/llamacpp.go:25 contains //go:embed models/*.gguf. go:embed is a compile-time directive and golangci-lint type-checks Go source, so some file matching models/*.gguf must exist. However the file does not need to be the real multi-hundred-megabyte weights; any non-empty file satisfies the directive.

Decision: deferred. The fix is to drop a stub .gguf file into backend/llm/backends/llamacpp/models/ from CI only for lint, instead of pulling 100 MB. Risk: if golangci-lint grows a future analyser that reads the embedded bytes, the stub breaks it. Worth a focused PR with owner review; not rolled up here.

Result: noted for follow-up, not applied.

Hypothesis (bug hunt): The reusable composite action ci-setup/action.yml has three actions/cache steps — Ubuntu / macOS / Windows. The macOS one was gated on startsWith(inputs.matrix.os, 'macos') which is not a valid expression for a composite-action input. The correct accessor is inputs.matrix-os. Because the condition always evaluated to null → false, macOS runners (which dominate the desktop release matrix) never used the Go build cache at all.

Implementation:

Result: kept. Direct effect is a big speedup on macOS desktop builds because the Go cache now actually restores; indirect effect on every runner that uses the action (better cache backend, correct Node).

Hypothesis: pnpm install --ignore-scripts skips postinstall for better-sqlite3, canvas, electron, sharp, fs-xattr, etc. The lint, typecheck, unit-tests web, and unit-tests shared matrix legs don't import any of those native modules at test time, so installing them is wasted CI time.

Experiment:

Analysis: Sandbox measurement understates the real CI saving because canvas fails to build here (no gyp toolchain) and better-sqlite3 is quick on this machine. In real CI the saving from skipping those builds is probably 20–40 s per job. But without a measured number I can't justify the configuration complexity (a matrix-leg-specific install flag, risk of someone importing better-sqlite3 from @shm/web tests in future).

Result: discarded. Revisit once we have CI wall-clock data post-rollout to re-measure.

Hypothesis: integration-tests runs cd tests && pnpm test:install-browsers (which runs npx playwright install chromium). That downloads ~300 MB of Chromium every run. The e2e-tests / editor leg does the same with --with-deps. Caching ~/.cache/ms-playwright/ keyed on pnpm-lock.yaml (which the playwright pin lives in) avoids the download on cache-hit runs.

Implementation:

Measurement: Chromium ~300 MB @ typical GitHub Runner bandwidth downloads in 30–60 s. Cache restore of the same is usually < 10 s. Expected saving 20–50 s per run on the integration and e2e-tests jobs.

Result: kept.

Hypothesis: Adding --cache to every package's format:check script would make reruns fast.

Measurement: On @shm/shared, prettier --check --cache . cold = 9.3 s, warm = 3.0 s. ~6 s saved per package on repeat runs.

Problem: The cache lives in node_modules/.cache/prettier which is not persisted across CI runs. A GitHub-Actions-cached version would help, but caching inside node_modules/ is fragile (pnpm store restore can overwrite it) and the hit rate would be low because prettier keys the cache by content hash — a single file change invalidates its entry only, not the whole cache.

Decision: Deferred. Low payoff for the setup complexity and CI risk.

Hypothesis: The typecheck job runs pnpm -r --parallel run typecheck which compiles every workspace via tsc --noEmit. Most of the heavier packages (@shm/shared, @shm/ui, @shm/editor, @shm/desktop, @shm/client) already have incremental: true in their tsconfigs, with tsBuildInfoFile pointing to either <pkg>/tsconfig.tsbuildinfo or <pkg>/node_modules/.tmp/tsconfig.app.tsbuildinfo. But CI throws those files away every run, so the incremental benefit is lost.

Measurement: Locally (warm disk, no source changes):

Implementation: actions/cache@v4 step in the typecheck job, restoring all *.tsbuildinfo paths (both the in-tree and node_modules/.tmp/ locations). Key on ${{ github.sha }} so every run writes a fresh cache; restore-keys: tsbuildinfo-${{ runner.os }}- falls back to the most recent available cache on this branch.

Notes:

Result: kept. Requires first run on a branch before a cache exists; first-time cost is 0.

Hypothesis: The e2e-tests matrix had suite: [desktop, editor], but every desktop step was commented out with echo 'SKIP DESKTOP E2E FOR NOW.'. The job still spun up a runner, ran pnpm install, and echoed a string — ~30 s of runner time per PR for nothing.

Implementation: Shrink the matrix to suite: [editor] and delete the corresponding if desktop branches. Comment in the job preserves the reinstatement plan.

Result: kept. Direct runner-minute saving per PR and cleaner logs.