soryu/makima, branch makima/contract-management-phase3

feat: Implement Phase 3.5 - Supervisor Status API

2026-02-01T01:10:26+00:00

- Add SupervisorStatusResponse for status endpoint - Add SupervisorHeartbeatEntry and history response types - Add SupervisorSyncResponse for sync endpoint - Add HeartbeatHistoryQuery for pagination - Resolve merge conflict keeping both API types and unit tests Co-Authored-By: Claude Opus 4.5

feat: Add Supervisor Status API endpoints (Phase 3 Task 3.5)

2026-02-01T01:08:13+00:00

Implement REST API endpoints for querying supervisor status: - GET /api/v1/contracts/{id}/supervisor/status Returns current supervisor status including task_id, state, phase, current_activity, progress, last_heartbeat, and pending_task_ids - GET /api/v1/contracts/{id}/supervisor/heartbeats?limit=10 Returns paginated supervisor activity history from history_events - POST /api/v1/contracts/{id}/supervisor/sync Triggers a sync to refresh the supervisor's last_activity timestamp New types added: - SupervisorStatusResponse - Status endpoint response - SupervisorHeartbeatEntry - Individual heartbeat history entry - SupervisorHeartbeatHistoryResponse - Heartbeat history with pagination - SupervisorSyncResponse - Sync endpoint response - HeartbeatHistoryQuery - Query params for heartbeats endpoint Repository helpers: - get_supervisor_status() - Combined info from supervisor_states and tasks - get_supervisor_activity_history() - Activity timeline from history_events - count_supervisor_activity_history() - Total count for pagination - sync_supervisor_state() - Refresh last_activity timestamp Error handling: - 404 for contract not found (CONTRACT_NOT_FOUND) - 404 for no supervisor (SUPERVISOR_NOT_FOUND) - Proper fallback when supervisor_state record doesn't exist but task does Co-Authored-By: Claude Opus 4.5

feat: Implement Phase 3 Tasks 3.3 and 3.4 - Supervisor State Persistence and Restoration

2026-02-01T00:42:53+00:00

Task 3.3: Supervisor State Persistence - Add migration 20260201000001_enhanced_supervisor_state.sql with new columns: - state (supervisor state enum) - current_activity (description) - progress (0-100) - error_message (for failed states) - spawned_task_ids (tasks created by supervisor) - pending_questions (questions awaiting user response) - restoration_count, last_restored_at, restoration_source (restoration tracking) - Update SupervisorState model with new fields - Add PendingQuestion struct for tracking unanswered questions - Add SupervisorRestorationContext for returning restoration info - Add StateValidationResult and StateRecoveryAction for state validation State persistence functions in repository.rs: - update_supervisor_detailed_state() - Update state, activity, progress - add_supervisor_spawned_task() - Track spawned tasks - add_supervisor_pending_question() - Track pending questions - remove_supervisor_pending_question() - Clear answered questions - save_supervisor_state_full() - Full state save (UPSERT) - mark_supervisor_restored() - Increment restoration count - get_supervisors_with_pending_questions() - Find supervisors with pending questions - get_supervisor_state_for_restoration() - Load state for restoration - validate_spawned_tasks() - Validate task consistency - update_supervisor_phase() - Update on phase change - update_supervisor_heartbeat_state() - Lightweight heartbeat update State save points: - On task spawn (save_state_on_task_spawn) - On question asked (save_state_on_question_asked) - On question answered (clear_pending_question) - On phase change (save_state_on_phase_change) - On heartbeat (update_supervisor_heartbeat_state) Task 3.4: Supervisor Restoration Protocol - Add restoration detection when supervisor starts with existing state - Implement validate_supervisor_state() for state consistency checks - Implement restore_supervisor() with validation and context generation - Add redeliver_pending_questions() for re-delivering questions after crash - Add generate_restoration_context_message() for Claude context injection - Update resume_supervisor endpoint to return RestorationInfo - Re-deliver pending questions when supervisor resumes Restoration flow: 1. Daemon restarts or task reassigned 2. Load supervisor state from supervisor_states 3. If NOT FOUND: Start fresh, log warning 4. If FOUND: Validate state consistency 5. If INVALID: Start from last checkpoint 6. If VALID: Restore conversation history 7. Check for pending questions - re-deliver to user 8. Check for waiting tasks - resume waiting state 9. Send restoration context to Claude 10. Resume execution from last state Co-Authored-By: Claude Opus 4.5

