mirror of
https://github.com/AutoMaker-Org/automaker.git
synced 2026-01-30 06:12:03 +00:00
Merge main into feat/cursor-cli-integration
Carefully merged latest changes from main branch into the Cursor CLI integration branch. This merge brings in important improvements and fixes while preserving all Cursor-related functionality. Key changes from main: - Sandbox mode security improvements and cloud storage compatibility - Version-based settings migrations (v2 schema) - Port configuration centralization - System paths utilities for CLI detection - Enhanced error handling in HttpApiClient - Windows MCP process cleanup fixes - New validation and build commands - GitHub issue templates and release process improvements Resolved conflicts in: - apps/server/src/routes/context/routes/describe-image.ts (Combined Cursor provider routing with secure-fs imports) - apps/server/src/services/auto-mode-service.ts (Merged failure tracking with raw output logging) - apps/server/tests/unit/services/terminal-service.test.ts (Updated to async tests with systemPathExists mocking) - libs/platform/src/index.ts (Combined WSL utilities with system-paths exports) - libs/types/src/settings.ts (Merged DEFAULT_PHASE_MODELS with SETTINGS_VERSION constants) All Cursor CLI integration features remain intact including: - CursorProvider and CliProvider base class - Phase-based model configuration - Provider registry and factory patterns - WSL support for Windows - Model override UI components - Cursor-specific settings and configurations 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
Kacper
File diff suppressed because it is too large
Load Diff
@@ -1,156 +0,0 @@
|
||||
# Pipeline Feature
|
||||
|
||||
Custom pipeline steps that run automatically after a feature completes "In Progress", creating a sequential workflow for code review, security audits, testing, and more.
|
||||
|
||||
## Overview
|
||||
|
||||
The pipeline feature allows users to define custom workflow steps that execute automatically after the main implementation phase. Each step prompts the agent with specific instructions while maintaining the full conversation context.
|
||||
|
||||
## How It Works
|
||||
|
||||
1. **Feature completes "In Progress"** - When the agent finishes implementing a feature
|
||||
2. **Pipeline steps execute sequentially** - Each configured step runs in order
|
||||
3. **Agent receives instructions** - The step's instructions are sent to the agent
|
||||
4. **Context preserved** - Full chat history is maintained between steps
|
||||
5. **Final status** - After all steps complete, the feature moves to "Waiting Approval" or "Verified"
|
||||
|
||||
## Configuration
|
||||
|
||||
### Accessing Pipeline Settings
|
||||
|
||||
- Click the **gear icon** on the "In Progress" column header
|
||||
- Or click the gear icon on any pipeline step column
|
||||
|
||||
### Adding Pipeline Steps
|
||||
|
||||
1. Click **"Add Pipeline Step"**
|
||||
2. Optionally select a **pre-built template** from the dropdown:
|
||||
- Code Review
|
||||
- Security Review
|
||||
- Testing
|
||||
- Documentation
|
||||
- Performance Optimization
|
||||
3. Customize the **Step Name**
|
||||
4. Choose a **Color** for the column
|
||||
5. Write or modify the **Agent Instructions**
|
||||
6. Click **"Add Step"**
|
||||
|
||||
### Managing Steps
|
||||
|
||||
- **Reorder**: Use the up/down arrows to change step order
|
||||
- **Edit**: Click the pencil icon to modify a step
|
||||
- **Delete**: Click the trash icon to remove a step
|
||||
- **Load from file**: Upload a `.md` or `.txt` file for instructions
|
||||
|
||||
## Storage
|
||||
|
||||
Pipeline configuration is stored per-project at:
|
||||
|
||||
```
|
||||
{project}/.automaker/pipeline.json
|
||||
```
|
||||
|
||||
## Pre-built Templates
|
||||
|
||||
### Code Review
|
||||
|
||||
Comprehensive code quality review covering:
|
||||
|
||||
- Readability and maintainability
|
||||
- DRY principle and single responsibility
|
||||
- Best practices and conventions
|
||||
- Performance considerations
|
||||
- Test coverage
|
||||
|
||||
### Security Review
|
||||
|
||||
OWASP-focused security audit including:
|
||||
|
||||
- Input validation and sanitization
|
||||
- SQL injection and XSS prevention
|
||||
- Authentication and authorization
|
||||
- Data protection
|
||||
- Common vulnerability checks (OWASP Top 10)
|
||||
|
||||
### Testing
|
||||
|
||||
Test coverage verification:
|
||||
|
||||
- Unit test requirements
|
||||
- Integration testing
|
||||
- Test quality standards
|
||||
- Running and validating tests
|
||||
|
||||
### Documentation
|
||||
|
||||
Documentation requirements:
|
||||
|
||||
- Code documentation (JSDoc/docstrings)
|
||||
- API documentation
|
||||
- README updates
|
||||
- Changelog entries
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
Performance review covering:
|
||||
|
||||
- Algorithm optimization
|
||||
- Memory usage
|
||||
- Database/API optimization
|
||||
- Frontend performance (if applicable)
|
||||
|
||||
## UI Changes
|
||||
|
||||
### Kanban Board
|
||||
|
||||
- Pipeline columns appear between "In Progress" and "Waiting Approval"
|
||||
- Each pipeline column shows features currently in that step
|
||||
- Gear icon on columns opens pipeline settings
|
||||
|
||||
### Horizontal Scrolling
|
||||
|
||||
- Board supports horizontal scrolling when many columns exist
|
||||
- Minimum window width reduced to 600px to accommodate various screen sizes
|
||||
|
||||
## Technical Details
|
||||
|
||||
### Files Modified
|
||||
|
||||
**Types:**
|
||||
|
||||
- `libs/types/src/pipeline.ts` - PipelineStep, PipelineConfig types
|
||||
- `libs/types/src/index.ts` - Export pipeline types
|
||||
|
||||
**Server:**
|
||||
|
||||
- `apps/server/src/services/pipeline-service.ts` - CRUD operations, status transitions
|
||||
- `apps/server/src/routes/pipeline/` - API endpoints
|
||||
- `apps/server/src/services/auto-mode-service.ts` - Pipeline execution integration
|
||||
|
||||
**UI:**
|
||||
|
||||
- `apps/ui/src/store/app-store.ts` - Pipeline state management
|
||||
- `apps/ui/src/lib/http-api-client.ts` - Pipeline API client
|
||||
- `apps/ui/src/components/views/board-view/constants.ts` - Dynamic column generation
|
||||
- `apps/ui/src/components/views/board-view/kanban-board.tsx` - Pipeline props, scrolling
|
||||
- `apps/ui/src/components/views/board-view/dialogs/pipeline-settings-dialog.tsx` - Settings UI
|
||||
- `apps/ui/src/hooks/use-responsive-kanban.ts` - Scroll support
|
||||
|
||||
### API Endpoints
|
||||
|
||||
```
|
||||
POST /api/pipeline/config - Get pipeline config
|
||||
POST /api/pipeline/config/save - Save pipeline config
|
||||
POST /api/pipeline/steps/add - Add a step
|
||||
POST /api/pipeline/steps/update - Update a step
|
||||
POST /api/pipeline/steps/delete - Delete a step
|
||||
POST /api/pipeline/steps/reorder - Reorder steps
|
||||
```
|
||||
|
||||
### Status Flow
|
||||
|
||||
```
|
||||
backlog → in_progress → pipeline_step1 → pipeline_step2 → ... → verified/waiting_approval
|
||||
```
|
||||
|
||||
Pipeline statuses use the format `pipeline_{stepId}` to support unlimited dynamic steps.
|
||||
@@ -1,94 +0,0 @@
|
||||
# API Security Hardening Design
|
||||
|
||||
**Date:** 2025-12-29
|
||||
**Branch:** protect-api-with-api-key
|
||||
**Status:** Approved
|
||||
|
||||
## Overview
|
||||
|
||||
Security improvements for the API authentication system before merging the PR. These changes harden the existing implementation for production deployment scenarios (local, Docker, internet-exposed).
|
||||
|
||||
## Fixes to Implement
|
||||
|
||||
### 1. Use Short-Lived wsToken for WebSocket Authentication
|
||||
|
||||
**Problem:** The client currently passes `sessionToken` in WebSocket URL query parameters. Query params get logged and can leak credentials.
|
||||
|
||||
**Solution:** Update the client to:
|
||||
|
||||
1. Fetch a wsToken from `/api/auth/token` before each WebSocket connection
|
||||
2. Use `wsToken` query param instead of `sessionToken`
|
||||
3. Never put session tokens in URLs
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
- `apps/ui/src/lib/http-api-client.ts` - Update `connectWebSocket()` to fetch wsToken first
|
||||
|
||||
---
|
||||
|
||||
### 2. Add Environment Variable to Hide API Key from Logs
|
||||
|
||||
**Problem:** The API key is printed to console on startup, which gets captured by logging systems in production.
|
||||
|
||||
**Solution:** Add `AUTOMAKER_HIDE_API_KEY=true` env var to suppress the banner.
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
- `apps/server/src/lib/auth.ts` - Wrap console.log banner in env var check
|
||||
|
||||
---
|
||||
|
||||
### 3. Add Rate Limiting to Login Endpoint
|
||||
|
||||
**Problem:** No brute force protection on `/api/auth/login`. Attackers could attempt many API keys.
|
||||
|
||||
**Solution:** Add basic in-memory rate limiting:
|
||||
|
||||
- ~5 attempts per minute per IP
|
||||
- In-memory Map tracking (resets on server restart)
|
||||
- Return 429 Too Many Requests when exceeded
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
- `apps/server/src/routes/auth/index.ts` - Add rate limiting logic to login handler
|
||||
|
||||
---
|
||||
|
||||
### 4. Use Timing-Safe Comparison for API Key
|
||||
|
||||
**Problem:** Using `===` for API key comparison is vulnerable to timing attacks.
|
||||
|
||||
**Solution:** Use `crypto.timingSafeEqual()` for constant-time comparison.
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
- `apps/server/src/lib/auth.ts` - Update `validateApiKey()` function
|
||||
|
||||
---
|
||||
|
||||
### 5. Make WebSocket Tokens Single-Use
|
||||
|
||||
**Problem:** wsTokens can be reused within the 5-minute window. If intercepted, attackers have time to use them.
|
||||
|
||||
**Solution:** Delete the token after first successful validation.
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
- `apps/server/src/lib/auth.ts` - Update `validateWsConnectionToken()` to delete after use
|
||||
|
||||
---
|
||||
|
||||
## Implementation Order
|
||||
|
||||
1. Fix #4 (timing-safe comparison) - Simple, isolated change
|
||||
2. Fix #5 (single-use wsToken) - Simple, isolated change
|
||||
3. Fix #2 (hide API key env var) - Simple, isolated change
|
||||
4. Fix #3 (rate limiting) - Moderate complexity
|
||||
5. Fix #1 (client wsToken usage) - Requires coordination with server
|
||||
|
||||
## Testing Notes
|
||||
|
||||
- Test login with rate limiting (verify 429 after 5 attempts)
|
||||
- Test WebSocket connection with new wsToken flow
|
||||
- Test wsToken is invalidated after first use
|
||||
- Verify `AUTOMAKER_HIDE_API_KEY=true` suppresses banner
|
||||
Reference in New Issue
Block a user