Iteron 0.0.4

Corrects the installer that v0.0.3 shipped.

install.sh looked for a core member inside an archive that has carried iteron since the rename, and would have installed the command under the old name. v0.0.3's tag is left where it is rather than moved: a published artifact that changes under its own name is worse than a spare version number.

release-tools/validate.sh passes for the first time since the rename, which was the last gate still red.

Built on macOS arm64 outside CI while hosted Actions minutes are exhausted (#223/#224). SOURCE_DATE_EPOCH is the release commit's own timestamp, the binary is built with cargo auditable so the SBOM binds its dependency graph rather than the file alone, and the manifest and receipt come from release-tools/.

Only aarch64-apple-darwin is published, which is what the team runs.

iteron 0.0.4 (abe5e174528c7cfa0e0e1aa7c5c098f5a4ec07e0 2026-08-10)

Iteron 0.0.3

First release carrying the Iteron name.

v0.0.2 and v0.0.2-internal-1 ship a core-named archive, and the installer verifies archive members byte-exactly, so the one-line install could not succeed against them after the rename. This release exists so the team can install again.

Built on macOS arm64 outside CI, the same way v0.0.1 and v0.0.2 were, because hosted Actions minutes are exhausted (#223/#224). The archive is deterministic: SOURCE_DATE_EPOCH is the release commit's own timestamp, the binary is built with cargo auditable so its SBOM binds 267 packages rather than the file alone, and the manifest and receipt are generated by release-tools/ rather than by hand.

Only aarch64-apple-darwin is published, which is what the team runs. Other targets need a working CI matrix.

iteron 0.0.3 (2335354a80827af321c29bb600f3af7243fff8e1 2026-08-10)

Core Code 0.0.2

Core Code v0.0.2: completed product-parity and platform surfaces, refined TUI/workflow control, current memory and attachment behavior, HEIC input, MCP and experiment surfaces. Built and verified locally from public main because the organization GitHub Actions quota was exhausted. The release contains the supported macOS arm64 runtime, content-addressed manifest/receipt/checksums, legal evidence, and SBOM; GitHub OIDC attestations could not be issued without Actions.

Core Code v0.0.1 (macOS arm64, built outside CI)

macOS arm64 only, and built outside CI. Read the next section before installing.

What is NOT here, and why

release.yml produces this normally. It has never succeeded: every run of it has failed, because
this repository's GitHub Actions runners do not start — jobs complete in seconds with zero steps
executed. So this release was produced by running the same release-tools/ pipeline by hand on a
developer Mac.

Consequently:

• No provenance or SBOM attestation. Those bundles are signed by GitHub's OIDC identity inside
  Actions; a machine outside Actions has no such identity and must not forge one. The manifest
  records this as a fact rather than omitting it — "provenance": {"attested": false, "reason": …}
  — so anything reading the manifest sees a refusal, not a plausible-looking digest.
• macOS arm64 only. The Linux, Intel-macOS and Windows targets are not built.
• No PE verification and no curl canary, both of which are Actions-only steps.

What IS intact

team-install.sh's own verification chain runs in full: receipt → manifest bytes → archive bytes →
the binary that actually runs, each checked by SHA-256 and size. The artefacts were produced by the
repository's own release-tools/ chain (legal → sbom → build-info → package → manifest → checksums)
with syft and cargo-about pinned by release-tools/fetch_tool.py, and the binary was built with
cargo auditable so the SBOM binds core-cli to the bytes that shipped.

Three defects fixed to get here

Producing a release end to end has never been done before, so each step had to be made to work:

1. manifest.py build-info raised AttributeError on every invocation (issue #198) — a guard
   belonging to create_release sat in create_build_info, where --receipt does not exist. It was
   not copied there, it was MOVED there: create_release had lost it entirely, so the tool both
   crashed and skipped a real check. Restored to the function whose arguments describe it.
2. A license the allowlist did not accept. fluent-uri pulls borrow-or-share, which is MIT-0.
   The allowlist had MIT but not MIT-0, and MIT-0 is MIT with the attribution clause removed —
   strictly less restrictive. Accepting MIT while refusing MIT-0 does not hold up.
3. The SBOM could not bind core-cli because the binary was built with plain cargo build.
   The pipeline requires cargo auditable build, which embeds the dependency list the scanner reads.

What is in the code

Thirteen slices merged as #210, plus the C-track work in #197 and #201. The largest:

• a workflow run can outlive the turn that started it — WorkflowSupervisor owns runs outside the
  turn's borrow, which is what runtime.rs had recorded as deferred
• a running agent row shows live tokens and tool activity; the emitter for it had never existed
• a partially failed fan-out is now visible on screen AND in the exit code
• a long paste becomes [Pasted text #N +M lines]; an attached image keeps its chip and gains an
  in-line [Image #N] anchor, so its position in the sentence is expressible
• a dropped file path is no longer misparsed as a slash command
• core workflow run can be interrupted