# Ict Engine Release Mirror CI

> Use when publishing ict-engine to the private release mirror, when GitHub Actions fails after publication, when a published tag needs correction, or when source repo and release mirror targets may be confused.

- Skill: `undermybelt/ict-engine-release-mirror-ci` (Agent Skill)
- Install (CLI): `npx skillmds@latest add undermybelt/ict-engine-release-mirror-ci`
- Raw SKILL.md: https://api.skillmd.com/api/skills/undermybelt/ict-engine-release-mirror-ci/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: undermybelt (https://skillmd.com/u/undermybelt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/undermybelt/ict-engine-release-mirror-ci

---


# ICT Engine Release Mirror CI

## Core rule

Publishing is part of verification. Local gates prove the export is worth publishing; the release mirror and its remote GitHub Actions prove cross-OS consumer safety. Do not stop at local green when the user's concern is whether another operating system will fail.

For `ict-engine`, the outward release target is `Undermybelt/ict-engine-release`. The source repo `Undermybelt/givenup-ict-engine` is provenance and development history, not the release surface.

## Use when

- User says release, publish, 发布, 发版, mirror, `ict-engine-release`, GitHub Actions failed after publish, run failed, cross-OS CI, correction release.
- A tag already exists and the remote release or CI is wrong.
- Local source checks pass but the release mirror may differ.
- Dirty shared checkout makes packaging or docs/runtime gates unreliable.

## Release loop

1. Re-read repo-local instructions and live handoff/TODO surfaces before touching files.
2. Protect the shared checkout: `git status --short`, stage exact files only, never `git add .` from a dirty `ict-engine` tree.
3. Build a clean committed export or clean mirror clone. Validate from that clean tree, not from a dirty working tree.
4. Run CI-equivalent local gates before publishing:
   - `python3 support/scripts/ci/check_docs_runtime_isolation.py`
   - release privacy audit with compact output and `release_blocking_hits=0`
   - `cargo fmt --check`
   - `cargo clippy --all-targets -- -D warnings`
   - `cargo test`
   - zero-config consumer smoke such as `provider-status --compact`, demo `analyze`, and `workflow-status` with a fresh `/tmp` state dir
5. Push source commits for provenance when appropriate, but publish releases, tags, and release notes on `Undermybelt/ict-engine-release`.
6. After publishing, verify the real remote state:
   - mirror `main` ref
   - tag object/peeled commit
   - GitHub release page or `gh release view`
   - GitHub Actions run conclusion
7. Treat flaky GitHub API/TLS/EOF polling as inconclusive, not as success or failure. Cross-check with `git ls-remote`, HTML release/run pages, and retries with short timeouts.

## If remote CI fails after publish

1. Inspect the exact remote run logs first; do not infer from local output.
2. Reproduce in a clean export/mirror clone with the same gate that failed.
3. Patch the source of the failure without weakening the gate.
4. Commit the fix in source if it belongs to source; then carry it into the release mirror.
5. Do not rewrite, move, or delete a published tag. Bump to a new patch version and publish a correction release.
6. Verify the new release tag and the new Actions run to `completed/success`.

Concrete precedent: `v0.1.5` mirror CI failed because `check_docs_runtime_isolation.py` caught a test fixture literal under `support/docs/plans/old.md`. The fix was to move that fixture literal to `support/docs/audits/old.md`, preserving privacy-audit coverage. The correction release was `v0.1.6`; `v0.1.5` was not rewritten.

## Mirror safety

- If mirror push rejects as non-fast-forward, preserve mirror history: fetch/clone the mirror, copy the clean export into it, commit normally, and push. Do not force-push unless the user explicitly asks and accepts history rewrite.
- Keep package-manager publication disabled unless the user explicitly changes policy. For Rust crates, `publish = false` remains a public-surface guard.
- Treat the mirror as public even if access is limited: run privacy/secret scans before release.
- Verify docs/runtime isolation in the exact exported tree. Local source may contain planning docs or fixtures that clean CI rejects.

## Required evidence

Final evidence must name:

- source HEAD commit and whether it was pushed
- release mirror repo, mirror `main` commit, and release tag commit
- release URL and Actions run URL
- local clean export path or clean mirror clone path
- local gates run and their pass/fail result
- remote Actions final conclusion
- if a previous tag failed, the old tag, reason, and correction tag

## Red flags

- Publishing to `givenup-ict-engine` when the task is an outward ict-engine release.
- Calling the job done after local checks without reading the remote mirror Actions result.
- Retrying local fixes while never publishing; that cannot reveal cross-OS CI failures.
- Rewriting a published failed tag instead of issuing a correction release.
- Trusting one failed API poll as the run conclusion.
- Running release packaging from a dirty shared checkout and assuming consumers see the same tree.

## Chinese triggers

`发布错仓库`, `发布到mirror`, `release mirror`, `ict-engine-release`, `givenup-ict-engine`, `GitHub Actions failed`, `run failed`, `发布后CI失败`, `跨OS CI`, `修复后发布`, `correction release`, `不要重写tag`, `发布才知道别的OSbug`.