v0.4.0

Fluent v0.4.0

Fluent v0.4.0 makes the build workflow easier to complete and safer to resume.
Since the published v0.3.0 source, Fluent has clarified who owns each required
action, improved how it matches test evidence, and strengthened cancellation
and verification before landing.

Recent evaluation found that a capable Writer usually completes the requested
change in one round. A second Writer remains appropriate when concrete failed
evidence requires a candidate change; one-round completion is not a guarantee.

What changed

• The Writer implements its assigned work and runs focused checks. Required
  actions assigned to the host, reviewers, Tester, or Learner stay with those
  owners. When only a host check remains, Fluent pauses with the exact candidate
  and command instead of sending the Writer back to perform it. Parallel
  reviews, one final Tester against the reviewed candidate, and a successful
  Learner still gate readiness.
• Corrective work follows evidence. A failed check or blocking review finding
  can return the candidate to a Writer with the current obligations and prior
  artifacts. When only host evidence is missing, an authorized check and
  targeted Tests Review can resolve it without changing the candidate.
  Repeated corrections that complete no additional obligations pause for
  inspection. Commit-message presentation advice alone no longer forces a
  corrective round; commit integrity and project checks still apply.
• Behavior test references now accept equivalent native Rust and nextest
  identities while preserving source, binary, and module distinctions. Shell
  references match the script path even when their descriptive label differs.
  Python unittest references resolve class-qualified methods from committed
  declarations. Missing, skipped, ambiguous, or unrelated evidence still
  leaves the requirement unsatisfied.
• Canceling a local Attempt records the stop before settling its owned
  processes. Writer, verification, Tester, review, and Learner workers observe
  the same stop, including between nested commands and during launch setup.
  No downstream stage starts until explicit resume. Repeating cancellation
  returns the settled result, and resuming preserves completed work and prior
  artifacts.
• Landing verifies the exact candidate commit that will reach the target
  branch. When capture-mode landing rebases a candidate, Fluent reuses complete
  passing Tester evidence only if it names that exact commit; otherwise it runs
  the configured Tester commands before fast-forward. A harness error or
  failure beyond the accepted target baseline leaves the target unchanged and
  retains the candidate and failure evidence for repair.
• Recovery validates the current candidate and its recorded evidence before
  resuming. Stale or unrelated evidence cannot authorize a correction, and
  approved responsibility assignments survive supported planning repairs.
  Status and dashboard now read Work without rewriting records, moving
  artifacts, or applying pending transactions. They show safely readable Work
  and report items that require recovery.

Installation and upgrade

If a scheduler is running, let its current Work finish and stop it before
installing the new binary:

fluent scheduler status
fluent scheduler stop
fluent update
fluent version
fluent scheduler run

The reported version should start with fluent 0.4.0 and include the build
commit. Without a running scheduler, use fluent update followed by
fluent version.

Fluent v0.4.0 reads legacy v0.3.0 Work Items and preserves them during read-only
observation. Existing Work Items and Attempts retain their durable lifecycle
state. Resume paused work with the exact command shown by fluent status;
scheduler-owned Work should return through fluent queue resume rather than
starting a new Attempt.

After v0.4.0 has resumed or mutated a Work Item, do not return to the published
v0.3.0 binary for that Work Item. Current writes use a writer-version envelope
that v0.3.0 deliberately cannot read, preventing the older executable from
rewriting newer state. If the older binary refuses a record, use v0.4.0 or a
compatible newer binary; do not edit the record to bypass the refusal.

To make the storage conversion explicit after installing this release, run
fluent work-item upgrade <work-item-id> or omit the ID to process every
stored Work Item independently. This also crosses the downgrade boundary.

Fluent v0.4.0 supports the verified local macOS workflow. Fargate execution is
not part of this release's readiness claim.