v0.6.10

v0.6.10 (2026-09-23)

Patch release in the v0.6 "Kentucky Butter" line. devcake-cli stays at 0.1.10. No profile change. Harness images re-bake at the re-pin (the nested store moved) and the app re-bakes for the Dev prompt. A Dev container already running keeps the image it started with.
Release notes.

• Fixed — nested Podman no longer fills the Dev cgroup with
  fuse-overlayfs (#482). Rootless image storage sat on the container's own
  overlay upper, so the diff fell back to fuse-overlayfs and that page
  cache was charged to the Dev's memory cap. The store now lives at
  /workspace/.podman-storage on the per-run workspace bind (host
  ext4), and mount_program is empty so the diff stays native. The
  entrypoint reads cpu.max and memory.max and exports
  DEVCAKE_CPUS, DEVCAKE_MEMORY_BYTES, GOMAXPROCS, GOMEMLIMIT
  and a Node heap cap at 70% of the memory max; an unlimited cgroup
  exports nothing for that resource. The Dev prompt says nproc and
  /proc/meminfo show the host. MemorySwap is pinned to Memory on
  both dev-run steps, so Docker's 2× default cannot pretend a swap
  device exists. The nested-engine probe records native overlay and
  the fuse process count without changing rig_ok. docs/07.

DevCake v0.6.9

Patch release in the v0.6 "Kentucky Butter" line. Ships with devcake-cli 0.1.10 — upgrade the CLI before devcake up --release v0.6.9.

Why this release. Two field episodes on a small host: a shared HTTP pool that filled with dead connections until every tracker and repository call failed, and a CPU-starved control plane whose baker read a slow app as a dead one. This release removes the leak, makes the pool and the host's capacity visible, teaches the baker the difference between slow and dead, and folds in a contributor's GitLab audit.

Deadlines never cancel a socket holder (ADR-0044). A wait that cancelled an outbound call mid TLS handshake leaked the socket. Waits now go through one module that lets the work finish in the background; the tracker probe reports "probe pending" instead of red while it runs, the branch-protection walk refreshes in the background, the forge sweep is one in-flight task, and a structure guard keeps cancellation away from HTTP. /health.http_pool meters the pool against the kernel's sockets and grades it; devcake status and the Overview alert read the grade. A network error with no message now names its class.

The fleet's CPU demand against the host's cores. /health.capacity reports concurrency × CPUs against the cores the app sees, one core kept for the control plane. An oversubscribed host shows as a dismissable Overview warning, a devcake status line and a devcake up warning. Sizing rule: cores ≥ concurrency × CPUs + 1.

The host baker tells slow from dead. A running container that cannot answer the liveness probe keeps the baker's heartbeat fresh with no bake work and never exits; a container listing that cannot be read spends nothing; only a container that is not running spends the five-minute budget, now wall-clock. Compose gives the control plane CPU weight and the app healthcheck tolerates a starved event loop; the app paints the baker dead after 60 seconds without a heartbeat.

GitLab hygiene. The merge request file listing walks the paginated diffs endpoint (the changes endpoint is deprecated) and reads the merge request's own overflow signal, so a capped diff is disclosed as truncated. Git transfers over the network, on the app side and in Dev containers, abort once they crawl under 1 kB/s for 60 seconds.

Operator sequence.

1. uv tool upgrade devcake-cli (0.1.10) on the host.
2. Let running missions finish, then devcake up --release v0.6.9. Every harness image re-bakes (the Dev-side clone change); compose recreates app, dagu and redis for their CPU weight. No AppArmor profile change.
3. devcake status: the new http_pool: and capacity: lines. If capacity says oversubscribed, raise the host or lower Limits.

Pull requests: #478, #479, #480, #481. Full changelog in CHANGELOG.md.

v0.6.8

Patch release in the v0.6 "Kentucky Butter" line. devcake-cli stays at 0.1.9. No profile change: devcake up --release v0.6.8 is the whole upgrade. A stored config that still carries attach_merged_changeset_to_pmo logs the usual unknown-key warning on load and runs without it — nothing to migrate.

Retired — the deployment-global "attach merged change set to PMO" toggle and its Settings → Policies → Delivery card. With the delivery destination shipped in v0.6.7, the ticket receives a change set exactly when the mission's recorded destination is the ticket, or — as always — after merge for the invisible internal forge. A deployment-wide switch had no place left: configured repositories no longer receive a post-merge archive; the forge pull request is their canonical artifact. ADR-0017 gains the addendum that records the decision, the rejected alternatives and the residuals.

Runs carry their delivery destination. The Runs API rows and the CSV export gain delivery_to (repository, ticket, or empty for older records) right after pr_url; the mission drawer labels a ticket-destination pull request "PR → ticket".

Full detail: CHANGELOG.md and the living log in docs/16-roadmap.md.

v0.6.7

Patch release in the v0.6 "Kentucky Butter" line. devcake-cli stays at 0.1.9.

Operator sequence: devcake up --release v0.6.7. No profile change and no CLI change: nothing else to run. Missions in flight keep their dispatched context; the next dispatch of any mission with finished blockers gets their records under upstream/.

• Fixed — a finished blocker's record now reaches the Dev on Linear
  boards. The upstream offer read the blocker edges from the mission
  node the activity read returned, and the Linear activity query fetched
  no relations, so every Linear mission read as "no blockers": the
  finished blocker's record never landed under upstream/{KEY}/ and no
  gap was disclosed. The dispatch's own live-resolved done set (the
  handoff notes, mission id included) is now the edge source for the
  mirror, its done-ness outranks a same-cycle stale snapshot, and the
  Linear activity read carries relations whole (paginated like get).
  ADR-0043 §4 addendum; docs/05 §4.
