release: publish a sanitized Robot SF v0.0.6 software package

[ll7]

Archetype Metadata

archetype: preflight
evidence_tier: blocked
linked_policy:
  - docs/maintainer_values.md
  - docs/RELEASE.md
  - docs/context/artifact_evidence_vocabulary.md

Goal / Problem

Publish the next full Robot SF software release as a sanitized v0.0.6 release from one
immutable source commit. The intended public surfaces are an immutable Git tag, GitHub software
Release, installable wheel and source distribution, a package-index release, and a fresh
software-only Zenodo concept/version.

This is separate from both the published S30/H600 benchmark dataset and the held 0.0.5
evidence-bundle route. 0.0.5 must not be repurposed: #7320 and #7409 prohibit its software tag
and GitHub Release while its exact artifact-only rights rows remain blocked.

Planning baseline at issue creation: 28fa8acb5474a728b2f3ce0c75dba92a2e2006a4. This is not the
final candidate. Freeze the release SHA only after the release-contract changes below merge and
the exact source is green.

Scope

• In scope:
  • version/tag v0.0.6, curated changelog, citation and software metadata;
  • sanitized Git/source-archive, wheel, and source-distribution membership;
  • explicit supported Python/platform/extra matrix;
  • every installed console entry point;
  • strict asset, model, dependency, companion, notice, and provenance gates;
  • protected TestPyPI/PyPI trusted publishing with attestations;
  • GitHub software Release and fresh software-only Zenodo concept/version;
  • cold download/install and byte-identity verification.
• Out of scope:
  • benchmark-data publication or benchmark claims;
  • model/checkpoint publication or inferred weight rights;
  • reusing the mixed Zenodo concept or the benchmark-only concept;
  • weakening a rights gate to preserve the current broad source tree or extras.

Current Status

NO-GO at the planning baseline. Exact audit evidence is stored at
/home/luttkule/.codex/agent-artifacts/dual-release/software-audit/.

• Clean simulated 0.0.6 wheel/source-distribution builds and notice checks pass.
• Only one of twelve installed console entry points loads successfully.
• Ten asset-rights families (42 tracked paths) remain blocked; the built source distribution
  contains four blocked example assets.
• Twenty-four model-registry rows lack licensing mappings; source-tag archives still expose model
  bytes unless the release surface is sanitized.
• Strict dependency inventory reports unresolved or policy-pending rows; the ORCA companion is not
  publicly installable as a properly versioned supported package.
• No TestPyPI/PyPI project or protected trusted-publishing workflow exists.
• The generic tag workflow does not yet compose strict release-content, entry-point, rights,
  dependency, Software Bill of Materials (SBOM), and attestation gates.

Execution Plan

1. Repair and test every declared wheel console entry point.
2. Define a sanitized release-tree/archive contract. Remove, externalize, or obtain exact rights
   evidence for every blocked asset/model byte on the selected source, wheel, source-distribution,
   GitHub, and Zenodo surfaces.
3. Freeze the supported dependency/extra/companion matrix. Narrow unsupported surfaces explicitly;
   do not silently omit failures.
4. Add one deterministic software-release preflight and a protected trusted-publishing workflow
   that builds once and promotes byte-identical artifacts.
5. Curate v0.0.6 changelog, citation, creator, licence, project URL, install, DOI, and known-limit
   metadata. Preserve 0.0.5 as an unpublished held evidence-bundle preparation.
6. Freeze one exact candidate SHA; run full pull-request readiness, version/content/rights gates,
   Python 3.11–3.13 cold installs, all supported extras, console scripts, metadata checks, hashes,
   SBOM, and provenance attestations.
7. Rehearse a correctly versioned prerelease on TestPyPI only after the version convention is PEP
   440-safe. Never upload rc0.0.6, which current tooling resolves as final 0.0.6.
8. After explicit final approval, create immutable v0.0.6, stage identical artifacts in GitHub
   and a fresh software-only Zenodo draft, publish to PyPI, then independently retrieve and install
   all channels before declaring success.

Definition of Done

• All declared console scripts load and --help succeeds from a clean wheel install.
• Selected wheel/source-distribution/tag-source members contain no blocked asset/model rows.
• Strict asset, model, dependency, companion, notice, and archive-member gates pass.
• Every claimed Python/platform/extra installs from public indexes only.
• Exact candidate CI, CodeQL, package matrix, release preflight, and PR readiness are green.
• v0.0.6, package metadata, CITATION.cff, changelog, and Zenodo metadata agree.
• GitHub, PyPI, and fresh software-only Zenodo artifacts are byte-bound to one build receipt.
• Independent cold download/install reports verified_zero_violations.
• release: evidence-freeze 0.0.5 after the missed 0.0.4 cutoff #6149/release: publish and independently verify 0.0.5 #6155/release-op(6155): publish immutable 0.0.5 tag, GitHub Release, and Zenodo version #7320/release-verify(6155): independently retrieve and verify published 0.0.5 artifacts and DOI lineage #7321/decision-required: clear exact 0.0.5 artifact-only rows before Zenodo deposit #7409 receive a transparent no-reuse/supersession record.

