Distillation

Date: Jul 28, 2026

• 🔴 (12:27) User stated scripts/notarize.cjs is dead code in getsentry/spotlight — electron-builder notarizes internally via its afterSign hook using @electron/notarize, never calls scripts/notarize.cjs. When debugging Apple notarization failures, check build.yml's Apple key decode/export steps and electron-builder's config, not this file.
• 🔴 (12:27) User stated they always request adversarial, evidence-based correctness reviews for infra/dependency PRs — explicitly scoping out style/cosmetic feedback. Reviewer must: (1) verify claims empirically rather than trust the diff at face value (check lockfile resolution, test builds, decode/inspect actual secrets or config), (2) enumerate specific concrete risk points (shell script edge cases, version resolution conflicts, security implications), (3) reproduce/test only in a scratch directory (/tmp/opencode) without touching tracked files when experimentation is needed, (4) provide root-cause-level investigation (bisecting versions, reading source code, ruling out hypotheses with evidence) rather than surface-level analysis.
• 🔴 (12:27) User stated they always verify real production behavior (log output, not just exit codes) and keep changes atomic and reviewed with skepticism. They require empirical reproduction of edge cases in an isolated scratch directory (e.g. /tmp/opencode) with throwaway test data—never touching tracked files—before merging. After merging, they follow up explicitly to confirm the actual CI run succeeded end-to-end (not just 'job passed' but that the specific mechanism, e.g. notarization, actually executed and succeeded for all variants/architectures). User also enforces splitting unrelated changes (e.g. dependency version bumps) into separate PRs, keeping fix PRs narrowly scoped. When assistant proposes optional/secondary improvements, user expects them raised explicitly for a yes/no decision rather than bundled in.
• 🔴 (12:27) User stated they always require an independent, adversarial correctness verification pass before merging build/dependency PRs (electron-builder upgrades, notarization/signing changes, dependency override fixes) — not just relying on CI green checks. Verification must include: (1) tracing actual dependency resolution in the lockfile to confirm which transitive versions are used at runtime, (2) reading the relevant node_modules source to verify code paths (e.g., signing/notarize logic) rather than assuming behavior, (3) cross-checking env var names between CI workflow jobs and consumed scripts/libraries, (4) explicitly noting CI gaps (e.g., macOS build job only runs on push to main, not PRs) as residual risk, (5) independently reproducing build failures/fixes locally (e.g., pnpm build:mac) rather than trusting a plain pnpm build. Assistant should proactively perform this deep verification, produce a todo list covering these checks, and give an explicit SAFE-TO-MERGE/NOT-SAFE verdict with cited evidence before recommending merge.