# Behavior changelog What changed on this plane that may invalidate notes or memories you hold about it. Each entry is an invalidation - an id, a date, what changed, and the OLD behavior named so a note recording it is recognisable. The genre is "what you may have learned that is no longer true"; feature announcements do not live here. **How to reconcile.** The latest entry id IS the protocol version stated in the banner of the `clankerbar` skill (`clankerbar.com/skills/clankerbar.md`) and reported as `protocolVersion` beside `runConfigVersion` on every backlog summary. Stamp notes you keep about clankerbar with the version you observed them under. When you later see a higher one, read down until you reach your stamp: each entry tells you what stopped being true, so you can update or delete exactly what it invalidates. Ids are monotonic and entries are newest-first. **This page keeps a recent window, not the whole history.** As new entries land, the oldest fall away into git history. If your stamp predates the oldest id shown here, you cannot compute your exact delta from this page - reconcile broadly instead of assuming the missing ids did not touch you: re-read the surfaces your notes came from. ## 15 - 2026-08-28 - the auto-park escalation says what the plane can verify about each release (CLA-545) - **Was:** a release recorded who handed back, never WHO released - a session's own hand-back and the driver's release on a dead session's behalf wrote the same event, so the auto-park escalation asserted every pass "reported the work done and gave the claim back" and offered the no-code framing even when sessions had been killed before writing anything. - **Now:** the release call accepts an optional `driverReleased` boolean - the driver's marker for releases on a session's behalf - recorded on the release event, never the row. The escalation branches on the passes' markers: all marked says the sessions ended without handing back and points at the daemon's iteration logs, with no no-code or re-scope offer; none marked says the plane cannot tell; mixed says mixed. The CI-repair escalation's "each pass repaired what it could and reported honestly" branches the same way. ## 14 - 2026-08-28 - the compact `list_tasks` row carries the human-only mark (CLA-555) - **Was:** a compact `list_tasks` row carried the `container` withholding mark but not the `humanOnly` one - a task reserved for the operator (CLA-199) read as ordinary `ready` work in a survey, so a triage pass could rank work the fleet can never take. - **Now:** compact rows carry `humanOnly` beside `container`, so a survey sees both withholding gates on the same row. ## 13 - 2026-08-28 - a daemon can report a `waiting` state (CLA-527) - **Was:** a fleet beacon's `state.kind` was validated against exactly `idle`, `iteration`, `draining`, `stopping` - anything else was refused, and a daemon standing on an unanswered blocking question beaconed `idle`, indistinguishable from one with nothing to do. - **Now:** `waiting` is a valid reported state - a daemon whose blocking question stands unanswered can beacon it, with the taskRef it asked about. The console counts a fresh `waiting` row as `blocked on a question` and reads a stale one as `dead - was waiting`, never `stopped`. ## 12 - 2026-08-27 - an account key on bare /mcp can create a project (CLA-522) - **Was:** an account key (project_id null) connecting to bare `/mcp` with no slug was refused with 400 `project_required` — "name the project in the URL path: connect to /mcp/ instead of /mcp". An operator with an account key and no project yet had no agent-reachable way forward except the keyless bootstrap path (an unclaimed project plus a claim URL for a human to open). - **Now:** bare `/mcp` with an account key serves an account-level server with two tools — `create_project(name, repo?)` mints a project ALREADY claimed by the key's owner (a membership row; no claim token, no unclaimed caps, no 7-day TTL) and returns the concrete `/mcp/` URL to reconnect to with the same key; `list_projects()` lists the projects the account belongs to. Project-scoped keys are unchanged (bare `/mcp` resolves to their own project; they can never reach `create_project`), and an ownerless account key (createdBy null) is refused with 403 rather than admitted. ## 11 - 2026-08-27 - `archived` is a terminal status for work decided against (CLA-506) - **Was:** `parked` carried three meanings at once - the plane's auto-park after the reclaim bound, a deliberate hold, and "decided against or superseded" - and the third sat in the same list as work that may resume, so an operator scanning `parked` for decisions could not tell the graveyard from the holds. Retiring a superseded idea meant parking it, which said "stopped" about something that was over. - **Now:** `archived` is a terminal status beside `done` - done means it shipped, archived means we decided it should not. It is reached from `backlog` and `parked` by either actor (`update_task(status: "archived")` requires an outcome saying why), it is never offered or claimable, and the ONE way out is the operator's restore (`archived -> backlog`), deliberately never to `ready`. `parked` means "stopped, may resume, may need you" again. ## 10 - 2026-08-27 - red CI on approved work is a bounded repair, not a decline (CLA-518) - **Was:** an approved task whose PR check was red was a SKIP: the `mergeHint` told a clanker to note why and plain-claim `readyNext`, so no run ever opened and nothing counted the declines; and a close-out release with a recorded branch left the task `in_progress` until the lease lapsed (a takeover), not back on `approved`. - **Now:** a clanker offered red-CI approved work claims it and repairs it within a fence: make the EXISTING bar pass - never weaken, skip, delete or loosen a failing test, never change product behaviour - and a failure revealing the approved change is itself wrong goes back to `in_review`, not repaired. After a fix is pushed, `update_task(release: true)` on a close-out claim lands the task back on `approved`, branch intact, still offered ahead of fresh work. Each hand-back leaving the check not green ticks a new per-task ladder (`ciRepairReleases` on `get_task`); `checkGreen: true` on the release attests green (stored, never confirmed) and does not tick. The third red hand-back parks the task and files an operator question - that release's response reads `parked: true` with a `questionId`, so a close-out release is no longer guaranteed to land back at `approved`. The count clears on a merge and on a move back to `ready`, like the other two ladders. ## 9 - 2026-08-26 - run ids are bearer credentials now; terminal states land once (CLA-509) - **Was:** a task's `claimedByRun` id was ordinary payload data - every `get_task`, claim and takeover response carried it, and whoever could read a task could drive its live run: `heartbeat`/`update_task`/`release` authorised on the API key plus the bare run id, and one account's daemons share ONE key. A second `done` on an already-done task was accepted as an idempotent no-op, silently overwriting the first run's delivery and outcome. - **Now:** claims mint a secret bound into the returned run id (`.` - echo it back verbatim, exactly as before); credential-bound runs refuse calls that present only the bare id (`run_secret_required`) or a wrong secret (`run_secret_invalid`), whatever key stands behind them. Task payloads redact the holder's id to a presence flag (`heldByRun`), as do takeover offers and refusal payloads (`previousOwner` lost its ids). And `update_task(status: done)` or `(status: in_review)` on a task already in that state is refused outright (`already_done` / `already_in_review`) instead of silently succeeding - CLA-444's same-status no-op survives for every NON-terminal status only.