[alpha.14] refactor(tools): autoflow/release.ts is 1887 lines — split release lifecycle phases

[SisyphusZheng]

Context

Found during deep code audit of tools/autoflow/release.ts.

Problem

tools/autoflow/release.ts is 1887 lines — the single largest file in the entire repository. It handles the full AutoFlow3 release lifecycle in one module:

1. Release policy resolution
2. Pre-publish checks (git clean, tag exists, ancestor verification)
3. npm view verification
4. Build step orchestration
5. Publish step orchestration (npm publish for each package)
6. Evidence collection (per-step)
7. Tag step orchestration (immutable tag, evidence commit)
8. Documentation version anchors update (VERSION_PLAN, STATUS, ROADMAP across 10+ files)
9. Release closure record writing
10. Resumption logic for partial-failure recovery

All 10 phases share one module-level state object and call each other directly.

Impact

• Bus factor critical: this file is the heart of the release pipeline; one 1887-line file is unmaintainable by anyone other than the original author
• Test friction: release.test.ts is 1013 lines and growing; testing one phase requires constructing the entire release context
• Resumption risk: if a release fails mid-pipeline, debugging which of the 10 phases failed requires reading the whole file
• Evolution blocked: adding a new release step (e.g., provenance attestation) requires touching the monolith

Proposal

1. Split along the 10 phases into separate modules:
   • release-policy.ts — phase 1
   • release-pre-checks.ts — phase 2-3
   • release-build.ts — phase 4
   • release-publish.ts — phase 5
   • release-evidence.ts — phase 6
   • release-tag.ts — phase 7
   • release-docs-sync.ts — phase 8
   • release-closure.ts — phase 9-10
2. release.ts becomes a thin orchestrator: imports the phase modules and composes them
3. Each phase has its own test file with phase-local fixtures
4. Shared types (ReleaseStepEvidence, ReleaseClosureRecord) move to release-types.ts

Priority

P3 — maintainability. Not a 0.42 blocker but blocks contributor onboarding to the release pipeline.

Audit reference

tools/autoflow/release.ts (1887 lines)
tools/autoflow/__tests__/release.test.ts (1013 lines)

[SisyphusZheng]

Partial progress in f618ed7 (main): release.ts 1887 -> 1511 lines. The version-anchor phase moved to tools/autoflow/version-anchors.ts (342 lines, including releaseTag as the neutral primitive to break the plan-builder import cycle), and the git/process wrappers moved to tools/lib/git.ts + tools/lib/process.ts. Remaining per the issue's phase-split proposal: policy resolution, pre-checks, npm verification, build/publish orchestration, evidence, tag, closure, resumption still live in release.ts.

[SisyphusZheng]

Deferred for this train (alpha.15) per the plan's own marking: "#907 remainder (optional, lowest priority)". The alpha.15 window was consumed by the higher-ranked WP3 splits (#908, #904, #901 — all shipped) and WP4 decisions. No code touched; file unchanged at 1511 lines. Re-queue for the next train when the phase split is wanted.

[SisyphusZheng]

Status from the v0.42.0-alpha.15-plan run (WP3, optional item): partial split already shipped — the module is down from 1887 → 1511 lines (policy.ts and version-anchors.ts extracted; tools/autoflow/ now holds cli/policy/release/version-anchors + __tests__). Tools suite is green (261 passed).

Deferral rationale (plan marks this optional, lowest priority): the remaining 1511-line monolith + 1013-line test file churn belongs to a quiet window between releases — not directly before the WP6 human checkpoint, where a mechanical 10-phase split adds regression risk to the release pipeline for zero behavior change. Recommended: take one phase module per commit in the first post-alpha.16 cycle, gated by deno test -A tools/ and a green AutoFlow release run.

Acceptance criteria are NOT fully met (file still 1511 lines), so the issue stays open with this status comment.

[SisyphusZheng]

Release-line conflict discovered while executing the v0.42.0-alpha.15 plan (2026-08-12): that plan is superseded by the alpha.16 line on main (974e945 bumped all version anchors to alpha.16; docs/release/v0.42.0-alpha.16-plan.md DRAFT covers #915-#943).

Status of the alpha.15 plan's ledger: 18/19 issues closed with evidence by the prior executor (all tagged [alpha.14], closed 2026-08-08). This issue (#907) is the only one still open — it was the WP3 optional, lowest-priority item ("release.ts 1887 lines, one phase module per commit") and is NOT scheduled anywhere in the alpha.16 plan.

Recommendation: either schedule #907 in an alpha.17 slot (after alpha.16 remediation closes) or close as wontfix with the deferral rationale — the 1887-line file is audit debt, not a defect. No code was written for it under the alpha.15 plan (stale).

[SisyphusZheng]

Superseded by ADR-0144 and #1156. The new objective is not to split a large custom release file while preserving all of its responsibilities; it is to offload generic governance and reduce AutoFlow to the irreducible OpenElement-specific release/evidence core. Any remaining lifecycle split belongs inside #1156 after the retirement matrix is proven.