| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
plus richer context menus (#114)
## The data-loss bug
User reported "even after clicking Save now I have lost my doc". Two causes:
1. **GoalChangePlugin only read children[1]** — it captured edits to the
single goal paragraph but silently dropped any typing that landed in
the trailing paragraph below the StepsBlock (or in extra paragraphs the
user had inserted). pendingGoalRef stayed at the persisted value, Save
now fired empty/stale content, the doc was overwritten.
2. **fireSave dropped localStorage immediately on save success.** If the
save persisted the wrong/empty content, the draft (which had the real
content) was already gone — no recovery path.
## Fixes
### Capture all body content
New `serializeGoalFromRoot` walks the entire root, skips only the H1 title
and the StepsBlock decorator, and emits multi-paragraph markdown joined by
blank lines. `GoalChangePlugin` and `fireSave` both call it now. Seed code
splits an existing multi-paragraph goal back into ParagraphNodes on load.
### Read directly from the editor at save time
`fireSave` now reads pendingGoalRef AND consults the live editor state via
`editor.getEditorState().read()`. If anything went wrong with OnChangePlugin
(which is rare, but possible — and was eating typing for many users), the
save still picks up the actual document body.
### Defensive pre-save flush
Before talking to the backend, `fireSave` writes the value to localStorage.
If the network fails, the page closes mid-flight, or anything else goes
sideways, the draft survives.
### Roundtrip-confirmed draft cleanup
We no longer drop the localStorage draft inside `fireSave`. Instead a new
effect watches `directive.goal` and clears the draft only when:
lastSavedValueRef === directive.goal === pendingGoalRef.current
i.e. only when the polled state confirms our save persisted AND the user
hasn't typed anything new in the meantime.
## Question notifications respect document mode
`SupervisorQuestionNotification` and `PhaseConfirmationToast` now route to
`/directives/<id>?task=<taskId>` (the doc-mode surface) when the user has
documentMode on AND the question carries a directiveId. Falls back to the
old `/exec/:taskId` route for non-doc-mode users.
## Richer directive folder context menu
In addition to start/pause/archive/delete/go-to-PR/new-draft we now expose:
- Advance DAG
- Plan orders
- Clean up
- Create / Update PR
All optional callbacks; the legacy tabular UI is unaffected.
## Richer task row context menu
In addition to interrupt/complete/fail/skip we now expose:
- Send message — browser prompt → sendTaskMessage (same wire as the
inline comment box)
- Open in task page — navigates to /exec/:taskId for the full task UI
(worktree diff viewer, checkpoint controls, etc.)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
steps, rename Mesh to Exec (#84)
* feat: soryu-co/soryu - makima: Rename Mesh to Exec in navigation
* WIP: heartbeat checkpoint
* WIP: heartbeat checkpoint
* WIP: heartbeat checkpoint
* feat: soryu-co/soryu - makima: Add contract-backed steps to directive flow
* WIP: heartbeat checkpoint
|
| |
|
|
|
| |
* [WIP] Heartbeat checkpoint - 2026-01-20 22:40:37 UTC
* Task completion checkpoint
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add comprehensive CLI documentation
- Create makima/docs/CLI.md with complete command reference for:
- makima server: HTTP/WebSocket server options
- makima daemon: Worker daemon configuration
- makima supervisor: Contract orchestration commands
- makima contract: Task-contract interaction commands
- Include configuration file examples and environment variables
- Add usage workflows for common scenarios
- Update makima/README.md with CLI overview and link to docs
Add GitHub Actions release workflow for v0.1.0
Creates automated release workflow that:
- Triggers on v* tag pushes
- Builds binaries for Linux x86_64, macOS x86_64, and macOS ARM64
- Uses Rust nightly toolchain (required for edition 2024)
- Packages binaries as .tar.gz archives
- Creates GitHub release with installation instructions
fix(ci): update macOS runner for x86_64 builds
Replace deprecated macos-13 runner with macos-15-intel for
x86_64-apple-darwin target. The macos-13 runner has been retired
by GitHub Actions.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add dismissing notifications and fix CLI task ID arg
Add worktree cleanup when contracts complete or are deleted (#21)
- Add CleanupWorktree daemon command variant
- Handle CleanupWorktree in daemon task manager
- Add cleanup_contract_worktrees helper function
- Trigger cleanup when contract status becomes 'completed'
- Trigger cleanup before contract deletion
Add Autonomous Loop Mode for persistent task completion (#20)
Implements the "Autonomous Loop Mode" feature inspired by Ralph for Claude Code.
This enables tasks to automatically restart and continue working until they
explicitly signal completion via a COMPLETION_GATE block.
Key features:
- Exit confirmation via COMPLETION_GATE: Tasks must output a <COMPLETION_GATE>
block with `ready: true` to signal completion. Without this, the task
auto-restarts using `claude --continue` to resume the conversation.
- Circuit breaker: Prevents infinite loops by detecting:
* Maximum iteration limit (default: 10)
* No progress for N consecutive iterations (default: 3)
* Same error repeated N times (default: 5)
- spawn_continue: New ProcessManager method to spawn Claude with the
`--continue` flag, resuming from the previous session state.
Toggle: Enable via `autonomous_loop` flag on contracts. When set, all tasks
spawned for that contract will run in autonomous loop mode.
Files changed:
- completion_gate.rs: COMPLETION_GATE parser and CircuitBreaker logic
- claude.rs: spawn_continue() for --continue mode spawning
- manager.rs: Autonomous loop iteration logic in run_task()
- protocol.rs: autonomousLoop field in DaemonCommand::SpawnTask
- models.rs/repository.rs: autonomous_loop column on contracts/tasks
- Migration: Adds autonomous_loop columns to contracts and tasks tables
Add get-task and output commands to supervisor CLI (#24)
Add two new supervisor subcommands:
- `makima supervisor task <task_id>` - Get individual task details
- `makima supervisor output <task_id>` - Get task output/claude log
This allows supervisors to fetch task details and claude output
directly from the CLI instead of using curl to call the task API.
Add optional bubblewrap sandboxing for Claude processes (#23)
Add --bubblewrap flag and process.bubblewrap config section to enable
running Claude Code in a bubblewrap sandbox for process isolation.
When enabled, claude processes run with filesystem restrictions:
- Root filesystem mounted read-only
- Working directory (worktree) mounted read-write
- Fresh /dev, /proc, /tmp
- Network access preserved for API calls
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
