Spec: V4-Only Repository Cutover

User Input

in @linear project https://linear.app/devpunks/project/harness-intelligence-23aceec78aca/issues we have new modules M7 M8 M9 for the refactor and re architecture around effect v4. so now please start a $delivery-phase FOR EACH SINGLE ONE of the EPICS. complete all epics and their inner stories with a delivery phase per epic

DO NOT MISS ON ANY OF THE STORIES

do this in full parallel. dont merge on main the subsequent pr

Context

Harness Intelligence must finish the accepted architecture as one coordinated Effect v4 product rather than ship a sequence of mixed-runtime intermediate states. Maintainers need a migration shape that keeps peer domains coherent, removes old and temporary architecture before release, and proves behavior from repository internals through packaged CLI/API products and representative consumers. This epic unifies IP-345 and IP-346 as the final M9 cutover contract.

Story Coverage

• IP-345: migrate breadth-first across peer architecture levels, move every Effect-dependent workspace together, keep all work on one unmerged and undeployed branch, and finish without old paths or migration scaffolding.
• IP-346: block merge and release until repository, workspace, public-output, packaged-product, adapter, renderer, operator, and fresh/existing consumer gates all pass.

Non-Goals

• Producing a deployable intermediate migration.
• Completing one domain vertically while peer domains remain on the old architecture.
• Keeping old imports or runtime paths alive for in-branch compatibility.
• Shipping a staged deployment, dual runtime, compatibility shim, feature flag, or v3/v4 translation layer.
• Waiving product-level proof because unit tests or a subset of workspace checks pass.
• Merging or releasing a partially verified architecture migration.

Acceptance Criteria

Breadth-first migration

• Deliberate public roots and dependency direction exist across every major domain before any one domain is completed vertically.
• Subsequent architecture levels progress across peer domains toward actions, services, repositories, adapters, and leaf behavior where applicable.
• Every Effect-dependent workspace moves as part of the same coordinated migration.
• Intermediate branch states may be broken and need not preserve old runtime paths or be deployable.
• All work remains on one unmerged and undeployed branch until the complete repository contract passes.
• No staged deployment, dual runtime, compatibility shim, feature flag, or v3/v4 translation layer ships.
• The final state contains no old architecture, compatibility alias, or temporary migration scaffolding.
• Rollback uses the prior known-good commit or release.

Complete repository and product gate

• The comprehensive repository suite passes.
• Every participating workspace passes its required static checks, typecheck, lint, and build validations.
• Every public-output characterization fixture passes according to its accepted byte-locked, semantically equivalent, or intentionally changed classification.
• No Effect v3 dependency, import, compatibility alias, shim, or temporary migration path remains.
• Packaged CLI command, help, plain, interactive, and JSON behavior passes.
• API protocol and handler behavior passes.
• Renderer catalog and operator lifecycle contracts pass.
• Isolated fresh-repository proof covers hi init and hi scaffold.
• Isolated existing-repository proof covers hi check and hi update, including preservation of user changes.
• Every required unavailable gate blocks completion rather than being waived.
• Merge or release occurs only after all required gates pass together.

Constraints

• At implementation start, the latest compatible Effect v4 beta and matching @effect/* set are selected, pinned to exact numeric versions in the shared catalog and lockfile, and held fixed until a deliberate repository-wide upgrade decision.
• IP-330 must characterize public behavior before IP-345 changes the owning architecture.
• IP-317 through IP-323 and IP-345 must all complete before IP-346 can declare the final gate satisfied.
• Migration follows the accepted breadth-first hierarchy and cannot be converted into vertical per-domain delivery for convenience.
• The coordinated branch may be internally broken, but it must remain unmerged and undeployed until all final evidence is green.
• Subsequent epic work and any eventual PR remain off main; no child epic is merged independently.
• Required unavailable evidence is a blocker, not a waiver candidate.

Dependency Readiness

• Status: Satisfied.
• Dependencies: IP-330 preceded IP-345; IP-317 through IP-323 and IP-345 preceded IP-346.
• Evidence: Live Linear verification on 2026-07-21 returned IP-317 through IP-346 as exactly 30/30 Done. IP-345, IP-346, and IP-324 were closed in that dependency order after the authoritative repository gate passed.
• Stack evidence: PR #76 is the parent. PRs #77–#83 and #87 are sibling children based on team/stefan/refactor-cli-architecture. Post-push stack status and stack sync --dry-run preserved that fan-out and reported the stack current, so no sync ran.

Review Status

• Spec status: Implemented on 83d0311aadd7cc93a5f5393902fb0d97645eaefb.
• Validation: The exact root behavior contract passed 15/15 tasks; the CLI passed 743/743 tests; GitHub behavior-contract run 29849467229, job 88698354582, passed in 5m27s.
• Content and independent review: Passed with no blocking or actionable findings after the final JSON bootstrap-stream repair.
• Delivery boundary: Draft PR #87 remains open, unmerged, and undeployed. No merge, release, or deployment is part of this completed delivery phase.
• Open questions: none.

Decision Log