v0.6.0

Fluent v0.6.0

Fluent v0.6.0 prepares the local Work and shared service transition from the
published v0.5.0 binary. This source version is a release candidate until its
exact candidate passes the integrated host checks, reviews, final Tester, and
Learner. The version change does not publish or install a binary.

What changed

• Writer input checks bind the current authorized instructions to the bytes a
  provider read. A stored path alone does not establish delivery.
• Verification checks bind Tester, review, and landing evidence to the current
  candidate and accepted baseline. New failures and incomplete results block
  credit; known failures require their accepted baseline.
• Recovery retains the Work, candidate, and publication history through
  interrupted Writer completion and landing follow-up writes. Public status
  reports the next supported continuation without changing stored Work.
• Release transition checks use the published v0.5.0 binary in isolated
  projects. The predecessor refuses to mutate newer authority and pending
  publication state.
• The workflow model and production trace checks retain named negative
  controls. The integrated checker records every suite and connection gap in a
  candidate-bound report. A missing result or unfinished connection fails it.

The report includes the approved Writer-input, public-continuation, landed-
evidence, and cleanup statements, A1–A9, and their 22 named tests. Each test
receipt binds the candidate binary and the retained command log. A missing,
failed, or changed receipt remains visible as an unmet obligation.

Acceptance evidence and limits

Run the exact candidate checks from the repository root:

python3 tests/formal/workflow/check.py --suite=integrated --jar=target/fluent-tools/tla2tools-1.7.4.jar
FLUENT_WORKFLOW_REQUIRE_HOST=1 cargo nextest run --offline --features test-support --test workflow_assurance --no-tests fail workflow_release_build_

The first command writes suite logs and target/formal/workflow/integrated/report.json.
Its pass field is false while any connection row lacks checked evidence. The
approved behavior inventory and named test results appear in
approved-behaviors; the connection inventory appears in connections. The
second command builds a release binary without test-support and drives public
foreground cancellation and queued intake through that binary. Final host
receipts, reviews, Tester, and Learner belong to the exact accepted candidate;
these notes do not substitute for those records.

The main model profiles use one Work Item for the ordinary, repeated-recovery,
and review-only paths, with failure bounds of zero, two, and one respectively.
The service-competition profile uses two Work Items and one failure. The host
model logs retain the exact explored state counts; these notes do not claim a
count before that run. Model progress assumes enabled recovery is eventually
invoked, required human decisions and access arrive, and persistent failures
end. Provider failures and malformed output remain possible.
Production traces establish observed local macOS safety, not a machine-checked
Rust refinement proof. Sudden power loss, OS crashes, remote execution,
installation, and release publication remain outside this assurance scope.

Upgrade and rollback

For a shared scheduler, follow the v0.5.0 transition procedure: drain
each project coordinator, stop the original service, verify it exited, then
start the replacement. Inspect unfinished Work with fluent work-item show <id>;
run the displayed public continuation, and use fluent work-item upgrade <id>
for a legacy split record.

Once the newer binary writes a Work record or publication transaction, v0.5.0
must refuse mutation of that state. Reinstalling v0.5.0 alone cannot roll it
back. Continue forward with the compatible binary and public recovery command.
There is no rehearsed backup restoration or automatic lossy downgrade.