| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
