Review follow-up:
- runtime.test.js: add syncProject wiring tests with a real temp-dir
project and real project-config runtime — asserts reconcileLoopTasks is
driven with the discovered loops when the project path is known (task
created, nextRunAt computed) and that plain listing is used when the
path cannot be resolved (reconcile not called).
- service.js: DELETE on a loop-owned task is rejected with a 400 only
while its loop file still exists on disk; once the file is gone the
orphan task can be deleted directly instead of waiting for the next
reconcile. Tests use real temp files for both branches.
- DOCUMENTATION.md: delete semantics updated accordingly.
- PR description refreshed for the final HEAD (test counts, reconciliation
contract, evidence wording).
Review fixes for the markdown loop feature:
- Loop-owned tasks now adopt by loop file path, not task name, so renaming
a loop (frontmatter name or UI rename) renames the task in place instead
of leaving a stale duplicate that keeps running the old definition;
orphan duplicates of the same file are unscheduled.
- Unparseable loop files are reported to the scheduler as
definition:null entries: a task whose file still exists is kept with its
last good definition, and only a genuinely removed file unschedules it.
Transiently malformed files (mid-edit, bad merge) no longer delete tasks
or their runtime state.
- Adoption preserves UI-only execution fields (goalEnabled, goalTokenBudget,
permissionAutoAccept, variant) that the portable format does not define.
- DELETE on a loop-sourced task now returns 400 with guidance to remove the
loop file, instead of being silently undone by the next reconcile.
- Loops default to enabled: false; discovery of repository content never
auto-executes scheduled sessions unless the file explicitly enables them.
Regression tests for each fix; DOCUMENTATION.md updated.
Add a shared OpenChamber control service with two thin adapters — a native
`openchamber` tool injected into managed OpenCode, and new CLI commands — so
users can manage parallel sessions, worktrees, and scheduled tasks
conversationally through agents or from the terminal.
Control plane:
- New openchamber-control service owning a fixed action contract:
projects.list, models.list, session list/create/send/fork/status/messages,
and schedule list/create/run/delete/toggle. Session and worktree deletion
and project registration are deliberately not exposed.
- New openchamber-sessions module owning create/worktree/prompt orchestration,
Goal Mode dispatch, wait semantics (initial idle never counts as completion;
timeout and cancellation are failures), and explicit partial-failure results.
- Scheduled-task logic extracted into a service shared by routes, CLI, and the
agent tool.
Agent tool:
- Managed OpenCode gets a materialized plugin registering one typed tool with
a loopback-only callback, per-child ephemeral bearer (timing-safe, never
persisted or logged), and abort propagation into the service.
- The ~1.5k-token schema applies progressive disclosure: short descriptions,
server-side validation returning actionable usage errors, and intent
guardrails — created sessions/tasks are user-facing work (not age
self-delegation); worktree/goal/agent/variant/wait are omit-by-default;
dispatches produce no completion notification, and later result r
to session.messages, which now returns the authoritative sessionStatus.
- session.create without a user-named model picks from favorites/re
send/fork omit the selection and the service reuses the target session's
last user-message model, agent, and variant before falling back t
- An "Agent control tool" setting (default on, Save + Reload to apply)
disables plugin injection entirely.
CLI:
- New `openchamber session`, `schedule`, `projects`, and `models` commands
with automatic instance targeting, --wait/--timeout/--last-assist
worktree flags, and Goal Mode, preserving interactive, non-TTY, --quiet,
and --json contracts. The control HTTP timeout derives from the w
instead of the 4-second default.
UI:
- New built-in "Schedule a Task" starter (/schedule-task) running a
dialogue that defines a task and offers to create it via the tool after
explicit confirmation; Craft a Goal and Feature Planning gain the
handoff offer, and guided starters reserve the question tool for concrete
option choices. Localized in all 10 locales, migrated into custom
starter lists, hidden on VS Code.
- Sidebar shows CLI/agent-created sessions live via the control eve
- openchamber tool calls render with per-action titles and metadata.
makeittech