zeroclaw-labs/zeroclaw

Documentation location https://docs.zeroclaw.com/master/en/contributing/multi-agent-setup.html Documentation issue type confusing or unclear Problem Summary The multi-agent setup guide currently lives under: docs/book/src/contributing/multi-agent-setup.md and is exposed in the documentation under Contributing. I wonder whether this is still the right location for the page. The guide is primarily operator/user-facing: it explains how to configure and operate multiple agents, including channel binding, cross-agent filesystem and memory access, peer groups, and agent inspection. By contrast, the rest of the Contributing section is focused on contributing to the ZeroClaw project itself: contribution workflow, RFCs, testing, PR review, CLA, contributor communication, etc. Historical context This location appears to originate from #6272, which explicitly specified: docs/book/src/contributing/multi-agent-setup.md However, the same issue describes the page as an "operator walkthrough". At that

Affected component zerocode/tui Severity S3 - minor issue Current behavior Press Del key cause nothing in zerocode chat. Expected behavior delete charactor Steps to reproduce zerocode --agent <alias> # focus the chat composer # type: hello world # press Left several times, then press Del # -> nothing is deleted Impact No response Logs / stack traces ZeroClaw version master @ dc5b968 Rust version No response Operating system Windows 11 Regression? Unknown Pre-flight checks I reproduced this on the latest master branch or latest release. I redacted secrets, tokens, and personal data from all submitted content.

Task Correct the graceful-shutdown paragraph in docs/book/src/ops/service.md so reload-refusal recovery is described by platform. Context PR #10262 documents refusing an in-process reload when old RPC work has not drained. At d23dd46c38e95962fad6ad9f8c4c94459edcc7ac, the paragraph says a service manager then restarts the daemon. The same document correctly states that systemd and launchd restart it, but the Windows ONLOGON task has no restart-on-failure policy. The latest approval explicitly treats this wording correction as nonblocking. Acceptance criteria Say that the documented systemd and launchd configurations restart the daemon after refusal. Explain that the Windows ONLOGON task may require manual restart or the next logon. Keep ZeroCode's owned-child replacement path distinct from service-manager behavior. Change documentation only; preserve the fail-closed drain policy. Likely files or areas docs/book/src/ops/service.md, graceful shutdown and service configuration. Contribut

Task Localize the ZeroCode daemon-wait notice and added socket-path timeout guidance introduced by #10737 using ZeroCode's existing Fluent catalogue and i18n helper. Context At head d871bf5d43ab151feaf3ba7f48c65685d9bfd278, await_spawned_daemon_ready in apps/zerocode/src/main.rs prints the new waiting notice and timeout guidance as literal English. The review on #10737 explicitly defers this localization work as nonblocking for the socket startup repair. The repository's AGENTS.md user-facing-text contract requires ZeroCode to use its own Fluent catalogue. This task covers those messages only. Do not change socket validation, daemon cleanup, readiness deadlines, or retry behavior. No new runtime reproduction is claimed; the evidence is the exact-head source and review. Acceptance criteria Move the waiting notice and timeout guidance into the existing ZeroCode Fluent catalogue and render them through the existing helper. Preserve path and duration interpolation and the actionable ZEROC

Summary Currently the cron Schedule field in the Add/Edit Cron Job modal is a single freeform text input (web/src/pages/Cron.tsx). The user types a raw expression such as 0 0 * * * with no per-field guidance, no client-side validation, and no human-readable confirmation of what the schedule means. This issue replaces that single input with a five-field cron editor: one labelled input per cron position (Minute · Hour · Day · Month · Week day), plus a consolidated view underneath that shows the assembled expression, a plain-English read-back, and a validity indicator. The consuming form must block submission while the expression is invalid. The change is confined to the frontend. The API still receives a single schedule field (one string), exactly as today, so no server change is required. Hard constraint — frontend only. This issue changes only the React frontend. There must be no change to the HTTP API, request/response shapes, gateway/runtime Rust code, or any persistence/datab