The dev loop — the iterative Decide-Build-Validate cycle that powers autonomous coding agents — received its most substantial upgrade since launch. Agents can now persist documents across cycles, blueprints are more structured, and stale execution state is cleaned up automatically.
Persistent Text Attachments
Agents can now read and write persistent documents (like ROADMAP.md, PLAN.md, or PROGRESS_REPORT.md) that survive across execution cycles. Previously, cross-cycle knowledge had to be squeezed into structured output fields. Now agents have a proper place to accumulate context.
- Read and write via CLI — The
kindship attachcommand lets agents read or update documents attached to any planning entity - Versioned by timestamp — Each attachment tracks when it was last updated, so agents (and you) can tell how fresh the information is
- Available at cycle start — When a new cycle begins, the system includes attachment metadata in the run context so the agent knows what documents exist and when they were last changed
This is particularly useful for progress reports, roadmaps, and any document that grows or changes incrementally over the life of a project.
Smarter Blueprints
The Decide-Build-Validate blueprint — the template that governs how each dev loop cycle runs — was restructured to be more disciplined:
- Decide phase — Now follows a six-step flow: archive the previous plan, write a progress report, triage any issues, update the roadmap, write a new plan, and red-team it. The explicit archive-first step prevents the agent from contradicting itself by reading its own stale plan.
- Build phase — Runs an explicit per-step loop: implement, test, type-check, mark as done, commit. Each step is verified before moving to the next.
- Validate phase — Reviews the full range of commits from the Build phase, not just the most recent one. This catches issues that span multiple commits.
Stale Run Auto-Abandon
Orchestration runs that have been active for more than 24 hours are now automatically abandoned. Previously, a crashed or stuck orchestration could leave runs in a permanent "running" state, blocking new cycles from starting. The system now detects these stale runs, cleans up any associated child runs, and frees the entity for a fresh cycle.
Run State Moves To The Database
Active run tracking previously relied on a local JSON file inside the agent container. That file could become stale or corrupted if the container restarted mid-execution. Run state is now stored in the database, making it reliable across container restarts and accessible from any endpoint without filesystem dependencies.