Attune Harness 1.4.0

Attune Harness 1.4.0 improves saved forms and consultation recovery while retaining the v1 compatibility contract.

• Saved answers remain visible above remaining questions. Approval uses Approve this work request and Keep as draft; neither starts work.
• First-round consultation seats run concurrently. Partial rounds retain successful results, and eligible refused turns require explicit checkpoint-bound selective retry.
• Readable consultation views, roundtable setup/seat checks and batch citation assessments improve inspection and preparation. JSON remains the default.

Release notes · Written forms walkthrough

Python 3.10 or later. A managed base installation includes forms, verification and retrieval:

uv tool install 'attune-harness==1.4.0'

Select attune-harness[all]==1.4.0 when the qualified Redis and Voyage integrations are required. Experimental native memory remains outside all. Python runtime installation and host-plugin installation are separate.

Qualification is bound to signed source d9332dc67b6f31218d9b34e6fab2fd08473aa576 (tree 27fcebb0be1e01a80c73680d0281e6e74f6ae9c2). Final main qualification passed 4,435 source tests (65 skipped), six installed-platform profiles, and all 18 GUI client cases per profile. Supplemental instrumentation and isolated Windows effects checks passed separately.

Actual PyPI publication run 38208403169, attempt 1 succeeded after human deployment approval. Both attached archives were independently downloaded from PyPI and matched this run’s checksums. All 105 runtime modules matched source. Fresh Mac arm64 Python 3.10.11 [all] and uv-managed base installs each passed 29 offline CLI cases and the plan/accept/build/review/status journey with zero model calls.

SHA-256:

ab18bf90546d4d5b761344d79e307aeade5976ab27c42374e1f6a6fe379b3363  attune_harness-1.4.0-py3-none-any.whl
6af2b02d6c86c46353ba5a9c6044b39af3330e1a7693933ec9b192ed23d909a7  attune_harness-1.4.0.tar.gz

The browser remains forms-only. Saving is not approval, and approval does not authorize execution or paid calls. Unsaved typing is not restored; automatic reload restoration requires current ownership/storage/checkpoint conditions. Receipts establish the declared checks and their limits, not universally accurate or hallucination-free AI output.

S3 fresh-session memory observations, S6 an independent non-programmer walkthrough, S9 migration observations, broader M2/M3/M4, accessibility/comprehension coverage, replacement decks and separate Help deployment remain under their published limits and approved deferrals. Historical 1.3.0 guidance and evidence are preserved.

Attune Harness 1.3.0

Attune Harness 1.3.0 release notes

Published on PyPI October 7, 2026. This GitHub Release records the existing
1.3.0 package at signed tag v1.3.0, commit
0ecf8e6058cee9ed6f9b9510e043e3af3cbe1da0. It contains no later changes from main.

1.3.0 lets plan and fix start from a command. Until now, both verbs
needed a file nobody wrote for you: plan --request needed a work request
with a frozen effects manifest, and fix needed a trusted probe. init --for
writes each one, checked by the verb that reads it (O-70). Use an isolated
environment:

pipx install 'attune-harness[all]==1.3.0'

The v1 compatibility contract holds. Envelope keys only grow: init adds
files. Existing defaults and exit codes are unchanged, and
docs/deprecations.json stays empty. One argparse effect is new: init --f,
--fo and --t are now ambiguous abbreviations. Spell --force, --tests
or --task-dir.

What is new

• init --for fix writes probe.json, the trusted probe fix reads. It
  runs the named tests with pytest. Before writing, init runs the same freeze
  fix runs, as a dry run, so anything fix would refuse is refused first, in
  the same words. It runs nothing. Its next_action is the fix preview.
• init --for plan writes a work request plan --request accepts as
  written: the goal, the scope, the named tests as acceptance, one task,
  distinct worker and reviewer, and an effects manifest frozen over the
  checkout. It goes beside the task directory, as <task-dir>.work.json,
  outside the checkout the manifest freezes. Writing it accepts nothing: the
  preview and --accept stay separate steps. A refused init removes what it
  wrote.
