| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add comprehensive Red Team system specification
Defines the adversarial review feature for contracts that monitors work tasks
in real-time to catch quality issues, plan deviations, and standards violations.
Key components specified:
- Contract configuration (red_team_enabled, red_team_prompt)
- Red team task lifecycle and spawning logic
- makima red-team notify CLI command for supervisor alerts
- Task output subscription for real-time monitoring
- Database schema changes (contracts, tasks, notifications table)
- API endpoints for notification and status
- System prompt template for red team behavior
- Security considerations and access control
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Fix new contract dialog not fitting on screen
Added viewport-relative constraints to the create contract modal:
- max-height: 90vh to limit dialog height to 90% of viewport
- overflow-y: auto to enable scrolling when content overflows
- padding on the backdrop container for edge margins on small screens
This ensures the dialog is accessible on all screen sizes while
maintaining scrollability for longer content.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Add redTeamEnabled and redTeamPrompt state to contracts page
- Add "Enable Red Team Monitoring" checkbox with description
- Add conditional "Custom Review Criteria" textarea when enabled
- Include redTeamEnabled/redTeamPrompt in CreateContractRequest
- Reset red team fields when canceling contract creation
- Add redTeamEnabled to ContractSummary and Contract types
- Add redTeamEnabled/redTeamPrompt to CreateContractRequest type
- Add Red Team badge (🔍) to ContractList for enabled contracts
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add comprehensive Red Team system specification
Defines the adversarial review feature for contracts that monitors work tasks
in real-time to catch quality issues, plan deviations, and standards violations.
Key components specified:
- Contract configuration (red_team_enabled, red_team_prompt)
- Red team task lifecycle and spawning logic
- makima red-team notify CLI command for supervisor alerts
- Task output subscription for real-time monitoring
- Database schema changes (contracts, tasks, notifications table)
- API endpoints for notification and status
- System prompt template for red team behavior
- Security considerations and access control
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Fix starting phase dropdown to show correct phase names from templates
Add phaseNames map to ContractTypeTemplate to preserve display names
from custom templates loaded from localStorage. The dropdown now uses
the template's phase name (e.g., 'Design & Architecture') instead of
naive capitalization of the phase ID. Falls back to capitalization for
built-in templates that don't provide phaseNames.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Add Qwen3-TTS research document for live TTS replacement
Research findings for replacing Chatterbox TTS with Qwen3-TTS-12Hz-0.6B-Base:
- Current TTS: Chatterbox-Turbo-ONNX with batch-only generation, no streaming
- Qwen3-TTS: 97ms end-to-end latency, streaming support, 3-second voice cloning
- Voice cloning: Requires 3s reference audio + transcript (Makima voice planned)
- Integration: Python service with WebSocket bridge (no ONNX export available)
- Languages: 10 supported including English and Japanese
Document includes:
- Current architecture analysis (makima/src/tts.rs)
- Qwen3-TTS capabilities and requirements
- Feasibility assessment for live/streaming TTS
- Audio clip requirements for voice cloning
- Preliminary technical approach with architecture diagrams
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 03:11:15 UTC
* Add Qwen3-TTS research documentation
Comprehensive research on replacing Chatterbox TTS with Qwen3-TTS-12Hz-0.6B-Base:
- Current TTS implementation analysis (Chatterbox-Turbo-ONNX in makima/src/tts.rs)
- Qwen3-TTS capabilities: 97ms streaming latency, voice cloning with 3s reference
- Cross-lingual support: Japanese voice (Makima/Tomori Kusunoki) speaking English
- Python microservice architecture recommendation (FastAPI + WebSocket)
- Implementation phases and technical approach
- Hardware requirements and dependencies
Key findings:
- Live/streaming TTS is highly feasible with 97ms latency
- Voice cloning fully supported with 0.95 speaker similarity
- Recommended: Python microservice with WebSocket streaming
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add comprehensive Qwen3-TTS integration specification
This specification document defines the complete integration of
Qwen3-TTS-12Hz-0.6B-Base as a replacement for the existing Chatterbox-Turbo
TTS implementation. The document covers:
## Functional Requirements
- WebSocket endpoint /api/v1/speak for streaming TTS
- Voice cloning with default Makima voice (Japanese VA speaking English)
- Support for custom voice references
- Detailed client-to-server and server-to-client message protocols
- Integration with Listen page for bidirectional speech
## Non-Functional Requirements
- Latency targets: < 200ms first audio byte
- Audio quality: 24kHz, mono, PCM16/PCM32f
- Hardware requirements: CUDA GPU with 4-8GB VRAM
- Scalability: 10 concurrent sessions per GPU
## Architecture Specification
- Python TTS microservice with FastAPI/WebSocket
- Rust proxy endpoint in makima server
- Voice prompt caching mechanism (LRU cache)
- Error handling and recovery strategies
## API Contract
- Complete WebSocket message format definitions (TypeScript)
- Error codes and responses (TTS_UNAVAILABLE, SYNTHESIS_ERROR, etc.)
- Session state machine and lifecycle management
## Voice Asset Requirements
- Makima voice clip specifications (5-10s WAV, transcript required)
- Storage location: models/voices/makima/
- Metadata format for voice management
## Testing Strategy
- Unit tests for Python TTS service and Rust proxy
- Integration tests for WebSocket flow
- Latency benchmarks with performance targets
- Test data fixtures for various text lengths
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add Qwen3-TTS implementation plan
Comprehensive implementation plan for replacing Chatterbox-TTS with
Qwen3-TTS streaming TTS service, including:
- Task breakdown with estimated hours for each phase
- Phase 1: Python TTS microservice (FastAPI, WebSocket)
- Phase 2: Rust proxy integration (speak.rs, tts_client.rs)
- Detailed file changes and new module structure
- Testing plan with unit, integration, and latency benchmarks
- Risk assessment with mitigation strategies
- Success criteria for each phase
Based on specification in docs/specs/qwen3-tts-spec.md
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add author and research references to TTS implementation plan
Add links to research documentation and author attribution.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 03:25:06 UTC
* Add Python TTS service project structure (Phase 1.1-1.3)
Create the initial makima-tts Python service directory structure with:
- pyproject.toml with FastAPI, Qwen-TTS, and torch dependencies
- config.py with pydantic-settings TTSConfig class
- models.py with Pydantic message models (Start, Speak, Stop, Ready, etc.)
This implements tasks P1.1, P1.2, and P1.3 from the Qwen3-TTS implementation plan.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add TTS engine and voice manager for Qwen3-TTS (Phase 1.4-1.5)
Implement core TTS functionality:
- tts_engine.py: Qwen3-TTS wrapper with streaming audio chunk generation
- voice_manager.py: Voice prompt caching with LRU eviction and TTL support
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 03:30:06 UTC
* Add TTS proxy client and message types (Phase 2.1, 2.2, 2.4)
- Add tts_client.rs with TtsConfig, TtsCircuitBreaker, TtsError,
TtsProxyClient, and TtsConnection structs for WebSocket proxying
- Add TTS message types to messages.rs (TtsAudioEncoding, TtsPriority,
TtsStartMessage, TtsSpeakMessage, TtsStopMessage, TtsClientMessage,
TtsReadyMessage, TtsAudioChunkMessage, TtsCompleteMessage,
TtsErrorMessage, TtsStoppedMessage, TtsServerMessage)
- Export tts_client module from server mod.rs
- tokio-tungstenite already present in Cargo.toml
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add TTS WebSocket handler and route (Phase 2.3, 2.5, 2.6)
- Create speak.rs WebSocket handler that proxies to Python TTS service
- Add TtsState fields (tts_client, tts_config) to AppState
- Add with_tts() builder and is_tts_healthy() methods to AppState
- Register /api/v1/speak route in the router
- Add speak module export in handlers/mod.rs
The handler forwards WebSocket messages bidirectionally between
the client and the Python TTS microservice with proper error handling.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add Makima voice profile assets for TTS voice cloning
Creates the voice assets directory structure with:
- manifest.json containing voice configuration (voice_id, speaker,
language, reference audio path, and Japanese transcript placeholder)
- README.md with instructions for obtaining voice reference audio
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add Rust-native Qwen3-TTS integration research document
Research findings for integrating Qwen3-TTS-12Hz-0.6B-Base directly into
the makima Rust codebase without Python. Key conclusions:
- ONNX export is not viable (unsupported architecture)
- Candle (HF Rust ML framework) is the recommended approach
- Model weights available in safetensors format (2.52GB total)
- Three components needed: LM backbone, code predictor, speech tokenizer
- Crane project has Qwen3-TTS as highest priority (potential upstream)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 11:21:43 UTC
* [WIP] Heartbeat checkpoint - 2026-01-27 11:24:19 UTC
* [WIP] Heartbeat checkpoint - 2026-01-27 11:26:43 UTC
* feat: implement Rust-native Qwen3-TTS using candle framework
Replace monolithic tts.rs with modular tts/ directory structure:
- tts/mod.rs: TtsEngine trait, TtsEngineFactory, shared types (AudioChunk,
TtsError), and utility functions (save_wav, resample, argmax)
- tts/chatterbox.rs: existing ONNX-based ChatterboxTTS adapted to implement
TtsEngine trait with Mutex-wrapped sessions for Send+Sync
- tts/qwen3/mod.rs: Qwen3Tts entry point with HuggingFace model loading
- tts/qwen3/config.rs: Qwen3TtsConfig parsing from HF config.json
- tts/qwen3/model.rs: 28-layer Qwen3 transformer with RoPE, GQA (16 heads,
8 KV heads), SiLU MLP, RMS norm, and KV cache
- tts/qwen3/code_predictor.rs: 5-layer MTP module predicting 16 codebooks
- tts/qwen3/speech_tokenizer.rs: ConvNet encoder/decoder with 16-layer RVQ
- tts/qwen3/generate.rs: autoregressive generation loop with streaming support
Add candle-core, candle-nn, candle-transformers, safetensors to Cargo.toml.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: integrate TTS engine into speak WebSocket handler
- Update speak.rs handler to use TTS engine directly from SharedState
instead of returning a stub "not implemented" error
- Add TtsEngine (OnceCell lazy-loaded) to AppState in state.rs with
get_tts_engine() method for lazy initialization on first connection
- Implement full WebSocket protocol: client sends JSON speak/cancel/stop
messages, server streams binary PCM audio chunks and audio_end signals
- Create voices/makima/manifest.json for Makima voice profile configuration
- All files compile successfully with zero errors
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: add /speak TTS page with WebSocket audio playback
Add a new /speak frontend page for text-to-speech via WebSocket.
The page accepts text input and streams synthesized PCM audio through
the Web Audio API. Includes model loading indicator, cancel support,
and connection status. Also adds a loading bar to the listen page
ControlPanel during WebSocket connection.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add comprehensive Red Team system specification
Defines the adversarial review feature for contracts that monitors work tasks
in real-time to catch quality issues, plan deviations, and standards violations.
Key components specified:
- Contract configuration (red_team_enabled, red_team_prompt)
- Red team task lifecycle and spawning logic
- makima red-team notify CLI command for supervisor alerts
- Task output subscription for real-time monitoring
- Database schema changes (contracts, tasks, notifications table)
- API endpoints for notification and status
- System prompt template for red team behavior
- Security considerations and access control
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Fix history page contracts dropdown overflow
Replace native HTML <select> with custom dropdown component that:
- Uses max-h-[300px] with overflow-y-auto for scrollable list
- Positions with z-50 to not interfere with other elements
- Closes on click outside via mousedown event listener
- Shows chevron indicator with rotation animation
- Maintains dark theme styling with blue accents
- Highlights selected contract with visual feedback
Fixes issue where long contract lists caused page overflow
and obscured date filter inputs.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-27 02:48:59 UTC
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add local_only flag to contracts database and models
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Skip automatic completion actions in local_only mode
Add `local_only` flag to contracts that prevents automatic completion
actions (branch, merge, pr) from executing when tasks complete. This
allows users to manually handle code changes via patch files or other
means when operating in local-only mode.
Changes:
- Add `local_only` field to Contract model and request types
- Add database migration for the new column
- Add `local_only` parameter to SpawnTask command in both state.rs and
daemon protocol.rs
- Modify task manager to skip completion action execution when
`local_only` is true, with appropriate logging
- Pass `local_only` flag through all task spawning paths:
- mesh_supervisor.rs (task spawn, retry, resume)
- mesh.rs (task start, reassign, continue)
- mesh_chat.rs (run task)
- contract_chat.rs (run task)
- Update repository create/update functions to handle `local_only`
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Implement core patch export system
Add functionality to create uncompressed, human-readable git patches
for export. This enables users to generate patches that can be manually
applied or shared, without the compression used for internal checkpoints.
Changes:
- Add ExportPatchResult struct with patch content, file count, and line stats
- Add create_export_patch() function that generates diffs against a base SHA
- Add get_head_sha() utility function
- Add parse_diff_stat() helper to extract line counts from git output
- Add CreateExportPatch command to daemon protocol
- Add ExportPatchCreated response message to protocol
- Add handler in task manager to process export patch requests
- Add server-side handling to broadcast patch results to UI
The export patch system automatically finds the merge-base when no base
SHA is provided, trying upstream tracking branch first, then common
default branches (origin/main, origin/master, main, master).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Add GitActionsPanel frontend component
* Add WorktreeFilesPanel and PatchesListPanel components
* Add local-only mode toggle to contract creation
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
| |
- Add 'execute' contract type as a built-in template in backend
- Fix API response field name mismatch (types -> contractTypes)
- Remove duplicate ContractTypeTemplate definition in api.ts
- Merge built-in types from API with user templates from localStorage
- User templates created in the Templates page now appear in contract creation
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* feat: Add contract type templates API endpoint
Add a new API endpoint to provide contract type templates (workflow
definitions) separate from file templates. This enables the create
contract page to dynamically show available contract types.
Changes:
- Add ContractTypeTemplate struct in templates.rs with id, name,
description, phases, default_phase, and is_builtin fields
- Add built-in contract types: 'simple' (plan/execute) and
'specification' (research/specify/plan/execute/review)
- Add GET /api/v1/contract-types endpoint returning all contract types
- Add frontend ContractTypeTemplate interface and listContractTypes()
API function
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: Update create contract modal to use dynamic templates
- Add ContractTypeTemplate interface and listContractTypes API function
to frontend api.ts
- Add GET /api/v1/contract-types backend endpoint that returns built-in
contract types (simple, specification) with their phases and defaults
- Update create contract modal to fetch contract types dynamically when
opened, with loading state and fallback to hardcoded types on error
- Dynamically render contract type selection buttons from fetched types
- Update phase dropdown to use phases from selected contract type
- Replace static getValidPhases/getDefaultPhase calls with dynamic data
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* feat: remove Files from top-level navigation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: update file links to use contract-scoped routes
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: add contract context to FileDetail component
- Add contractId, contractName, and onContractClick props to FileDetailProps
- Update breadcrumb navigation to show contract name with path separator
when viewing file within a contract context
- Fall back to "Back to list" when no contract context is provided
- This enables the FileDetail component to be used within the
/contracts/:contractId/files/:fileId route
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: update routes to nest files under contracts
- Add react-router-dom for client-side routing
- Create ContractList component to list all contracts
- Create ContractDetail component with tabs (overview, files, tasks, repos)
- Create FileDetail component to view individual files
- Configure routes:
- /contracts - list all contracts
- /contracts/:id - view contract details with Files tab
- /contracts/:contractId/files/:fileId - view file in contract context
- Remove standalone file routes (/files, /files/:id)
Files are now only accessible through their parent contract.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* feat: Add contract-scoped file route /contracts/:id/files/:fileId
- Create ContractFilePage component for viewing files within contract context
- Add route for /contracts/:id/files/:fileId in main.tsx
- Update handleFileSelect in contracts.tsx to navigate to contract-scoped file URL
- File viewer now has "Back to Contract" navigation instead of standalone /files
This allows files accessed from a contract to maintain context and return
to the contract page when going back.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* feat: remove Files from top-level navigation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: update file links to use contract-scoped routes
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: add contract context to FileDetail component
- Add contractId, contractName, and onContractClick props to FileDetailProps
- Update breadcrumb navigation to show contract name with path separator
when viewing file within a contract context
- Fall back to "Back to list" when no contract context is provided
- This enables the FileDetail component to be used within the
/contracts/:contractId/files/:fileId route
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: update routes to nest files under contracts
- Add react-router-dom for client-side routing
- Create ContractList component to list all contracts
- Create ContractDetail component with tabs (overview, files, tasks, repos)
- Create FileDetail component to view individual files
- Configure routes:
- /contracts - list all contracts
- /contracts/:id - view contract details with Files tab
- /contracts/:contractId/files/:fileId - view file in contract context
- Remove standalone file routes (/files, /files/:id)
Files are now only accessible through their parent contract.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
* Task completion checkpoint
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
## Backend Changes
### Phase Deliverables Simplified
- **Simple contract type**:
- Plan phase: Only 'Plan' deliverable (required)
- Execute phase: Only 'PR' deliverable (required)
- **Specification contract type**:
- Research phase: Only 'Research Notes' deliverable (required)
- Specify phase: Only 'Requirements Document' deliverable (required)
- Plan phase: Only 'Plan' deliverable (required)
- Execute phase: Only 'PR' deliverable (required)
- Review phase: Only 'Release Notes' deliverable (required)
### New 'execute' Contract Type
- Only has 'execute' phase (no plan or review phases)
- NO deliverables at all - executes tasks directly
- Added to ContractType enum with proper Display/FromStr implementations
- Added helper methods: `initial_phase()`, `terminal_phase()`
### API Updates
- Added `get_phase_deliverables_for_type()` for contract-type-aware deliverables
- Added `get_phase_checklist_for_type()` for contract-type-aware checklists
- Added `check_phase_completion_for_type()` for contract-type-aware completion checks
- Added `check_deliverables_met()` function for deliverable validation
- Added `should_auto_progress()` for autonomous contract progression
- Added new ContractToolRequest::CheckDeliverablesMet tool
## Frontend Changes (makima/frontend)
### Templates Page
- Add TemplateEditor component for editing phase deliverables
- Create Templates page with template card grid layout
- Add navigation link in NavStrip
- Implement three built-in templates: Simple, Specification, Execute
- Support for creating custom templates with configurable phases/deliverables
- Templates are persisted to localStorage
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix completion actions: default to PR and support remote repos
- Change default completion action from 'branch' to 'pr' for tasks
using daemon working directory
- Allow PR completion action to work without target_repo_path if the
worktree already has an origin remote configured (e.g., when cloned
from a remote URL)
- Update create_pull_request to accept optional target_repo parameter
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add dismiss functionality for completed standalone tasks
## Changes
### Backend
- Add 'hidden' field to Task model (models.rs)
- Add database migration for hidden column (20250122000000_add_task_hidden.sql)
- Update task listing queries to include hidden field and filter out hidden tasks
- Update update_task_for_owner to handle hidden field
### Frontend
- Add hidden field to TaskSummary interface (api.ts)
- Add dismissTask API function (api.ts)
- Add hideTask function to useTasks hook
- Add Dismiss button to TaskList for completed standalone tasks
- Wire up onDismiss handler in mesh.tsx route
## Behavior
- Completed standalone tasks (tasks without a contract) show a "Dismiss" button
- Dismissing a task sets hidden=true and removes it from the task list
- Hidden tasks are filtered out by default in all task listing queries
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
When phase_guard is enabled on a contract, the backend expects
{ phase, confirmed: true } to actually perform the phase change.
Without confirmed: true, the backend returns a PhaseTransitionRequest
instead of ContractSummary, causing the frontend to not update properly.
Add confirmed parameter to changeContractPhase() with default true
for backward compatibility and explicit user actions like drag-and-drop.
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add daemon restart feature from settings
This adds the ability to restart a connected daemon from the settings page.
The feature includes:
- Backend: RestartDaemon command added to DaemonCommand enum
- Backend: New POST /api/v1/mesh/daemons/{id}/restart endpoint
- Backend: Daemon gracefully shuts down tasks and exits with code 42
(can be used by process managers like systemd to detect restart requests)
- Frontend: restartDaemon() API function
- Frontend: Restart button in Connected Daemons section of settings
- Frontend: Confirmation dialog before restart to prevent accidental restarts
When a daemon receives the restart command, it:
1. Gracefully shuts down all running Claude processes (5s timeout)
2. Exits with code 42 to signal restart requested
3. The daemon can be restarted by a process manager or manually
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add repository selection with suggestions to standalone task creation
Enhance the standalone task creation modal with repository selection:
- Add Remote/Local repository type selector buttons
- Show recent repository suggestions dropdown (fetched via API)
- Add repository URL input for remote repositories
- Add local path input with DirectoryInput for local repositories
- Auto-fill form fields when clicking a suggestion
- Wire up handleCreateTask to use standalone repo fields
This builds on PR #16's standalone task feature by adding the same
repository suggestion capabilities that exist in contract creation.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Allow creating anonymous tasks (tasks without a contract_id) directly
from the mesh page:
- Add 'Create Standalone Task' option in task creation modal step 1
- Update step 2 to handle null selectedContract for standalone tasks
- Show working directory input for standalone tasks
- Update TaskList to show standalone tasks (filter: !parentTaskId && (isSupervisor || !contractId))
- Display 'Standalone Tasks' group header with lightning bolt icon
- Update empty state message to mention standalone tasks
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
| |
* [WIP] Heartbeat checkpoint - 2026-01-20 22:40:37 UTC
* Task completion checkpoint
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* feat: Add contract lifecycle management commands (complete and resume-contract)
Add supervisor commands for properly managing contract lifecycle:
- `makima supervisor complete` - Mark a contract as complete and stop the supervisor
- `makima supervisor resume-contract` - Resume a completed contract (reactivate it)
Also adds `api_key` field to TaskConfig for authenticated API calls.
This consolidates the lifecycle management features from the contract-lifecycle-cleanup branch.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Fix: prevent supervisor auto-start for completed contracts
When viewing a completed contract, the supervisor was auto-starting
on component mount. This would resurrect completed contracts and
cause them to continue running.
Changes:
- Add contract.status !== 'completed' check to the auto-start condition
- Add contract.status to the useEffect dependency array
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
| |
Remove unused useMemo import from contracts.tsx that was causing
the TypeScript build to fail with TS6133 error.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add right-click context menu for contracts on contracts and board pages
Implement a reusable ContractContextMenu component that provides:
- Mark as Complete/Active/Archive status actions (conditionally shown)
- Go to Supervisor Task link (when supervisor exists)
- Delete action with confirmation
Integrate context menu into:
- ContractList.tsx on the contracts page
- WorkflowBoard on the workflow/board page via PhaseColumn and WorkflowContractCard
Features match ElementContextMenu patterns:
- Fixed positioning with z-50
- Click outside and Escape key close handlers
- Viewport overflow prevention
- Dark theme colors (#0a1628, #0d1b2d, #75aafc, #9bc3ff)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* [WIP] Heartbeat checkpoint - 2026-01-19 19:30:52 UTC
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a reusable ContractContextMenu component that provides:
- Mark as Complete/Active/Archive status actions (conditionally shown)
- Go to Supervisor Task link (when supervisor exists)
- Delete action with confirmation
Integrate context menu into:
- ContractList.tsx on the contracts page
- WorkflowBoard on the workflow/board page via PhaseColumn and WorkflowContractCard
Features match ElementContextMenu patterns:
- Fixed positioning with z-50
- Click outside and Escape key close handlers
- Viewport overflow prevention
- Dark theme colors (#0a1628, #0d1b2d, #75aafc, #9bc3ff)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Filter mesh page task list to show only supervisor tasks
- Add `isSupervisor` filter to rootTasks filter in TaskList component
- Only supervisor tasks will appear in the mesh page task list
- Regular tasks are now hidden from the main view
- Update empty state messages to reflect supervisor-only filtering
- When clicking a supervisor task, its detail still shows orchestrated tasks
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add supervisor task button to workflow board contract cards
- Add supervisorTaskId field to ContractSummary type in backend and frontend
- Update SQL queries in repository.rs to include supervisor_task_id
- Add navigation button (▶) to WorkflowContractCard that links to /mesh/{supervisorTaskId}
- Button only shows when contract has a supervisorTaskId
- Button has tooltip "Open Supervisor Task" and stops propagation to avoid triggering card click
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add full task page navigation button to TaskTree rows
Add a hover-visible arrow icon (↗) to each task row in the TaskTree
component that links to the full task page (/tasks/{taskId}). The button:
- Appears on hover using opacity transition
- Stops event propagation to avoid triggering parent onSelect
- Matches existing hover styling patterns with the #75aafc color scheme
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add status filter toggle to Mesh Tab TaskList component
Add a filter toggle at the top of the TaskList that allows filtering by
contract status (All, Active, Completed, Archive) with Active as the default.
Changes:
- Backend: Add contract_status field to TaskSummary struct in models.rs
- Backend: Update all SQL queries returning TaskSummary to include
c.status as contract_status from the contracts table join
- Frontend: Add contractStatus to TaskSummary TypeScript type
- Frontend: Add useState for statusFilter with 'active' as default
- Frontend: Add filter button group in header area next to '+ New Task'
- Frontend: Update groupedTasks useMemo to filter based on contract status
- Frontend: Update empty state message to reflect current filter
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* feat(mesh): show all contract tasks for supervisor tasks
When viewing a supervisor task (task.isSupervisor === true), the
TaskDetail component now shows all tasks in the contract instead
of showing the subtasks tree.
Changes:
- Add contractTasks prop to TaskDetailProps for passing contract tasks
- Add displayTasks computed value that uses contractTasks for supervisors
- Change section header from "Subtasks" to "Contract Tasks" for supervisors
- Hide the "+ Add Subtask" button for supervisor tasks
- Update empty state message for supervisors
- Fetch contract tasks in mesh.tsx when viewing a supervisor task
- Filter out the supervisor itself from the contract tasks list
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Task completion checkpoint
* Task completion checkpoint
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add phase_guard field to Contract model and database
This adds a new boolean field to control whether the supervisor should
wait for user confirmation before progressing to the next phase. When
enabled, users can review and potentially amend phase outputs (like
plans, requirements docs) before the contract continues.
Changes:
- Add migration for phase_guard column (defaults to false)
- Add phase_guard to Contract, CreateContractRequest, and
UpdateContractRequest structs
- Update create_contract_for_owner and update_contract_for_owner
repository functions to handle phase_guard
- Update all CreateContractRequest instantiations with phase_guard field
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat: Add phase_guard for contract phase transitions
Implement phase_guard logic in the advance_phase tool. When a contract
has phase_guard enabled, the phase transition now:
1. Asks for user confirmation before advancing
2. Allows users to request changes to phase deliverables
3. Passes feedback to the task without advancing if changes requested
Changes:
- Add phase_guard field to Contract model and CreateContractRequest
- Add PhaseTransitionRequest, PhaseFileInfo, PhaseTaskInfo structs
- Update ChangePhaseRequest with confirmed and feedback fields
- Update ContractToolRequest::AdvancePhase with confirmed/feedback
- Modify advance_phase handling in contract_chat.rs with phase_guard logic
- Update change_phase endpoint in contracts.rs with phase_guard support
- Add database migration for phase_guard column
When phase_guard=false: Phase advances immediately (current behavior)
When phase_guard=true: Returns pending_confirmation status with deliverables
If user provides feedback: Returns feedback to task, doesn't advance
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat(frontend): Add UI for phase transition confirmation requests
When phase_guard is enabled and a supervisor tries to advance the contract
phase, users now see a confirmation modal with:
- Current and proposed next phase visualization
- Phase deliverables checklist (if available)
- Summary of the phase work
- Options to "Approve & Advance" or "Request Changes" with feedback
Components added:
- PhaseConfirmationModal: Full modal dialog for phase confirmations
- PhaseConfirmationInline: Inline variant for task output view
- PhaseConfirmationNotification: Global notification wrapper
- PhaseConfirmationToast: Alternative toast-style notification
Integration:
- Added phase_confirmation message type to TaskOutput renderer
- Extended PendingQuestion API type with phase confirmation data
- Integrated notification into main app layout
The UI uses the existing supervisor question infrastructure (polling via
/api/v1/mesh/questions) and responds with APPROVE or CHANGES_REQUESTED
prefixed feedback.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat(frontend): Add Phase Guard toggle to AutopilotPanel
Added the phase_guard toggle to the AutopilotPanel component, which allows
users to enable/disable requiring confirmation before phase transitions.
Changes:
- Added phaseGuard and autonomousLoop fields to Contract interface in api.ts
- Added phaseGuard field to UpdateContractRequest in api.ts
- Added Phase Guard toggle UI in AutopilotPanel with similar styling to master
- Toggle shows an 'active' badge when enabled
- Connected toggle to contract update API
The toggle appears below the autopilot control buttons and allows users to
require confirmation before the supervisor advances to the next phase.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| | |
|
| |
|
|
| |
Also add checkpointing/history
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
repositories (#18)
- Add repository_history table migration with repo_type, repo_path, use_count, last_used_at
- Add RepositoryHistoryEntry model and CRUD database functions
- Create API endpoints: GET/POST/DELETE /api/v1/repository-history, GET /api/v1/repository-history/suggestions
- Update add_remote_repository and add_local_repository handlers to automatically track history
- Update frontend API with repository history types and functions
- Add Repository History section to Settings page with list of entries and delete functionality
- Add suggestions dropdown to RepositoryPanel when entering new repository URL/path
- Suggestions filter by repo type (remote vs local) and match on user input
Test plan:
- Add a remote repository to a contract - verify it appears in Settings history
- Add a local repository to a contract - verify it appears in Settings history
- Add same repository again - verify use_count increments, not duplicate
- When adding new repository, verify suggestions appear based on history
- Delete a history entry from Settings - verify it's removed
- Verify suggestions only show matching type (remote for remote, local for local)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| |
|
|
|
|
|
| |
Add optional contractId and authToken fields to the StartMessage TypeScript
type to match the backend message structure and fix type checking.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add UI integration for the transcript analysis feature:
- Add TranscriptSaved WebSocket message type to notify client when transcript is saved
- Create TranscriptAnalysisPanel component to display analysis results
- Shows requirements grouped by category, decisions, action items with priorities
- Displays speaker statistics and suggested contract name/description
- Provides buttons to create new contract or add to existing contract
- Update Listen page to show analysis panel as modal overlay after recording stops
- Update useWebSocket hook to handle transcriptSaved message
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
| | |
|
| | |
|