feat: Implement Phase 3 Tasks 3.1 and 3.2 - SupervisorState enum and Heartbeat Infrastructure

2026-02-01T00:25:43+00:00

Task 3.1: Enhanced Supervisor State Enum - Add SupervisorStateEnum with states: Initializing, Idle, Working, WaitingForUser, WaitingForTasks, Blocked, Completed, Failed, Interrupted - Implement Display, FromStr, Default, and serde serialization - Add SupervisorHeartbeatRecord and SupervisorHeartbeatRequest structs Task 3.2: Heartbeat Infrastructure - Create supervisor_heartbeats migration with proper indexes and constraints - Add heartbeat storage functions to repository.rs: - create_supervisor_heartbeat - get_latest_supervisor_heartbeat - get_supervisor_heartbeats - get_contract_supervisor_heartbeats - cleanup_old_heartbeats (24 hour TTL support) - find_stale_supervisors (for dead supervisor detection) - Add SupervisorHeartbeat message to protocol.rs with enhanced fields - Update mesh_daemon.rs to process and store supervisor heartbeats - Add unit tests for SupervisorStateEnum and heartbeat serialization Co-Authored-By: Claude Opus 4.5

feat: Add contract management system improvements (Phase 1)

2026-01-31T22:54:50+00:00

- Add docs/contract-management-spec.md with full system design - Add docs/plans/implementation-plan.md with 5-phase rollout plan - Add validate_deliverable() function and use in mark_deliverable_complete - Add PhaseChangeResult enum and change_contract_phase_with_version() with FOR UPDATE locking - Enforce phase_guard at API level for all callers This addresses critical issues in contract management: - Deliverable validation to prevent marking non-existent deliverables complete - Version conflict detection for phase changes with row locking - Phase guard enforcement at API level (applies to all callers including supervisors) - Comprehensive specification and implementation plan for future phases

Fix null handling for deliverables in create_template_for_owner (#51)

2026-01-31T22:17:31+00:00

The previous code used `.unwrap_or_default()` which could produce `Some(Value::Null)` if JSON serialization failed, leading to inconsistent handling when the database returned NULL and sqlx attempted to decode with the `#[sqlx(json)]` attribute on an Option type. Changed to use `.ok()` which properly returns `None` when serialization fails, ensuring consistent NULL handling between the application and database layer. Fixes: "Failed to create template: error occurred while decoding column 'deliverables': unexpected null; try decoding as an Option" Co-authored-by: Claude Opus 4.5

Add auto_merge_local option for local-only contracts (#50)

2026-01-31T22:17:09+00:00

When local_only=true on a contract, all completion actions are skipped. This adds a new option auto_merge_local that, when enabled along with local_only, will automatically merge completed task changes to the master/main branch locally (without pushing or creating PRs). Changes: - Add auto_merge_local column to contracts table (migration) - Add auto_merge_local field to Contract model and summary - Update CreateContractRequest and UpdateContractRequest structs - Update contract repository create/update functions - Add auto_merge_local to WebSocket protocol StartTask command - Pass auto_merge_local through spawn_task and run_task functions - Modify task manager completion logic: if local_only=true AND auto_merge_local=true, execute 'merge' completion action locally - Update all server handlers to retrieve and pass auto_merge_local - Add TypeScript types to frontend components Co-authored-by: Claude Opus 4.5

Fix Qwen3-TTS tensor paths to match HuggingFace model structure

2026-01-30T03:07:52+00:00

The HuggingFace model uses different tensor name prefixes: - talker.model.text_embedding instead of model.embed_tokens - talker.codec_head instead of lm_head - talker.code_predictor.model.codec_embedding instead of code_embeddings - talker.code_predictor.lm_head instead of output_heads Also removed input_proj which doesn't exist in the HF model. Co-Authored-By: Claude Opus 4.5

Download vocab.json and merges.txt in container image

2026-01-30T02:59:45+00:00

Fix download for hf TTS model

2026-01-30T02:54:51+00:00