• Example participants in examples/starter/participants.json finish both
  journeys with no model call. They are example code, not a profile: lead
  applies one declared replacement and reviewer approves without judging.
  They need python on PATH.
• The Claude Code plugin comes from a release tag. The 1.3.0 plugin uses
  v1.3.0 and its verified release commit, rather than unreleased main.
• build says when its participants cannot build. Every profile init
  writes is for review, so build refuses a plan made with one. The refusal
  now names those participants, comes before any dispatch flag is asked for,
  and says to plan again with participants that can propose files;
  init --for plan says so up front (O-77). The starter journeys run from a
  checkout of this repository with a virtual environment activated, because
  examples/ is not in the package.
• Symlink refusals name the path to use. On macOS, /tmp and /var are
  symlinks, so a task directory under them is refused. The refusal now says
  which link and what to use instead (O-76).

Additional changes included in 1.3.0

• Shared source review and roundtable: bounded preparation, explicit dispatch,
  inspection and abandonment over immutable selected source bytes. Retained
  evidence distinguishes requested and reported model identities and preserves
  unresolved outcomes. These tools do not authorize their own model calls.
• Consultation evidence and Antigravity: inspect frozen cited lines and retain
  checkpoint-bound citation judgments. Explicit Antigravity seats record model,
  effort and correlated process evidence; Codex seats can specify reasoning
  effort. This does not establish tool isolation or native plan/build parity.
• Browser intake and intent approval: register existing feature-work drafts,
  save partial answers, inspect the current preview and explicitly accept intent.
  Existing CLI/agent forms remain supported. The loopback server retains session,
  origin, checkpoint and single-use decision checks. Browser build grants,
  dispatch, resume and broader GUI navigation are deferred to 1.4.0; neither
  launch flags nor direct HTTP execution routes enable them. M2 completion is
  not required for this bounded forms release. Confirmed saves and intent
  acceptance show inline success; unsuccessful submissions remain explicitly
  unconfirmed, with copyable answers and disabled controls. Accepted cards show
  intent acceptance. Cards lead with “Draft saved — ready for review” or
  “Intent accepted”, with the work goal beneath. Partial drafts say more answers
  are needed. The “Saved work” list includes both states, and confirmed retained
  forms update their headings while staying read-only.
  Browser storage refusals no longer abort startup or disable Refresh. The
  private launcher link works for the current page; if session storage is
  unavailable, reopen that complete link after reloading the page.
  Saved answers name the next step in Saved work. Editable cards show a bold Tip
  and a Continue form or Review your answers button, selected from the saved owner
  state. Accepted cards explain that intake and review are complete; execution
  stays separate.
  Reopened intake forms show Saved answers above the remaining questions.
  The full owner record stays below the form under Technical details (optional).
  Saved answers remain evidence, never prefilled into a newly issued field;
  the explicit approval boundary remains unchanged.
  Approval previews show questions with their saved answers in plain language.
  Full owner markdown, action definitions, checkpoint metadata and file-effects
  JSON stay in a collapsed Technical details disclosure. Owner readiness
  blockers remain visible outside it, with no unavailable action enabled.
  Open in browser is available in editable and read-only forms views. Panels
  at most 600 pixels wide recommend it; opening requires a click. The launcher
  requests the same private workspace in the system browser, which decides
  whether to use a tab or window. Copy unsaved answers before switching views;
  they remain read-only in the original view and are never transferred or saved
  automatically. This does not resize host panels or choose a monitor.
• Reliability: malformed native-memory content entries now retain structured
  refusal evidence. Starter failures clean up their own partial writes, forced
  probe backups count toward the entry bound, and Claude refusal classification
  distinguishes completed refusals from uncertain supervision failures.
  Native-root recall, refresh and document resolve retain generated status,
  staleness and provenance, including recorded WRONG verdicts; tombstones remain
  inspectable. Source and sidecar changes invalidate existing handles. Nonfinite
  raw-memory timestamps expire instead of bypassing the age check.
