菜单
Validate a 6529-core Electron desktop update on Windows with secure installs, renderer and Electron type/build checks, local package creation, artifact inspection, and Windows-specific environment constraints. Use when Codex needs to test or package the 6529 Electron app before a PR or release.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Open and iterate a 6529-core Electron desktop update pull request after local renderer sync and Windows build validation, including branch hygiene, PR body evidence, GitHub checks, review-bot comments, and follow-up fix commits. Use when Codex is asked to raise or shepherd a desktop update PR until CI and bots are satisfied.
Own scoped 6529 frontend workstreams end to end. Use when Codex is asked to act as a manager, workstream owner, PR owner, review-feedback owner, release/staging/prod coordinator, ops/skills package owner, or autonomous implementation lead for the 6529seize frontend repository.
Merge and deploy 6529 frontend or coordinated frontend/backend releases through staging and production with explicit approval gates, GitHub Actions or repo-approved deploy paths, staging and production E2E/smoke validation, autonomous failed-gate recovery, rollback or fix-forward handling, and coordination with other active Codex agents. Use when Codex is asked to merge PRs, deploy to staging, validate staging, promote to production, validate production, recover from failed deploy/E2E, or coordinate a 6529seize-backend deployment with frontend release work.
Sync the 6529 web frontend into the 6529-core Electron renderer subtree, preserve desktop-only behavior, resolve pull-web conflicts, update duplicated desktop config, and bump the desktop version. Use when Codex is asked to bring the Electron desktop app up to date with recent or current 6529.io frontend changes.
Write, open, iterate, and prepare pull requests for merge or deployment with clear PR descriptions, safe validation notes, review-bot follow-up, signed commits, readiness gates, and deployment handoff notes. Use when preparing PR bodies, creating PRs, responding to CodeRabbit or Claude review bots, deciding whether a PR is ready, or preparing a PR for merge, staging, or production rollout; use deploy-6529 for actual deployment execution.
| name | test-desktop-build |
| description | Validate a 6529-core Electron desktop update on Windows with secure installs, renderer and Electron type/build checks, local package creation, artifact inspection, and Windows-specific environment constraints. Use when Codex needs to test or package the 6529 Electron app before a PR or release. |
Validate that the merged renderer can run through the desktop build path on this Windows EC2 Codex host.
The repo's install:secure scripts are the authority, but the Bash wrapper can fail on this Windows checkout. If that happens, run the same guarded pieces directly:
$env:SEIZE_6529_COMMAND='1'
node scripts/assert-no-package-lock.cjs
node scripts/run-secure-pnpm.cjs install
Then install renderer dependencies through the root renderer runner. It sets SEIZE_6529_COMMAND=1 and uses Git Bash as npm's script shell on Windows, which renderer scripts need for rm, mv, and bash:
$env:SEIZE_6529_COMMAND='1'
node scripts/run-renderer-pnpm.cjs run install:secure
Run the smallest checks that prove the merge contract first, then broaden. If the worktree may contain old generated artifacts, clean before standalone type checks; renderer/out/types can otherwise be picked up by broad TypeScript includes and report stale Next validator errors.
$env:SEIZE_6529_COMMAND='1'; pnpm run clean-win
$env:SEIZE_6529_COMMAND='1'; pnpm run build-env-schema
$env:SEIZE_6529_COMMAND='1'; pnpm run build-next-config
$env:SEIZE_6529_COMMAND='1'; pnpm run type-check
For renderer-specific tests, run from renderer/ with the same guard. Include tests near manually merged desktop files when they exist:
$env:SEIZE_6529_COMMAND='1'; pnpm run test:no-coverage -- __tests__/components/auth/Auth.test.tsx __tests__/components/ipfs/IPFSContext.test.tsx __tests__/config/securityHeaders.test.ts __tests__/config/nextConfig.test.ts
Use the Windows build script for local testing:
$env:SEIZE_6529_COMMAND='1'; pnpm run build-win
For a local Windows package, prefer a non-publishing package build after build-win. If signed IPFS binaries are needed, first run download-signed-ipfs; do not upload or sign unless requested.
$env:SEIZE_6529_COMMAND='1'; pnpm run download-signed-ipfs
$env:SEIZE_6529_COMMAND='1'; $env:CSC_IDENTITY_AUTO_DISCOVERY='false'; pnpm exec electron-builder --config electron-builder.production.json --win --x64 --publish never
If download-signed-ipfs is blocked by AWS credentials, document the blocker and still run build-win and an unsigned package path if possible.
Launch dist/win-unpacked/6529 Desktop.exe after packaging and inspect AppData\Roaming\6529-core\logs\main.log.
Require evidence for:
SCHEMA: true) without env.schema.runtime.cjs not foundNEXT SERVER: Ready on http://localhost:<port>IPFS] Daemon fully initializedMain window ready to showTerminate only the processes started by the smoke test after collecting evidence.
Record command results, package artifact paths under dist/, and any skipped checks with reasons in the PR body. Run codex-diff-check before commit.