[Release]: Bundle exact dependency wheelhouses in Candidate artifacts #76

Problem

Fresh post-#74 Candidate build 43041771738 / artifact 13865373311 authenticates and verifies completely, but clean native acceptance cannot install it because third-party dependencies are fetched later from a live package index on the acceptance host.

Two explicitly approved, isolated source paths failed before installation:

1. pypi.org / default-public timed out twice with zero final wheels;
2. pypi.tuna.tsinghua.edu.cn / user-approved lacked a matching locked distribution, again with zero final wheels.

Both attempts used null-config isolated pip, no ambient PIP_*/UV_*/proxy/configuration/credentials, transaction-owned staging/cache, strict hashes, and exact identity-bound cleanup. The Candidate archive digest and complete nine-asset checksum closure passed on both attempts. Continuing to rotate mirrors would be trial and error, while package installation, Skill/MCP discovery, Calculator acceptance, PR #29, #70 publication, and public-artifact acceptance remain blocked.

User outcome

An assigned independent acceptor downloads one exact commit/run/attempt-bound Candidate artifact, verifies its GitHub service digest and complete internal checksum closure, selects the exact wheelhouse for the approved acceptance environment, and installs every first- and third-party package fully offline. Clean native acceptance no longer depends on live package-index reachability or ambient package configuration.

Minimum sufficient design

Keep the existing Candidate artifact as the single acceptance unit and deepen its manifest/build contract:

• The same quality-gates.yml workflow run builds the four first-party wheels and universal strict-hash dependency lock, acquires every required third-party wheel for each exact acceptance target, and assembles one final Candidate artifact only after all target wheelhouses verify.
• Initial exact target matrix:
  • native macOS arm64, CPython 3.11, for OMP 18.18.3 acceptance;
  • native Windows x64, CPython 3.12, for the deferred Windows acceptance environment.
• Place target wheelhouses under distinct canonical paths such as wheelhouse/darwin-arm64-py311/ and wheelhouse/win32-amd64-py312/; identical universal wheels may be duplicated or content-addressed internally, but the public manifest interface exposes one deterministic file inventory per target.
• Acquire third-party wheels only through an explicitly fixed unauthenticated default-public source inside CI, with ambient package-manager configuration, credentials, proxy/source overrides, caches, targets, prefixes, and user/global configuration disabled without reading values.
• Use wheel-only, strict-hash acquisition. Never resolve or download any first-party AutoGenesis distribution from an index. No sdist, VCS, editable, installed-distribution, cache-hit, or dependency-resolution substitution is accepted.
• Emit a canonical target-wheelhouse manifest containing target key, Python implementation/version, platform/architecture, every normalized package name/version, filename, byte size, wheel tags, and SHA-256. Reject duplicate identity, missing lock entry, extra file, incompatible tag, unsupported target, hash mismatch, filename collision, or incomplete dependency closure.
• Include every wheelhouse file and wheelhouse manifest in the Candidate manifest and final SHA256SUMS; only SHA256SUMS excludes itself. Generate final checksums after all files and prompts are final.
• Preserve the exact canonical repository, workflow run ID, positive run attempt, head commit, attempt-qualified artifact name, unique artifact ID, unexpired state, and GitHub service digest external anchor. Internal checksums never replace that anchor.
• Candidate install prompt selects exactly one compatible target wheelhouse after host/Python proof, refuses unsupported or ambiguous environments, and performs only --no-index --no-cache-dir --find-links <verified-target-wheelhouse> --require-hashes --no-deps installation inside the approved disposable transaction.
• Candidate acceptance performs zero package-index, source, credential, or dependency-download network calls after the authenticated artifact is obtained.

This is one deep Candidate packaging Module: callers provide the authenticated artifact and exact host/Python facts; the Module owns dependency completeness, target selection, provenance, and offline installation.

Deferred by design

• No public dependency mirror, proxy, package cache, credential store, or new package manager.
• No public release wheelhouse or change to normal public PyPI installation in this issue.
• No Runtime, MCP tool/schema, Skill-discovery, application, Appium Driver, OMP, or generated-write behavior change.
• No Linux/WSL support, new platform, Python support expansion, or compatibility claim from wheelhouse availability alone.
• No retry/fallback source list. A failed CI source or incomplete target fails the Candidate build.

