Cycle for Zcode 1.0.6

Cycle for Zcode 1.0.6

Governed delivery for ZCode: an architect plans, an executor implements inside an
isolated worktree, two independent reviewers judge the frozen candidate, and an
arbiter decides — with every gate result and verdict written to a hash-chained,
signature-checkpointed ledger.

This release closes the four defects the second live thirteen-scenario campaign
found against the sealed 1.0.5 archive, plus two found in the release machinery
itself while shipping it.

Fixed

A per-role model pin is no longer lost in silence. The pin lived only in the
profile's model: line, which was both the request and its resolution, so
anything that rewrote the profile from its template erased the request without a
trace. In the campaign the arbiter was pinned through the supported path, read
back from disk, and dispatched on inherit eighty-two minutes later with the
ledger faithfully recording it. The request is now kept apart from its
resolution, outside the project tree, and the two are compared on every call.
A profile rewritten from its own template is structurally perfect, so repair
no longer waits for damage: a pin missing from the file it was set on is itself
the thing to repair.

A claimed gate result is distinguishable from a verified one. Both used to
serialise to {"type":"verification","gate":"…","status":"passed"} byte for
byte, and the only signals separating them sat outside the entry. A reported
outcome now carries declared, which only the caller-facing audit path can set
and always does. Entries written before this field keep their bytes and read as
what they were.

A repaired candidate can be verified again. Evidence ids come from the
verification plan and a repair reuses that plan, while evidence was keyed on the
evidence id alone — so a refrozen candidate arrived carrying the failed
candidate's ids and every gate was refused. Evidence is now keyed by gate and
candidate, and both candidates keep their rows: the failed run stays in the
record rather than being overwritten by the run that fixed it.

CI=1 is no longer accepted as a program name. It is one word, carries no
metacharacter, is on no denylist, and is still not a program. What a program may
be is now stated positively: a command name, or a path whose final component is
one.

Fixed in the release machinery

The release gate now asks the daemon its version instead of scanning for one.
It searched the executable for the expected version as a substring; in a 39 MB
binary that sequence occurs on its own, and a 1.0.5 Linux daemon was duly
reported as declaring 1.0.6 and passed. workflowd --version answers without a
data directory or an IPC handshake, and each CI job names the daemon it must have
actually executed.

The tracked Linux daemon carries its executable bit again. It had regressed
to 100644, in 1.0.5 as well. This was not user-visible: the control plane never
runs the daemon from the plugin tree — it copies it into the data directory at
runtime/native/<target>/<digest>/ with mode 0700 and runs it from there, so
neither a checkout nor the sealed archive depends on the bit. What it broke was
the new gate above, which runs the binary in place to ask its version, and which
found it on its first Linux run.

Known ZCode limitations

Uninstalling the plugin leaves the marketplace's cached copy — roughly 76 MB
including a native daemon per platform — in your ZCode profile, and ZCode's
confirmation dialog promises to remove "the plugin's cached files" while leaving
those. This is host behaviour: the cache and its registry belong to ZCode, and a
plugin reaching in to erase entries would be a worse fault than the disk space it
recovers. The retained copy is inert. Remove the marketplace itself to reclaim
the space. Your audit data is untouched by an uninstall, which is why the control
plane lives outside the plugin tree.

Schema

The store moves to schema 18. A newer schema opens in the documented safe
read-only mode rather than refusing or migrating downward.

Verification

Rust 297 tests, MCP 36, qualification 21, clippy and cargo fmt clean. Built,
sealed, clean-installed on Ubuntu 22.04, Ubuntu 24.04 and Windows 11, and
attested with build provenance by release-candidate run 35405135492 from
71bab2fe96734cd413ead94c2d8483c9d4b10a67.

artifact	SHA-256
zcode-cycle-1.0.6.zip	a5fd6943a39f40218be8d246d8e64da39f75d3798e7ee33ea494b7a1093a57d1
zcode-cycle-native-linux-x64-1.0.6.tgz	505ace4ef8566ba64de95bddba226e2245903cc373855c319ecd72ef002b12c4
zcode-cycle-native-win32-x64-1.0.6.tgz	43c75fd81e1c184a4d0bd67dd4ab67bb6518896df35e91981b8e2e8094325062

Both native archives are byte-identical to the ones an earlier seal of a
different commit produced, so the daemon builds reproduce across runs. Only the
plugin ZIP differs, because its documentation did.

The Windows daemon is unsigned; authenticode.json records NotSigned. That is
a declared limitation of this release, not a failure, and the clean-install job
verifies it is unsigned rather than badly signed.

Not yet claimed

This build has not been through the thirteen-scenario live campaign. Every
fix above is covered by tests and the whole release lane is green, but the live
campaign is what found all four of the defects this release closes — in a 1.0.5
that was also entirely green. Until 1.0.6 has been certified live against these
exact bytes, this is a sealed and reproducible candidate rather than a certified
release, and it is marked as a pre-release for that reason.