• Packaging and diagnostics: Codex onboarding no longer assumes unbundled
  helper scripts; qualification retains timing and slow-stack evidence. Windows
  supplemental coverage has temporary measurement headroom, not broader platform
  qualification. The Windows-traps guide and compact Shepherd reference are added.
  Installed qualification rejects editable or copied-source imports and optimized
  Python before effects, and its receipt records the final aggregate exit as well
  as the pytest exit.

See model consultation, the GUI specification,
Windows guidance and Shepherd.

The two journeys

The CLI guide's plan and fix sections open with blocks that CI runs as
printed on the installed wheel. The fix block runs on POSIX only, as fix
is qualified.

attune-harness init --for fix --project /path/to/repo --scope calc.py \
  --interpreter /path/to/venv/bin/python --tests tests/test_calc.py

See Plan and build and
Scoped repair.

Known limits

• --test-root . is still refused (O-76).
• Windows native-memory, fix and test limits remain as documented; isolated
  backend checks do not broaden the supported command surface.
• Native-memory SDK/live model quality is not established by offline tests.
• Fresh-session memory observations (S3), a qualifying non-programmer walkthrough
  (S6), and installed migration observations (S9) remain open.
• The Claude marketplace explicitly lists Harness, cross-review and smart-test.
  The bundled roundtable skill is included in Codex packaging but is not selected
  by that marketplace entry. A tag-pointer update alone does not add it.
• GUI browser, embedded-host, accessibility and real-user observations remain
  open acceptance gaps. Published library qualification does not close those
  observations; broader GUI remains deferred to 1.4.0.
  Retained research/opportunity prototypes are not installed-product qualification.

Evidence