Scope

• Candidate workflow job ordering and same-run intermediate/final artifact handling.
• Candidate dependency-wheelhouse acquisition, target manifests, complete checksum closure, and final artifact verification.
• Candidate install-prompt text needed to prohibit acceptance-host dependency downloads and select one verified target wheelhouse.
• Focused builder/verifier tests, negative provenance/substitution cases, and clean built-artifact install checks on the two exact target environments.
• Technical Candidate documentation and exact identity pins only if authenticated Contract bytes change.

Non-goals

• No package, GitHub Release, MCP Registry, documentation-site, or root README publication.
• No merge, protected-branch/settings/environment/trusted-publisher change.
• No source credential read, storage, output, or redaction-after-reading fallback.
• No change to AutoGenesis 1.1.1 Skills Preview technical versions: Agent Contract 2.1.0, Appium Runtime 0.5.0, Windows Runtime 0.5.0, CLI 0.2.0, tag agent-contract-v2.1.0.
• No claim that a wheelhouse-only install proves Skill discovery, MCP readiness, Calculator/Notepad behavior, recording safety, or client/platform qualification.

Interfaces affected

• .github/workflows/quality-gates.yml Candidate job graph and final artifact contents.
• agent-contract/tools/build_candidate_release.py Candidate manifest/verifier interface.
• Candidate-specific install prompt and tests.
• Candidate artifact layout gains target wheelhouse directories plus one canonical wheelhouse manifest per target.

The public Release artifact interface and normal package coordinates remain unchanged.

Acceptance scenarios

Scenario: One same-run Candidate contains complete target wheelhouses
  Given exact first-party wheels and a universal strict-hash dependency lock were built from one clean commit
  When the Candidate workflow assembles the final artifact
  Then both exact target wheelhouses are present
  And every locked dependency required by each target has exactly one compatible wheel
  And every wheel identity, filename, tag, size, and SHA-256 is recorded
  And no first-party package came from an index
  And the final Candidate manifest and SHA256SUMS cover every final file

Scenario: Clean macOS acceptance installs without a package index
  Given the acceptor verified the exact run, attempt, commit, artifact ID, service digest, manifest, and complete checksums
  And the host is native macOS arm64 with CPython 3.11
  When the Candidate prompt selects the macOS wheelhouse
  Then all packages install from verified local wheels with no index, cache, resolution, sdist, VCS, or editable source
  And no package-source credential, configuration, or network request is required
  And installed distribution metadata and pip check match the Candidate lock

Scenario: Clean Windows acceptance installs without a package index
  Given the same authenticated Candidate on native Windows x64 with CPython 3.12
  When the Candidate prompt selects the Windows wheelhouse
  Then the same offline and exact-identity requirements pass for that target
  And wheelhouse availability alone is not reported as Windows journey qualification

Scenario: Incomplete or substituted wheelhouse fails closed
  Given a wheel is missing, extra, renamed, hash-changed, tag-incompatible, duplicated, from another run/commit/target, or replaced together with a self-consistent internal manifest
  When Candidate verification or installation begins
  Then the external run/artifact anchor or complete internal closure rejects it before package installation
  And no fallback index, alternate target, cached wheel, installed distribution, or source build is used

Scenario: Rerun cannot mix attempts
  Given a later workflow attempt exists
  When final Candidate assembly consumes intermediate artifacts
  Then every intermediate and final artifact is bound to the same repository, run ID, run attempt, head commit, target, lock digest, and first-party wheel set
  And cross-attempt, cross-run, cross-commit, or stale artifact reuse fails closed

Scenario: Existing installation security boundary remains enforced
  Given the authenticated Candidate is complete
  When the Agent plans installation
  Then the exact private-parent/random-path/approval/atomic-reservation/exclusive-lock/identity-marker lifecycle from #74 remains unchanged
  And cleanup removes only still-matching prompt-owned state
  And the same-OS-user residual threat remains explicit

Required verification

