Merge story-32: Multi-Instance Worktree Support

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

# Conflicts:
#	.story_kit/stories/archived/32_multi_instance_worktree_support.md
#	.story_kit/stories/current/30_worktree_agent_orchestration.md
#	.story_kit/stories/current/32_multi_instance_worktree_support.md
#	.story_kit/stories/current/36_enforce_story_front_matter.md
#	.story_kit/stories/upcoming/29_directory_based_workflow_coordination.md
#	.story_kit/stories/upcoming/32_worktree_agent_orchestration.md
#	.story_kit/stories/upcoming/33_worktree_diff_and_editor_integration.md
#	.story_kit/stories/upcoming/34_agent_configuration_and_roles.md
#	.story_kit/stories/upcoming/35_agent_security_and_sandboxing.md
This commit is contained in:
Dave
2026-02-19 17:17:21 +00:00
11 changed files with 123 additions and 33 deletions

View File

@@ -1,8 +1,7 @@
---
name: Worktree-Based Agent Orchestration
test_plan: approved
test_plan: pending
---
# Story 30: Worktree-Based Agent Orchestration
## User Story

View File

@@ -1,22 +0,0 @@
---
name: "Multi-Instance Worktree Support"
test_plan: approved
---
# Story 32: Multi-Instance Worktree Support
## User Story
**As a** developer working across multiple git worktrees,
**I want** to run separate app instances (server + frontend) per worktree on different ports,
**So that** I can QA each worktree independently without port conflicts.
## Acceptance Criteria
- [ ] Server discovers an available port instead of hardcoding 3001 (e.g., try 3001, then 3002, etc., or use port 0 and report back).
- [ ] Server prints the actual bound port on startup so callers can discover it.
- [ ] Frontend dev server proxy target is configurable (env var or auto-detected from server).
- [ ] WebSocket client in the frontend reads the port dynamically rather than hardcoding it.
- [ ] A simple registry or file-based mechanism lets a supervisor discover which ports map to which worktrees.
## Out of Scope
- Agent orchestration across worktrees (separate story).
- Service mesh or container orchestration.
- Multi-machine distributed instances (local only for now).

View File

@@ -2,7 +2,6 @@
name: Enforce Front Matter on All Story Files
test_plan: pending
---
# Story 36: Enforce Front Matter on All Story Files
## User Story
@@ -13,3 +12,4 @@ As a user, I want the system to validate that every story file has valid front m
- [ ] Existing story files are updated to include valid front matter.
- [ ] The TODO panel displays the story name from front matter instead of falling back to the file stem.
- [ ] A CLI or API command can check all stories for front matter compliance.
- [ ] A `POST /workflow/stories/create` endpoint creates a new story file with valid front matter (name, test_plan) and story scaffold, so agents never need to manually construct the file format.