kenyang/loong-workflow
1
0
Fork 0
forked from Octopus/octopus-workflow
Code Pull Requests Activity

v0.1.4: audit remediation export — release skill hardening (batching rule refs delinked, cross-refs fixed, role names registered) + #4786 round-budget three-tier ladder + STD 8.8 audit item + image-interpret/checklist sync

Browse Source
This commit is contained in:
fourbroad
2026-09-19 14:51:48 +08:00
parent 4518f41fd4
commit d6567b1842
8 changed files with 58 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
core/skills/release/SKILL.md
+31 -28
View File
@@ -1,12 +1,11 @@
---
name: release
description: >
Use ONLY when ready to cut a release. The Release Manager (Worker) inspects
Use ONLY when ready to cut a release. The Producer (Worker) inspects
project state (git log, version files, build) to determine the semver bump,
generate the changelog, tag, and produce a release artifact. Works on any
project state — no pipeline artifacts required.
triggers:
- release
- cut release
- 发版
- publish release
@@ -14,7 +13,6 @@ triggers:
role: Producer
---
> Core 中立版（Increment 6a 改写，原 deferHard verbatimDir）。机制、结构与 frontmatter 保持；实例术语（工具名、路径、工单号）按 `core/adapters/TERMINOLOGY.md` 绑定到具体实例。
# Release
Prepare and tag a release based on project facts — git history since the last
@@ -28,14 +26,14 @@ produced here is the input to project-specific deployment workflows.
## Agent Role
The release is owned and executed by the **Release Manager** (Worker).
The release is owned and executed by the **Producer** (Worker).
**Context compaction**: release is a pipeline stage boundary. The main session
compacts at this clean boundary ONLY when a capacity/projection trigger holds,
per `core/rules/compact.md` §"Stage-boundary compaction" (long multi-stage
per `.octopus/rules/compact.md` §"Stage-boundary compaction" (long multi-stage
runs — DAG Epic orchestration — keep the legacy every-boundary compaction;
short runs — bugfix / DAG task — and standalone runs default to NOT
compacting). The Release Manager itself is single-phase and
compacting). The Producer itself is single-phase and
artifact-driven (version files, changelog, tag); a mid-run compaction loses
nothing — re-read the release checklist state and git log to resume.
@@ -46,7 +44,7 @@ nothing — re-read the release checklist state and git log to resume.
Before starting the release:
- [ ] Working tree is clean (`git status` has no uncommitted changes).
- [ ] `core/checklists/release.md` is accessible.
- [ ] `.octopus/checklists/release.md` is accessible.
---
@@ -65,7 +63,7 @@ Run each check against the live project. Stop and report failures.
- No new HIGH or CRITICAL CVEs block the release.
- Pre-existing HIGH/CRITICAL CVEs do NOT block but **MUST be filed as
tech-debt** before the release lands. File them in TWO TIERS (batching
rule, [org-internal #3846] — a single release audit once fanned out to 14 TDs → 14 PRs →
rule, [org-internal #3846] — a single release audit once fanned out to 14 TDs → 14 PRs →
56-84 CI runs on a saturated runner pool): Tier A below is the general
mechanical-change batching rule; Tier B and the escape hatch follow it.
@@ -86,7 +84,7 @@ Two source types today: (a) dependency bump audits; (b) docs 批量修订
- **(a) Dependency bump audits** (the [org-internal #3846] origin case): advisories whose
remediation is a plain version bump (lockfile-only diff, no semver-major
jump, no overrides/catalog surgery, no API or adapter fallout) are filed
together via `工单 API（见 TERMINOLOGY）create` with
together via REST `POST .../issues` with
`title="[{origin}] audit-batch@{version}: mechanical bumps for {N} advisories (TD-{NNN})"`
and labels `[tech_debt_label_id, severity_label_id, kind_bug_label_id]`
(severity = highest in the batch). One row per advisory — CVE/GHSA ID,
@@ -101,7 +99,7 @@ Two source types today: (a) dependency bump audits; (b) docs 批量修订
`title="[{origin}] docs-batch: {class} revisions for {N} files"`, with one
row per file (path, correction, reason); same ONE-batch-PR landing.
- **Landing**: when members live on separate branches, compose the single
batch PR via the `land-batch` skill (`core/skills/land-batch/SKILL.md`
batch PR via the `land-batch` skill (`.octopus/skills/land-batch/SKILL.md`
— cross-branch batch composition, topology B). For dependency-bump
batches pass `batch-compose --convergent bun.lock` (script
`.gitea/scripts/batch-compose.ts`): the regenerable lockfile is exempt
@@ -110,14 +108,14 @@ Two source types today: (a) dependency bump audits; (b) docs 批量修订
#### 适用边界 / Applicability boundary
- **非mechanical（含判断成分的变更，不并单）** — items requiring judgment
- **非 mechanical（含判断成分的变更，不并单）** — items requiring judgment
(wording decisions, behavior/API changes, review-dependent edits) are
never batched; file each as its own issue.
- **路径重叠（batch 成员触碰相同文件 → 不并单；唯一豁免 =
可再生共享文件`bun.lock` 经batch-compose `--convergent` 收敛）** — the sole
可再生共享文件 `bun.lock` 经 batch-compose `--convergent` 收敛）** — the sole
path-overlap exemption is the regenerable shared lockfile under
`--convergent`; every other same-file collision stays un-batched.
- **semver-major 跳变 / overrides·catalog 手术 / adapter·peer 联动（→
- **semver-major 跳变 / overrides·catalog 手术 / adapter·peer 联动（→
Tier B 独立单，维持 per-package）** — these stay per-package Tier B
issues. Tier B and the escape hatch (below) survive this generalization
unchanged.
@@ -157,12 +155,12 @@ template and `_shared/gitea-write-patterns.md` Pattern 3.
| Check | Status |
| ----------------- | ----------------------------------------------------- |
| Clean workspace | ✅/ ❌ |
| Clean workspace | ✅ / ❌ |
| Branch | {branch name} |
| Build | ✅/ ❌ |
| Typecheck + Lint | ✅/ ❌ |
| Tests | ✅/ ❌(N passed, M failed) |
| Dependency audit | ✅/ ⚠️ N known CVEs (pre-existing) / ❌N new CVEs |
| Build | ✅ / ❌ |
| Typecheck + Lint | ✅ / ❌ |
| Tests | ✅ / ❌ (N passed, M failed) |
| Dependency audit | ✅ / ⚠️ N known CVEs (pre-existing) / ❌ N new CVEs |
```
If any gate fails except known CVEs, stop and report what failed.
@@ -309,7 +307,7 @@ credentials in the environment.
- `NODE_AUTH_TOKEN` — only if publishing to npm.
- `AUR_KEY` — only if pushing the AUR package.
- Docker logged in to the Gitea container registry:
`echo "$GITEA_TOKEN" | docker login <instance-registry-host> -u <user> --password-stdin`.
`echo "$GITEA_TOKEN" | docker login eightarms.net -u <user> --password-stdin`.
### Steps
@@ -323,7 +321,7 @@ credentials in the environment.
```bash
OCTOPUS_VERSION={version} OCTOPUS_RELEASE={release-id} \
GH_REPO=Octopus/octopus GITEA_TOKEN=<pat> \
bun <harness-package>/script/build.ts
bun packages/octopus/script/build.ts
```
`build.ts` attaches the 12 release assets to the draft release.
@@ -339,14 +337,14 @@ credentials in the environment.
4. **Undraft the release** (makes it public):
```bash
curl -fsS -X PATCH \
"<instance-base-url>/api/v1/repos/Octopus/octopus/releases/{release-id}" \
"https://eightarms.net/api/v1/repos/Octopus/octopus/releases/{release-id}" \
-H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" -d '{"draft": false}'
```
5. **Verify assets** — the release must carry 12 assets:
```bash
curl -sS "<instance-base-url>/api/v1/repos/Octopus/octopus/releases/tags/v{version}" \
curl -sS "https://eightarms.net/api/v1/repos/Octopus/octopus/releases/tags/v{version}" \
-H "Authorization: token $GITEA_TOKEN" | jq '.assets | length'
```
@@ -375,9 +373,14 @@ Document how to undo this release:
1. **Git rollback**:
- `git tag -d v{version}` (if not yet pushed).
- `git revert {commit_hash}` (if already merged).
- If the release includes DB migrations, confirm the `down` migration exists.
- If the release includes DB migrations, confirm the `down` migration exists
**when the project's migration tooling provides one**. This repo's Drizzle
convention is forward-only (`migration.sql` + `snapshot.json`, no `down`
files) — there, record the reversal plan (manual SQL / restore) or mark the
change irreversible instead of waiting on a `down` file that never comes.
2. **Data rollback** (if applicable):
- For each migration, confirm the `down` migration exists and has been tested.
- For each migration, confirm the `down` migration exists and has been tested
where the tooling offers one; otherwise document the manual reversal steps.
- If the release changes data format without a reversible migration, mark
`⚠️ IRREVERSIBLE DATA CHANGE`.
@@ -390,7 +393,7 @@ git tag -d v{version}
# or: git revert {hash}
### Data Rollback
- Migration `{name}`: down {exists / NOT FOUND}
- Migration `{name}`: down {exists / NOT FOUND / N/A — forward-only tooling}
- {additional risks}
### Rollback Triggers
@@ -419,7 +422,7 @@ git tag -d v{version}
**Version**: {old} → {new} (MAJOR / MINOR / PATCH)
**Tag**: v{version}
**Commits**: {N} since last tag ({feat} features, {fix} fixes)
**Typecheck**: ✅| Lint: ✅| Tests: ✅
**Typecheck**: ✅ | Lint: ✅ | Tests: ✅
### Changelog
@@ -435,13 +438,13 @@ git tag -d v{version}
**Deploy**: {manual step — "merge to main triggers CI", etc.}
**Rollback**: see Phase 5 above
**Next**: `core/skills/retrospective/SKILL.md` (optional — run on any project state)
**Next**: `.octopus/skills/retrospective/SKILL.md` (optional — run on any project state)
```
---
## References
- `core/checklists/release.md` — Release checklist
- `.octopus/checklists/release.md` — Release checklist
- Semver spec: https://semver.org
- Conventional Commits: https://www.conventionalcommits.org