agentflow-proof 1.1.0__tar.gz → 1.2.0__tar.gz

{agentflow_proof-1.1.0 → agentflow_proof-1.2.0}/CHANGELOG.md

@@ -7,6 +7,134 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.2.0] - 2026-10-29
+
+Agentflow 1.2.0 shows why a run is stuck. `next-step --explain` reports why
+no step is eligible (#71). `next-action` reports the blockers recorded with
+`block-step` and `fail-step`, and the stop hook prints the current ones when it
+refuses a stop (#72). `next-action` now answers only from the ledger rows it
+validated, and agent-written ledger text reaches the terminal with
+non-printable characters shown as `?`. Every change is additive under
+`docs/stability.md`: a new flag, a new `next-action --json` key, new
+`value_sets` codes in `docs/cli-contract.json` and an optional MCP input. No
+artifact schema or schema-version constant changes.
+
+### Added
+
+- `next-action --json` reports `recorded_blockers`. It has one entry per
+  attempt closed by `block-step` or `fail-step`, in ledger order, with
+  `step_id`, `attempt_id`, `event` (`blocked` or `failed`), `reason`,
+  `recorded_at`, `attempt_owner` and `superseded_by` (the first later attempt
+  of the same step, or `null` for a current blocker). It is derived from the
+  validated step ledger and absent for `uninitialized`, `plan_unlocked`,
+  `execution_uninitialized` and `state_invalid`. `state`, `blocking` and the
+  recovery actions are unchanged. The MCP `next_action` tool carries the field.
+  Human `next-action` output adds one `recorded blocker:` line per current
+  blocker, with control characters shown as `?` and the reason cut at 200
+  characters. (#72)
+
+- `next-step --explain` reports why no step is eligible. With `--json` it
+  prints `{step, reason_code, diagnostics}`, where `reason_code` is
+  `eligible`, `dependencies_unmet`, `open_attempts` or `steps_complete`.
+  `steps_complete` requires that no attempt is open anywhere, amendments
+  included; it does not mean the run verifies (use `next-action`). With
+  `--explain`, an invalid plan, contract or ledger exits 1 instead of looking
+  like a finished run. Plain `next-step` and `next-step --json` are
+  unchanged. `docs/cli-contract.json` lists the codes in `value_sets`. MCP
+  `next_step` takes an optional `explain` input. (#71)
+
+### Changed
+
+- `hooks/stop-gate.sh` prints `agentflow next-action` (the next action and any
+  current recorded blocker) and a fixed line pointing to operator interruption
+  to stderr when it refuses a stop. Stdout and exit codes are unchanged, and a
+  recorded blocker still does not satisfy the gate. (#72)
+
+### Fixed
+
+- `next-action` reduces step state and selects the eligible step from the
+  `.agent/step-runs.jsonl` rows it validates and derives `recorded_blockers`
+  from. It used to read the ledger again for both, so a row appended during
+  the call could change the step state or the step offered to claim without
+  passing validation. (#72 follow-up)
+
+- `next-action` answers from that validated snapshot or not at all. The
+  amend, in-flight, run, drift and proof checks read `.agent/` again, so when
+  the step, command or file receipt ledgers no longer equal the validated read
+  it now reports `state_invalid` ("execution ledgers changed during
+  next-action; run it again") instead of an answer steered by a row that never
+  passed validation. Malformed or unreadable ledgers encountered by the
+  downstream checks produce the same diagnostic. A claim offer comes from the
+  snapshot alone and is unaffected. (#72 follow-up)
+
+- Standard output of `events`, `next-action`, `next-step --explain`,
+  `finish-step`, `finish-run`, `verify-step`, `detect-stuck` and
+  `replay-gates` shows non-printable characters in agent-written ledger text
+  (reasons, agent, attempt and receipt ids, recorded argv, recorded paths) as
+  `?`, as the `recorded blocker:` lines already did, so ANSI escapes, line
+  breaks and bidi overrides written to `.agent/` no longer reach the terminal
+  through these commands. `events` cuts a reason at 200 characters. `--json`
+  and `--jsonl` output is unchanged. The next entry covers the remaining
+  human output and error messages. (#71 follow-up)
+
+- Human output of `audit-drift`, `verify-run`, `build-proof`, `verify-proof`,
+  `status`, `doctor`, `runtime-status` and `lint-handoff`, the acknowledgement
+  lines of commands that write `.agent/` ledgers, and error messages on stderr
+  also show non-printable characters as `?`. So does that text where it is
+  captured: `finish-run --json` `diagnostics`, and MCP `content` text,
+  `structuredContent.stdout` and `structuredContent.stderr` (the `status`,
+  `audit_drift`, `build_proof` and `verify_proof` tools return human output,
+  and a failing tool returns its stderr), including the error text the MCP
+  server builds for an unexpected exception. The rendering is deliberately
+  lossy: tab, NBSP and ZWJ also become `?`, and a multi-line message such as
+  git's own stderr prints as one line. Gate output is sanitized before
+  `finish-run` splits it into lines, so a recorded line break no longer adds
+  `diagnostics` entries. Captured human text has no byte-stability guarantee.
+  JSON keys and types, raw values in other `--json` output and in `.agent/`
+  files, flags and exit codes are unchanged. (#71 follow-up)
+
+## [1.1.1] - 2026-10-26
+
+Agentflow 1.1.1 closes two gaps through which a step could complete, and a
+proof issue, over a gate whose last run failed. `verify-step` judges a
+structured command gate by its latest receipt in the attempt instead of its
+first (#77), and `complete-step` re-runs that judgment before it closes an
+attempt, as `finish-step` already did (#81). A failed gate run followed by an
+identical passing one now verifies in the same attempt. No flag, artifact
+schema, schema-version constant or `docs/cli-contract.json` change.
+
+### Fixed
+
+- `verify-step` judges a structured command gate (`{"kind": "command", "run":
+  [...]}`) by the latest receipt in the attempt with the gate's exact argv. It
+  used the first one; legacy `step.validation` gates and requirement coverage
+  already used the latest. The verdict moves in both directions. It relaxes: a
+  failed first run followed by an identical passing run in the same attempt now
+  verifies, and `next-action` recommends `finish-step` instead of asking for the
+  same run again. It tightens: an identical failing or timed-out run after a
+  passing one now fails `verify-step` instead of being masked, so an attempt
+  that verified only because its later failure was ignored fails if
+  `verify-step` runs on it again. `finish-step`, `next-action` and the MCP
+  `verify_step` tool follow, since they use the same check, and the per-gate
+  `receipt_id` in the `next-action --json` resumability projection names the
+  later receipt. `complete-step` and `finish-step` still refuse an attempt that
+  holds a timed-out receipt anywhere in it. No receipt, artifact schema or
+  schema-version constant changes. (#77)
+- `complete-step` re-runs the `verify-step` judgment (gates on their latest
+  receipts, inspection evidence and file scope) before it closes the attempt, as
+  `finish-step` already did. Previously it only checked that `verify-step` had
+  passed at some point, so a gate that failed after `verify-step` still
+  completed the step, and `verify-run`, `build-proof` and `verify-proof` then
+  passed over a failing last run. It now refuses (exit 1, nothing written) with
+  `<step> attempt <id> no longer passes verify-step: ...`; rerun the gate to a
+  pass, then complete. It reads `.agent/plan.lock.json` for this check and
+  refuses (exit 1, `cannot re-check <step> before completing: ...`) when the
+  plan is missing, unreadable or not a JSON object. Its other refusals keep
+  their messages and order: no or unopened attempt, closed attempt, a command
+  still running, a timed-out receipt, no `verify-step` yet, not the owner. The
+  MCP `complete_step` tool follows. No flag, artifact schema or schema-version
+  constant changes. (#81)
+
 ## [1.1.0] - 2026-10-18
 
 Agentflow 1.1.0 closes integrity and recovery gaps in the execution ledger and
@@ -219,7 +347,9 @@ repository, so this heading is intentionally unlinked._
 
 - Existing v0.2 proof artifacts remain valid when no execution contract exists.
 
-[Unreleased]: https://github.com/kstruzzieri/agentflow/compare/v1.1.0...HEAD
+[Unreleased]: https://github.com/kstruzzieri/agentflow/compare/v1.2.0...HEAD
+[1.2.0]: https://github.com/kstruzzieri/agentflow/compare/v1.1.1...v1.2.0
+[1.1.1]: https://github.com/kstruzzieri/agentflow/compare/v1.1.0...v1.1.1
 [1.1.0]: https://github.com/kstruzzieri/agentflow/compare/v1.0.0...v1.1.0
 [1.0.0]: https://github.com/kstruzzieri/agentflow/releases/tag/v1.0.0
 [0.4.0]: https://github.com/kstruzzieri/agentflow/releases/tag/v0.4.0

{agentflow_proof-1.1.0/src/agentflow_proof.egg-info → agentflow_proof-1.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: agentflow-proof
-Version: 1.1.0
+Version: 1.2.0
 Summary: A model-agnostic workflow runner for drift-resistant agentic development.
 Author: Agentflow contributors
 License-Expression: MIT

{agentflow_proof-1.1.0 → agentflow_proof-1.2.0}/pyproject.toml

@@ -1,10 +1,10 @@
 [build-system]
-requires = ["setuptools==83.0.0"]
+requires = ["setuptools==84.1.0"]
 build-backend = "setuptools.build_meta"
 
 [project]
 name = "agentflow-proof"
-version = "1.1.0"
+version = "1.2.0"
 description = "A model-agnostic workflow runner for drift-resistant agentic development."
 readme = "README.md"
 requires-python = ">=3.11"

{agentflow_proof-1.1.0 → agentflow_proof-1.2.0}/src/agentflow/__init__.py

@@ -2,4 +2,4 @@
 
 __all__ = ["__version__"]
 
-__version__ = "1.1.0"
+__version__ = "1.2.0"