• Handoff excerpts say where the whole note is. The per-blocker
  excerpt cap rises from 700 to 1,500 characters (the blocker section's
  byte budget still bounds the sum; the steward's family package keeps
  its own 700-character head), and a cropped excerpt ends with a pointer
  to the whole handoff — the blocker's mirrored record when this dispatch
  has it, else the mission's description on the board — in both the
  prompt note and MISSION.md. ADR-0032.
• A missing grandparent is a named gap. The ancestor walk stops at
  the first parent the board snapshot does not hold; only the mission's
  own missing parent was reported, so an ancestor dropped from the
  listing (archived, another board) vanished silently while the nearer
  ancestors mirrored as if the chain were whole. The missing ancestor is
  now named wherever the chain breaks — a strict-gate gap with a banner —
  and the resolved ancestors still mirror.
• An executed outcome requires a pull request; a parked mission with
  none is handed back, never wedged. An EXECUTE that reports no pull
  request makes the app ask the forge for the mission branch's PR; a
  forge-found one becomes the record's url, and a branch with none fails
  the run as DEV_BAD_OUTPUT instead of advancing to REVIEW. A REVIEW
  approve with no forge-visible PR opens the deferred merge window on
  every repository (naming the branch), the sweep merges or hands back
  once when the window elapses, and a zero window hands back at once.
  DevCake never cancels for a missing pull request. docs/02, 03, 04, 11,
  15.