The released source is commit 0ecf8e6058cee9ed6f9b9510e043e3af3cbe1da0 (#228),
signed tag v1.3.0. The successful Library qualification
and PyPI publishing run
both target that exact commit. The attached files are the original publishing
run's distributions, independently matched to PyPI by size and SHA-256:

7b6f40a41f5017aa0f96c3f83aee21f7eef2af8d38c951d76c363c3512fdd18a  attune_harness-1.3.0-py3-none-any.whl
c7c564e07b011c6eaad2617c8368819f8241c278e61d3d18c887951edc2a5e36  attune_harness-1.3.0.tar.gz

Merged intake/approval implementation and recovery changes support the bounded
browser forms slice. Broader GUI execution remains deferred and unreachable from
the 1.3.0 release ser...

Attune Harness 1.2.0

Attune Harness 1.2.0 release notes

1.2.0 gives a stuck review task a way forward. When the claude CLI refused
a participant turn before any model ran, for example because the login had
expired or the account was out of usage credits, the task could not be resumed
or reconciled. The only way on was a new task, which repeated turns that had
already completed and been paid for (#182). Use an isolated environment:

pipx install 'attune-harness[all]==1.2.0'

The v1 compatibility contract holds. No JSON envelope key, default or exit code
changes, and docs/deprecations.json stays empty. The new flag and the new
saved event field are additive.

What is new

• reconcile-task --retry-refused (and reconcile-review --retry-refused)
  authorizes one retry of a participant turn the Claude CLI refused. It is
  available only when the CLI exited with a structured error result that has no
  structured output and an explicitly empty modelUsage. The failed turn saves
  that result as native_refusal. Diagnostic text alone never qualifies. The
  retry is recorded as an operator decision alongside that evidence, and
  provider usage may repeat. resume then continues. Completed turns, including
  another participant's finished turn, are replayed rather than dispatched
  again. A turn without this evidence still reconciles with a recovered reply,
  or cancel-task closes the record.
• init names the flags each route takes. For the claude and codex
  profiles, next_action now says a review needs --allow-external and only
  plan and build also take --allow-native. The requires field is
  unchanged.

Recovering a refused turn

attune-harness status TASK_DIR
attune-harness reconcile-task TASK_DIR --event EVENT_ID --retry-refused
attune-harness resume TASK_DIR

Fix the cause first (log in again, or add credits). See
the recovery workflow.

Attune Harness 1.1.0

1.1.0 makes every task verb reachable from a fresh install. A cold
walkthrough of 1.0.1 found that only test completed: plan, review and
fix needed a participant registry that nothing wrote, refusals came in three
shapes, and the Harness skill had no way into Claude Code. Use an isolated
environment:

pipx install 'attune-harness[all]==1.1.0'

The v1 compatibility contract holds. Every JSON envelope key, default and
saved-state format is unchanged, and docs/deprecations.json stays empty. New
verbs, options and golden rows are additive. Two behaviours change, and each
is listed under "Behaviour changes" below.

What is new

• attune-harness init writes a starter participants.json: demo
  (two offline deterministic participants, the default), claude or codex
  (a lead and a reviewer on different models). It refuses to replace a
  registry unless given --force, which keeps a backup. Writing a native
  profile authorizes nothing.
• Refusals name the next step. review, fix and plan without a
  registry name init. Every refusal from the task verbs and controls carries
  next_action. A rejected option combination for review or fix is a JSON
  refusal on stdout rather than usage text on stderr, and still exits 2.
• Path refusals explain resolution. --document, --context and
  --corpus resolve against --project, and --config against the working
  directory. A refusal now says which base it used and what the path resolved
  to.
• Readable output on request. --format markdown on plan, build,
  review, fix, test and resume prints the same result for people, with
  the same exit code. status --format markdown|html works for every task.
• The Claude Code plugin. /plugin marketplace add Smart-AI-Memory/attune-harness
  installs the Harness skill with cross-review and smart-test. The Codex
  plugins are unchanged.
• Documented journeys run in CI. Blocks tagged in the README and the CLI
  guide run as written, from an empty directory, in every installed-wheel
  platform job.

Behaviour changes

• status --format markdown|html on a task other than feature-work-v1 used
  to be refused with exit 2. It now renders the task and exits 0.
• A rejected combination of valid options for review or fix (for example
  fix --goal alone) used to print argparse usage text on stderr. It now
  prints a JSON refusal on stdout. The exit code is still 2.

Limits

• plan/build and fix still have no copy-and-paste example: they need a
  frozen effects manifest and a trusted probe that no command writes. The
  offline plan, accept, build and review journey in scripts/check_installed.py
  covers them in CI.
• Markdown status for assessment and repair tasks is the generic envelope
  rendering, not a designed per-profile report.
• This release adds no model or platform qualification. The named
  non-programmer walkthrough (S6) is still to be performed. It is now worth
  scheduling, because each verb starts from a fresh install.

Attune Harness 1.0.1

Attune Harness 1.0.1 release notes

1.0.1 fixes documentation links on the PyPI project page. PyPI renders the
package README outside GitHub, so repository-relative links in 1.0.0 led to
404 pages. The README now links to release-specific GitHub documentation, and
the link check catches this class of error before a future release.

The runtime files, dependency pins and v1 compatibility contract are unchanged
from 1.0.0. Use an isolated environment:

pipx install 'attune-harness[all]==1.0.1'

See the 1.0.0 release notes for the stable scope,
qualification evidence and limits. This patch does not add model or platform
qualification. The originally planned fourteen days of candidate observation,
named non-programmer walkthrough, ordinary host and memory observations, and
migration trial remain unverified.

Attune Harness 1.0.0

Attune Harness 1.0.0 makes the v1 compatibility contract the stable PyPI default. It promotes the rc2 runtime without a CLI, API, saved-state format, runtime-file, or dependency-pin change. The rc2 [all] and [voyage] resolution fix is included.

Install in a separate environment:

pipx install 'attune-harness[all]==1.0.0'

The supported core covers explicit plan, acceptance, build, review, fix, test, and saved-task inspection with local receipts. Native model-driven planning/building, the memory-native extra, some Windows paths, and host integrations retain the limits in the release notes and qualification guide. Attune AI is not deprecated by this release.

This stable release was accelerated for PyPI discoverability. The originally planned 14-day observed candidate period, named non-programmer walkthrough, and ordinary host, memory, and migration observations were not completed before publication; they remain visible in the release plan. Software checks do not establish those human outcomes.

Release commit: 6a383e1d5442a19b069f95edc7672496194c81bb. Exact-main six-platform qualification and PyPI publishing run passed. A fresh unconstrained PyPI [all] install passed pip check and the installed Forms plan/accept/build/review journey with zero model calls.

Publishing-run SHA-256:

• attune_harness-1.0.0-py3-none-any.whl: a48217441bb75de06b8577e29ebd85ce5224de6546117038b1a394674f380b05
• attune_harness-1.0.0.tar.gz: 25de8d692ce4ff06d8c43a0268e0dd548072d8f23d7d6f434512f8fe8dcc7db4

attune-harness 1.0.0rc2

Attune Harness 1.0.0rc2 is a release candidate, not stable 1.0.

This candidate fixes fresh voyage and all installations by pinning
httpx2==2.13.0, the version required by the signed Voyage plugin import closure.
An unconstrained rc1 installation could select 2.13.1 and refuse that plugin path.
No saved-state format or public CLI contract changed. Rc1 and its evidence remain
available; use rc2 for new candidate installations.

Install explicitly into an isolated environment:

pipx install 'attune-harness[all]==1.0.0rc2'

Release commit: 6ed6b1825c8c2846f39a7ef4c0cc2063106d573f.

Release notes ·
Qualification and limits ·
Main qualification run

The candidate observation period and separate stable-release acceptance still
apply. Publication does not establish model quality or full Attune AI parity.

attune-harness 1.0.0rc1

• Prepare 1.0.0rc1 package metadata and capture the candidate saved-state
  fixture from a clean, installed local writer wheel. The fixture retains exact
  record bytes and reader/replay/refusal cases; publication and the observed
  candidate period are separate release steps.

• Pin each CLI argument's accepted choices and default in the 1.0 surface
  fixture, including the working-directory default for spec intake --project.
  Reconcile current-main signed-plugin and Voyage qualification claims with
  their bounded platform and recorded-response evidence.

• Read a single memory configuration with both native recall roots and saved
  storage: memory recall sets aside the saved section while memory saved
  continues to use it.

• Executable plugins can read selected installed wheel metadata through the
  bounded import closure, supporting offline Voyage SDK and compiled dependency
  imports without exposing site-packages or undeclared distribution metadata.

• Preserve the host-owned dispatching stage when a provider adapter reports
  an interrupted subprocess, refusing automatic replay without exposing child diagnostics.

• Legacy Codex build timeouts can retain an explicit operator stop observation
  for one bounded retry, without inventing historical process evidence.

• Add a signed Python plugin run binding with explicit grants, a declared
  import closure, bounded subprocesses, and unresolved receipts when host
  evidence changes. MCP and review wrap results as untrusted data.
  Network plugins await host-owned provider journals; platform qualification
  claims remain unchanged.

• Add the empty active deprecation register and opt-in envelope notice helper
  for the stable compatibility promise. Pin actual retrieval MCP listings by
  protocol version and the A2A local profile. No current form is deprecated;
  the candidate saved-state freeze remains pending executable-plugin completion.

• End the legacy memory adapter transition (D28): reader: adapter is now
  refused with "Memory reader must be 'native'". Native formats remain frozen
  as read; offline worker and native read envelopes replace adapter fixtures.

• Preserve optional deferred opportunity-review checkpoints on saved tasks,
  with visible resume guidance and memory saved list --pending-review.
  Task completion does not clear a pending review.

• Add explicit memory saved save, inspect, search, revise, withdraw, complete
  and reindex commands. Local POSIX files retain history and retry identities;
  optional Redis indexing reports pending work without losing durable saves.

• Codex build proposals isolate user configuration and plugin integrations.
  Stopped native timeouts retain process evidence and support one explicit,
  checkpoint-bound retry while preserving the failed attempt.

• Raise the complete-checkout snapshot limit to 2,048 entries for build and
  repair, consistently across capture and validation. Files, directories and
  Git metadata remain checked; the 16 MiB tree and 64 KiB edit limits remain.

• Preserve attributed design feedback and a current discussion question in task
  briefings, with consistent section labels and accessible definition controls.
  Keep presentation revision, task inspection time and report time distinct;
  historical/stale/completed tasks withhold the retained question.

• Add a Saved Tasks entrance through explicit status --include-task inputs.
  Human briefings separate context, goal, desired end state and current focus;
  optional attributed summaries stay bound to their continuation revision.
  Local reply controls prepare text for an assistant without sending, approving
  or executing it. Default JSON and saved task authority remain unchanged.

• Add opt-in status --format markdown|html return-to-work views for saved
  feature-work tasks. --continuation FILE adds an explicitly supplied stopping
  point, attributed external progress and a comparison with retained request scope.
  Current task guidance takes precedence; supporting evidence stays inspectable.
  Default JSON output and task execution semantics remain unchanged.

• Add the workspace MCP profile, Spec intake/presentation CLI, and local Claude
  and Codex plugin candidates. Lifecycle gates remain a separate prerequisite;
  the Spec skill stops at that boundary. No marketplace release is claimed.

attune-harness v0.6.0

attune-harness 0.6.0

This alpha release completes the native plan/build journey and adds filtered memory delivery, prompt-related recall, external-plan import receipts, and versioned scratch storage.

• memory serve checks active membership and authorized file verdicts before displaying memory. Banners identify provenance and untrusted evidence; --for PROMPT supports the documented UserPromptSubmit bridge.
• Native plan acceptance follows the workspace execution stages. External legacy plans can be imported without modifying their originals, with a receipt for each conversion.
• Scratch records carry a format, writer and version. Compare-and-set detects conflicting updates; uncertain writes are reported explicitly. Expired-key cleanup respects concurrent compare-and-set writes.
• Signed and revocable plugin bundles establish the trust groundwork. Executable plugin dispatch remains future work.
• CLI/API compatibility inventories and installed native-journey checks strengthen the release gates.

The release commit passed the full suite and installed-wheel qualification on Ubuntu, macOS and Windows with Python 3.10 and 3.12. A maintainer-run fresh Claude Code session confirmed both memory-hook banners. Existing platform and experimental-feature limits still apply; see the README qualification table.

Install or upgrade:

python -m pip install --upgrade attune-harness==0.6.0

Add [redis] for Redis memory support, or [all] for both qualified extras.

Changelog · CLI guide

attune-harness 0.5.0

Memory is native. attune-harness memory recall, resolve and refresh
read explicit raw, personal and curated roots with Harness's own
reader by default, nothing from attune-ai on the path: the standard library
for the raw tier and attune-rag's keyword retriever, already in the base
install, for the document tiers (native memory Phase 2, D19). The reader
reproduces the adapter's contract, its refusal texts, the strict content
gate carried verbatim from the sanitizer's patterns, and the provenance and
staleness metadata on document items; a differential against attune-ai's
adapter, run where its checkout exists, agrees on statuses, result order,
texts, versions and every item's metadata. "reader": "adapter" keeps that
adapter selectable as the rollback until the transition ends. The import
guard's known list is empty; the release gate reads a raw root from the
--no-deps wheel and asserts on the receipt; the golden envelope table pins
the native shapes. The reader is POSIX-only until the Phase 4 decision; on
Windows it reports the refusal. Interfaces may still change before 1.0; the
README's qualification table says what is and is not covered.

The full list of changes is the 0.5.0 section of CHANGELOG.md.

Published to PyPI from 31e1d906f49e55cdee2c7bdad996323aae7a66dc by run 35822819696. The attached files are the ones that run built and uploaded:

61a9c9b5c844bc25ab556eb60c8fea6b42130b4ca69f3c80eb7fa8e280574210  attune_harness-0.5.0-py3-none-any.whl
88b6bdf0cdbfc9f4fe617cee34f71b0fdbb33f442923a8d1c43566c15ea4649c  attune_harness-0.5.0.tar.gz