v0.9.0 / v0.12.0

New features and improvements

1. 01

   The release window is much larger than a patch note

   This log is written from the previous published release log, not only from the immediately previous tag. The covered window spans TUI/Portal, the kernel, and the Telegram addon work that affected the same operating surface.

   • Across the audited repositories the window contains 129 commits, 370 changed files, +31,717 / -2,047 lines.
   • TUI/Portal contributes 58 commits and 108 changed files (+6,443 / -986) from v0.8.15 to v0.9.0.
   • Kernel contributes 40 commits and 234 changed files (+22,416 / -676) from v0.11.3 to v0.12.0.
   • Telegram addon contributes 31 commits and 28 changed files (+2,858 / -385) from v0.3.0 to current main in the same release-log window.
   • The GitHub surface contains 109 PRs updated in the window (81 merged, 20 closed unmerged) plus 48 issues (41 closed).
   • The contributor list includes commit authors/co-authors, merged PR authors, closed-unmerged PR authors, issue reporters, assignees/reviewers, and participants whose issue or PR was closed even when the proposal was not adopted.

   Why it matters:The scale matters because the release blog is the public memory of the project. If the window is counted too narrowly, contributors disappear and operators lose the real shape of the work.

2. 02

   TUI becomes an operator cockpit for long runs

   The strongest user-facing theme is readability under load. Long agent runs now have a layered replay path, quieter defaults, and more places where the UI shows the runtime state instead of hiding it in raw logs.

   • Text output and Ctrl+O replay are separated by API call, so multiple model invocations read as distinct steps.
   • Tool-call display controls, tool-result payload rendering, tool-result summaries, two Ctrl+O detail levels, and a 100-rune tool-call summary cap make replay usable instead of overwhelming.
   • The TUI daemon browser, independent daemon pane scrolling, daemon counts in kanban, and daemon detail layout fixes make background work visible.
   • Kanban gained context stats and clearer Ctrl+D detail hints; list views became closer to a decentralized contact book.
   • Root-owned layout budgeting, adaptive mail input height, and global status-bar design work make the shell more stable for dense sessions.
   • The TUI /clear path is routed through kernel context clear, reducing mismatch between the interface and the runtime operation.

   Why it matters:When agents work for a long time, the UI cannot be a text dump. It has to preserve attention: summary first, details on demand, and runtime state where the operator can see it.

3. 03

   Setup, presets, manifests, and first-run paths are safer

   Several fixes close the gap between what the operator selected and what the runtime actually loaded. This section also carries forward the v0.8.16 preset-safety patch that was not given its own release log.

   • Switching preset models no longer drops skills.paths or other non-model capability overrides; old presets without skills.paths are migrated.
   • /setup no longer writes a synthetic keep_current.json placeholder into real preset default/allowed policy.
   • The TUI can read resolved manifest artifacts published by the kernel, so the interface can inspect effective runtime state instead of only raw init.json.
   • Default agent max_turns increased, and list/max-turns surfaces now describe the actual operating limits more accurately.
   • Tutorial language defaulting, adaptive welcome guidance, first-install troubleshooting, README top guidance, and install.sh source helper behavior were repaired.
   • Runtime checkout refresh and stale worktree cleanup were added to developer/release procedures so local state does not silently poison future work.

   Why it matters:Configuration drift is one of the easiest ways to lose trust in an agent system. This release spends real work making effective state inspectable and safer to mutate.

4. 04

   Kernel tool execution becomes governed and observable

   Kernel v0.12.0 reshapes tool execution as a structured runtime surface. It removes brittle nested call paths, adds tracing and guard layers, and returns richer recovery information to the model.

   • The nested secondary tool-call channel was removed after transitional read-only restrictions; stale secondary args are no longer a hidden execution path.
   • Tool-call lifecycle tracing and api_call_id fields now group LLM/tool events, matching the TUI replay work.
   • ToolCallGuard introduces normalized proposal review with structured pass/warn/deny decisions before dispatch.
   • Repeated tool-error pairing, tool-loop non-dispatch recovery, formal recovery metadata, active-turn progress meters, and repeated-call advisories make recovery less disruptive.
   • Notification sync became tool-only; MCP previews are deduped; goal/system notifications gained protection and atomic dismiss controls.
   • OpenAI Responses compact-threshold handling, context-window overflow recovery, strict avatar schema compatibility, and prompt_cache_key support make provider integrations safer.

   Why it matters:Future side-effect policy, budget enforcement, and model self-recovery all need a reliable execution ledger. This release builds that ledger into the kernel instead of asking operators to infer it from logs.

