summaryrefslogtreecommitdiff
path: root/makima/src/server/handlers/contract_chat.rs
Commit message (Collapse)AuthorAgeFilesLines
* chore(cleanup): Phase 5 contracts removal + tmp directive + 30-day expiry + ↵soryu2026-05-011-3183/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scroll fix (#118) Sweeping cleanup across the surface and the wire. Net: -14k LOC of legacy contracts code, plus the tmp/scroll/UX fixes the user asked for. ## Sidebar/editor independent scroll Replace `height: calc(100vh - 80px)` (which assumed an 80px masthead and quietly clipped or pushed the whole page below the fold when the masthead was taller) with `h-screen + overflow-hidden` on the page root and proper `flex-1 min-h-0` sizing on `<main>`. Sidebar and editor pane now manage their own scroll independently; the page itself never scrolls. Same fix in /tmp/:taskId. ## tmp directive — real backing for orphans/ephemerals New migration `20260501100000_tmp_directive_and_clear_orphans.sql`: * Adds `directives.is_tmp` BOOLEAN NOT NULL DEFAULT false. * Partial unique index `(owner_id) WHERE is_tmp` — at most ONE tmp directive per owner. * Hard-deletes every existing orphan task (`directive_id IS NULL`). Per the user spec: "ALSO there are TOO MANY old tasks in tmp, we need to remove all of them as well." New repository helpers: * `get_or_create_tmp_directive(pool, owner_id) -> Directive` INSERT ON CONFLICT DO NOTHING + fallback SELECT, race-safe. * `list_all_tmp_directives` — drives the expiry sweep. * `delete_expired_tmp_tasks(tmp_directive_id) -> u64`. * `list_tmp_tasks_for_owner` (replaces `list_orphan_tasks_for_owner`). `mesh::create_task`: every top-level task must have a directive. If a caller doesn't supply `directive_id` and isn't a subtask, attach to the caller's tmp directive (auto-creating it on first use). `list_directives_for_owner` filters out `is_tmp=true` so the scratchpad directive doesn't pollute the contract list — surfaced via the sidebar's `tmp/` folder instead. ## 30-day expiry on tmp tasks New `phase_tmp_expiry` in the directive reconciler. Throttled to once per hour: enumerates every tmp directive, calls `delete_expired_tmp_tasks`, logs the count. The actual delete is `WHERE created_at < NOW() - INTERVAL '30 days'` and is fast on the existing index. Subtasks die via FK cascade. ## Phase 5 — contracts removed ### Frontend Deleted entire `/contracts` surface: * routes: `contracts.tsx`, `contract-file.tsx` * components/contracts: ContractList, ContractDetail, ContractCliInput, ContractContextMenu, CommandModePanel, PhaseBadge, PhaseHint, PhaseDeliverablesPanel, PhaseProgressBar, QuickActionButtons, RepositoryPanel, TaskDerivationPreview * (Kept `PhaseConfirmationModal` — used outside the contracts surface by `TaskOutput` and `PhaseConfirmationNotification`.) * Routes deregistered from `main.tsx`; nav entry removed from `NavStrip`. ### Backend handlers Deleted: `contracts.rs` (2.4k LOC), `contract_chat.rs` (3.2k LOC), `contract_daemon.rs` (~940 LOC), `contract_discuss.rs` (~590 LOC), `transcript_analysis.rs` (~690 LOC). All `/api/v1/contracts/*` routes deregistered. OpenAPI entries dropped. Module declarations removed from `server/handlers/mod.rs`. ### CLI Removed `makima contract` and `makima supervisor` subcommands. Deleted `daemon/cli/contract.rs` and `daemon/cli/supervisor.rs`. Bin dispatch trimmed (~377 LOC). ### Orchestrator Removed the contract-spawn path from `phase_execution` (`spawn_step_contract` and its caller). `directive_steps.contract_type` now logs a warning and falls through to standalone-task spawn. Column itself stays — old data still reads, just no longer triggers a contract+supervisor spawn. ### TUI `Action::PerformCreateContract` is now a no-op that surfaces a status message: "Contracts have been removed. Use directives instead." The TUI form is dead code pending a wider refresh. ## Out of scope (deliberately left) * Contracts DB tables (`contracts`, `contract_repositories`, `contract_chat_history`, `contract_events`, `contract_templates`) are retained for historical data + because some peripheral code still joins to them in TaskSummary queries. * `mesh_supervisor` handlers are retained — they aren't only used by contracts (some mesh-level supervisor behaviour persists), and the cross-cutting cleanup is bigger than this PR. * `directive_steps.contract_type` column itself isn't dropped; just no longer functional. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Set directive env vars correctly for daemonsoryu2026-02-091-0/+1
|
* Add new directive mechanism v3soryu2026-02-091-21/+8
|
* Add directive-first chain system redesignsoryu2026-02-051-1205/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 makima directivessoryu2026-02-051-1/+1213
|
* Make makima more opinionated and structuredsoryu2026-02-021-8/+2
|
* feat: Add contract management system improvements (Phase 1)makima/contract-management-improvementssoryu2026-01-311-2/+19
| | | | | | | | | | | | | | - 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-5/+7
| | | | | | | | | | | | | | | | | | | | 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 contract type selectionsoryu2026-01-291-0/+1
|
* Fix worktree cleanup to not run for shared worktreessoryu2026-01-291-0/+4
|
* Default to shared worktree and add worktree endpointsoryu2026-01-271-0/+1
|
* Add Red Team adversarial review system for contract monitoring (#35)soryu2026-01-271-0/+6
| | | | | | | | | | | | | | | | | | | | 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/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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-138/+87
|
* feat: Simplify contract deliverables and add Templates UIsoryu2026-01-241-7/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ## 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/+3
|
* Add task branching feature (#15)soryu2026-01-211-4/+12
|
* Remove 'task' type contractsoryu2026-01-191-4/+21
|
* Make sure tasks can continuesoryu2026-01-191-0/+2
|
* Add phase guard toggle for contract phase confirmation (#2)soryu2026-01-171-2/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* Fixup: Add cleanup and isolation features to makimasoryu2026-01-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* fix: add missing contract_type field to CreateContractRequestsoryu2026-01-151-0/+1
| | | | | | | | 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(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>
* Contract systemsoryu2026-01-151-0/+2592
generated by cgit v1.2.3 (git 2.39.1) at 2026-05-21 01:44:42 +0000