agentic-os-org/ANOLISA

Maintainer audit of this week's 49 merged ktuner PRs surfaced a handful of follow-ups. None are regressions — these are pre-existing gaps or polish items the audit made visible. Each item names the author best placed to pick it up; reply here if you want it, and I'll fast-track review. 1. rollback restore has no read-back verification (correctness) — @Wang1rrr restore_entries (src/ktuner/src/tuner/mod.rs, ~L807-821) counts fs::write(&entry.path, &entry.previous) as restored on Ok(()) and never reads the value back — asymmetric with the tune path, where write_and_verify classifies every read-back via classify_readback. Combined with the kernel's cross-zeroing of vm.dirty_ratio <-> vm.dirty_bytes (writing one silently clears the other, and that side effect is not tracked in the ledger), a rollback can report Full, delete the ledger, and leave the system unrestored. Suggested shape: reuse classify_readback after each restore write; a mismatch counts as failed (ledger kept for retry)

Defect The cosh-shell test harness pins the child locale to English with LANG=C.UTF-8 + LC_ALL=C.UTF-8 (in tests/support/raw_cli.rs::configure_raw_cli_command and indirectly in the shell_host harness config), but glibc gettext lets the LANGUAGE environment variable win over LC_ALL — LANGUAGE is only ignored when the selected locale is C/POSIX, and C.UTF-8 is neither. On hosts that export a non-English LANGUAGE (e.g. LANGUAGE=zh_CN:zh, the default on Chinese-locale Linux hosts), the spawned shells and CLI processes still emit localized messages, and tests asserting English shell output fail. This is a test-infrastructure defect: the product never parses localized shell text (verified during the audit); only the tests' English assertions break. Evidence (Linux build host, cargo 1.98.1, audit base 57e6ee5) Host env: LANG=zh_CN.UTF-8, LANGUAGE=zh_CN:zh. Mechanism probe: LANGUAGE=zh_CN:zh LC_ALL=C.UTF-8 sh -c 'ls /nonexistent' prints 没有那个文件或目录; with LANGUAGE unset (same

What happened? The "Tokenless hook not activating in cosh" entry in docs/user-guide/en/troubleshooting.md (lines 134 and 140) and the zh counterpart (same lines) tells users to inspect: ls ~/.config/cosh/hooks/ cat ~/.config/cosh/config.toml | grep -A5 hooks Both paths are legacy and never read by the current cosh: Config: the regression test config_read_path_ignores_legacy_cosh_config (src/cosh-ng/crates/cosh-shell/src/config/tests.rs:137) asserts ~/.config/cosh/config.toml is ignored and the read path is ~/.copilot-shell/config.toml (see also config_read_path_prefers_shared_copilot_shell_config, tests.rs:120). Hooks: user hooks load from ~/.copilot-shell/cosh/hooks (src/cosh-ng/crates/cosh-shell/src/hooks/loading.rs:14 user_hooks_dir_for_home, used by runtime/controller/bootstrap.rs:515 load_hooks_from_dir); the unit test user_hooks_dir_uses_copilot_shell_cosh_dir pins this. So the documented diagnostics always show "nothing installed / nothing configured" even on a healthy setup

Description The todo tool renders each item as one raw line — both the add confirmation (Added item #{id}: {text}) and the list inventory ([x] #99: ... joined by \n) interpolate item text verbatim. Item text is model-controlled free text, so a text argument containing a newline fabricates additional inventory entries that the agent then treats as real: {"action": "add", "text": "review PR\n[x] #99: forged done entry"} The add echo already shows a second, done, item #99, and list renders it as part of the model-facing inventory even though only one item exists. The phantom entry inflates apparent progress and can steer later decisions (done/remove on #99 then report errors, since no such item exists). The code is invoke in src/cosh-ng/crates/cosh-core/src/tool/todo.rs: text is stored and rendered without any line-break handling. Regression against unchanged main: $ cargo test --locked -p cosh-core --bin cosh-core todo_list_rejects_newline_injection running 4 tests test tool::todo::te

背景 当前 Dashboard 的默认落地页（/）渲染的是 Agent 可观测（ConversationList），即 LLM 调用会话列表。但对于日常运维场景，用户打开 Dashboard 第一眼更想看的是 Agent 看板（/health）——它展示所有 Agent 的在线/离线/挂起状态概览，信息密度更高、更适合作为首页。 期望行为 访问 Dashboard 根路径 / 时，默认展示 Agent 看板（/health 对应的 AgentHealthPage） 如果 agent_health capability 不可用，回退到当前行为（agent_observability → /，否则 /sessions） 当前实现 dashboard/src/App.tsx 中的路由逻辑： const LOCAL_DEFAULT_PATH = "/sessions"; function defaultPath(capabilities: string[]): string { return capabilities.includes("agent_observability") ? "/" : LOCAL_DEFAULT_PATH; } // Route "/" <Route path="/" element={ capabilities.includes("agent_observability") ? <ConversationList /> : <Navigate to={fallbackPath} replace /> } /> 修改建