phg/iodd-tool

Fork 0

Define the mise release stages and signing handoff #32

New issue

Open

opened 2026-10-16 09:16:43 +00:00 by phg · 3 comments

phg commented

2026-10-16 09:16:43 +00:00

Owner

Parent: Plan the signed IODD Tool prerelease
Type: grilling
Mode: HITL
Blocked by: Establish mise-driven local prerelease mechanics, Choose the prerelease identity and download coordinates, Agree the manual and Homebrew lifecycle handoff

Question

What is the concrete, reproducible local mise task interface and stage ordering for producing, qualifying, signing/notarizing/stapling, freezing and publishing the first prerelease and its matching cask, and which human-owned signing/publication inputs does it require?

Use the established mechanics and selected identity/lifecycle contract. Decide task names, dependencies and explicit side-effect entry points; the pinned stable toolchain/build prerequisites; nonsecret credential references and operator handoff; durable output/manifest boundaries; safe resumption after failures; and the separation of final DMG publication from tap publication. Compute the cask digest only from the final frozen bytes. Missing credentials must block signing/publication clearly while allowing earlier image-based and build work to proceed.

The user's choice is manually initiated local automation through mise, not automated CI publishing. A concrete task contract/runbook is the decision artifact; do not implement mise tasks/scripts, access signing secrets, enroll services, sign or publish anything. Resolve the remaining operational choices through live discussion with phg.

