summaryrefslogtreecommitdiff
path: root/makima/src/server
Commit message (Collapse)AuthorAgeFilesLines
* Add patch merging and fix task healthcheck failing due to worktreessoryu2026-01-272-25/+138
|
* Fix worktree info and patches endpointsoryu2026-01-274-17/+321
|
* Fixup: Build fixsoryu2026-01-271-0/+1
|
* Default to shared worktree and add worktree endpointsoryu2026-01-276-0/+179
|
* Fix supervisor merge and PR commands (#36)soryu2026-01-273-11/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Task completion checkpoint * Task completion checkpoint * Task completion checkpoint * Fix supervisor merge for completed tasks and make PR command synchronous ## Issue 1: makima supervisor merge doesn't work for completed tasks When a task completes, the daemon removes it from in-memory task tracking. This caused merge operations to fail with "Task not found". Fixed by updating handle_merge_task_to_target() to use get_task_worktree_path() which scans the worktrees directory as a fallback when the task is not in memory. Also updated handle_create_pr() with the same pattern for consistency. ## Issue 2: makima supervisor pr returns immediately without result The create_pr handler was asynchronous - it sent the CreatePR command to the daemon and immediately returned without waiting for the result. Fixed by: 1. Adding PrResultNotification struct and pr_results broadcast channel to AppState 2. Updating mesh_daemon.rs to broadcast PRCreated results to the channel 3. Updating create_pr() handler to subscribe to pr_results and wait for the result with a 60-second timeout (matching the merge command pattern) Now the PR command returns the actual pr_url and pr_number from the daemon. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* Add Red Team adversarial review system for contract monitoring (#35)soryu2026-01-279-1/+810
| | | | | | | | | | | | | | | | | | | | 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-268-2/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* Make merges synchronoussoryu2026-01-263-12/+86
|
* Add completion phasessoryu2026-01-266-307/+246
|
* Update supervisor tasks page when supervisor spawns a new tasksoryu2026-01-261-1/+21
|
* Fix branching to restore from checkpointsoryu2026-01-261-2/+26
|
* Add automatic phase transitions and fix PR creationsoryu2026-01-253-70/+211
|
* Update create contract page to use dynamic templates (#29)soryu2026-01-252-0/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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: Simplify contract deliverables and add Templates UIsoryu2026-01-242-10/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ## 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>
* Clean up questions after removing tasks or contractssoryu2026-01-243-0/+70
|
* Add resume to daemon taskssoryu2026-01-234-7/+239
|
* Add patch checkpointingsoryu2026-01-237-0/+168
|
* Fix completion actions: default to PR and support remote repos (#21)soryu2026-01-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* Fix daemon disconnects not being continuablesoryu2026-01-221-6/+20
|
* Add daemon restart feature from settings (#18)soryu2026-01-223-0/+113
| | | | | | | | | | | | | | | | | | | | | * 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 pausing taskssoryu2026-01-221-4/+65
|
* Heartbeat daemonsoryu2026-01-211-1/+14
|
* Enforce phaseguardsoryu2026-01-211-4/+5
|
* Add task branching feature (#15)soryu2026-01-218-29/+362
|
* Add non-blocking persistent contract completion questions (#14)soryu2026-01-202-0/+33
| | | | | * [WIP] Heartbeat checkpoint - 2026-01-20 22:40:37 UTC * Task completion checkpoint
* Remove 'task' type contractsoryu2026-01-195-253/+85
|
* Make sure tasks can continuesoryu2026-01-195-5/+97
|
* Clean up mesh page (#6)soryu2026-01-182-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 pushed heartbeats and multi-question selectsoryu2026-01-182-0/+18
|
* Fix: Find alternate daemonsoryu2026-01-182-11/+173
|
* Add phaseguard flag for supervisor questions to wait indefinitely (#4)soryu2026-01-181-2/+5
| | | | | | | | | | | | | | | | | | | | | | | * Add phaseguard flag to supervisor ask command When phaseguard is enabled (--phaseguard flag), the supervisor's ask command will block indefinitely waiting for user response instead of timing out after the default 1 hour. This ensures that phase transitions requiring user confirmation cannot proceed without explicit approval. Changes: - Add phaseguard field to AskQuestionRequest in server handler - Add phaseguard field to AskQuestionRequest in API client - Add --phaseguard CLI flag to AskArgs - Update supervisor_ask() to accept phaseguard parameter - Modify ask_question handler to skip timeout check when phaseguard=true Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * Task completion checkpoint --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* Add phase guard toggle for contract phase confirmation (#2)soryu2026-01-174-15/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* Add heartbeat commitssoryu2026-01-174-1/+188
|
* Add autopilot panel and retry systemsoryu2026-01-172-93/+145
|
* Update continue task system and daemon IDssoryu2026-01-172-45/+70
|
* Fixup: fix history call and try to start pending tasks when a daemon is ↵soryu2026-01-162-21/+156
| | | | available
* Fixup: set daemon ID on spawned tasks by supervisorsoryu2026-01-162-39/+98
|
* Fixup: use default api.makima.jp URL and fix default branch detectionsoryu2026-01-162-1/+26
| | | | Also add checkpointing/history
* Add Task Contract Type for one-off adhoc tasks (#2)soryu2026-01-166-77/+266
|
* Add resume and history system for makima (#1)soryu2026-01-155-0/+1492
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR implements a comprehensive resume and history system that enables: 1. **History Viewing** - View complete conversation history for contracts across all phases - View conversation history for individual tasks - View task output/tool call history with timestamps - View checkpoint history - Timeline view showing all activities 2. **Resume System** - Resume interrupted supervisor conversations with full context - Resume interrupted task conversations - Resume from specific checkpoints - Continue tasks from previous task state (worktree inheritance) 3. **Rewind/Restore Features** - Rewind code to any checkpoint (git restore) - Rewind conversation to any point - Create new branches from historical points - Fork tasks from any point in history - New migration: 20250117000000_history_tables.sql - conversation_snapshots table for storing conversation state - history_events table for unified timeline - Added forking fields to tasks table - Added conversation_snapshot_id to task_checkpoints - ConversationSnapshot, HistoryEvent, ConversationMessage - Request/response types for resume and rewind operations - Query filter types for history endpoints - CRUD functions for conversation_snapshots - CRUD functions for history_events - Task conversation retrieval from task_events - GET /api/v1/contracts/{id}/history - GET /api/v1/contracts/{id}/supervisor/conversation - GET /api/v1/mesh/tasks/{id}/conversation - GET /api/v1/timeline - POST /api/v1/contracts/{id}/supervisor/resume - POST /api/v1/mesh/tasks/{id}/rewind - POST /api/v1/mesh/tasks/{id}/fork - POST /api/v1/mesh/tasks/{id}/checkpoints/{cid}/resume - POST /api/v1/mesh/tasks/{id}/checkpoints/{cid}/branch - POST /api/v1/contracts/{id}/supervisor/conversation/rewind - task-history: View task conversation history - task-checkpoints: List task checkpoints - resume: Resume supervisor after interruption - task-resume-from: Resume task from checkpoint - task-rewind: Rewind task code to checkpoint - task-fork: Fork task from historical point - rewind-conversation: Rewind supervisor conversation
* Implement git config inherit systemsoryu2026-01-152-0/+41
|
* Implement simple git checkpoint command for supervisorsoryu2026-01-153-10/+165
|
* Fixup: Add cleanup and isolation features to makimasoryu2026-01-155-2/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Advance stages of a contractsoryu2026-01-151-1/+1
|
* Add repository history feature to store and suggest previously used ↵soryu2026-01-155-5/+234
| | | | | | | | | | | | | | | | | | | | | | 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>
* Automatically derive repo URL and add notifications for inputsoryu2026-01-155-15/+1226
|
* fix: add missing contract_type field to CreateContractRequestsoryu2026-01-152-0/+2
| | | | | | | | The CreateContractRequest struct requires a contract_type field. Set to "specification" for transcript analysis contracts since they follow the full Research -> Specify -> Plan -> Execute -> Review workflow. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat(listen): add transcript analysis UI panelsoryu2026-01-152-0/+17
| | | | | | | | | | | | | 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>
* feat(contract-tools): add transcript analysis tools for contract chatsoryu2026-01-151-0/+323
| | | | | | | | | | Adds two new tools to contract_tools: - analyze_transcript: Analyze a file's transcript and return structured results - create_contract_from_transcript: Create a new contract from transcript analysis These tools enable voice-to-contract workflows directly from the contract chat interface. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* feat(listen): add transcript analysis API endpointssoryu2026-01-153-1/+680
| | | | | | | | | | | | Adds three new endpoints under /api/v1/listen/: - POST /analyze - Analyze a file's transcript for requirements, decisions, action items - POST /create-contract - Create a new contract from analyzed transcript - POST /update-contract - Update an existing contract with extracted information These endpoints bridge the Listen (voice transcription) system with the Contract system, enabling voice-to-contract workflows. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-05-21 19:19:16 +0000