Stop Rules

• Stop on any unresolved shipped-byte right, unclassified archive member, console-script failure,
  unsupported claimed extra, version drift, non-green exact-source gate, hash mismatch, or stale
  metadata.
• Do not publish a model, checkpoint, dataset, dependency archive, or companion without its own
  exact distribution authorization.
• After any public channel accepts a version, never overwrite it. Correct forward with a new
  version and record partial publication as failed.

Validation / Testing

BASE_REF=origin/main PR_READY_MODE=final scripts/dev/pr_ready_check.sh
uv run python scripts/tools/check_asset_rights_inventory.py --json
uv run python scripts/tools/check_dependency_license_inventory.py --fail-on-unresolved
uv run python scripts/tools/publish_model_registry_release.py --validate-licensing
uv run python scripts/dev/check_version_alignment.py
uv run python scripts/validation/check_zenodo_release_metadata.py
uv build --out-dir dist
uv run python scripts/tools/check_distribution_licenses.py dist
bash scripts/validation/wheel_install_smoke.sh 'dist/robot_sf-*.whl'

The final gate must additionally inspect every source/wheel member, invoke every console script,
verify the SBOM/attestations, and cold-install through the selected public package indexes.

Effort / Risk

• Fastest truthful sanitized/narrow release: 4–10 working days (about 75% confidence).
• Retaining all current assets, models, and extras: 2–6+ weeks because external rights evidence
  dominates.
• Publication after all gates are green: 2–4 hours plus independent verification.
• Functional and legal/release risk: high; fail closed and prefer a narrower supported surface.

Parent / Dependencies

• Held historical lane: release: evidence-freeze 0.0.5 after the missed 0.0.4 cutoff #6149, release: publish and independently verify 0.0.5 #6155, release-op(6155): publish immutable 0.0.5 tag, GitHub Release, and Zenodo version #7320, release-verify(6155): independently retrieve and verify published 0.0.5 artifacts and DOI lineage #7321, decision-required: clear exact 0.0.5 artifact-only rows before Zenodo deposit #7409.
• Asset rights: licensing: inventory maps, media, examples, and data rights before release #7299.
• Model rights: licensing: obtain rights evidence for detached model releases #6855.
• Dependency policy: release: add reproducible dependency license inventory for optional extras #7298.
• Child implementation issues will cover wheel entry points, sanitized archive membership,
  supported dependency/ORCA surfaces, release preflight/trusted publishing, and metadata.

Project Metadata

• Priority: highest release lane
• Effort: 32–80 engineering hours plus maintainer/account operations
• Reviewed: 2026-08-30 audit at 28fa8acb5474a728b2f3ce0c75dba92a2e2006a4

schema: goal_autopilot_preparation.v1
repository: ll7/robot_sf_ll7
issue: 8017
source_body_sha256: ef95dff3451c4c70440474753a0b7e0704cc32ffa9dd647a0c87d2c793b8fc72
source_comments_sha256: 
audit_schema: open_issue_contract_audit.v1
audit_digest: 3f3c51addec2c0ac8aad5ca07f84a63669ce53bf2603a0919267fd1bd198b7c6
audit_classification: parent
next_action: split_or_select_bounded_leaf
authority: parent_owner
execution_mode: decomposition
preferred_worker: MaxRunner
expected_pr_runner_label: runner:max
implementation_admitted: False
state_ready_change_proposed: False
mutation_batch: open-issues-authority-final-20260831-b

This packet is preparation evidence only. It never overrides live labels, exact claim state, branch state, typed dependencies, domain gates, compute authority, release authority, or scientific evidence rules.

[ll7]

Orchestration update — 2026-08-30

The independent release audit is complete. The current candidate is NO-GO; the next software release remains v0.0.6 and must not reuse v0.0.5.

Implementation graph:

• bug: make every shipped wheel console script pass a clean-install smoke #8022 — clean-install console-script and wheel-smoke contract (started in a dedicated worktree; PR only, no merge)
• release: enforce a sanitized v0.0.6 archive member and rights contract #8020 — sanitized distribution/source-archive membership and rights gate (started in a dedicated worktree; PR only, no merge)
• release: define supported v0.0.6 dependencies and the ORCA companion boundary #8021 — supported dependency/extras and ORCA companion boundary
• release: add trusted TestPyPI, PyPI, and software-Zenodo publication #8023 — trusted TestPyPI/PyPI plus software-only Zenodo publication
• release: align v0.0.6 version, changelog, citation, and release metadata #8019 — final v0.0.6 version/changelog/citation/metadata alignment

Integration order: land the packaging/content/dependency contracts, build the exact v0.0.6 candidate once, pass TestPyPI cold-install verification, then promote the same bytes to PyPI, a GitHub Release, and a fresh software-only Zenodo concept. Publication stays protected and manual; no registry or DOI mutation is authorized before all strict gates pass.

Best current estimate for the sanitized route is 4–10 working days (about 75% confidence). Retaining every currently blocked asset/model/extra would likely take 2–6+ weeks because it depends on external rights and packaging decisions.