Move story 32 to current and rename to multi-instance worktree support

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

.story_kit/stories/upcoming/29_directory_based_workflow_coordination.md

@@ -1,3 +1,7 @@
+---
+name: Directory-Based Workflow Coordination and Locks
+test_plan: pending
+---
 # Story 29: Directory-Based Workflow Coordination and Locks
 
 ## User Story
@@ -12,4 +16,4 @@ As a user, I want directory-based story workflow coordination with lock tracking
 ## Out of Scope
 - Implementing the lock mechanism or agents in code.
 - Enforcing locks at runtime.
-- Multi-agent orchestration beyond documenting the workflow.
+- Multi-agent orchestration beyond documenting the workflow.

.story_kit/stories/upcoming/30_worktree_agent_orchestration.md

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

.story_kit/stories/upcoming/32_worktree_agent_orchestration.md

@@ -1,18 +0,0 @@
-# Story 32: Worktree Agent Orchestration — Dynamic Port Management
-
-## User Story
-**As a** developer running multiple agents in parallel worktrees,
-**I want** each server instance to bind to a unique port automatically,
-**So that** I can run multiple worktree-based agents concurrently 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.
-- [ ] Agent pool can target agents at different worktree server instances by URL.
-- [ ] A simple registry or file-based mechanism lets a supervisor discover which ports map to which worktrees.
-
-## Out of Scope
-- Service mesh or container orchestration.
-- Multi-machine distributed agents (local only for now).

.story_kit/stories/upcoming/33_worktree_diff_and_editor_integration.md

@@ -1,3 +1,7 @@
+---
+name: Worktree Diff Inspection and Editor Integration
+test_plan: pending
+---
 # Story 33: Worktree Diff Inspection and Editor Integration
 
 ## User Story

.story_kit/stories/upcoming/34_agent_configuration_and_roles.md

@@ -1,3 +1,7 @@
+---
+name: Per-Project Agent Configuration and Role Definitions
+test_plan: pending
+---
 # Story 34: Per-Project Agent Configuration and Role Definitions
 
 ## User Story

.story_kit/stories/upcoming/34_agent_security_and_sandboxing.md

@@ -1,28 +0,0 @@
-# Story 34: Agent Security and Sandboxing
-
-## User Story
-**As a** supervisor orchestrating multiple autonomous agents,
-**I want to** constrain what each agent can access and do,
-**So that** agents can't escape their worktree, damage shared state, or perform unintended actions.
-
-## Acceptance Criteria
-- [ ] Agent creation accepts an `allowed_tools` list to restrict Claude Code tool access per agent.
-- [ ] Agent creation accepts a `disallowed_tools` list as an alternative to allowlisting.
-- [ ] Agents without Bash access can still perform useful coding work (Read, Edit, Write, Glob, Grep).
-- [ ] Investigate replacing direct Bash/shell access with Rust-implemented tool proxies that enforce boundaries:
-  - Scoped `exec_shell` that only runs allowlisted commands (e.g., `cargo test`, `npm test`) within the agent's worktree.
-  - Scoped `read_file` / `write_file` that reject paths outside the agent's worktree root.
-  - Scoped `git` operations that only work within the agent's worktree.
-- [ ] Evaluate `--max-turns` and `--max-budget-usd` as safety limits for runaway agents.
-- [ ] Document the trust model: what the supervisor controls vs what agents can do autonomously.
-
-## Questions to Explore
-- Can we use MCP (Model Context Protocol) to expose our Rust-implemented tools to Claude Code, replacing its built-in Bash/filesystem tools with scoped versions?
-- What's the right granularity for shell allowlists — command-level (`cargo test`) or pattern-level (`cargo *`)?
-- Should agents have read access outside their worktree (e.g., to reference shared specs) but write access only within it?
-- Is OS-level sandboxing (Docker, macOS sandbox profiles) worth the complexity for a personal tool?
-
-## Out of Scope
-- Multi-user authentication or authorization (single-user personal tool).
-- Network-level isolation between agents.
-- Encrypting agent communication channels (all local).

.story_kit/stories/upcoming/35_agent_security_and_sandboxing.md

@@ -1,3 +1,7 @@
+---
+name: Agent Security and Sandboxing
+test_plan: pending
+---
 # Story 34: Agent Security and Sandboxing
 
 ## User Story

.story_kit/stories/upcoming/36_enforce_story_front_matter.md

@@ -1,3 +1,7 @@
+---
+name: Enforce Front Matter on All Story Files
+test_plan: pending
+---
 # Story 36: Enforce Front Matter on All Story Files
 
 ## User Story
@@ -8,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.