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.

v0.5.0

Fluent v0.5.0

Fluent v0.5.0 tightens the evidence used to decide whether a candidate can
advance, and makes interrupted Writer and recovery paths more reliable. These
changes follow the published v0.4.0 release.

What changed

• Verification now tracks each required command and its accepted proof through
  correction, targeted review, and final Tester runs. A failed command sends a
  candidate back for source correction only when the failure establishes a
  defect; missing prerequisites and unexplained failures pause for diagnosis.
  Host-provided proof must still match the current candidate, command, inputs,
  and freshness rules before it can satisfy a requirement.
• Rust library Test: references can name tests in a package-root library or a
  selected member of a virtual Cargo workspace. Fluent resolves the package,
  library target, and committed sources, then requires matching native test
  results. Ambiguous targets, dirty sources, and results from another library
  do not satisfy the reference.
• Writer handoffs assess the current completion matrix and candidate gate before
  assigning corrective work. The Writer receives the pending obligations and a
  compact view of current verification; malformed matrix state has an explicit
  recovery path. Candidate files remain confined to the Writer's checkout.
• Recovery commands preserve their original evidence and authorization across
  retries. Approach revisions at a failed-review round cap require a matching
  approved extension. Interrupted output-free Writer restoration and combined
  recovery paths validate the saved candidate and model state before changing
  Git or Work records.
• Review coverage and release test fixtures now check the full Writer history
  and supervise nested Fluent and provider processes through cleanup. This
  reduces the chance that stale review evidence or a surviving fixture process
  is mistaken for a completed gate.

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.5.0 and include the build
commit. Without a running scheduler, use fluent update followed by
fluent version.

Fluent v0.5.0 reads v0.4.0 Work Items. Existing Work Items and Attempts retain
their durable lifecycle state; resume paused work with the command shown by
fluent status. Scheduler-owned Work should return through fluent queue resume.

After v0.5.0 mutates a Work Item, use v0.5.0 or a compatible newer binary for
that item. The writer-version gate prevents older binaries from rewriting newer
state. To explicitly upgrade stored Work Items, run
fluent work-item upgrade <work-item-id>, or omit the ID to process all items.

Fluent v0.5.0 supports the verified local macOS workflow. Fargate execution is
outside this release's readiness claim.

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.

v0.3.0

Fluent v0.3.0

Fluent v0.3.0 adds durable Slack collaboration and broadens recovery for
long-running, scheduler-owned work. It also makes provider failures, candidate
rewrites, and host-specific test evidence safer to diagnose and resume.

What changed

• Slack Socket Mode can now carry a project-bound Fluent thread without a
  public endpoint. Threads preserve planning context, approvals, provider
  switches, Work status, reviewable candidates, and recovery actions. A local
  runner keeps Slack credentials in the macOS Keychain and enforces configured
  project, checkout, participant, and approver boundaries.
• Slack can enable approved existing checkouts, start planning, deliver Work
  transitions, and connect ready candidates to GitHub review. Reconnects,
  duplicate events, delayed provider replies, and interrupted deliveries are
  reconciled through durable identities.
• Scheduler-owned Work now has stronger service registration, nested-sandbox
  handling, fair provider admission, and explicit recovery for provider
  outages, canceled tasks, and stale dispatches. Scheduler status identifies
  the exact Fluent build that owns a project.
• Candidate recovery now covers Tester harness repairs, host-specific evidence,
  failed-command rechecks, candidate ancestry repairs, audited commit-message
  rewrites, and planning-reference or Approach revisions. These paths preserve
  candidate provenance and reject ordinary drift instead of silently combining
  evidence from different commits.
• Review and Tester settlement now waits for parallel reviewers, preserves
  late or superseded task output, reuses immutable baseline results, and avoids
  terminalizing an Attempt while authorized work is still settling.
• Codex and Claude provider failures now distinguish authentication, host
  sandbox, capacity, argument, and response-liveness failures. Bounded
  continuation and explicit handoffs keep transient provider problems from
  losing the current Attempt.
• Commit validation is clearer and more targeted. Prospective commit-message
  policy checks, executable command-shaped behavior references, isolated Git
  inspection, and bounded candidate gates catch malformed or drifted output
  before reviewers run.
• The release documentation and project Expertise now describe the Slack
  runner, recovery boundaries, scheduler ownership, and durable external
  effects. The release test harness also tracks the current transcript-pump
  schema.

Installation and upgrade

Run fluent update to install the latest binary, or follow the release
installation instructions in the repository. Verify the installed build with:

fluent version

The reported version should start with fluent 0.3.0.

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

Existing Work Items and Attempts retain their durable lifecycle state. Resume a
paused Attempt with the exact command shown by fluent status; scheduler-owned
Work should return through fluent queue resume rather than starting a new
Attempt.

For Slack setup, see docs/slack-runner.md.
Fluent v0.3.0 supports the verified local macOS workflow. Fargate execution is
not part of this release's readiness claim.

v0.2.0

Fluent v0.2.0

Fluent v0.2.0 makes scheduler-owned work practical from first setup through a
reviewed Merge Candidate. It supports Codex-only, Claude-only, and mixed Codex
and Claude coder profiles on macOS.

What changed

• The first-use flow now detects enclosing agent sandboxes, validates provider
  readiness, and gives the user a host-side command when authentication or
  nested macOS sandboxing cannot work inside the invoking agent's sandbox.
