Design and implement the multi-package release pipeline #519

1. Background Context

Source: git-warp #519. Audited against main 94b40dac64034cd8caab9bb05efe14a0c22bd735. Template: feature; work type: type:feature.

Current scope and disposition: Lock-step multi-package preflight, publication and version checks must exist before any private shell becomes a shipped dependency.

Additional source requirements/context:

Release model:

• One repo tag per release.
• All public package version fields equal the tag version.
• The release workflow publishes root plus every public workspace package from
  that single tag.
• Version lock is enforced across root and public workspaces.
• No per-package tag formats.

Work items:

• Extend release preflight to run package dry-runs for every public package.
• Extend publish workflow to publish every public workspace package from the
  same tag.
• Enforce lock-step versions across root and public workspace package files.
• Decide how JSR publication works for multiple packages before flipping a
  workspace package public.
• Update docs/method/release.md with the multi-package flow.

2. Problem Description

Lock-step multi-package preflight, publication and version checks must exist before any private shell becomes a shipped dependency.

Historical source report; the current disposition above supersedes obsolete claims:
The release machinery is still rooted in the top-level
@git-stunts/git-warp package. The workspace packages
@git-stunts/warp-orset, @git-stunts/warp-kernel, and
@git-stunts/warp-adapters exist, but they are private shells.

Before any workspace package can be flipped public and consumed by shipped root
code, release, preflight, tag guard, and version verification must support
publishing multiple packages from one repo tag.

2b. Proposed Solution

Lock-step multi-package preflight, publication and version checks must exist before any private shell becomes a shipped dependency.

2c. Alternatives considered and rejected

No additional alternatives are recorded as decided. Reject duplicate ownership, private-import escape hatches and a broken intermediate mainline; retain original alternatives below when present.

2d. Acceptance Criteria

• Lock-step multi-package preflight, publication and version checks must exist before any private shell becomes a shipped dependency.

2e. Test Plan

Golden: Validate a packed artifact and the declared release/publication outcome.

Edges: Missing workspace manifest, stale metadata, rerun and runtime/platform differences.

Known failure modes: Deterministic validation failure is not retried as a transport error or reported as publication success.

Fuzz and stress: Repeated clean Docker builds/dry-runs; registry publishing requires the separate release workflow.

All tests and benchmarks execute in COPY-based Docker containers without host repository or Git-directory mounts. This planning audit does not claim those checks were run.

3. Prerequisites

No unsatisfied open-issue prerequisite established by this review. This is not proof that an unresolved design or external readiness condition is satisfied.

4. Scope

In: Lock-step multi-package preflight, publication and version checks must exist before any private shell becomes a shipped dependency.

Source scope and exclusions:

• Moving ORSet, kernel, or adapter code.
• Flipping any specific workspace package public.
• Inventing per-package tags.

Safe intermediate state: the PR builds and passes relevant checks after its listed prerequisites; existing supported behavior remains usable. Any preparatory step must be independently mergeable.

5. Why now

Maintainer ordering: memory correctness first, supported attachments next, then land eligible PRs. Preserve this card’s existing priority unless a separately recorded scope decision changes it.

6. Risks

Main risk: implementing the historical description instead of the current runtime contract. Preserve compatibility, causal/ownership invariants and bounded behavior relevant to release.

7. Definition of Done

The issue-specific acceptance checks pass, relevant validation evidence is attached, and the issue links the coherent PR and resulting mainline integration commit. No open item is hidden in a later repair PR.

8. Stakeholders

James Ross: maintainer, assignee and acceptance owner. Package consumers and release maintainers rely on reproducible published artifacts.

9. Related Issues

• Blocks completion of #517: Publishing root imports of warp-orset requires multi-package release, dry-run and lock-step version support.
• Blocks completion of #516: Kernel publication consumes the lock-step multi-package release pipeline directly, in addition to the published ORSet dependency.
• Blocks completion of #515: Adapter publication consumes the lock-step release pipeline directly, in addition to the published kernel.

Source (source record):
Rehomed from archived v17 residual note
INFRA_multipackage-publish-pipeline. The old TS_publish-pipeline blocker is
not carried forward; root package release preflight exists, and this is the
future multi-package successor.

Historical paths, counts, release names and shell examples in source material are evidence to reconcile, not authority to restore retired documentation or run host tests.