upilot: Instructions file for Codex

UPilot Repository Instructions

Release Workflow

• Before handling this repository's release, release-status monitoring, or release-failure diagnosis, read the relevant sections of Documentation~/Release.md. The runbook supplies procedures, not permission to publish, retry, change files, or delete tags; a diagnosis-only request remains read-only.
• Treat commands such as 发布版本 v0.3.22，并检查打包结果和版本号是否正确, 发布 v0.3.22, 触发发布版本 0.3.22, and semantically equivalent requests as explicit authorization to run the GitHub Actions workflow named 发布版本 from .github/workflows/prepare-release.yml.
• Use the requested semantic version after normalizing it to vMAJOR.MINOR.PATCH. If the user requests the next version without specifying a number, inspect existing tags and use the next patch version unless the user states otherwise.
• Trigger the workflow from main with gh workflow run prepare-release.yml --ref main -f version=<version>. Do not manually create or push the release tag, and do not manually maintain release versions in package.json or upilotserver~/pyproject.toml; the workflow owns those operations.
• Unity release evidence is optional. When -f acceptanceRunId=<runId> is supplied, verify its provenance, age and source identity; a missing evidence run must not block release dispatch. Do not substitute a local summary for explicitly supplied evidence. See Documentation~/UP001-UP009-Delivery.md for the optional evidence workflow and source C→R contract.
• Before triggering a release, verify that the intended release changes are committed and pushed to main. Do not include unrelated local changes without explicit authorization.
• Preserve the repository's established check policy: do not enable optional checks, disable required checks, or change strictness just to retry or diagnose a release without an explicit requirement. Never report a skipped, disabled, or unknown check as passed.
• After triggering, monitor both the 发布版本 run and its downstream Build UPilot MCP Server EXE run until completion. A successful dispatch alone is not a successful release.
• Before reporting release success, verify both workflow conclusions, the tag-to-build commit identity, the GitHub release and expected assets, and that the tag's package.json, upilotserver~/pyproject.toml, and release manifest.json versions match the requested version. Confirm the build's local EXE/manifest/checksum and --version verification passed before publication; observe the remote asset list, but do not claim to have verified downloaded EXE bytes unless that was separately done. Report run URLs, commits/tag, asset and local hash results, and any unverified item clearly. Packaging/release success is not Unity compilation, EditMode, or business acceptance: report only coverage backed by actual evidence.
• If either workflow fails or any version is inconsistent, do not report release success. Preserve the failure logs and identify the failed step and corrective action.
• Do not automatically delete, move, or recreate a remote tag or overwrite a Release after failure. Recovery requires appropriate user authorization; when a new release is authorized, prefer a new patch version over reusing a failed tag. If dispatch or publication is uncertain, inspect the original run, tag, and Release before considering another request; do not automatically redispatch.