loopy-loop 0.4.0__tar.gz → 0.5.0__tar.gz

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/CHANGELOG.md

@@ -1,5 +1,68 @@
 # Changelog
 
+## 0.5.0
+
+- **events.jsonl is now written (P1.1).** The coordinator appends one
+  versioned JSON event per significant transition — `session_started`,
+  `task_dispatched`, `task_finished` (with tokens/duration/failure_kind),
+  `iteration_abandoned`, `goal_check`, `child_started`, `child_finished`,
+  `session_stopped` — to each session's `events.jsonl` after the producing
+  state mutation commits. Delivery is best-effort by design: a crash in the
+  commit-to-append window drops the event while the durable truth
+  (`state.json` history/ledger) survives; readers key on `event_id` and
+  tolerate gaps and a torn final line. New `loopy events [--follow]
+  [--json]` tails the deepest active session's stream and follows the
+  active session as it changes.
+- **Usage/cost ledger + `max_cost_usd` (P1.1).** The worker reads
+  coordinator-model token usage from team-harness's `run.json` and reports
+  it (plus wall-clock duration) on `/finished`; the coordinator keeps a
+  durable per-session ledger in `state.json` and records a finalized
+  child's totals on its `children.json` record. With the new optional
+  `model_prices` (USD per 1M tokens, coordinator-side), `loopy status`
+  shows estimated cost and the new optional `max_cost_usd` budget stops
+  the loop with `stop_reason="max_cost_usd"`. Cost explicitly covers the
+  harness coordinator model only — agent-CLI subprocess spend is not
+  measurable and is never pretended into the number.
+- **`loopy status` shows the session stack and `--watch`.** While a child
+  session runs, `status` now walks the durable parent→child pointers and
+  shows the live child (previously it showed only the suspended parent);
+  `--watch` re-renders every 2 seconds.
+
+- **Failure taxonomy + per-workflow failure cap (P2.3).** Failed iterations
+  now record a `failure_kind` — `transient` (provider said retry;
+  team-harness's own retries were exhausted), `deterministic` (auth/config
+  errors retries cannot fix), `crash` (worker died mid-iteration), or
+  `unknown` — on `result.json`, `/finished`, and session history. A new
+  coordinator-side `workflow_consecutive_failures_cap` (default 5) stops the
+  loop with `stop_reason="workflow_failure_cap"` when the same workflow fails
+  that many iterations in a row (crash-abandoned iterations included; any
+  success resets the workflow's counter) instead of burning the remaining
+  `max_turns` on a wedged workflow. The cap is not part of the wire config
+  snapshot, so released workers are unaffected.
+- **Agent Skill rewritten for the current API (P1.3).** `skills/loopy-loop/SKILL.md`
+  still described the removed pre-0.2.0 surface (top-level `.loopy_loop/state.json`,
+  polling multi-worker model, inline `goal`, `.loopy_loop/workflows/<id>/` layout) and
+  would have taught agents to generate broken setups. It now documents the 0.4.0
+  reality: `goal_file`, workflow sets, all three templates, the single
+  identity-verified worker, child sessions, crash recovery, and resume semantics —
+  validated against clean `loopy init` runs of every template. Remaining plural
+  "workers" wording in the README corrected to the single-worker model.
+- **eval-banana is now a hard dependency.** The recommended
+  `inner_outer_eval` template (and the PM template's child sessions) shell
+  out to the `eval-banana` CLI; previously it had to be installed
+  separately, so a fresh install could dispatch eval workflows against a
+  missing tool. It now installs with loopy-loop — no extra, no preflight.
+- **Worker appends its bundled-CLI scripts directory to `PATH`.** Harness
+  agents inherit the worker's environment, but under `uv tool install` /
+  `pipx` only loopy-loop's own entry points are exposed on `PATH`, so
+  dependency CLIs such as `eval-banana` were invisible to agents. The
+  directory is derived from where eval-banana's script was actually
+  installed (its package record; `sysconfig` only as fallback — the default
+  scheme is wrong for e.g. `pip install --user` under a system
+  interpreter). It is appended, never prepended, and existing `PATH`
+  entries are preserved verbatim: the target repo's own `python`/tooling
+  and any eval-banana already on `PATH` keep winning.
+
 ## 0.4.0 (breaking)
 
 **Breaking API interaction — completions must echo the dispatched

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/Makefile

@@ -17,7 +17,7 @@ claudecontinue:
 ## Codex
 codex:
 	# do /fast
-	codex --yolo --model gpt-5.5
+	codex --yolo --model gpt-5.6-sol
 
 install_globally:
 	uv tool install --editable "$(CURDIR)"

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: loopy-loop
-Version: 0.4.0
+Version: 0.5.0
 Summary: Run long-running AI agent workflows inside your repository.
 Project-URL: Homepage, https://github.com/writeitai/loopy-loop
 Project-URL: Repository, https://github.com/writeitai/loopy-loop
@@ -23,6 +23,7 @@ Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Classifier: Typing :: Typed
 Requires-Python: >=3.12
 Requires-Dist: click>=8.1
+Requires-Dist: eval-banana>=0.3.1
 Requires-Dist: fastapi>=0.115.0
 Requires-Dist: filelock>=3.16
 Requires-Dist: httpx>=0.28
@@ -58,12 +59,13 @@ and PRs.
 
 Under the hood, loopy-loop runs a small FastAPI coordinator and a single
 worker. The coordinator owns the loop state and chooses the next workflow. The
-workers run assignments through
+worker runs assignments through
 [`team-harness`](https://github.com/writeitai/team-harness), which can delegate
 to agent CLIs such as Codex, Claude Code, and Gemini. The packaged
 `inner_outer_eval` template also uses
 [`eval-banana`](https://github.com/writeitai/eval-banana) conventions for
-session-scoped evaluation checks.
+session-scoped evaluation checks; eval-banana installs automatically as a
+loopy-loop dependency.
 
 ## Install
 
@@ -118,7 +120,8 @@ This is the recommended starting template. It creates:
 - a `.gitignore` entry for `.loopy_loop/sessions/`
 
 `loopy init` is idempotent. It creates missing files and leaves existing files
-alone.
+alone — except `.gitignore`, which is updated in place to ensure the sessions
+ignore rule.
 
 ## Write the Goal
 
@@ -244,6 +247,7 @@ goal_file: loopy_loop_goal.txt
 workflow_set: inner_outer_eval
 max_turns: 160
 goal_check_consecutive_failures_cap: 3
+# workflow_consecutive_failures_cap: 5
 team_harness_provider: "codex"
 team_harness_model: "gpt-5.5"
 team_harness_agents:
@@ -278,7 +282,21 @@ Important rules:
   processes a dead worker left running: drain lets them finish (one shared
   bounded deadline) before the iteration is re-run; reap kills them
   immediately. These are coordinator-side settings and are not part of the
-  config snapshot sent to workers.
+  config snapshot sent to the worker.
+- `workflow_consecutive_failures_cap` (default 5) is a per-workflow circuit
+  breaker: that many consecutive failed iterations of the same workflow stop
+  the loop with `stop_reason="workflow_failure_cap"` instead of retrying a
+  wedged workflow until `max_turns`. Any success of the workflow resets its
+  counter. Coordinator-side only; not part of the config snapshot sent to
+  the worker.
+- `model_prices` (optional, coordinator-side only) sets USD prices per 1M
+  tokens for the harness coordinator model (`prompt_usd_per_1m`,
+  `completion_usd_per_1m`); with prices set, `loopy status` derives an
+  estimated cost from the token ledger. `max_cost_usd` (optional, requires
+  `model_prices`) stops the loop with `stop_reason="max_cost_usd"` once the
+  session tree's estimated cost reaches the budget. Cost covers the harness
+  COORDINATOR model only — agent-CLI subprocesses (codex, claude, gemini)
+  bill through their own accounts and are not measurable here.
 
 Workflow config lives beside each workflow prompt:
 
@@ -332,8 +350,12 @@ Important session files:
 
 - `goal.md`: the exact goal text copied into the session.
 - `session.json`: session metadata.
-- `state.json`: coordinator-owned dispatch state.
-- `events.jsonl`: reserved append-only diagnostics log.
+- `state.json`: coordinator-owned dispatch state, including the session's
+  token/duration usage ledger.
+- `events.jsonl`: append-only event stream — one versioned JSON line per
+  significant transition (`session_started`, `task_dispatched`,
+  `task_finished`, `iteration_abandoned`, `goal_check`, `child_started`,
+  `child_finished`, `session_stopped`). Tail it with `loopy events --follow`.
 - `control.json`: workflow-owned stop switch.
 - `updates_from_user.md`: human-writable inbox for changes after the session
   starts.
@@ -419,7 +441,13 @@ To stop because the loop cannot continue:
 A valid `goal_check.json` does not stop the loop by itself. It is evidence.
 Stopping is controlled by session `control.json`. If goal-check output is
 missing or invalid repeatedly, the coordinator stops with
-`stop_reason="goal_check_broken"` after the configured failure cap.
+`stop_reason="goal_check_broken"` after the configured failure cap. Similarly,
+consecutive failed iterations of any single workflow stop the loop with
+`stop_reason="workflow_failure_cap"` after `workflow_consecutive_failures_cap`.
+Failed iterations record a `failure_kind` in history — `transient` (provider
+said retry; team-harness's own retries were exhausted), `deterministic`
+(auth/config errors retries cannot fix), `crash` (worker died mid-iteration),
+or `unknown` — so a stopped run is legible without reading harness logs.
 
 ## Workflow Sets and Child Sessions
 
@@ -431,8 +459,11 @@ Workflow sets are mandatory. Even a single-loop repo uses:
 
 The older `.loopy_loop/workflows/...` layout is not loaded.
 
-A workflow can request one sequential child session by writing a JSON file under
-the active session's `child_requests/` directory:
+A top-level session's workflow can request one sequential child session by
+writing a uniquely named `*.json` file under the active session's
+`child_requests/` directory (only `*.json` filenames are scanned; publish via
+a non-`.json` temp name plus rename — invalid requests are renamed to
+`*.json.rejected` and skipped):
 
 ```json
 {
@@ -501,16 +532,24 @@ loopy worker --coordinator http://127.0.0.1:8080
 Runs a blocking worker until the coordinator returns `action: "stop"`.
 
 ```bash
-loopy status
+loopy status           # session stack, usage totals, estimated cost
+loopy status --watch   # re-render every 2 seconds
+loopy events           # the active session's event stream
+loopy events --follow  # tail it live (--json for raw lines)
 loopy stop
 ```
 
-`status` prints the latest session state. `stop` sets `stop_requested=true` in
-the latest session-local state.
+`status` prints the latest session state — the whole session stack while a
+child runs (the live child is shown under its suspended parent), each
+session's subtree token usage, and (with `model_prices` configured) estimated
+cost. `stop` still flags the latest **top-level** session only: a running
+child does not see the flag, and the stop takes effect once the child reaches
+a terminal state and the parent resumes.
 
 ## Related Projects
 
 - [`team-harness`](https://github.com/writeitai/team-harness): the model and
-  agent-CLI orchestration layer used by loopy-loop workers.
+  agent-CLI orchestration layer used by the loopy-loop worker.
 - [`eval-banana`](https://github.com/writeitai/eval-banana): a lightweight YAML
-  evaluation framework used by the packaged eval workflows.
+  evaluation framework used by the packaged eval workflows. Installed
+  automatically as a loopy-loop dependency.

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/README.md

@@ -18,12 +18,13 @@ and PRs.
 
 Under the hood, loopy-loop runs a small FastAPI coordinator and a single
 worker. The coordinator owns the loop state and chooses the next workflow. The
-workers run assignments through
+worker runs assignments through
 [`team-harness`](https://github.com/writeitai/team-harness), which can delegate
 to agent CLIs such as Codex, Claude Code, and Gemini. The packaged
 `inner_outer_eval` template also uses
 [`eval-banana`](https://github.com/writeitai/eval-banana) conventions for
-session-scoped evaluation checks.
+session-scoped evaluation checks; eval-banana installs automatically as a
+loopy-loop dependency.
 
 ## Install
 
@@ -78,7 +79,8 @@ This is the recommended starting template. It creates:
 - a `.gitignore` entry for `.loopy_loop/sessions/`
 
 `loopy init` is idempotent. It creates missing files and leaves existing files
-alone.
+alone — except `.gitignore`, which is updated in place to ensure the sessions
+ignore rule.
 
 ## Write the Goal
 
@@ -204,6 +206,7 @@ goal_file: loopy_loop_goal.txt
 workflow_set: inner_outer_eval
 max_turns: 160
 goal_check_consecutive_failures_cap: 3
+# workflow_consecutive_failures_cap: 5
 team_harness_provider: "codex"
 team_harness_model: "gpt-5.5"
 team_harness_agents:
@@ -238,7 +241,21 @@ Important rules:
   processes a dead worker left running: drain lets them finish (one shared
   bounded deadline) before the iteration is re-run; reap kills them
   immediately. These are coordinator-side settings and are not part of the
-  config snapshot sent to workers.
+  config snapshot sent to the worker.
+- `workflow_consecutive_failures_cap` (default 5) is a per-workflow circuit
+  breaker: that many consecutive failed iterations of the same workflow stop
+  the loop with `stop_reason="workflow_failure_cap"` instead of retrying a
+  wedged workflow until `max_turns`. Any success of the workflow resets its
+  counter. Coordinator-side only; not part of the config snapshot sent to
+  the worker.
+- `model_prices` (optional, coordinator-side only) sets USD prices per 1M
+  tokens for the harness coordinator model (`prompt_usd_per_1m`,
+  `completion_usd_per_1m`); with prices set, `loopy status` derives an
+  estimated cost from the token ledger. `max_cost_usd` (optional, requires
+  `model_prices`) stops the loop with `stop_reason="max_cost_usd"` once the
+  session tree's estimated cost reaches the budget. Cost covers the harness
+  COORDINATOR model only — agent-CLI subprocesses (codex, claude, gemini)
+  bill through their own accounts and are not measurable here.
 
 Workflow config lives beside each workflow prompt:
 
@@ -292,8 +309,12 @@ Important session files:
 
 - `goal.md`: the exact goal text copied into the session.
 - `session.json`: session metadata.
-- `state.json`: coordinator-owned dispatch state.
-- `events.jsonl`: reserved append-only diagnostics log.
+- `state.json`: coordinator-owned dispatch state, including the session's
+  token/duration usage ledger.
+- `events.jsonl`: append-only event stream — one versioned JSON line per
+  significant transition (`session_started`, `task_dispatched`,
+  `task_finished`, `iteration_abandoned`, `goal_check`, `child_started`,
+  `child_finished`, `session_stopped`). Tail it with `loopy events --follow`.
 - `control.json`: workflow-owned stop switch.
 - `updates_from_user.md`: human-writable inbox for changes after the session
   starts.
@@ -379,7 +400,13 @@ To stop because the loop cannot continue:
 A valid `goal_check.json` does not stop the loop by itself. It is evidence.
 Stopping is controlled by session `control.json`. If goal-check output is
 missing or invalid repeatedly, the coordinator stops with
-`stop_reason="goal_check_broken"` after the configured failure cap.
+`stop_reason="goal_check_broken"` after the configured failure cap. Similarly,
+consecutive failed iterations of any single workflow stop the loop with
+`stop_reason="workflow_failure_cap"` after `workflow_consecutive_failures_cap`.
+Failed iterations record a `failure_kind` in history — `transient` (provider
+said retry; team-harness's own retries were exhausted), `deterministic`
+(auth/config errors retries cannot fix), `crash` (worker died mid-iteration),
+or `unknown` — so a stopped run is legible without reading harness logs.
 
 ## Workflow Sets and Child Sessions
 
@@ -391,8 +418,11 @@ Workflow sets are mandatory. Even a single-loop repo uses:
 
 The older `.loopy_loop/workflows/...` layout is not loaded.
 
-A workflow can request one sequential child session by writing a JSON file under
-the active session's `child_requests/` directory:
+A top-level session's workflow can request one sequential child session by
+writing a uniquely named `*.json` file under the active session's
+`child_requests/` directory (only `*.json` filenames are scanned; publish via
+a non-`.json` temp name plus rename — invalid requests are renamed to
+`*.json.rejected` and skipped):
 
 ```json
 {
@@ -461,16 +491,24 @@ loopy worker --coordinator http://127.0.0.1:8080
 Runs a blocking worker until the coordinator returns `action: "stop"`.
 
 ```bash
-loopy status
+loopy status           # session stack, usage totals, estimated cost
+loopy status --watch   # re-render every 2 seconds
+loopy events           # the active session's event stream
+loopy events --follow  # tail it live (--json for raw lines)
 loopy stop
 ```
 
-`status` prints the latest session state. `stop` sets `stop_requested=true` in
-the latest session-local state.
+`status` prints the latest session state — the whole session stack while a
+child runs (the live child is shown under its suspended parent), each
+session's subtree token usage, and (with `model_prices` configured) estimated
+cost. `stop` still flags the latest **top-level** session only: a running
+child does not see the flag, and the stop takes effect once the child reaches
+a terminal state and the parent resumes.
 
 ## Related Projects
 
 - [`team-harness`](https://github.com/writeitai/team-harness): the model and
-  agent-CLI orchestration layer used by loopy-loop workers.
+  agent-CLI orchestration layer used by the loopy-loop worker.
 - [`eval-banana`](https://github.com/writeitai/eval-banana): a lightweight YAML
-  evaluation framework used by the packaged eval workflows.
+  evaluation framework used by the packaged eval workflows. Installed
+  automatically as a loopy-loop dependency.

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/design/designs/improvement-proposals.md

@@ -1,12 +1,12 @@
 # Design: Improvement Proposals
 
-**Status:** Proposed (not yet accepted)
+**Status:** Living — per-proposal statuses below (last status pass: 2026-07-13)
 **Date:** 2026-07-12
 **Relationship to other docs:** Companion to
 [`success-semantics-and-evaluation.md`](./success-semantics-and-evaluation.md)
 (which records decisions that are *already made* and should not be reverted). This
-doc is the opposite: forward-looking changes we are *considering*. It is derived
-from the July 2026 review under [`../analysis/`](../analysis/), curated and
+doc is a tracked ledger of changes we are considering or have since shipped. It is
+derived from the July 2026 review under [`../analysis/`](../analysis/), curated and
 re-prioritized.
 
 **Framing decision that drives priority:** we intend to drive a large, multi-phase
@@ -16,7 +16,10 @@ not after a single-loop pilot. That decision moves the parent/child machinery fr
 flagship use case. The ordering below reflects that.
 
 Each proposal has: **what**, **why**, **sketch**, **effort** (S≈1–2 days, M≈1 week,
-L≈multi-week), and **status**. Nothing here is committed until we accept it.
+L≈multi-week), and **status**. The **Status** line is authoritative — read it first.
+For proposals marked implemented, the What/Why text is preserved as the *original
+problem statement*: it describes the pre-implementation state that motivated the
+work, not the current behavior.
 
 ---
 
@@ -86,8 +89,9 @@ hard OS ceiling (see P2.5). This is the right split, because the two crash cases
   running. That is a process-cleanup problem, handled separately in P2.5 — do not fold it
   into P0.1.
 
-**Effort.** M–L. **Status.** Proposed — **highest priority** given the double-loop
-decision.
+**Effort.** M–L. **Status.** **Implemented in 0.4.0** — `active_child_session_id`
+pointer, startup session-stack walk with adoption/finalization, attempt ids,
+request-file tombstones, atomic artifact writes.
 
 ### P0.2 — Keep the last-resort human escape hatch; do NOT build a preferred human-gate
 
@@ -126,9 +130,9 @@ resume-after-human flow, no external-action approval gate.
   `unresolvable_error` reason with a good message is likely sufficient. Only split it
   if operational reports actually need to tell the two apart.
 
-**Effort.** S (prompt guidance only) — or none. **Status.** Reframed: **do not build
-the pause/resume gate.** The autonomy escape hatch already exists; only optional
-prompt/report polish remains.
+**Effort.** S (prompt guidance only) — or none. **Status.** **Resolved by decision
+(D5), no code** — do not build the pause/resume gate. The autonomy escape hatch
+already exists; only optional prompt/report polish remains.
 
 ### P0.3 — Per-child budgets *(withdrawn)*
 
@@ -160,7 +164,9 @@ the PM template, or make workflow-set dependencies declarative and installable
 (`requires_workflow_sets: [...]`) with preflight validation and a clean-install
 template smoke test in CI.
 
-**Effort.** S–M. **Status.** Proposed.
+**Effort.** S–M. **Status.** **Implemented in 0.4.0** — the PM template ships its
+child workflow set via packaged-template extra sources, with an end-to-end
+clean-init smoke test.
 
 ---
 
@@ -188,7 +194,17 @@ usage adapter with explicit `known`/`unknown` fields (don't pretend worker token
 costs are always measurable). Budgets enforceable at session/child/workflow/wall-clock
 levels, checked before dispatch and after each result.
 
-**Effort.** M–L. **Status.** Proposed.
+**Effort.** M–L. **Status.** **Implemented (unreleased)** — versioned events
+appended after each committing mutation (best-effort delivery by design —
+state.json stays the durable truth; torn-tail-tolerant reader); worker-read token usage from team-harness `run.json` with explicit
+unknown-usage accounting; durable per-session ledger + children.json roll-up;
+`model_prices`-derived cost with the `max_cost_usd` stop condition
+(coordinator-side, requires prices — preflight-enforced); `loopy status`
+(session stack + usage + cost, `--watch`) and `loopy events [--follow]
+[--json]`. Scope notes: budget enforcement is per session subtree (a running
+child enforces against its own spend until finalized — bounded by the
+two-level depth limit); only session-level budgets shipped (per-workflow and
+wall-clock budgets were not needed yet).
 
 ### P1.2 — Deterministic backstop under the judge (per target, for high-stakes work)
 
@@ -212,7 +228,10 @@ outcome"; add the deterministic suite as the objective floor so a mis-judged
 > that overrides the stock policy.
 
 **Effort.** S–M (mostly the child workflow set + runner-side report parsing).
-**Status.** Proposed — needed before high-stakes acceptance is trustworthy.
+**Status.** **Deferred (2026-07-13)** — out of scope for the pre-target milestone.
+It only pays off against a target repo that owns a trustworthy suite, so build it
+as part of that target's dedicated child workflow set when the double loop is
+pointed at one, not generically now. The boundary above still binds when it lands.
 
 ### P1.3 — Fix the Agent Skill and stale "multi-worker" claims
 
@@ -239,15 +258,16 @@ coordinator is explicitly safe under.
 **What.** Replace hardcoded model IDs (repeated across `config.py`, `cli.py`, packaged
 YAML, README, `.team-harness/config.toml`, `.eval-banana/config.toml`, and sibling
 repos) with named profiles (`balanced`, `high_assurance`, `cheap`) resolved once in a
-project-local file. Pin `team-harness>=0.2.10,<0.3`. Make eval-banana a declared
-extra (`loopy-loop[eval]`) or fail preflight with a clear message.
+project-local file. Consider bounding the `team-harness` dependency once its contract
+churns independently of loopy releases. ~~Make eval-banana a declared extra
+(`loopy-loop[eval]`) or fail preflight with a clear message~~ — superseded, see Status.
 
 **Why.** Model IDs churn (git history is full of "bump gpt-5.4 → 5.5"); duplicating a
 model string across N files and sibling repos guarantees drift and a launch-day
 footgun (install today, hit a decommissioned model). team-harness has already shipped
 breaking pre-1.0 changes, so an unbounded `>=` dependency is a standing risk.
-eval-banana is required by the recommended template but is not a hard dependency, so a
-template can require a tool that isn't installed.
+eval-banana was required by the recommended template without being a dependency, so a
+template could require a tool that wasn't installed.
 
 **Sketch.** One resolved profile → exact provider/model/effort, snapshotted into the
 session. `loopy doctor` validates the profile against the actually-installed CLIs.
@@ -255,7 +275,13 @@ Consider a small compatibility matrix (loopy-loop × team-harness × eval-banana
 in CI: "treat the trio as one release train" until the contracts have survived real
 use.
 
-**Effort.** M. **Status.** Proposed.
+**Effort.** M. **Status.** **Partially resolved (2026-07-13)** — the eval-banana
+piece landed the simple way: it is now a plain hard dependency (chosen over the
+optional-extra design; one less install mode to document), and the worker appends
+the scripts directory that actually holds the installed `eval-banana` script
+(derived from the package's install record, `sysconfig` as fallback) to `PATH` so
+the CLI resolves for spawned agents across supported install modes (`uv tool
+install` and pipx expose only the primary package's entry points). Named profiles and trio pinning remain **Proposed**.
 
 ### P2.2 — `_advance()` refactor, folded into the P0.1 state-machine work
 
@@ -270,7 +296,8 @@ P0.1, not as a cosmetic pass first — encode the new session-stack invariants a
 table-driven transition tests at the same time, or the refactor just centralizes the
 current ambiguity.
 
-**Effort.** S (as part of P0.1). **Status.** Proposed.
+**Effort.** S (as part of P0.1). **Status.** **Implemented in 0.4.0** — folded into
+P0.1 as `_advance()`.
 
 ### P2.3 — Richer failure taxonomy + per-workflow failure cap
 
@@ -285,7 +312,15 @@ becomes a failed iteration the scheduler can retry until `max_turns` — spendin
 without distinguishing a transient 429 from a deterministic test failure. A wedged
 `inner` shouldn't be able to burn the whole turn budget.
 
-**Effort.** S–M. **Status.** Proposed.
+**Effort.** S–M. **Status.** **Implemented (unreleased)** — `failure_kind`
+(`transient`/`deterministic`/`crash`/`unknown`, derived from team-harness's
+structured `retryable` signal) recorded on results, `/finished`, and history;
+per-workflow consecutive-failure counter in `LoopState` with coordinator-side
+`workflow_consecutive_failures_cap` (default 5) stopping the loop with
+`stop_reason="workflow_failure_cap"`. Retry/backoff at the loopy level was
+deliberately NOT added: team-harness already retries transient API errors with
+backoff (`team_harness_max_retries` etc.); a second retry layer would multiply
+delays without new information.
 
 ### P2.4 — Operator experience: `doctor`, `validate`, session-aware `status`/`stop`
 
@@ -345,8 +380,10 @@ the ownership split. Summary of the split:
   team-harness provides the liveness check + policy ops + timeout (TH-D5); the logical-session
   resume path is a separate, larger option and is **not** proposed here.
 
-**Effort.** M (team-harness, tracked there) + S (loopy surfacing). **Status.** Proposed —
-separate from P0.1, which recovers state only. Pairs with the P0.1 worker-liveness bullet.
+**Effort.** M (team-harness, tracked there) + S (loopy surfacing). **Status.**
+**Implemented** — team-harness 0.3.0 (TH-D5: process-group identity + `th reap`)
+plus loopy-loop 0.3.0 (worker identity on `/register`, bounded-drain recovery of
+orphaned agents, `salvage.json`).
 
 ---
 
@@ -368,18 +405,22 @@ separate from P0.1, which recovers state only. Pairs with the P0.1 worker-livene
 
 ## Suggested sequencing
 
-1. **P0.1 + P2.2 together** — the session-stack/state-machine hardening and the
-   `_advance()` refactor are one coherent piece of work. (P0.2 needs no code — the
-   autonomy escape hatch already exists; at most it's prompt polish.)
-2. **P0.4** — a PM template runnable from a clean init; the double loop is now
-   executable end to end.
-3. **P1.1** — events/cost ledger + `status --watch`, so double-loop runs are legible.
-4. **P1.2 + P1.3** — deterministic backstop for high-stakes targets; fix the skill.
-5. **P2.1, P2.3, P2.4, P2.5** — profiles/pins, failure taxonomy, operator UX, and
-   orphan-process cleanup (rolling).
-
-After (1)–(3), the double loop is ready to drive a large, multi-phase target as a
-sequence of narrow, deterministically-backstopped work packages that runs
-unattended — falling back to the `unresolvable_error` escape hatch only when a
-blocker is genuinely unresolvable without a human. That target-execution design is
-the subject of a separate doc, not this one.
+1. ~~**P0.1 + P2.2 together**~~ — **done (0.4.0)**: session-stack/state-machine
+   hardening plus the `_advance()` refactor. (P0.2 needed no code — the autonomy
+   escape hatch already exists.)
+2. ~~**P0.4**~~ — **done (0.4.0)**: PM template runnable from a clean init; the
+   double loop is executable end to end. (P2.5 also **done**: team-harness 0.3.0 +
+   loopy-loop 0.3.0.)
+3. **P1.3** — fix the Agent Skill and stale claims (now also stale against
+   0.3.0/0.4.0: worker identity, attempt ids, workflow sets).
+4. **P2.3** — failure taxonomy + per-workflow failure cap.
+5. **P1.1** — events/cost ledger + `status --watch`, so double-loop runs are legible.
+6. **P2.1 remainder, P2.4** — profiles/pins and operator UX (rolling). **P1.2** is
+   deferred into the flagship target's own workflow-set design.
+
+After (3)–(5), the double loop is ready to drive a large, multi-phase target as a
+sequence of narrow work packages that runs unattended — falling back to the
+`unresolvable_error` escape hatch only when a blocker is genuinely unresolvable
+without a human. Deterministic backstops (P1.2) arrive with that target's own
+workflow-set design. That target-execution design is the subject of a separate
+doc, not this one.

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/docs/http-contract.md

@@ -136,6 +136,9 @@ Request:
   "success": true,
   "text": "done",
   "error": null,
+  "failure_kind": null,
+  "usage": {"prompt_tokens": 5210, "completion_tokens": 902, "turns": 3},
+  "duration_s": 187.4,
   "attempt_id": "a1b2c3d4e5f6",
   "worker": {
     "hostname": "buildbox",
@@ -147,6 +150,20 @@ Request:
 
 `worker` is optional (same semantics as `/register`): the calling worker will
 run the next dispatched task, so its identity is stamped onto that task.
+`failure_kind` is optional and classifies a failed iteration for the history
+record: `transient` (provider said retry — the harness's own retries were
+already exhausted), `deterministic` (auth/config error retries cannot fix), or
+`unknown`. The coordinator itself records `crash` for iterations abandoned by
+a dead worker. Consecutive failures of the same workflow are counted
+(coordinator-side `workflow_consecutive_failures_cap`, default 5; any success
+of that workflow resets its counter) and stop the loop terminally with
+`stop_reason="workflow_failure_cap"` at the cap.
+`usage` (optional) is the coordinator-model token usage the worker read from
+team-harness's `run.json`; absence means usage is UNKNOWN for the iteration,
+not zero (agent-CLI subprocess usage is never measurable). `duration_s`
+(optional) is the worker-measured harness wall-clock. Both feed the
+session's durable ledger; with configured `model_prices` the ledger drives
+the `max_cost_usd` stop condition (`stop_reason="max_cost_usd"`).
 
 Response: same shape as `/register` response (`action` is either `"run"` or `"stop"`).
 

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/docs/session-layout.md

@@ -47,8 +47,19 @@ One session directory is created per fresh coordinator run and reused for all it
 
 `events.jsonl`
 
-- Reserved append-only event log for diagnostics
-- Created at session start in v1
+- Append-only event stream: one JSON object per line, one file per session
+- Envelope: `event_id` (unique per emission), `schema_version` (1), `ts`
+  (UTC), `session_id`, `type`, `payload`
+- Types in v1: `session_started`, `task_dispatched`, `task_finished`
+  (success/error/failure_kind/tokens/duration), `iteration_abandoned`,
+  `goal_check`, `child_started`, `child_finished`, `session_stopped`
+- Delivery is best-effort, not guaranteed: events append AFTER the
+  producing state mutation commits, so a crash or append failure in that
+  window loses the event (never the state), and a crash-replayed
+  finalization can duplicate one — consumers key on `event_id`, tolerate
+  gaps and a truncated final line, and never build correctness on this
+  stream (`state.json` history/ledger is the durable truth)
+- Tail with `loopy events --follow` (`--json` for raw lines)
 
 `control.json`
 
@@ -175,6 +186,10 @@ eval-banana run \
 - The parent's `state.json` additionally records `active_child_session_id`
   while a child runs — the durable session-stack pointer a restarted
   coordinator follows to resume the child instead of orphaning it
+- At finalization the record also captures the child's usage totals
+  (`usage`: tokens, known/unknown iteration counts, duration), which is how
+  a parent's tree-wide usage and `max_cost_usd` budget include finished
+  children without double-storing
 
 Atomicity and crash model: the coordinator- and worker-owned artifacts above
 are written atomically (same-directory temp file + rename), so a **process

{loopy_loop-0.4.0 → loopy_loop-0.5.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "loopy-loop"
-version = "0.4.0"
+version = "0.5.0"
 description = "Run long-running AI agent workflows inside your repository."
 readme = "README.md"
 requires-python = ">=3.12"
@@ -37,6 +37,7 @@ classifiers = [
 ]
 dependencies = [
     "click>=8.1",
+    "eval-banana>=0.3.1",
     "fastapi>=0.115.0",
     "filelock>=3.16",
     "httpx>=0.28",