summaryrefslogtreecommitdiff
path: root/makima/src/db/models.rs
Commit message (Collapse)AuthorAgeFilesLines
* feat: smart cleanup, order linking, and improved PR titles (#69)soryu2026-02-171-1/+9
| | | | | | | | | | | | | * feat: soryu-co/soryu: Reorder navigation: move Orders before Contracts * feat: soryu-co/soryu: Generate PR titles from step content instead of directive title * feat: soryu-co/soryu: Add orderId field to step creation and link orders to steps * feat: soryu-co/soryu: Handle completed orders during plan-orders flow * WIP: heartbeat checkpoint * Merge origin/makima/soryu-co-soryu--handle-completed-orders-during-pla-5aa9a15b (resolved conflicts)
* soryu-co/soryu - makima (#67)soryu2026-02-171-2/+5
| | | | | | | | | | | | | | | | | | | | | | | * feat: soryu-co/soryu - makima: Fix contracts page scrolling overflow * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * feat: soryu-co/soryu - makima: Remove contract association from orders and make directive mandatory in UI * feat: soryu-co/soryu - makima: Add directive name to order metadata for searchability * feat: soryu-co/soryu - makima: Change directive link in orders to use search interface * feat: soryu-co/soryu - makima: Name directive PRs based on content not directive title * feat: soryu-co/soryu - makima: Add orderId to step creation and auto-link orders to steps * feat: soryu-co/soryu - makima: Add under_review status and auto-complete orders in plan flow
* soryu-co/soryu - makima (#66)soryu2026-02-161-1/+1
| | | | | | | | | | | * feat: soryu-co/soryu - makima: Fix contracts page scrolling overflow * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint
* Fix contracts page overflow, remove contract link from orders, add directive ↵soryu2026-02-161-22/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | name (#65) * feat: soryu-co/soryu - makima: Add frontend pick-up-orders button and API integration * WIP: heartbeat checkpoint * feat: soryu-co/soryu - makima: Remove contract link from orders and add directive name to order metadata (frontend) * fix: contracts page overflow - use contained scrolling layout Changed the contracts page to use contained scrolling matching the orders/directives pages, preventing the page from growing beyond viewport height. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: resolve completion_task_id FK violation and duplicate button The completion_task_id column has an FK to tasks(id), but claim_directive_for_completion was being called with a placeholder UUID that did not exist in the tasks table, causing FK constraint violations. Fix: Create the task FIRST via create_task_for_owner, then use the real task.id when calling claim_directive_for_completion. Applied in all three locations: phase_completion Part 1 (idle directives), Part 3 (verification tasks), and trigger_completion_task (manual PR creation). Also removes a duplicate "Pick Up Orders" button in DirectiveDetail.tsx. * fix: restore Order type changes lost during rebase conflict resolution Re-apply changes from the orders-refactor commit that were dropped when resolving rebase conflicts with --ours: - Replace contractId with directiveName in Order interface - Make directiveId required in CreateOrderRequest - Remove contractId from UpdateOrderRequest - Change listOrders parameter from contractId to search - Remove linkOrderToContract function - Simplify convertOrderToStep to single argument --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Add pick-up-orders feature for directives (#64)soryu2026-02-161-0/+9
| | | | | | | | | * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * feat: soryu-co/soryu - makima: Add frontend pick-up-orders button and API integration * feat: soryu-co/soryu - makima: Add pick-up-orders backend endpoint and repository functions
* feat: track directive goal history for intelligent re-planning (#63)soryu2026-02-161-0/+10
| | | | | * WIP: heartbeat checkpoint * feat: soryu-co/soryu - makima: Save previous goal on update and include history in re-planning prompt
* Makima system improvements: Orders, directive questions, PR creation fix, ↵soryu2026-02-141-0/+125
| | | | | | | | | | | | | | | | | | | | | | | bug fixes (#62) * feat: soryu-co/soryu - makima: Fix directive goal update bug - stale closure issue * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * feat: soryu-co/soryu - makima: Create Orders database schema and backend API * feat: soryu-co/soryu - makima: Fix task Claude instance not receiving user inputs from input box * WIP: heartbeat checkpoint * feat: soryu-co/soryu - makima: Build Orders frontend page replacing the Board page * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * feat: soryu-co/soryu - makima: Fix directive PR creation system
* Fix worktree branching for directive tasks and remove memoriessoryu2026-02-131-45/+0
|
* Add depends_on for directive taskssoryu2026-02-121-1/+7
| | | | | # Conflicts: # makima/src/orchestration/directive.rs
* makima: Add an optional memory system for directives (#59)soryu2026-02-121-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * feat: makima: Add an optional memory system for directives: Add directive_memories database table and migration * feat: makima: Add an optional memory system for directives: Update directive skill documentation with memory commands * feat: makima: Add an optional memory system for directives: Add repository functions for directive memory CRUD * feat: makima: Add an optional memory system for directives: Add frontend API functions and types for directive memory * feat: makima: Add an optional memory system for directives: Add Rust models for directive memory * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * WIP: heartbeat checkpoint * feat: makima: Add an optional memory system for directives: Add memory panel to frontend DirectiveDetail component * Merge remote-tracking branch 'origin/makima/makima--add-an-optional-memory-system-for-directiv-5de1e06d' into combined branch * Merge remote-tracking branch 'origin/makima/makima--add-an-optional-memory-system-for-directiv-c8298c6c' into combined branch * feat: makima: Add an optional memory system for directives: Create useMultiTaskSubscription hook for multi-output WebSocket streaming * feat: makima: Add an optional memory system for directives: Create DirectiveLogStream component for stern-like multi-task output viewing * feat: makima: Add an optional memory system for directives: Integrate log stream panel into directive detail page
* Add auto-PR creation for remote repos in directivessoryu2026-02-101-0/+7
|
* Add new directive mechanism v3soryu2026-02-091-0/+151
|
* Remove directive mechanismsoryu2026-02-081-333/+0
|
* Fixes for directive chain initsoryu2026-02-081-0/+7
|
* Add directive monitor contractssoryu2026-02-071-1/+85
|
* Show directive init on frontendsoryu2026-02-071-2/+2
|
* Add new directive initial implementationsoryu2026-02-071-0/+234
|
* Remove directives for reimplementationsoryu2026-02-071-666/+0
|
* Fix: Cleanup old chain codesoryu2026-02-061-0/+21
|
* Add directive-first chain system redesignsoryu2026-02-051-722/+456
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-051-0/+2
| | | | | | | | | | | | | | - 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-051-0/+351
|
* Add multi-repository support for chainssoryu2026-02-051-10/+54
| | | | | | | | | | | | | | | | | | | | | | 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>
* Remove chain supervisor capabilitysoryu2026-02-041-6/+2
| | | | | | | | | | | | 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>
* Add chain checkpoint contractssoryu2026-02-041-0/+67
|
* Allow chain creation via web interfacesoryu2026-02-031-1/+106
|
* Add makima chain mechanismsoryu2026-02-031-0/+356
|
* Make makima more opinionated and structuredsoryu2026-02-021-94/+0
|
* feat: Implement Phase 3.5 - Supervisor Status APImakima/contract-management-phase3soryu2026-02-011-0/+76
|\ | | | | | | | | | | | | | | | | | | - 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-011-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-011-0/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-011-0/+201
|/ | | | | | | | | | | | | | | | | | | | | | | | | 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>
* feat: Add contract management system improvements (Phase 1)makima/contract-management-improvementssoryu2026-01-311-0/+31
| | | | | | | | | | | | | | - 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
* Add auto_merge_local option for local-only contracts (#50)soryu2026-01-311-0/+18
| | | | | | | | | | | | | | | | | | | | 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 Red Team UI visibility by adding red_team_enabled to ContractSummarysoryu2026-01-291-0/+3
| | | | | | | | | | | | | | | | | 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>
* Fix phase config in DBsoryu2026-01-291-8/+10
|
* Allow null phase configs for legacy contractssoryu2026-01-291-1/+1
|
* Fix contract type selectionsoryu2026-01-291-20/+193
|
* Fix worktree cleanup to not run for shared worktreessoryu2026-01-291-0/+3
|
* Add Red Team adversarial review system for contract monitoring (#35)soryu2026-01-271-0/+91
| | | | | | | | | | | | | | | | | | | | Implements a parallel "red team" task that monitors work task outputs in real-time, verifying implementations stick to contract requirements, repository standards, and the execution plan. Key features: - New `red_team_enabled` and `red_team_prompt` contract configuration - Red team tasks auto-spawn when first work task is created - `makima red-team notify` CLI command for alerting supervisors - POST /api/v1/mesh/red-team/notify and /status endpoints - Alert delivery to supervisor via SendMessage daemon command - Notification audit trail via history_events table Database changes: - Add red_team_enabled/red_team_prompt columns to contracts - Add is_red_team flag to tasks with partial index - Create red_team_notifications table for audit logging Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* Add local-only mode for contracts with patch export support (#34)soryu2026-01-261-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 completion phasessoryu2026-01-261-0/+24
|
* feat: Simplify contract deliverables and add Templates UIsoryu2026-01-241-6/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ## 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>
* Add patch checkpointingsoryu2026-01-231-0/+42
|
* Fix completion actions: default to PR and support remote repos (#21)soryu2026-01-221-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* Add task branching feature (#15)soryu2026-01-211-2/+43
|
* Remove 'task' type contractsoryu2026-01-191-37/+0
|
* Clean up mesh page (#6)soryu2026-01-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* Improve Mesh Tab: Organize by contract with status filter (#5)soryu2026-01-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 toggle for contract phase confirmation (#2)soryu2026-01-171-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>