• Fluent now adopts its marked bootstrap skill without taking ownership of
  unrelated skills or lock entries. Reinstalling the managed skill preserves a
  current installation. Bare skill refreshes no longer create a Claude Code
  root by default; a new installation names codex or claude together with
  --project or --global.
• Queued Work uses the configured coder profile, resumes the same Attempt after
  provider or Tester pauses, and reports the terminal queue state. Scheduler
  status also identifies the running Fluent build so an installed update cannot
  silently reuse an older coordinator.
• Writers now complete a host-generated matrix that maps approved plan steps,
  execution guidance, review findings, and verification evidence. Cheap
  candidate checks run before review, and failed checks return directly to a
  corrective Writer.
• Reviews bind passing inspection evidence to the exact candidate commit.
  Missing test evidence can use one explicitly approved host-side command and
  rerun only the Tests Reviewer instead of repeating the full lifecycle.
• Corrections preserve the candidate and completed work across review failures,
  final-Tester failures, uncertain reviews, provider outages, and retryable
  Learner failures. Failed Tester commands can be rechecked before Fluent spends
  another full review round.
• Landed commits seed baseline results for later Work Items, avoiding a new
  baseline run when the same commit becomes a Work Item.
• Claude readiness diagnostics now distinguish authentication failures,
  provider capacity limits, enclosing-sandbox restrictions, and stalled
  launches. Provider wait time is included in Attempt status.
• Release publication now builds, signs, and checksums separate Apple Silicon
  and Intel macOS binaries.

Installation security notice

The public skills scanner labels the Fluent bootstrap High Risk. The shim
runs curl -fsSL fluent.computer/install | sh when the Fluent binary is
missing, then loads the version-matched full skill written by that binary. The
scanner treats the remote installer and the generated instruction handoff as a
code-execution and supply-chain risk.

Fluent v0.2.0 retains this bootstrap design. Review
skills/fluent/SKILL.md
and the contents served by
fluent.computer/install before running the
installer. The release assets themselves are checked against their published
SHA-256 files before installation.

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.2.0.

An older scheduler may not have build-identity metadata. In that case, stop it
from the terminal or process supervisor that launched it before starting the
new scheduler.

Existing Work Items and Attempts retain their durable lifecycle state. When an
existing Attempt is paused, use the exact resume command shown by
fluent status; scheduler-owned Work should return through fluent queue resume rather than starting a separate Attempt.

Fluent v0.2.0 supports local execution on macOS. Fargate execution is not part
of this release's readiness claim.

v0.1.5

Fluent v0.1.5

Fluent v0.1.5 focuses on making local autonomous work faster to operate and
safer to recover.

What changed

• fluent status and fluent work-item show now read persisted incremental
  metrics instead of recursively walking historical artifact trees. In the
  release repository, warm status reads fell from tens of seconds to about
  0.02 seconds.

• Local coder executions now have durable owner, process-group, heartbeat, and
  settlement records. fluent attempt cancel <work-item-id> <attempt-id> stops
  only the recorded execution group and preserves the workspace for a retry.

• A genuine round-cap pause can continue in the same Attempt after an explicit,
  bounded approval:

  fluent attempt extend <work-item-id> <attempt-id> --additional-write-rounds N

  The approval binds the candidate and failed review contents.

• Claude Writers use a managed project-local home, while the operator's Claude
  project memory remains denied by the Writer sandbox.

• Release installation and fluent update now require the matching .sha256
  asset and preserve the installed binary if the checksum is missing or wrong.

• Release publication now refuses dirty or unsynchronized source, reused tags,
  failed acceptance gates, and missing version-specific release notes.

Upgrade

Run:

fluent update
fluent version

The reported version should start with fluent 0.1.5.

Historical Work Items keep their existing lifecycle state. To populate complete
storage totals for older artifacts, run either:

fluent work-item rebuild-metrics
fluent work-item rebuild-metrics <work-item-id>

The first command rebuilds every Work Item; the second limits the scan to one.
Normal status and show commands remain bounded reads.

Fargate execution is not part of the v0.1.5 readiness claim. Use the verified
local workflow for this release.

v0.1.4

Release 0.1.4

v0.1.3

Release 0.1.3

v0.1.2

Reliability, concurrency, and onboarding fixes.

• Concurrent Work Items are now safe to run in parallel: Work Item diffs are computed from the merge-base (three-dot), so a main that moves while a review or land is in flight is no longer read as the branch deleting a sibling's work; and a self-releasing land lock serializes the rebase-and-merge window so two lands never interleave.
• fluent --version prints the version instead of starting an interactive session.
• fluent init keeps observations/ local (no longer committed) and suggests the <project>/main/ sibling-worktree layout.
• A transient auth rejection (HTTP 401) pauses the attempt for re-authentication and resumes, instead of hard-failing and discarding in-flight work. A single flaky review or tester error retries transient failures and pauses persistent ones rather than failing the attempt.
• The tester supports Node/pnpm projects: pnpm's store directory is added to the sandbox's writable roots for projects with a package.json.

v0.1.1

Reliability and skill-distribution improvements.

• The fluent skill installed by npx skills add is now a thin shim that installs the binary if missing and runs fluent skills add to materialize the full skill from the binary — so the skill an agent runs always matches the installed binary.
• State and artifact files are written atomically, removing a race where a concurrent reader could observe empty or partial content.
• Task execution is gated on a runner lease, so a task counts as running only while a live process holds it; a stale marker no longer blocks progress.
• A single flaky review or tester task no longer hard-fails an attempt — transient errors retry and persistent ones pause for the user; reviewers ground removal claims in the diff and route design questions to the user.