使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/sociuu/sociuu-skills --skill sociuu-ship-hotfix开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
Sociuu Ship Hotfix
A hotfix ships one reviewed fix on top of the exact version running in Production without releasing unreleased work from the integration branch. All deployable Sociuu repositories share this release model; confirm job names in each repository's .gitlab-ci.yml before acting.
| Ref | Deploys |
|---|---|
Integration branch (poc; Prime main) | Staging, automatically |
| Release tag (each repository's series) | Demo automatically; Production through the manual <APP>/PRODUCTION job |
Prime releases two applications, HOUSTON and MYHUB; treat each as its own release.
The explicit request authorizes the steps below for the named fix and repositories, except the actions the release owner's own instructions control: pushing a tag, playing a Production job, writing to Production, merging, and the release policy mode. Where those instructions are silent, the mode is manual and the release owner confirms each one in chat. A failed release needs a new explicit decision to roll back or roll forward.
Procedure
- Scope. Identify the reviewed fix (MR or commits), its ClickUp task, and
every affected repository and application. Confirm its tests and review passed.
- Baseline. For each application, find the tag of the last successful
<APP>/PRODUCTION job and confirm it against the running version. Filter by job: Houston and MyHub share one permanent/production environment. If the integration branch has nothing unreleased beyond that tag, stop and use an ordinary release.
- Branch. In a task worktree, create
hotfix/<task-key>from that tag and
apply only the fix. Keep conflict resolution minimal and run the repository's focused tests.
- Merge-back MR. Open an MR from the hotfix branch to the integration
branch, noting any original MR it replaces.
- Collisions. Check that no other tag pipeline or Production deployment
is running, and ask the release owner to tell the team before tagging.
- Tag. Run
git fetch --tagsand push the next unused number in the
repository's series (see release contents) on the hotfix branch head; tags are never moved or reused. For several repositories, release providers before consumers (Apex before Fuse and Prime) unless the change requires another order.
- Demo. Wait for the Demo deployment and verify the fix and adjacent
behaviour on Demo. If Demo fails, stop before Production and report.
- Production. Record the error baseline, then play
<APP>/PRODUCTION
under the authority above. Verify the deploy chain, migrations, the fix and error monitoring with production checks before releasing the next application.
- Finish. Ask the release owner to close the team notice. After the
merge-back MR is merged, close any superseded original MR. Run sociuu-release-notes for the hotfix: it posts the task's release-note comment and, when the release owner wants one, writes the #dev_updates note. Then set the task to complete.
Report the exact tags, deployments, verification results, open MRs and any human action still required. A tag or a green pipeline alone is not a Production release.
