2 Commits

Include renames

Author	SHA1	Message	Date
HomerandClaude Opus 5.5	d111cad22e	Scheduled work on this computer (spec 3.5.0): Accept scheduled work, scheduled turns, the watch command; team_add names the sub-manager ... remote.scheduled (lembas service scheduled on|off, lembas remote scheduled on|off) said as limits.scheduled; a scheduled session runs in the schedule's mode (Edit when none, Plan refused, lowered to max_mode), reports ok/silent/failed/cancelled and the final reply, waits the schedule's wait on approvals and offers no question, plan card or show. _lembas/monitor judges the watch command by the mode (ask is refused) and hashes the output as it streams. Conformance areas scheduled, silent and monitor run here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-10 12:16:54 +00:00
HomerandClaude Opus 5.5	479f647cc9	lembas remote: manage remote: without YAML; a running service follows it ... `lembas remote list | add | remove | enable | disable | mode | terminal`, with `--json` printing {enabled, roots, max_mode, terminal}, for LLeMbas Desktop. Writes go through the global config writer and keep comments. The device's limits are now live getters over the remote: block, re-read when config.yaml's stat changes. `lembas service` links even with remote work off or no roots: it says roots: [] and refuses every session, directory and terminal, so the instance can tell "no folder allowed yet" from "not running". When what the instance was told changes, the link re-dials once nothing is working, so `lembas remote add` or `enable` takes effect without a restart. Harness spec 1.0.1 documents both. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-14 18:15:59 +00:00