Kernel v0.16.2 · TUI/Portal v0.10.5

New features and improvements

1. 01

   Safer TUI state transitions

   The TUI release focuses on protecting user projects from partial writes and unsafe cleanup commands.

   • Schema-critical migrations m028/m030/m039 now propagate real transform/read/write failures instead of advancing the stored migration version after a partial failure.
   • lingtai clean refuses to remove .lingtai/ while live or surviving agents are discoverable, or when discovery fails, unless the operator explicitly uses --force.
   • Global config.json, tui_config.json, and .env writes now use sibling-temp files, fsync, rename, cleanup, and permission preservation.

   Why it matters:Project state should either move forward completely or fail with evidence; cleanup must never silently erase a running network.

2. 02

   Clearer setup, Codex, and operator feedback

   Several smaller TUI changes make failures visible at the surface where the operator can act.

   • Codex OAuth/pool credentials now have clearer account labels and fallback filenames.
   • First-run config saves, recipe re-apply failures, preset load causes, and updater already-current states now surface more directly.
   • The UI gained API-call grouping, Ctrl+End tail-jump coverage, refreshed knowledge entries, async home telemetry, and network activity evidence.

   Why it matters:When setup fails, the fastest fix is a precise surface message rather than another hidden log hunt.

3. 03

   Kernel summary and manual contracts

   Kernel v0.16.2 continues the progressive-disclosure work needed by long-lived agents.

   • Daemon/glob results now participate in summary flows, with better a-priori compression metadata and documentation.
   • Info/manual signpost actions are split so tools can report runtime health separately from bundled manuals.
   • Prompt section contracts, adapt-from-evidence guidance, retention footprint reports, and timely transient _meta filtering reduce stale or noisy context.

   Why it matters:Agents doing release work need to preserve evidence without dragging every raw log through the next hundred calls.

4. 04

   Daemon, MCP, and messaging resilience

   The runtime side adds more explicit contracts for delegated work and notification delivery.

   • Kimi native MCP config, parent MCP propagation into CLI backends, and daemon architecture docs make delegated coding/review work easier to reproduce.
   • Codex pool provider/preset support and external skill intake docs make tool routing more explicit.
   • Persistent Telegram notification/reply context and the LICC notification contract reduce lost context across message surfaces.

   Why it matters:Delegated work is only useful if the parent can reconstruct what happened and why the result is safe to ship.

5. 05

   Release-window audit and contributors

   Following the previous release-log structure, this entry accounts for actual commit authors as well as every issue and PR closed in the release window, including closed-unmerged PRs and triaged/rejected issues.

   • TUI/Portal: 45 commits (39 @huangzesen, 2 @TZZheng, 4 @github-actions[bot]); 20 PRs closed (19 merged, 1 closed unmerged); 31 issues closed.
   • Kernel: 51 commits (29 @9s5bz2jvd2-lang, 20 @huangzesen, 2 @TZZheng); 26 PRs closed (20 merged, 6 closed unmerged); 15 issues closed.
   • Release-window contributors/authors: @huangzesen, @TZZheng, @9s5bz2jvd2-lang, @ZigongXu, @BrianLiubr, and @888yzbt888.

   Why it matters:The contributor list intentionally includes issue/PR authors from the release window even when a specific issue or PR was closed, rejected, or unmerged.