• Delivery destination — the ticket as a legitimate end of a pull
  request. Every change set still rides a pull request; a mission may
  now record where it lands: the repository (default, silent, merge as
  before) or the ticket. The record is one description marker
  (`devcake:delivery:v1 to=repository|ticket`), written once by the
  app when ONBOARD declares it on a fresh mission (the park follows the
  board's plan-approval setting), carried by decomposition children from
  birth, and changed afterwards only by a person: a later differing
  declaration by ONBOARD or EXECUTE is a proposal that parks the mission
  under DEVCAKE-NEEDS-HUMAN with the exact line to paste; REVIEW never
  proposes. In ticket mode a REVIEW approve attaches the pull request's
  files to the ticket (file by file when small, else the archive with its
  manifest; text redacted), completes the mission through the one
  completion chokepoint with "no repository changed", and closes the pull
  request unmerged (ForgePort.close_pr, all three forges, contract
  battery row 15). A person may write the marker onto a mission parked at
  DEVCAKE-MERGE and the sweep honours it. Description appends now go
  through one chokepoint (feed.append_note) with a structure guard.
  Missions that declare nothing are unchanged. docs/02, 03, 04, 05, 06,
  08, 14; ADR-0016 and ADR-0034 addenda.
• Docs — installing without an agent. The README carries the AppArmor
  profile step for people setting a host up by hand.

v0.6.6

Patch release in the v0.6 "Kentucky Butter" line. devcake-cli stays at 0.1.9.

Operator sequence on a host that runs AppArmor: devcake up --release v0.6.6 → re-run the two profile commands (devcake doctor prints them with the checkout's path; the profile changed, so the installed copy reads as outdated):

sudo install -m 0644 scripts/apparmor/devcake-nested /etc/apparmor.d/
sudo apparmor_parser -r /etc/apparmor.d/devcake-nested

→ devcake up (not required for the new profile bytes to take effect — the kernel replaces the loaded profile in place — but it lets the baker re-measure at once; the receipt re-measures on the installed profile's digest either way). Hosts without AppArmor: devcake up --release v0.6.6, nothing else.

• Fixed — user-defined networks inside the Dev's engine work on AppArmor
  hosts. The Dev-container profile denied every write under /proc/sys,
  which broke docker network create and any compose project with
  published ports: the engine's network helper writes a bridge sysctl in
  the network namespace it owns. The profile now leaves /proc/sys/net/*
  to the kernel's own per-namespace ownership check (the container's own
  network sysctls stay refused, measured), the nested-engine probe
  exercises a user-defined network with a published port as part of its
  verdict, and the baker re-measures when the installed profile's bytes
  change. Re-run the two profile commands after upgrading; the doctor
  reports the old copy as outdated.

v0.6.5

Patch release in the v0.6 "Kentucky Butter" line. Ships with devcake-cli 0.1.9 — upgrade the CLI before devcake up --release v0.6.5.

Operator sequence on a host that runs AppArmor (stock Ubuntu): upgrade the CLI (uv tool install --reinstall '.[mcp]' from this checkout, or devcake-cli 0.1.9 from PyPI) → let running missions finish → devcake up --release v0.6.5 (archives the Dagu state store, then warns that the Dev-container profile is not loaded and carries on without the nested engine) → run the two sudo commands devcake doctor prints (they install and load scripts/apparmor/devcake-nested; an older copy reads as outdated and needs the same two commands) → devcake up → after the harness images re-bake, devcake doctor shows apparmor_profile ok and devcake status shows nested engine: ok … compose too. Hosts without AppArmor (WSL2, Docker Desktop): upgrade the CLI and run devcake up --release v0.6.5; nothing else changes.

Security posture, stated plainly (docs/14 §6): on AppArmor hosts the profile lifts the default restriction on unprivileged user namespaces for Dev containers, and on every host a Dev can read a few host-information files Docker normally masks.

• Added — compose inside Dev containers. The harness images ship a
  pinned podman-compose as the nested engine's compose provider, reached
  through docker compose and a docker-compose symlink alike, with the
  iptables binary netavark needs for compose-created networks and the
  provider banner silenced; the nested-engine probe records a compose step
  in its receipt, shown on the Dev Types panel, devcake status, an
  Overview warning and the Dev's prompt when it is red. The Dev's prompt
  section names the compose gaps (health-check waits, daemon socket, host
  name). Before this the images carried no compose at all.
• Fixed — the nested engine inside Dev containers works on hosts that
  run AppArmor (ADR-0023 addendum). Under Docker's default profile the
  rootless engine could not mount, and Ubuntu confined it further the
  moment it created a user namespace; nested docker/podman had never
  worked on such hosts, only on the rigs without AppArmor. The checkout
  now ships a Dev-container profile (scripts/apparmor/devcake-nested,
  compiled in CI) that the operator loads once (devcake doctor prints
  the two commands, never runs them); devcake up derives the profile
  name into .env — asking the daemon first, so a profile the host cannot
  apply is never named (a virgin host with no image yet falls back to the
  installed file compiled by the host's own parser) — the run DAG names it on both Dev steps, allows
  the one extra syscall the runtime needs, and launches with Docker's
  masked system paths removed. Security posture, stated plainly: on
  Ubuntu hosts the profile lifts the default restriction on unprivileged
  user namespaces for Dev containers (a Dev may hold capabilities inside
  namespaces it creates, which the rootless engine needs), and on every
  host a Dev can now read a few host-information files Docker normally
  masks; the profile re-denies them on AppArmor hosts, elsewhere they stay
  readable. docs/14 §6 has the full list. The host baker
  now runs the nested-engine probe after every harness bake and
  publishes the newest receipt: the Overview warns, the Dev Types panel
  and devcake status name the first red step, and a Dev on a red host
  is told in its prompt that containers are unavailable — runs still
  launch. devcake up archives the Dagu state volume under
  .factory/backups/ (0600, named with the version it came from, newest
  three kept, the newest versioned one never evicted) when the checkout pins a Dagu the volume was not last used
  with — the last container's image decides, or after devcake down
  whether the pinned image was ever pulled here; dagu is stopped for the
  copy and started again at once — a backup for rollback, not a migration; the
  command is printed when it cannot be taken. The baker re-measures the
  nested-engine receipt after a kernel or engine upgrade and asks the
  daemon every minute whether it still applies the named profile; when it
  no longer does, every surface says that no Dev container can start until
  the profile is loaded again or devcake up is run.
• Changed — devcake-cli 0.1.9. The host CLI carries the AppArmor
  derivation, the doctor check and the Dagu archive; a release checkout
  refuses devcake up --release under an older installed CLI, so upgrade
  the CLI first (uv tool install --reinstall '.[mcp]' from the checkout,
  or the PyPI release of the same version).
  Every Dev prompt now carries a short section saying what docker is
  inside the container.
• Changed — Dagu 2.13.0 → 2.16.3. The release that carries our
  upstream fix for container limits: the run DAG now writes them in
  Docker's own flat form instead of the nested workaround the old decoder
  needed. Also in the range: a step's containers are stopped on timeout,
  the docker group is created by the stock entrypoint, and the Dagu state
  layout was refactored — devcake up archives the Dagu volume before the
  re-pinned Dagu first starts (the "Fixed" bullet above).

DevCake v0.6.4

Patch release in the v0.6 "Kentucky Butter" line. devcake-cli stays at 0.1.8.

Routed discoveries reach the mission they were sent to, in full. A leads delivery used to carry short excerpts of each finding, and a long one carried nothing but a pointer to a file on the source mission that the recipient's Dev never receives. The delivery's record now carries every finding in full, with no inline ceiling; the head quotes an excerpt of each. The recipient's Dev reads them from its own activity folder.

One place to read a mission's discoveries. The status comment's fold gains a Discoveries section: what the mission reported, with the record-file link, and every lead it received, in full. It is a view over the feed with no marker, no file token and no provenance line, so nothing that scans the feed counts it, the freshness check ignores it, and no Dev sees it. The status refresh now reads the feed once and the record push at the same boundary reuses that read.

Upgrading a host.

devcake up --release

Full detail: CHANGELOG.md and the living log in docs/16-roadmap.md.

DevCake v0.6.3

Patch release in the v0.6 "Kentucky Butter" line. devcake-cli stays at 0.1.8.

A mission that cannot start is now visible. A mission whose dispatch DevCake refuses or defers for a reason a person can act on, for longer than a threshold (thirty minutes by default), is listed on the health endpoint with its age, raised as an alert on the admin Overview, and badged on its board card. The ticket receives one notice per distinct block, and its status comment is created early with a "waiting to start since" line that says why and what would clear it. Waiting on a blocker never counts, the same block is never repeated, a different block notifies again, and neither the notice nor the status comment ever enters a Dev's context. The occasion was a decomposition child that sat for eight days after its original was archived, with only a log line saying so.

Upgrading a host.

devcake up --release

Full detail: CHANGELOG.md and the living log in docs/16-roadmap.md.

DevCake v0.6.2

Patch release in the v0.6 "Kentucky Butter" line — the activity repository becomes the record of a mission's run (ADR-0043). devcake-cli stays at 0.1.8.

Every Dev receives the whole record of every mission upstream of its work. The upstream folders in a Dev's workspace are now copies of each upstream mission's activity repository: the decomposition ancestors to the root, the project the mission belongs to, and every direct blocker that finished. Each folder holds that mission's brief, its full feed and every attachment, so a starting attachment on a blocker's ticket reaches the dependent instead of being lost in the thread. The byte budget is decided from the record's sizes before anything is fetched; a mission that never ran is rebuilt from the vendor and marked as such; an unreadable blocker is disclosed, never a reason to hold a dispatch.

The activity repository is kept current. It used to be written once, before a step launched. It is now refreshed at every run boundary: each step close including failures, completion, hand-offs, a pull request closed unmerged, and a conflict routed back. Reading the record from the internal forge costs nothing against a vendor's request budget, which is what makes "every direct blocker, no count cap" affordable.

A project's own run leaves a record. DevCake used to suppress every write to a project, so the step that split a project, its transcript and its reasoning were invisible to the children. A project run's step card, its notices and its decomposition note now post as project updates, the transcript uploaded and linked, through the same chokepoint issues use. Those cards appear in the project's Updates tab.

Upgrading a host.

devcake up --release

Full detail: CHANGELOG.md, ADR-0043 and the living log in docs/16-roadmap.md.

DevCake v0.6.1

Patch release in the v0.6 "Kentucky Butter" line. devcake-cli stays at 0.1.8.

An issue placed in a project now sees the project's activity. A Dev working an issue a person added to a project by hand received nothing from the project: the upstream offer followed only the marker DevCake writes when it splits a mission, so the project's brief, its updates and its documents were invisible. The offer now ends at the project the issue belongs to, mirrored under the workspace's upstream folder exactly like a decomposition parent, with each folder's relation and the upstream mission's title named in the activity banner. A project the board does not poll is read once at dispatch; one that cannot be read is a named gap, never a silent omission, so a strict board defers rather than launching blind. ADR-0036 addendum.

Upgrading a host.

devcake up --release

Full detail: CHANGELOG.md and the living log in docs/16-roadmap.md.