• Builder tests for deterministic target manifests, normalized identities, compatible wheel tags, exact lock closure, first-party exclusion, duplicate/missing/extra wheel rejection, and complete SHA256SUMS coverage.
• Negative tests for self-consistent substitution, wrong target, wrong Python/architecture, cross-run/attempt/commit artifact mixing, stale intermediate artifact, sdist/VCS/editable input, cache substitution, and index fallback.
• CI syntax plus an executable final-artifact install on native macOS arm64 / Python 3.11 and native Windows x64 / Python 3.12 using an empty package cache, null pip config, --no-index, strict hashes, and no editable/source checkout.
• A network-denied install proof after artifact download, demonstrating zero package-index/DNS/HTTP access during venv installation.
• Exact installed distribution inventory, metadata, pip check, canonical Skill bytes, and Contract identity from the final Candidate.
• Independent correctness and security review. The implementer cannot approve the change.
• After merge, a new exact-main Candidate and separate native-macOS acceptor must resume the blocked [Documentation]: Publish AutoGenesis 1.1.1 Skills Preview onboarding #28/[Release]: Publish AutoGenesis 1.1.1 Skills Preview atomically #70 direct, exact-BDD, recording-preview, schema-boundary, and cleanup journeys. Existing run 43041771738 becomes historical build/blocker evidence, not acceptance for the changed Candidate.

Security impact

This moves third-party acquisition from the acceptance host into the authenticated Candidate build. It reduces acceptance-host network and credential exposure but increases the final artifact's supply-chain responsibility. Therefore the workflow must fail closed on source drift, target incompleteness, cross-job provenance mismatch, unreviewed source/configuration, or any file outside the strict lock and target manifests. Logs and evidence may include sanitized source host/class, package names, versions, filenames, tags, sizes, and hashes; never credentials, full credential-bearing URLs, ambient configuration, raw untrusted diagnostics, or local user paths.

Rollback

Before merge, revert the issue branch. After merge but before publication, revert the Candidate wheelhouse change and return #28/#70 to blocked; do not cite or accept a wheelhouse Candidate. Candidate execution rollback remains #74 identity-bound cleanup of exact prompt-owned roots and state. No public identity is exposed by this capability. If authenticated Contract bytes change, revert the Contract manifest and every exact consumer pin atomically.

Dependencies and ownership

• Blocks [Documentation]: Publish AutoGenesis 1.1.1 Skills Preview onboarding #28 / PR Publish AutoGenesis 1.1.1 Skills Preview onboarding #29 clean Candidate acceptance and merge.
• Blocks [Release]: Publish AutoGenesis 1.1.1 Skills Preview atomically #70 publication and public-artifact acceptance.
• Depends on merged [Security]: Harden generated install prompts and checksum closure #74 installation threat boundary and [Capability]: Make AutoGenesis 1.1.1 Skills Preview publication resumable #71 same-run provenance controls; neither may be weakened.
• One implementation owner controls quality-gates.yml, Candidate builder/prompt/verifier, focused tests, and any changed exact pins in one isolated worktree.
• Root README.md and PR Publish AutoGenesis 1.1.1 Skills Preview onboarding #29 media remain owned by Onboarding and are out of scope.
• Independent combined correctness/security review is required. A separate clean built-artifact acceptor is required after merge.

Task sizing

Appropriate: one independently observable result—an authenticated Candidate installs its exact dependency set offline on the two declared acceptance targets. Workflow, manifest, prompt, tests, and clean install proof are inseparable layers of that behavior and form one revertible boundary. No intermediate product decision or public interface version change is required.

Definition of Ready

• Observed failure and expected user outcome are explicit.
• Exact target environments and artifact/provenance interface are frozen.
• Source, secret, first-party exclusion, checksum, rerun, and cleanup boundaries are explicit.
• Acceptance scenarios cover positive installs and substitution/incompleteness failures.
• Scope, non-goals, deferred work, ownership, dependencies, rollback, review, and post-merge acceptance are explicit.
• Technical versions remain frozen unless authenticated Contract bytes force atomic pin regeneration.
• No product decision remains for the implementer.