Parent: [Plan the signed IODD Tool prerelease](https://git.s1q.dev/phg/iodd-tool/issues/27) Type: grilling Mode: HITL Blocked by: [Establish mise-driven local prerelease mechanics](https://git.s1q.dev/phg/iodd-tool/issues/29), [Choose the prerelease identity and download coordinates](https://git.s1q.dev/phg/iodd-tool/issues/30), [Agree the manual and Homebrew lifecycle handoff](https://git.s1q.dev/phg/iodd-tool/issues/31) ## Question What is the concrete, reproducible local mise task interface and stage ordering for producing, qualifying, signing/notarizing/stapling, freezing and publishing the first prerelease and its matching cask, and which human-owned signing/publication inputs does it require? Use the established mechanics and selected identity/lifecycle contract. Decide task names, dependencies and explicit side-effect entry points; the pinned stable toolchain/build prerequisites; nonsecret credential references and operator handoff; durable output/manifest boundaries; safe resumption after failures; and the separation of final DMG publication from tap publication. Compute the cask digest only from the final frozen bytes. Missing credentials must block signing/publication clearly while allowing earlier image-based and build work to proceed. The user's choice is manually initiated local automation through mise, not automated CI publishing. A concrete task contract/runbook is the decision artifact; do not implement mise tasks/scripts, access signing secrets, enroll services, sign or publish anything. Resolve the remaining operational choices through live discussion with phg.

phg added the

wayfinder:grilling

label

2026-10-16 09:16:44 +00:00

phg referenced this issue

2026-10-16 09:17:17 +00:00

Set the qualification freeze and evidence handoff #33

phg referenced this issue

2026-10-16 09:17:17 +00:00

Plan the signed IODD Tool prerelease #27

phg referenced this issue

2026-10-16 09:59:05 +00:00

Choose the prerelease identity and download coordinates #30

phg referenced this issue

2026-10-16 11:28:58 +00:00

Agree the manual and Homebrew lifecycle handoff #31

phg self-assigned this

2026-10-16 11:55:03 +00:00

phg commented

2026-10-16 12:00:09 +00:00

Author

Owner

Interview checkpoint — explicit entrypoints and durable workspace selected

phg answered the first interview round for Define the mise release stages and signing handoff, agreeing to both recommendations:

Four explicit checkpoints: preparation, signing/notarization, DMG publication and tap publication each have their own entrypoint. Preparation works without signing credentials. Signing/notarization requires its own invocation; DMG publication and tap publication each require another invocation. A default task never starts those later actions. Exact task names and internal stage ordering remain to be confirmed.
Durable workspace outside the checkout: default to the checkout's sibling iodd-tool-releases/<version>/<candidate-id>/ for artifacts, manifest, stage receipts and qualification evidence. Keep the task/runbook in Git and source/tool/artifact identities in the candidate workspace. Credentials remain in private credential stores.

The mechanics and source evidence remain owned by Establish mise-driven local prerelease mechanics. A read-only fact-finding delegate (/root/release_contract_facts) checked its retained report at commit f83201112cf0f5625ebd12654a3c1ac0a558efbc and current main b8334e758a8fb11d61b7af8d3ed6f0f632a4216b. In particular, mise confirmation runs after dependencies and can be bypassed; the explicit entrypoint contract cannot rely on confirmation alone. Those observations do not select a release candidate or prove qualification.

The signing/publication reference handoff, supported stable tool pins, concrete task ordering, receipt and retry contract remain for the next interview rounds. Agree the manual and Homebrew lifecycle handoff remains open and continues to block complete resolution. No Homebrew compatibility requirement or release gate is waived. Detailed freeze and evidence-invalidation decisions remain with Set the qualification freeze and evidence handoff.

This is a partial human-selection record, not a resolution. The issue stays open and assigned to phg; the map's Decisions so far is unchanged. Only tracker records were updated; no implementation, credential provisioning, signing, tests or publication occurred.

## Interview checkpoint — explicit entrypoints and durable workspace selected phg answered the first interview round for [Define the mise release stages and signing handoff](https://git.s1q.dev/phg/iodd-tool/issues/32), agreeing to both recommendations: 1. **Four explicit checkpoints:** preparation, signing/notarization, DMG publication and tap publication each have their own entrypoint. Preparation works without signing credentials. Signing/notarization requires its own invocation; DMG publication and tap publication each require another invocation. A default task never starts those later actions. Exact task names and internal stage ordering remain to be confirmed. 2. **Durable workspace outside the checkout:** default to the checkout's sibling `iodd-tool-releases/<version>/<candidate-id>/` for artifacts, manifest, stage receipts and qualification evidence. Keep the task/runbook in Git and source/tool/artifact identities in the candidate workspace. Credentials remain in private credential stores. The mechanics and source evidence remain owned by [Establish mise-driven local prerelease mechanics](https://git.s1q.dev/phg/iodd-tool/issues/29). A read-only fact-finding delegate (`/root/release_contract_facts`) checked its retained report at commit `f83201112cf0f5625ebd12654a3c1ac0a558efbc` and current main `b8334e758a8fb11d61b7af8d3ed6f0f632a4216b`. In particular, mise confirmation runs after dependencies and can be bypassed; the explicit entrypoint contract cannot rely on confirmation alone. Those observations do not select a release candidate or prove qualification. The signing/publication reference handoff, supported stable tool pins, concrete task ordering, receipt and retry contract remain for the next interview rounds. [Agree the manual and Homebrew lifecycle handoff](https://git.s1q.dev/phg/iodd-tool/issues/31) remains open and continues to block complete resolution. No Homebrew compatibility requirement or release gate is waived. Detailed freeze and evidence-invalidation decisions remain with [Set the qualification freeze and evidence handoff](https://git.s1q.dev/phg/iodd-tool/issues/33). This is a partial human-selection record, not a resolution. The issue stays open and assigned to phg; the map's Decisions so far is unchanged. Only tracker records were updated; no implementation, credential provisioning, signing, tests or publication occurred.

phg commented

2026-10-16 12:04:34 +00:00

Author

Owner

Interview checkpoint — credential references, exact tools and verified resumption selected

phg agreed to Q3–Q5 in the live discussion for Define the mise release stages and signing handoff. These add to the earlier accepted four explicit entrypoints and external candidate workspace:

Private credential handoff: the operator provides a Developer ID Application certificate/private key in Keychain, explicit Team ID and certificate fingerprint, a named notarytool Keychain profile, and separate existing Forgejo/tap Git authentication. The runbook records nonsecret references only. Missing credentials stop the relevant signing/publication stage clearly; preparation remains available. Provisioning is a later human task, outside this planning effort. No actual credential reference values, readiness or access authority were verified.
Exact release tools: pin mise 2026.10.11, fj 0.6.0, and Xcode 27.0 / 27A266a, selected through process-local DEVELOPER_DIR with its bundled Swift/SDK. Reject mismatches and record exact compiler/SDK identities. The installed mise observation (2026.10.9) is not the selected pin and requires correction before later release execution. No tool was installed or changed, and no source candidate or runtime evidence was selected.
Failure and resumption: retain stage receipts and failed outputs. Resume a stage only when recorded source, tools and input hashes still match, and output integrity is established. Resume an existing notary submission by UUID. Read back remote state and asset contents before retrying uploads. Ambiguous or conflicting state stops for reconciliation. Changed inputs require a new candidate; changed published DMG bytes require a new prerelease version. Never automatically overwrite a conflicting published asset.

Supporting toolchain fact check

The read-only delegate /root/release_contract_facts verified primary sources on 16 October 2026: Apple's Xcode 27 release record names build 27A266a, dated 14 September 2026. The current Apple requirements table and release notes cover Swift 6.4, macOS 27 SDK, Apple Silicon/macOS 26.6+ hosts and deployment including macOS 15. The official mise release is stable, published 15 October 2026; its signed tag peels to the mechanics report baseline a24763b05e203e4d8e72702d7bc68214b99fbd06. Downloaded tool binaries were not verified by this discussion.

Observed compiler/SDK suffixes remain observations rather than independent web-source guarantees: Swift swiftlang-6.4.0.34.1, clang 2100.3.34.1, driver 1.168.6; SDK 27.0 / 26A425. The eventual selected Xcode installation must be checked and its identities bound to the manifest. The original mechanics report and its retained artifact/commit pointers stay owned by Establish mise-driven local prerelease mechanics.

Concrete task names, internal ordering and the publication/qualification visibility boundary remain to be discussed. Agree the manual and Homebrew lifecycle handoff remains unresolved and blocks full resolution. The detailed evidence/freeze contract still belongs to Set the qualification freeze and evidence handoff. No gate is waived and the map's Decisions so far is unchanged.

Only this partial tracker record was added; no source changes, tests, credential provisioning/access, signing, notarization or release/tap publication occurred.

## Interview checkpoint — credential references, exact tools and verified resumption selected phg agreed to Q3–Q5 in the live discussion for [Define the mise release stages and signing handoff](https://git.s1q.dev/phg/iodd-tool/issues/32). These add to the earlier accepted four explicit entrypoints and external candidate workspace: 1. **Private credential handoff:** the operator provides a Developer ID Application certificate/private key in Keychain, explicit Team ID and certificate fingerprint, a named `notarytool` Keychain profile, and separate existing Forgejo/tap Git authentication. The runbook records nonsecret references only. Missing credentials stop the relevant signing/publication stage clearly; preparation remains available. Provisioning is a later human task, outside this planning effort. No actual credential reference values, readiness or access authority were verified. 2. **Exact release tools:** pin mise `2026.10.11`, fj `0.6.0`, and Xcode `27.0 / 27A266a`, selected through process-local `DEVELOPER_DIR` with its bundled Swift/SDK. Reject mismatches and record exact compiler/SDK identities. The installed mise observation (`2026.10.9`) is not the selected pin and requires correction before later release execution. No tool was installed or changed, and no source candidate or runtime evidence was selected. 3. **Failure and resumption:** retain stage receipts and failed outputs. Resume a stage only when recorded source, tools and input hashes still match, and output integrity is established. Resume an existing notary submission by UUID. Read back remote state and asset contents before retrying uploads. Ambiguous or conflicting state stops for reconciliation. Changed inputs require a new candidate; changed published DMG bytes require a new prerelease version. Never automatically overwrite a conflicting published asset. ### Supporting toolchain fact check The read-only delegate `/root/release_contract_facts` verified primary sources on 16 October 2026: [Apple's Xcode 27 release record](https://developer.apple.com/news/releases/?id=09142026h) names build `27A266a`, dated 14 September 2026. The current [Apple requirements table](https://developer.apple.com/xcode/system-requirements) and [release notes](https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes) cover Swift 6.4, macOS 27 SDK, Apple Silicon/macOS 26.6+ hosts and deployment including macOS 15. The [official mise release](https://github.com/jdx/mise/releases/tag/v2026.10.11) is stable, published 15 October 2026; its signed tag peels to the mechanics report baseline `a24763b05e203e4d8e72702d7bc68214b99fbd06`. Downloaded tool binaries were not verified by this discussion. Observed compiler/SDK suffixes remain observations rather than independent web-source guarantees: Swift `swiftlang-6.4.0.34.1`, clang `2100.3.34.1`, driver `1.168.6`; SDK `27.0 / 26A425`. The eventual selected Xcode installation must be checked and its identities bound to the manifest. The original mechanics report and its retained artifact/commit pointers stay owned by [Establish mise-driven local prerelease mechanics](https://git.s1q.dev/phg/iodd-tool/issues/29). Concrete task names, internal ordering and the publication/qualification visibility boundary remain to be discussed. [Agree the manual and Homebrew lifecycle handoff](https://git.s1q.dev/phg/iodd-tool/issues/31) remains unresolved and blocks full resolution. The detailed evidence/freeze contract still belongs to [Set the qualification freeze and evidence handoff](https://git.s1q.dev/phg/iodd-tool/issues/33). No gate is waived and the map's Decisions so far is unchanged. Only this partial tracker record was added; no source changes, tests, credential provisioning/access, signing, notarization or release/tap publication occurred.

phg commented

2026-10-16 12:20:57 +00:00

Author

Owner

Agreed mise task contract — Homebrew integration pending

phg agreed to Q6 and Q7, completing the independent workflow choices in this discussion. This consolidates the accepted Q1–Q7 answers for Define the mise release stages and signing handoff. Earlier interview checkpoints remain history. This is an agreed conditional task contract, not resolution of the complete handoff: the standard-cask integration prerequisite remains unresolved.

Operator entrypoints

The implementation will provide four manually initiated local mise entrypoints:

mise run release:prepare --candidate <id> --source <full-commit>
mise run release:sign --candidate <id>
mise run release:publish-dmg --candidate <id> --sha256 <final-dmg-sha256>
mise run release:publish-tap --candidate <id> --sha256 <final-dmg-sha256>

Every entrypoint requires an explicit candidate. Preparation additionally requires the source commit; both publication commands require the expected final DMG SHA-256 and must compare it with the frozen manifest and actual artifact. An optional --workspace <root> selects the release workspace; its default is the checkout's sibling iodd-tool-releases/<version>/<candidate-id>/ candidate location. This release-output option is not an installation-destination or lifecycle-lease override.

The default task displays status/help. Signing/notarization, DMG publication and tap publication each require a separate explicit invocation. Later entrypoints validate prerequisite receipts; they never silently rebuild, re-sign, start an earlier side-effect stage or publish another distribution path. Required stage ordering is serial where bytes or receipts depend on earlier outputs. Mise confirmation, freshness, cached logs or task exit alone do not establish permission or qualification; stage guards must still refuse missing, failed, pending or mismatched prerequisites.

Durable candidate boundary

Keep artifacts, the manifest, stage receipts and qualification evidence outside the checkout, under the candidate workspace. The later implementation keeps its mise tasks and operator runbook in Git. Credentials remain in private stores.

The records must distinguish:

Candidate/source identity, selected release metadata, exact tools/compiler/SDK/build settings and preserved unsigned products.
Each stage/attempt's bound inputs and hashes, arguments/tool identities, observed result, output inventory/digests and evidence pointers; keep failed and partial attempts.
Signed component identities and their relationship to unsigned inputs; the two notarization input identities, submission UUIDs, terminal status and logs; app/DMG staple and signature checks.
Final frozen DMG bytes, size and SHA-256; independently downloaded bytes/results; the matching cask version/URL/SHA-256 and actual public tap commit.
Actual remote tag/release/asset/tap state after publication or an ambiguous response, including publication whose public verification is still pending.

The detailed minimal release manifest/checklist, evidence owners, exact runtime builds and evidence-invalidation rules remain with Set the qualification freeze and evidence handoff. This contract establishes the storage and stage boundaries, not a claim that those evidence requirements have been met.

Preparation and tool prerequisites

release:prepare checks the explicit source and tool identities, builds the complete intended bundle and records the credential-free qualification it actually performs. Missing signing credentials do not block image-based/build work. Signed-artifact, final-download and distribution-path evidence cannot be inferred from these earlier results.

Pin mise 2026.10.11, fj 0.6.0, and Xcode 27.0 / 27A266a. Use process-local DEVELOPER_DIR with that Xcode's bundled Swift/SDK; reject mismatches and record exact compiler/SDK identities. Installation of the selected tools is an execution prerequisite, not an automatic upgrade during a frozen candidate. The observed local mise 2026.10.9 is not the agreed release pin.

The later integrated source must include the complete app, ordinary worker and signed lifecycle helper, correct bundle packaging, arm64/macOS 15 minimum and the accepted release identities. Use Choose the prerelease identity and download coordinates for 0.1.0-beta.1, build 2, trust identifiers, tag/asset/tap coordinates and its prior-distribution build-number check. No inspected historical main or development artifact becomes the candidate implicitly.

Private signing and publication inputs

The operator supplies these nonsecret references through the later private handoff:

Developer ID Application certificate fingerprint/selector, expected Team ID and relevant Keychain reference; the private key stays in Keychain.
A named notarytool Keychain profile.
Existing Forgejo authentication for release mutations and separate tap Git authentication/write authority.

The operator handles credential provisioning and any required private credential-store interaction. Record reference names and public identity metadata, not private keys, passwords or token values. Missing/unusable credentials stop the relevant signing/publication stage clearly while preparation remains available. Tracker access is not proof of release-upload or tap-write authority. This discussion establishes no actual credential values or readiness.

Signing and final byte freeze

release:sign validates its preparation receipt and runs these byte transformations in order:

Sign the bundled ordinary worker and lifecycle helper individually, then sign their containing app with the accepted Developer ID identities, appropriate hardened runtime, secure timestamps and required entitlements.
Verify the signed components and package the signed app in a temporary ZIP. Submit that ZIP for notarization, persist its UUID, require acceptance and retain/inspect the log.
Staple and validate the app.
Create the DMG containing that stapled app, then sign the DMG.
Submit the DMG separately; persist its own UUID, require acceptance and retain/inspect the log.
Staple and validate the DMG; verify the final image and embedded signed components. Freeze the final bytes and compute their size/SHA-256 after the last byte-changing operation.

The ZIP is intermediate; one final DMG is distributed. The app and DMG carry their supported tickets; standalone worker/helper executables are not stapling targets. Do not mutate the embedded app after sealing the final image or re-sign a frozen artifact in place. The cask digest comes only from the frozen DMG. A frozen artifact is not yet a qualified or successfully published release.

Qualification and DMG publication

Both publication entrypoints remain blocked until Agree the manual and Homebrew lifecycle handoff supplies a compatible accepted contract and all applicable prepublication gates are satisfied. Preserve every accepted software/oracle/fault/recovery, whole-branch review, app smoke/accessibility, baseline/current-stable runtime and lifecycle requirement. Detailed qualification receipts belong to Set the qualification freeze and evidence handoff; the existing acceptance/implementation owners remain Set validation gates and the implementation handoff and Qualify and package the native app. Do not add a second mutation matrix or waive a gate for the beta.

release:publish-dmg checks the candidate and expected digest, reconciles any existing remote state, verifies the exact tag-to-source binding, prepares/uploads the draft and verifies the downloaded draft bytes. Versioned tag/release creation or upload effects belong to this explicit publication checkpoint, not preparation/signing. An existing conflicting tag or asset stops progression rather than being silently repaired or replaced.

After the applicable prior gates pass, publish the evaluation prerelease at the exact accepted coordinates. Independently verify the anonymous final download's size/SHA-256 and required clean-user, Gatekeeper/install results on the supported environments. The checkpoint remains incomplete while public verification is pending or failed. Draft verification does not substitute for the final public user path. Tap publication waits for successful final-download verification.

Separate tap publication

release:publish-tap validates the reviewed cask against the final public DMG and frozen digest, then publishes the exact reviewed tap commit as its own mutation. Verify the public tap, anonymous Git access, matching cask version/URL/SHA-256 and remaining fully qualified distribution-path/lifecycle results before marking this checkpoint complete. Local recipe checks do not by themselves establish public tap acceptance.

The recipe remains subject to the unresolved standard-cask lifecycle contract. No current hook, staging, purge, helper-selection or registration-reconciliation approach is approved by this task contract. Manual-path selections do not establish Homebrew compatibility.

Failure, resumption and withdrawal

Resume only when the recorded source/tools/input hashes still match and preserved output integrity is verified. Changed bound inputs require a new candidate. Preserve failed outputs and stage receipts; do not replace evidence with a replayed success log.

Resume an existing notary submission by UUID rather than treating a timeout as cancellation. A lost submission response requires reconciliation; an ambiguous match stops automatic resubmission. Likewise, read back release/asset/tap state and verify asset contents before retrying an external mutation. Names/sizes or a lost response alone do not establish either success or failure. Never automatically overwrite a conflicting published asset.

Each publication checkpoint stays incomplete until its public checks pass. On failure, stop progression and record actual remote state. Withdrawal is an explicit operator action: re-draft the release or publish a reviewed tap revert. Do not move the release tag, replace the distributed DMG bytes or rewrite tap history. Any changed distributed DMG requires a new prerelease version and coordinates. A failed tap step does not undo a successful DMG publication; report each path truthfully and independently.

Remaining dependency and status

Agree the manual and Homebrew lifecycle handoff still owns the unresolved preservation/bookkeeping/purge/phase-gap and helper/registration integration contract. Its unchanged preservation guarantees and the qualified standard-cask release path remain required. That existing blocker prevents completing this dependent handoff; no duplicate child, contract reopening or gate waiver follows from these seven accepted answers.

This issue stays open and assigned to phg. Do not index it as a completed decision on Plan the signed IODD Tool prerelease. Once the lifecycle prerequisite is resolved, integrate its concrete route and check whether it changes this accepted workflow before recording the full resolution. The qualification/freeze question remains in its existing child.

This session updated tracker records only. No mise tasks/scripts, source or test code, credentials, builds, signing/notarization, lifecycle operations, release assets or tap commits were created or changed.

## Agreed mise task contract — Homebrew integration pending phg agreed to Q6 and Q7, completing the independent workflow choices in this discussion. This consolidates the accepted Q1–Q7 answers for [Define the mise release stages and signing handoff](https://git.s1q.dev/phg/iodd-tool/issues/32). Earlier interview checkpoints remain history. This is an agreed conditional task contract, **not resolution of the complete handoff**: the standard-cask integration prerequisite remains unresolved. ### Operator entrypoints The implementation will provide four manually initiated local mise entrypoints: ```text mise run release:prepare --candidate <id> --source <full-commit> mise run release:sign --candidate <id> mise run release:publish-dmg --candidate <id> --sha256 <final-dmg-sha256> mise run release:publish-tap --candidate <id> --sha256 <final-dmg-sha256> ``` Every entrypoint requires an explicit candidate. Preparation additionally requires the source commit; both publication commands require the expected final DMG SHA-256 and must compare it with the frozen manifest and actual artifact. An optional `--workspace <root>` selects the release workspace; its default is the checkout's sibling `iodd-tool-releases/<version>/<candidate-id>/` candidate location. This release-output option is not an installation-destination or lifecycle-lease override. The default task displays status/help. Signing/notarization, DMG publication and tap publication each require a separate explicit invocation. Later entrypoints validate prerequisite receipts; they never silently rebuild, re-sign, start an earlier side-effect stage or publish another distribution path. Required stage ordering is serial where bytes or receipts depend on earlier outputs. Mise confirmation, freshness, cached logs or task exit alone do not establish permission or qualification; stage guards must still refuse missing, failed, pending or mismatched prerequisites. ### Durable candidate boundary Keep artifacts, the manifest, stage receipts and qualification evidence outside the checkout, under the candidate workspace. The later implementation keeps its mise tasks and operator runbook in Git. Credentials remain in private stores. The records must distinguish: - Candidate/source identity, selected release metadata, exact tools/compiler/SDK/build settings and preserved unsigned products. - Each stage/attempt's bound inputs and hashes, arguments/tool identities, observed result, output inventory/digests and evidence pointers; keep failed and partial attempts. - Signed component identities and their relationship to unsigned inputs; the two notarization input identities, submission UUIDs, terminal status and logs; app/DMG staple and signature checks. - Final frozen DMG bytes, size and SHA-256; independently downloaded bytes/results; the matching cask version/URL/SHA-256 and actual public tap commit. - Actual remote tag/release/asset/tap state after publication or an ambiguous response, including publication whose public verification is still pending. The detailed minimal release manifest/checklist, evidence owners, exact runtime builds and evidence-invalidation rules remain with [Set the qualification freeze and evidence handoff](https://git.s1q.dev/phg/iodd-tool/issues/33). This contract establishes the storage and stage boundaries, not a claim that those evidence requirements have been met. ### Preparation and tool prerequisites `release:prepare` checks the explicit source and tool identities, builds the complete intended bundle and records the credential-free qualification it actually performs. Missing signing credentials do not block image-based/build work. Signed-artifact, final-download and distribution-path evidence cannot be inferred from these earlier results. Pin **mise `2026.10.11`**, **fj `0.6.0`**, and **Xcode `27.0 / 27A266a`**. Use process-local `DEVELOPER_DIR` with that Xcode's bundled Swift/SDK; reject mismatches and record exact compiler/SDK identities. Installation of the selected tools is an execution prerequisite, not an automatic upgrade during a frozen candidate. The observed local mise `2026.10.9` is not the agreed release pin. The later integrated source must include the complete app, ordinary worker and signed lifecycle helper, correct bundle packaging, arm64/macOS 15 minimum and the accepted release identities. Use [Choose the prerelease identity and download coordinates](https://git.s1q.dev/phg/iodd-tool/issues/30) for `0.1.0-beta.1`, build 2, trust identifiers, tag/asset/tap coordinates and its prior-distribution build-number check. No inspected historical main or development artifact becomes the candidate implicitly. ### Private signing and publication inputs The operator supplies these nonsecret references through the later private handoff: - Developer ID Application certificate fingerprint/selector, expected Team ID and relevant Keychain reference; the private key stays in Keychain. - A named `notarytool` Keychain profile. - Existing Forgejo authentication for release mutations and separate tap Git authentication/write authority. The operator handles credential provisioning and any required private credential-store interaction. Record reference names and public identity metadata, not private keys, passwords or token values. Missing/unusable credentials stop the relevant signing/publication stage clearly while preparation remains available. Tracker access is not proof of release-upload or tap-write authority. This discussion establishes no actual credential values or readiness. ### Signing and final byte freeze `release:sign` validates its preparation receipt and runs these byte transformations in order: 1. Sign the bundled ordinary worker and lifecycle helper individually, then sign their containing app with the accepted Developer ID identities, appropriate hardened runtime, secure timestamps and required entitlements. 2. Verify the signed components and package the signed app in a temporary ZIP. Submit that ZIP for notarization, persist its UUID, require acceptance and retain/inspect the log. 3. Staple and validate the app. 4. Create the DMG containing that stapled app, then sign the DMG. 5. Submit the DMG separately; persist its own UUID, require acceptance and retain/inspect the log. 6. Staple and validate the DMG; verify the final image and embedded signed components. Freeze the final bytes and compute their size/SHA-256 after the last byte-changing operation. The ZIP is intermediate; one final DMG is distributed. The app and DMG carry their supported tickets; standalone worker/helper executables are not stapling targets. Do not mutate the embedded app after sealing the final image or re-sign a frozen artifact in place. The cask digest comes only from the frozen DMG. A frozen artifact is not yet a qualified or successfully published release. ### Qualification and DMG publication Both publication entrypoints remain blocked until [Agree the manual and Homebrew lifecycle handoff](https://git.s1q.dev/phg/iodd-tool/issues/31) supplies a compatible accepted contract and all applicable prepublication gates are satisfied. Preserve every accepted software/oracle/fault/recovery, whole-branch review, app smoke/accessibility, baseline/current-stable runtime and lifecycle requirement. Detailed qualification receipts belong to [Set the qualification freeze and evidence handoff](https://git.s1q.dev/phg/iodd-tool/issues/33); the existing acceptance/implementation owners remain [Set validation gates and the implementation handoff](https://git.s1q.dev/phg/iodd-tool/issues/6) and [Qualify and package the native app](https://git.s1q.dev/phg/iodd-tool/issues/24). Do not add a second mutation matrix or waive a gate for the beta. `release:publish-dmg` checks the candidate and expected digest, reconciles any existing remote state, verifies the exact tag-to-source binding, prepares/uploads the draft and verifies the downloaded draft bytes. Versioned tag/release creation or upload effects belong to this explicit publication checkpoint, not preparation/signing. An existing conflicting tag or asset stops progression rather than being silently repaired or replaced. After the applicable prior gates pass, publish the evaluation prerelease at the exact accepted coordinates. Independently verify the anonymous final download's size/SHA-256 and required clean-user, Gatekeeper/install results on the supported environments. The checkpoint remains **incomplete** while public verification is pending or failed. Draft verification does not substitute for the final public user path. Tap publication waits for successful final-download verification. ### Separate tap publication `release:publish-tap` validates the reviewed cask against the final public DMG and frozen digest, then publishes the exact reviewed tap commit as its own mutation. Verify the public tap, anonymous Git access, matching cask version/URL/SHA-256 and remaining fully qualified distribution-path/lifecycle results before marking this checkpoint complete. Local recipe checks do not by themselves establish public tap acceptance. The recipe remains subject to the unresolved standard-cask lifecycle contract. No current hook, staging, purge, helper-selection or registration-reconciliation approach is approved by this task contract. Manual-path selections do not establish Homebrew compatibility. ### Failure, resumption and withdrawal Resume only when the recorded source/tools/input hashes still match and preserved output integrity is verified. Changed bound inputs require a new candidate. Preserve failed outputs and stage receipts; do not replace evidence with a replayed success log. Resume an existing notary submission by UUID rather than treating a timeout as cancellation. A lost submission response requires reconciliation; an ambiguous match stops automatic resubmission. Likewise, read back release/asset/tap state and verify asset contents before retrying an external mutation. Names/sizes or a lost response alone do not establish either success or failure. Never automatically overwrite a conflicting published asset. Each publication checkpoint stays incomplete until its public checks pass. On failure, stop progression and record actual remote state. Withdrawal is an **explicit operator action**: re-draft the release or publish a reviewed tap revert. Do not move the release tag, replace the distributed DMG bytes or rewrite tap history. Any changed distributed DMG requires a new prerelease version and coordinates. A failed tap step does not undo a successful DMG publication; report each path truthfully and independently. ### Remaining dependency and status [Agree the manual and Homebrew lifecycle handoff](https://git.s1q.dev/phg/iodd-tool/issues/31) still owns the unresolved preservation/bookkeeping/purge/phase-gap and helper/registration integration contract. Its unchanged preservation guarantees and the qualified standard-cask release path remain required. That existing blocker prevents completing this dependent handoff; no duplicate child, contract reopening or gate waiver follows from these seven accepted answers. This issue stays **open and assigned to phg**. Do not index it as a completed decision on [Plan the signed IODD Tool prerelease](https://git.s1q.dev/phg/iodd-tool/issues/27). Once the lifecycle prerequisite is resolved, integrate its concrete route and check whether it changes this accepted workflow before recording the full resolution. The qualification/freeze question remains in its existing child. This session updated tracker records only. No mise tasks/scripts, source or test code, credentials, builds, signing/notarization, lifecycle operations, release assets or tap commits were created or changed.