5. 05

   Daemons, avatars, soul/idle care, and long subprocesses are treated as operations

   Many changes are about keeping a running network healthy after the first happy path. Daemon records, dead parents, long CLI subprocesses, and idle timing all became explicit operational surfaces.

   • Dead-parent daemon records are reaped on startup; daemon max_turns increased to 1000 for larger isolated tasks.
   • The experimental interactive Claude backend landed for daemon work while preserving managed-workspace boundaries.
   • Async bash guidance now explicitly requires agent/coding CLIs to run asynchronously rather than blocking the active turn.
   • Idle-care / watchdog-before-idle is documented: before resting with long subprocess or daemon work pending, arm a wake and later verify logs, processes, outputs, worktree progress, and provider prompts.
   • Molt-history and session-journal knowledge entries were documented so recovery after context shedding has a durable trail.
   • Avatar schema strictness and provider relay compatibility were tightened for networks running through stricter APIs.

   Why it matters:A LingTai network is not a single request/response. It is a living runtime. These changes reduce the number of failures that only appear after an agent has been working for a while.

6. 06

   Knowledge, skills, tutorials, and research workflows became more teachable

   The release window also expands the methodology layer. Several issues and PRs turned one-off lessons into skills, docs, and reusable guardrails for future agents and human operators.

   • Skill-backed multilingual /help, markdown viewer routing fixes, notification commands, goal request commands, and community slash-command docs make the TUI easier to teach.
   • Optional skill repository remotes, hidden nested-knowledge catalog behavior, preset-health checks, textbook distillation, and ResearchClawBench docs improve reusable knowledge surfaces.
   • Academic-research gained Zotero institutional full-text handoff guidance and an evidence-verification gate before academic drafting.
   • Graphify repo-map documentation, cyclic manifold architecture docs, and beginner/user-manual issues sharpen the project’s conceptual model.
   • Tutorial material now explains the LICC chat command flow; README/install guidance makes first contact with LingTai less brittle.
   • Closed community requests around browser-based CLIs, login skills, Feishu/WeChat onboarding, rewind/snapshot inspection, and yolo/permission controls remain part of the public contribution record even when not fully adopted in this release.

   Why it matters:A feature is more valuable when future people can learn it without rediscovering the story. This release turns more of LingTai’s operating culture into durable teaching material.

7. 07

   MCP, chat, and mail integrations became more reliable

   Communication is the lifeline of an agent network. This window adds Cloud Mail to the curated addon set, strengthens the kernel LICC path, and fixes Telegram polling recovery after real transport failures.

   • Kernel v0.12.0 embeds curated MCP servers and adds the Cloud Mail MCP addon for self-hosted maillab/cloud-mail REST deployments.
   • Cloud Mail covers check/search/read/send/accounts/add_user plus LICC inbox polling; add_user payload shape was corrected before merge.
   • The kernel exposes the LICC client interface, and the Telegram addon now prefers that client path.
   • Telegram polling now rebuilds stale httpx/proxy clients after disconnects, closing the MCP _poll_loop failure reported in the window.
   • Notification preview dedupe and tool-only notification sync reduce repeated chat replies and diary-looking synthesized text leaks.
   • Adaptive welcome now recommends IM channels when they are the right interface for a human operator.

   Why it matters:A smart agent that misses or repeats human messages is not operationally trustworthy. The integration work in this release is directly about that trust.

8. 08

   Release hygiene and packaging are part of the delivery

   The release was published before the final blog, as it should be: versions should not be blocked by prose. The blog then records the validation and the corrections made so the next release is easier.

   • TUI/Portal v0.9.0 was tagged and released on GitHub; the tag workflow updated Homebrew to v0.9.0 with source SHA f811ea3ccf341dd073b8e9728cfa9125bfe578251cc281fac7c90a5837d4a036.
   • Kernel v0.12.0 was tagged and released on GitHub; lingtai==0.12.0 was built, twine-checked, uploaded to PyPI, and verified as latest.
   • TUI gates passed: diff check after whitespace normalization, TUI Go tests, portal web build, portal Go tests, TUI build, and portal build.
   • Kernel gates passed: compileall, 555 focused pytest tests, build of sdist and macOS arm64 wheel, and twine check.
   • The release-log workflow is being tightened so future blogs start from commits, LOC, merged PRs, closed unmerged PRs, and closed issues by default instead of relying on a narrow patch-note summary.

   Why it matters:A release is not complete just because tags exist; it also needs a public record that names the work, the people, the validation, and the lessons for next time.