summaryrefslogtreecommitdiff
path: root/makima/src
Commit message (Collapse)AuthorAgeFilesLines
* Add directive task progressionsoryu2026-02-093-7/+98
|
* Add directive initsoryu2026-02-098-1/+757
|
* Resume contracts from patchessoryu2026-02-094-0/+253
|
* Add new directive mechanism v3soryu2026-02-0921-516/+2004
|
* Remove directive mechanismsoryu2026-02-0817-4160/+17
|
* Fix directive evaluation and add to frontendsoryu2026-02-083-54/+203
|
* Fix directive evaluationsoryu2026-02-081-13/+30
|
* Fix directive deletion and stop local only on contractssoryu2026-02-082-3/+27
|
* Fix INT4/INT8 type mismatch in create_directive_chainsoryu2026-02-081-2/+2
|
* Fixes for directive chain initsoryu2026-02-089-106/+278
|
* Fixes for directive chain creationsoryu2026-02-072-7/+158
|
* Check on completion for contractssoryu2026-02-072-1/+143
|
* Add directive monitor contractssoryu2026-02-0711-39/+1152
|
* Show directive init on frontendsoryu2026-02-072-4/+21
|
* Add directive init mechanismsoryu2026-02-0711-1/+1118
|
* Add new directive initial implementationsoryu2026-02-0713-17/+1256
|
* Remove directives for reimplementationsoryu2026-02-0719-8297/+4
|
* Fix: Link directives and contractssoryu2026-02-063-7/+114
|
* Fix: Cleanup old chain codesoryu2026-02-0623-3726/+940
|
* Fix: Directives fixessoryu2026-02-063-111/+348
|
* Fix: Directives APIsoryu2026-02-063-30/+251
|
* Add directive-first chain system redesignsoryu2026-02-0532-4152/+6466
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Redesigns the chain system with a directive-first architecture where Directive is the top-level entity (the "why/what") and Chains are generated execution plans (the "how") that can be dynamically modified. Backend: - Add database migration for directive system tables - Add Directive, DirectiveChain, ChainStep, DirectiveEvent models - Add DirectiveVerifier and DirectiveApproval models - Add orchestration module with engine, planner, and verifier - Add comprehensive API handlers for directives - Add daemon CLI commands for directive management - Add directive skill documentation - Integrate contract completion with directive engine - Add SSE endpoint for real-time directive events Frontend: - Add directives route with split-view layout - Add 6-tab detail view (Overview, Chain, Events, Evaluations, Approvals, Verifiers) - Add React Flow DAG visualization for chain steps - Add SSE subscription hook for real-time event updates - Add useDirectives and useDirectiveEventSubscription hooks - Add directive types and API functions Fixes: - Fix test failures in ws/protocol, task_output, completion_gate, patch - Fix word boundary matching in looks_like_task() - Fix parse_last() to find actual last completion gate - Fix create_export_patch when merge-base equals HEAD - Clean up clippy warnings in new code Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add repository selection to chain creation modalsoryu2026-02-052-1/+43
| | | | | | | | | | | | | | - Update CreateChainModal to include repository input fields - Add repository suggestions from history using getRepositorySuggestions - Support both remote (URL) and local (path) repositories - First repository added becomes primary automatically - Pass repositories to CreateChainRequest Also includes backend changes: - Copy chain repositories to contracts when created from definitions - Add created_at field to ChainContractDetail Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add makima directivessoryu2026-02-0511-18/+3450
|
* Add multi-repository support for chainssoryu2026-02-056-42/+612
| | | | | | | | | | | | | | | | | | | | | | Chains can now have multiple repositories attached, with one marked as primary. Repositories are used by contracts created from chain definitions. Backend changes: - Add chain_repositories table migration - Add ChainRepository model with CRUD operations - Add API endpoints for listing, adding, deleting repositories - Add endpoint to set a repository as primary - Update Chain and ChainEditorData models to use repositories - Update chain parser to support repositories in YAML format - Remove deprecated repository_url/local_path from Chain Frontend changes: - Add ChainRepository interface and API functions - Add repository section to ChainEditor showing attached repos - Add modal for adding new repositories (remote or local) - Support setting primary repository and removing repositories Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Add makima skillssoryu2026-02-047-0/+557
|
* Remove chain supervisor capabilitysoryu2026-02-046-320/+6
| | | | | | | | | | | | Chains no longer spawn a supervisor task. Checkpoint contracts will be automatically run as part of the DAG execution when dependencies complete. - Remove supervisor task creation from start_chain handler - Remove chain supervisor CLI commands - Remove supervisor_task_id from StartChainResponse - Remove withSupervisor option from frontend Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Fix buildsoryu2026-02-041-1/+2
|
* Add chain checkpoint contractssoryu2026-02-048-14/+856
|
* Allow chain creation via web interfacesoryu2026-02-034-14/+1058
|
* Add 'Discuss Contract' feature to listen page (#57)soryu2026-02-036-2/+818
|
* Add makima chain mechanismsoryu2026-02-0316-11/+3210
|
* Release in makima reposoryu2026-02-029-2539/+11
| | | | Also remove all other TTS models
* Make makima more opinionated and structuredsoryu2026-02-0222-2100/+262
|
* Use chatterbox TTSsoryu2026-02-015-17/+16
|
* Merge pull request #55 from soryu-co/makima/contract-management-phase3soryu2026-02-017-27/+2044
|\ | | | | feat: Implement Phase 3 - Supervisor Resilience and State Management
| * feat: Implement Phase 3.5 - Supervisor Status APImakima/contract-management-phase3soryu2026-02-014-0/+557
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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 <noreply@anthropic.com>
| | * feat: Add Supervisor Status API endpoints (Phase 3 Task 3.5)soryu2026-02-014-0/+557
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <noreply@anthropic.com>
| * | feat: Implement Phase 3 Tasks 3.3 and 3.4 - Supervisor State Persistence and ↵soryu2026-02-015-25/+1001
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restoration 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 <noreply@anthropic.com>
| * | feat: Implement Phase 3 Tasks 3.1 and 3.2 - SupervisorState enum and ↵soryu2026-02-014-3/+487
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Heartbeat Infrastructure 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 <noreply@anthropic.com>
* / fix(supervisor): ensure all implementation phases are executed before PR (#53)soryu2026-02-011-0/+76
|/ | | | | | | | | | | | Previously the supervisor would implement only the first phase of a multi-phase plan and then create a PR. This change updates the supervisor system prompt to explicitly instruct it to: 1. Read and parse plan documents for multiple implementation phases 2. Execute phases sequentially 3. Track completion of each phase 4. Only create PR after ALL phases are complete Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* feat: Add contract management system improvements (Phase 1)makima/contract-management-improvementssoryu2026-01-318-29/+497
| | | | | | | | | | | | | | - 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)soryu2026-01-311-1/+4
| | | | | | | | | | | | | | | 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 <noreply@anthropic.com>
* Add auto_merge_local option for local-only contracts (#50)soryu2026-01-3113-45/+119
| | | | | | | | | | | | | | | | | | | | 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 <noreply@anthropic.com>
* Fix Qwen3-TTS tensor paths to match HuggingFace model structuresoryu2026-01-302-41/+36
| | | | | | | | | | | | 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 <noreply@anthropic.com>
* Fix download for hf TTS modelsoryu2026-01-301-1/+3
|
* Support both tokenizor.json and vocab.json+merges.txt formatssoryu2026-01-301-4/+28
|
* Rename to command mode and update worktree to show committed changessoryu2026-01-291-12/+78
|
* Add autodetection of master for PR creationsoryu2026-01-294-10/+33
|
* Fix Red Team UI visibility by adding red_team_enabled to ContractSummarysoryu2026-01-293-2/+9
| | | | | | | | | | | | | | | | | The Red Team toggle was implemented in the frontend but not visible because the backend API's ContractSummary response struct was missing the red_team_enabled field. The frontend relies on this field to: 1. Show the red team badge in the contract list view 2. Show the red team badge and tab in the contract detail view Changes: - Add red_team_enabled field to ContractSummary struct in models.rs - Update list_contracts_for_owner SQL query to include red_team_enabled - Update get_contract_summary_for_owner SQL query to include red_team_enabled - Update all fallback ContractSummary constructions in contracts.rs handler Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-05-21 06:37:41 +0000