| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
- Add 'execute' contract type as a built-in template in backend
- Fix API response field name mismatch (types -> contractTypes)
- Remove duplicate ContractTypeTemplate definition in api.ts
- Merge built-in types from API with user templates from localStorage
- User templates created in the Templates page now appear in contract creation
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
| |
|
|
|
|
|
|
|
|
|
| |
When phase_guard is enabled on a contract, the backend expects
{ phase, confirmed: true } to actually perform the phase change.
Without confirmed: true, the backend returns a PhaseTransitionRequest
instead of ContractSummary, causing the frontend to not update properly.
Add confirmed parameter to changeContractPhase() with default true
for backward compatibility and explicit user actions like drag-and-drop.
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
| | |
|
| |
|
|
|
| |
* [WIP] Heartbeat checkpoint - 2026-01-20 22:40:37 UTC
* Task completion checkpoint
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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 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 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>
|
| | |
|
| |
|
|
| |
Also add checkpointing/history
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Migrations are local only currently, and must be run manually by setting POSTGRES_CONNECTION_URI
|
| |
|