orchestr8 2.7.1 → 3.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.blueprint/agents/AGENT_BA_CASS.md +18 -34
- package/.blueprint/agents/AGENT_DEVELOPER_CODEY.md +21 -28
- package/.blueprint/agents/AGENT_SPECIFICATION_ALEX.md +6 -0
- package/.blueprint/agents/AGENT_TESTER_NIGEL.md +5 -3
- package/.blueprint/agents/WHAT_WE_STAND_FOR.md +0 -0
- package/.blueprint/features/feature_interactive-alex/FEATURE_SPEC.md +263 -0
- package/.blueprint/features/feature_interactive-alex/IMPLEMENTATION_PLAN.md +69 -0
- package/.blueprint/features/feature_interactive-alex/handoff-alex.md +19 -0
- package/.blueprint/features/feature_interactive-alex/handoff-cass.md +21 -0
- package/.blueprint/features/feature_interactive-alex/handoff-nigel.md +19 -0
- package/.blueprint/features/feature_interactive-alex/story-flag-routing.md +54 -0
- package/.blueprint/features/feature_interactive-alex/story-iterative-drafting.md +65 -0
- package/.blueprint/features/feature_interactive-alex/story-pipeline-integration.md +66 -0
- package/.blueprint/features/feature_interactive-alex/story-session-lifecycle.md +75 -0
- package/.blueprint/features/feature_interactive-alex/story-system-spec-creation.md +57 -0
- package/.blueprint/features/feature_parallel-abort/FEATURE_SPEC.md +117 -0
- package/.blueprint/features/feature_parallel-confirm/FEATURE_SPEC.md +90 -0
- package/.blueprint/features/feature_parallel-features/FEATURE_SPEC.md +291 -0
- package/.blueprint/features/feature_parallel-features/IMPLEMENTATION_PLAN.md +73 -0
- package/.blueprint/features/feature_parallel-lock/FEATURE_SPEC.md +119 -0
- package/.blueprint/features/feature_parallel-logging/FEATURE_SPEC.md +105 -0
- package/.blueprint/features/feature_parallel-preflight/FEATURE_SPEC.md +141 -0
- package/.blueprint/prompts/codey-implement-runtime.md +1 -1
- package/.blueprint/prompts/nigel-runtime.md +1 -1
- package/.blueprint/ways_of_working/DEVELOPMENT_RITUAL.md +4 -4
- package/README.md +249 -0
- package/SKILL.md +35 -1
- package/bin/cli.js +187 -0
- package/package.json +2 -2
- package/src/index.js +61 -1
- package/src/init.js +21 -3
- package/src/interactive.js +338 -0
- package/src/parallel.js +1544 -0
- package/src/stack.js +320 -0
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
## Handoff Summary
|
|
2
|
+
**For:** Cass
|
|
3
|
+
**Feature:** interactive-alex
|
|
4
|
+
|
|
5
|
+
### Key Decisions
|
|
6
|
+
- Interactive mode triggers automatically when specs are missing, or explicitly via `--interactive` flag
|
|
7
|
+
- Session flow: context gathering → clarifying questions → iterative drafting → finalization
|
|
8
|
+
- In-memory state only (no persistence for v1)
|
|
9
|
+
- Supports both SYSTEM_SPEC.md and FEATURE_SPEC.md creation
|
|
10
|
+
- Integrates with existing `--pause-after=alex` for exit control
|
|
11
|
+
|
|
12
|
+
### Files Created
|
|
13
|
+
- .blueprint/features/feature_interactive-alex/FEATURE_SPEC.md
|
|
14
|
+
|
|
15
|
+
### Open Questions
|
|
16
|
+
- None - all resolved in spec
|
|
17
|
+
|
|
18
|
+
### Critical Context
|
|
19
|
+
Focus stories on: flag parsing/routing, conversational session management, iterative spec drafting, pipeline integration. The feature modifies SKILL.md routing and adds a new interaction pattern while keeping downstream agents (Cass, Nigel, Codey) unchanged.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
## Handoff Summary
|
|
2
|
+
**For:** Nigel
|
|
3
|
+
**Feature:** interactive-alex
|
|
4
|
+
|
|
5
|
+
### Key Decisions
|
|
6
|
+
- Split into 5 stories covering distinct concerns: routing, session lifecycle, drafting, pipeline integration, system spec creation
|
|
7
|
+
- Each story has 5-7 testable acceptance criteria in Given/When/Then format
|
|
8
|
+
- Focused on observable behavior and user commands
|
|
9
|
+
|
|
10
|
+
### Files Created
|
|
11
|
+
- story-flag-routing.md - `--interactive` flag parsing and auto-detection
|
|
12
|
+
- story-session-lifecycle.md - Session commands (/approve, /change, /skip, /restart, /abort, /done)
|
|
13
|
+
- story-iterative-drafting.md - Context gathering, questions, section drafting
|
|
14
|
+
- story-pipeline-integration.md - Spec output, handoff, queue, history
|
|
15
|
+
- story-system-spec-creation.md - Interactive SYSTEM_SPEC.md creation when missing
|
|
16
|
+
|
|
17
|
+
### Open Questions
|
|
18
|
+
- None
|
|
19
|
+
|
|
20
|
+
### Critical Context
|
|
21
|
+
Tests should focus on SKILL.md routing logic and the new `src/interactive.js` module. Mock the conversation loop for unit tests; the iterative drafting can use state machine patterns.
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
## Handoff Summary
|
|
2
|
+
**For:** Codey
|
|
3
|
+
**Feature:** interactive-alex
|
|
4
|
+
|
|
5
|
+
### Key Decisions
|
|
6
|
+
- 29 tests covering all 5 stories with 100% AC coverage
|
|
7
|
+
- Tests use Node.js built-in test runner (node:test)
|
|
8
|
+
- Mock-based testing for session state machine and routing
|
|
9
|
+
- State machine pattern for session lifecycle
|
|
10
|
+
|
|
11
|
+
### Files Created
|
|
12
|
+
- test/artifacts/feature_interactive-alex/test-spec.md
|
|
13
|
+
- test/feature_interactive-alex.test.js
|
|
14
|
+
|
|
15
|
+
### Open Questions
|
|
16
|
+
- None
|
|
17
|
+
|
|
18
|
+
### Critical Context
|
|
19
|
+
Create `src/interactive.js` with session state machine (idle → gathering → questioning → drafting → finalizing). Update SKILL.md routing logic to check for `--interactive` flag and missing specs. All tests currently pass with stubs - implement the actual logic.
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# User Story: Flag Parsing & Mode Routing
|
|
2
|
+
|
|
3
|
+
## Story
|
|
4
|
+
|
|
5
|
+
**As a** developer using orchestr8,
|
|
6
|
+
**I want** the `/implement-feature` command to detect when interactive mode is needed and route accordingly,
|
|
7
|
+
**so that** I get a collaborative spec experience for new/unclear features without manual flag management.
|
|
8
|
+
|
|
9
|
+
## Acceptance Criteria
|
|
10
|
+
|
|
11
|
+
### AC-1: Explicit Interactive Flag
|
|
12
|
+
|
|
13
|
+
**Given** a user invokes `/implement-feature "my-feature" --interactive`
|
|
14
|
+
**When** the command parses flags
|
|
15
|
+
**Then** interactive mode is activated regardless of existing spec files
|
|
16
|
+
|
|
17
|
+
### AC-2: Auto-Detect Missing System Spec
|
|
18
|
+
|
|
19
|
+
**Given** a user invokes `/implement-feature "my-feature"` without `--interactive`
|
|
20
|
+
**And** `.blueprint/system_specification/SYSTEM_SPEC.md` does not exist
|
|
21
|
+
**When** the pipeline routing logic runs
|
|
22
|
+
**Then** interactive mode is activated for system spec creation
|
|
23
|
+
|
|
24
|
+
### AC-3: Auto-Detect Missing Feature Spec
|
|
25
|
+
|
|
26
|
+
**Given** a user invokes `/implement-feature "my-feature"` without `--interactive`
|
|
27
|
+
**And** `SYSTEM_SPEC.md` exists
|
|
28
|
+
**And** `.blueprint/features/feature_my-feature/FEATURE_SPEC.md` does not exist
|
|
29
|
+
**When** the pipeline routing logic runs
|
|
30
|
+
**Then** interactive mode is activated for feature spec creation
|
|
31
|
+
|
|
32
|
+
### AC-4: Autonomous Mode When Specs Exist
|
|
33
|
+
|
|
34
|
+
**Given** a user invokes `/implement-feature "my-feature"` without `--interactive`
|
|
35
|
+
**And** both `SYSTEM_SPEC.md` and `FEATURE_SPEC.md` exist
|
|
36
|
+
**When** the pipeline routing logic runs
|
|
37
|
+
**Then** Alex runs in autonomous (non-interactive) mode
|
|
38
|
+
|
|
39
|
+
### AC-5: Combined Flags
|
|
40
|
+
|
|
41
|
+
**Given** a user invokes `/implement-feature "my-feature" --interactive --pause-after=alex`
|
|
42
|
+
**When** the command parses flags
|
|
43
|
+
**Then** interactive mode is activated
|
|
44
|
+
**And** the pipeline will pause after Alex completes (before Cass)
|
|
45
|
+
|
|
46
|
+
## Out of Scope
|
|
47
|
+
|
|
48
|
+
- `--no-interactive` flag to force autonomous mode (users can create placeholder specs)
|
|
49
|
+
- Interactive modes for agents other than Alex
|
|
50
|
+
- Flag validation errors (handled by existing CLI parsing)
|
|
51
|
+
|
|
52
|
+
## References
|
|
53
|
+
|
|
54
|
+
- Feature Spec: `.blueprint/features/feature_interactive-alex/FEATURE_SPEC.md` (Section 4.1)
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# User Story: Iterative Spec Drafting
|
|
2
|
+
|
|
3
|
+
## Story
|
|
4
|
+
|
|
5
|
+
**As a** developer in an interactive session,
|
|
6
|
+
**I want** Alex to gather context, ask targeted questions, and draft spec sections incrementally,
|
|
7
|
+
**so that** the resulting specification accurately captures my intent with minimal revision cycles.
|
|
8
|
+
|
|
9
|
+
## Acceptance Criteria
|
|
10
|
+
|
|
11
|
+
### AC-1: Context Gathering Phase
|
|
12
|
+
|
|
13
|
+
**Given** an interactive session has started
|
|
14
|
+
**When** the user provides their initial feature description
|
|
15
|
+
**Then** Alex acknowledges understanding by summarizing the core intent
|
|
16
|
+
**And** Alex identifies 2-4 information gaps relative to the FEATURE_SPEC template
|
|
17
|
+
|
|
18
|
+
### AC-2: Clarifying Questions
|
|
19
|
+
|
|
20
|
+
**Given** Alex has identified information gaps
|
|
21
|
+
**When** Alex asks clarifying questions
|
|
22
|
+
**Then** questions are presented in a single batch (2-4 questions)
|
|
23
|
+
**And** questions are specific and actionable (not open-ended)
|
|
24
|
+
**And** Alex waits for user responses before proceeding
|
|
25
|
+
|
|
26
|
+
### AC-3: Section-by-Section Drafting
|
|
27
|
+
|
|
28
|
+
**Given** Alex has gathered sufficient context
|
|
29
|
+
**When** Alex drafts spec sections
|
|
30
|
+
**Then** sections are drafted incrementally (Intent first, then Scope, then Actors, etc.)
|
|
31
|
+
**And** after each section, Alex presents the draft
|
|
32
|
+
**And** Alex asks: "Does this capture your intent? Any changes?"
|
|
33
|
+
|
|
34
|
+
### AC-4: Revision Handling
|
|
35
|
+
|
|
36
|
+
**Given** Alex has presented a draft section
|
|
37
|
+
**And** the user requests changes via `/change <feedback>`
|
|
38
|
+
**When** Alex revises the section
|
|
39
|
+
**Then** Alex incorporates the specific feedback
|
|
40
|
+
**And** Alex presents the revised draft
|
|
41
|
+
**And** Alex asks for approval again
|
|
42
|
+
|
|
43
|
+
### AC-5: Progress Indication
|
|
44
|
+
|
|
45
|
+
**Given** an interactive session is active
|
|
46
|
+
**When** Alex transitions between sections
|
|
47
|
+
**Then** Alex indicates which sections are complete
|
|
48
|
+
**And** Alex indicates which sections remain
|
|
49
|
+
|
|
50
|
+
### AC-6: Concise Responses
|
|
51
|
+
|
|
52
|
+
**Given** Alex is drafting or responding in the session
|
|
53
|
+
**When** Alex produces conversational output
|
|
54
|
+
**Then** each response is under 200 words
|
|
55
|
+
**And** focus is on actionable content, not filler
|
|
56
|
+
|
|
57
|
+
## Out of Scope
|
|
58
|
+
|
|
59
|
+
- Full-spec-at-once drafting mode
|
|
60
|
+
- Configurable question count (fixed at 2-4)
|
|
61
|
+
- Template customization during session
|
|
62
|
+
|
|
63
|
+
## References
|
|
64
|
+
|
|
65
|
+
- Feature Spec: `.blueprint/features/feature_interactive-alex/FEATURE_SPEC.md` (Section 4.3)
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
# User Story: Pipeline Integration
|
|
2
|
+
|
|
3
|
+
## Story
|
|
4
|
+
|
|
5
|
+
**As a** developer completing an interactive session,
|
|
6
|
+
**I want** the interactive mode to integrate seamlessly with the existing pipeline infrastructure,
|
|
7
|
+
**so that** downstream agents receive proper handoffs and the pipeline can resume or record history as expected.
|
|
8
|
+
|
|
9
|
+
## Acceptance Criteria
|
|
10
|
+
|
|
11
|
+
### AC-1: Spec File Output
|
|
12
|
+
|
|
13
|
+
**Given** an interactive session completes successfully (via `/approve` on final section or `/done`)
|
|
14
|
+
**When** Alex finalizes the spec
|
|
15
|
+
**Then** FEATURE_SPEC.md is written to `{FEAT_DIR}/FEATURE_SPEC.md`
|
|
16
|
+
**And** the file includes all completed sections
|
|
17
|
+
**And** skipped sections are marked as "TBD"
|
|
18
|
+
**And** the file includes a note: "Created via interactive session"
|
|
19
|
+
|
|
20
|
+
### AC-2: Handoff Artifact
|
|
21
|
+
|
|
22
|
+
**Given** an interactive session completes successfully
|
|
23
|
+
**When** Alex writes the spec file
|
|
24
|
+
**Then** Alex also produces `handoff-alex.md` in the feature directory
|
|
25
|
+
**And** the handoff includes key decisions, files created, and open questions
|
|
26
|
+
|
|
27
|
+
### AC-3: Queue Update
|
|
28
|
+
|
|
29
|
+
**Given** an interactive session completes successfully
|
|
30
|
+
**When** the pipeline continues
|
|
31
|
+
**Then** the queue is updated with the feature moving from `alexQueue` to `cassQueue`
|
|
32
|
+
**And** `current.stage` reflects "cass" (or the next applicable stage)
|
|
33
|
+
|
|
34
|
+
### AC-4: History Recording
|
|
35
|
+
|
|
36
|
+
**Given** an interactive session completes (success or abort)
|
|
37
|
+
**When** history is recorded (unless `--no-history` flag present)
|
|
38
|
+
**Then** the `pipeline-history.json` entry includes `mode: "interactive"`
|
|
39
|
+
**And** the entry includes question count, revision count, and session duration
|
|
40
|
+
|
|
41
|
+
### AC-5: Pause After Alex
|
|
42
|
+
|
|
43
|
+
**Given** an interactive session completes successfully
|
|
44
|
+
**And** `--pause-after=alex` flag was provided
|
|
45
|
+
**When** Alex finishes
|
|
46
|
+
**Then** the pipeline pauses before spawning Cass
|
|
47
|
+
**And** user can review the spec before continuing
|
|
48
|
+
|
|
49
|
+
### AC-6: Continue to Downstream Agents
|
|
50
|
+
|
|
51
|
+
**Given** an interactive session completes successfully
|
|
52
|
+
**And** `--pause-after=alex` flag was NOT provided
|
|
53
|
+
**When** Alex finishes
|
|
54
|
+
**Then** the pipeline continues automatically
|
|
55
|
+
**And** Cass is spawned with the produced FEATURE_SPEC.md as input
|
|
56
|
+
|
|
57
|
+
## Out of Scope
|
|
58
|
+
|
|
59
|
+
- Changes to Cass, Nigel, or Codey agent behaviour
|
|
60
|
+
- Parallel pipeline execution
|
|
61
|
+
- Multi-feature batch processing
|
|
62
|
+
|
|
63
|
+
## References
|
|
64
|
+
|
|
65
|
+
- Feature Spec: `.blueprint/features/feature_interactive-alex/FEATURE_SPEC.md` (Section 6)
|
|
66
|
+
- System Spec: `.blueprint/system_specification/SYSTEM_SPEC.md` (Sections 6-7)
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# User Story: Interactive Session Lifecycle
|
|
2
|
+
|
|
3
|
+
## Story
|
|
4
|
+
|
|
5
|
+
**As a** developer entering interactive mode,
|
|
6
|
+
**I want** a clear session lifecycle with explicit commands for controlling the conversation,
|
|
7
|
+
**so that** I can navigate the spec creation process efficiently and exit gracefully when needed.
|
|
8
|
+
|
|
9
|
+
## Acceptance Criteria
|
|
10
|
+
|
|
11
|
+
### AC-1: Session Initialization
|
|
12
|
+
|
|
13
|
+
**Given** interactive mode is activated (explicit flag or auto-detect)
|
|
14
|
+
**When** the session starts
|
|
15
|
+
**Then** Alex reads system spec (if exists), business context, and feature template
|
|
16
|
+
**And** Alex presents an opening prompt: "Describe the feature you want to build. What problem does it solve and for whom?"
|
|
17
|
+
|
|
18
|
+
### AC-2: Approve Command
|
|
19
|
+
|
|
20
|
+
**Given** an interactive session is active
|
|
21
|
+
**And** Alex has presented a draft section
|
|
22
|
+
**When** the user responds with `/approve` or `yes`
|
|
23
|
+
**Then** the current section is marked complete
|
|
24
|
+
**And** Alex proceeds to the next section
|
|
25
|
+
|
|
26
|
+
### AC-3: Change Command
|
|
27
|
+
|
|
28
|
+
**Given** an interactive session is active
|
|
29
|
+
**And** Alex has presented a draft section
|
|
30
|
+
**When** the user responds with `/change <feedback>`
|
|
31
|
+
**Then** Alex revises the current section based on the feedback
|
|
32
|
+
**And** Alex presents the revised draft for approval
|
|
33
|
+
|
|
34
|
+
### AC-4: Skip Command
|
|
35
|
+
|
|
36
|
+
**Given** an interactive session is active
|
|
37
|
+
**And** Alex has presented a draft section
|
|
38
|
+
**When** the user responds with `/skip`
|
|
39
|
+
**Then** the current section is marked as "TBD" in the spec
|
|
40
|
+
**And** Alex proceeds to the next section
|
|
41
|
+
|
|
42
|
+
### AC-5: Restart Command
|
|
43
|
+
|
|
44
|
+
**Given** an interactive session is active
|
|
45
|
+
**And** Alex is working on a section
|
|
46
|
+
**When** the user responds with `/restart`
|
|
47
|
+
**Then** Alex discards the current section draft
|
|
48
|
+
**And** Alex starts the section from scratch with fresh questions
|
|
49
|
+
|
|
50
|
+
### AC-6: Abort Command
|
|
51
|
+
|
|
52
|
+
**Given** an interactive session is active
|
|
53
|
+
**When** the user responds with `/abort`
|
|
54
|
+
**Then** the session terminates immediately
|
|
55
|
+
**And** no spec file is written to disk
|
|
56
|
+
**And** the pipeline exits without proceeding to downstream agents
|
|
57
|
+
|
|
58
|
+
### AC-7: Done Command
|
|
59
|
+
|
|
60
|
+
**Given** an interactive session is active
|
|
61
|
+
**And** at least Intent, Scope, and Actors sections are complete or skipped
|
|
62
|
+
**When** the user responds with `/done`
|
|
63
|
+
**Then** Alex finalizes the spec with completed sections
|
|
64
|
+
**And** skipped sections are marked as "TBD"
|
|
65
|
+
**And** the spec file is written to disk
|
|
66
|
+
|
|
67
|
+
## Out of Scope
|
|
68
|
+
|
|
69
|
+
- Session persistence between interrupted sessions
|
|
70
|
+
- Timeout handling (session continues until user acts)
|
|
71
|
+
- Multi-user concurrent sessions
|
|
72
|
+
|
|
73
|
+
## References
|
|
74
|
+
|
|
75
|
+
- Feature Spec: `.blueprint/features/feature_interactive-alex/FEATURE_SPEC.md` (Section 4.4)
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# User Story: Interactive System Spec Creation
|
|
2
|
+
|
|
3
|
+
## Story
|
|
4
|
+
|
|
5
|
+
**As a** developer initializing a new project without a system specification,
|
|
6
|
+
**I want** Alex to guide me through creating a SYSTEM_SPEC.md interactively,
|
|
7
|
+
**so that** I establish the project's boundaries and constraints before creating feature specs.
|
|
8
|
+
|
|
9
|
+
## Acceptance Criteria
|
|
10
|
+
|
|
11
|
+
### AC-1: System Spec Auto-Detection
|
|
12
|
+
|
|
13
|
+
**Given** a user invokes `/implement-feature "my-feature"`
|
|
14
|
+
**And** `.blueprint/system_specification/SYSTEM_SPEC.md` does not exist
|
|
15
|
+
**When** the pipeline checks prerequisites
|
|
16
|
+
**Then** interactive mode activates for system spec creation (not feature spec)
|
|
17
|
+
|
|
18
|
+
### AC-2: System Spec Session Flow
|
|
19
|
+
|
|
20
|
+
**Given** interactive system spec mode is active
|
|
21
|
+
**When** Alex starts the session
|
|
22
|
+
**Then** Alex asks about: purpose, actors, system boundaries, and governing rules
|
|
23
|
+
**And** Alex drafts SYSTEM_SPEC.md sections incrementally
|
|
24
|
+
**And** the same session commands apply (`/approve`, `/change`, `/skip`, `/restart`, `/abort`, `/done`)
|
|
25
|
+
|
|
26
|
+
### AC-3: System Spec Output Location
|
|
27
|
+
|
|
28
|
+
**Given** an interactive system spec session completes successfully
|
|
29
|
+
**When** Alex writes the spec
|
|
30
|
+
**Then** the file is written to `.blueprint/system_specification/SYSTEM_SPEC.md`
|
|
31
|
+
**And** the file follows the SYSTEM_SPEC template structure
|
|
32
|
+
|
|
33
|
+
### AC-4: Pipeline Gate Satisfied
|
|
34
|
+
|
|
35
|
+
**Given** SYSTEM_SPEC.md is created via interactive session
|
|
36
|
+
**When** the user re-invokes `/implement-feature "my-feature"`
|
|
37
|
+
**Then** the system spec gate passes
|
|
38
|
+
**And** the pipeline proceeds to feature spec creation (interactive or autonomous)
|
|
39
|
+
|
|
40
|
+
### AC-5: System Spec Before Feature Spec
|
|
41
|
+
|
|
42
|
+
**Given** a user invokes `/implement-feature "my-feature" --interactive`
|
|
43
|
+
**And** SYSTEM_SPEC.md does not exist
|
|
44
|
+
**When** the pipeline routing logic runs
|
|
45
|
+
**Then** system spec interactive session runs first
|
|
46
|
+
**And** only after system spec is complete does feature spec interactive session begin
|
|
47
|
+
|
|
48
|
+
## Out of Scope
|
|
49
|
+
|
|
50
|
+
- Updating existing SYSTEM_SPEC.md interactively (only creation)
|
|
51
|
+
- Skipping system spec gate entirely
|
|
52
|
+
- System spec versioning or change tracking
|
|
53
|
+
|
|
54
|
+
## References
|
|
55
|
+
|
|
56
|
+
- Feature Spec: `.blueprint/features/feature_interactive-alex/FEATURE_SPEC.md` (Section 4.1, Open Question 2)
|
|
57
|
+
- System Spec: `.blueprint/system_specification/SYSTEM_SPEC.md` (Section 7 - System spec gate)
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
# Feature Specification — Parallel Abort
|
|
2
|
+
|
|
3
|
+
## 1. Feature Intent
|
|
4
|
+
|
|
5
|
+
Provide a way to stop all running parallel pipelines and optionally clean up worktrees. Users need an escape hatch if something goes wrong or they need to stop execution mid-way.
|
|
6
|
+
|
|
7
|
+
**Problem:** Once parallel pipelines start, there's no clean way to stop them. Users would have to manually find and kill processes, then clean up worktrees.
|
|
8
|
+
|
|
9
|
+
**Solution:** `orchestr8 parallel abort` command that gracefully stops all pipelines and handles cleanup.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 2. Scope
|
|
14
|
+
|
|
15
|
+
### In Scope
|
|
16
|
+
- Stop all running pipeline processes
|
|
17
|
+
- Update queue state to 'aborted'
|
|
18
|
+
- Option to preserve or remove worktrees
|
|
19
|
+
- Handle Ctrl+C in main process
|
|
20
|
+
- Clear status reporting
|
|
21
|
+
|
|
22
|
+
### Out of Scope
|
|
23
|
+
- Selective abort (single feature) — future enhancement
|
|
24
|
+
- Rollback of completed merges
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## 3. Behaviour Overview
|
|
29
|
+
|
|
30
|
+
### Abort (Preserve Worktrees)
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
$ orchestr8 parallel abort
|
|
34
|
+
|
|
35
|
+
Stopping parallel pipelines...
|
|
36
|
+
|
|
37
|
+
[10:35:01] feat-a: Stopping process (PID: 12345)
|
|
38
|
+
[10:35:01] feat-b: Stopping process (PID: 12346)
|
|
39
|
+
[10:35:02] feat-a: Stopped
|
|
40
|
+
[10:35:02] feat-b: Stopped
|
|
41
|
+
|
|
42
|
+
Aborted 2 pipelines. Worktrees preserved for debugging:
|
|
43
|
+
• .claude/worktrees/feat-feat-a/
|
|
44
|
+
• .claude/worktrees/feat-feat-b/
|
|
45
|
+
|
|
46
|
+
To clean up: orchestr8 parallel cleanup
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### Abort with Cleanup
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
$ orchestr8 parallel abort --cleanup
|
|
53
|
+
|
|
54
|
+
Stopping parallel pipelines...
|
|
55
|
+
|
|
56
|
+
[10:35:01] feat-a: Stopping process (PID: 12345)
|
|
57
|
+
[10:35:02] feat-a: Stopped
|
|
58
|
+
[10:35:02] feat-a: Removing worktree
|
|
59
|
+
|
|
60
|
+
Aborted 1 pipeline. Worktrees removed.
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
### Ctrl+C Handling
|
|
64
|
+
|
|
65
|
+
```
|
|
66
|
+
$ orchestr8 parallel feat-a feat-b feat-c
|
|
67
|
+
|
|
68
|
+
Starting parallel pipelines...
|
|
69
|
+
[10:30:01] feat-a: Started
|
|
70
|
+
[10:30:02] feat-b: Started
|
|
71
|
+
|
|
72
|
+
^C
|
|
73
|
+
Received interrupt signal. Stopping pipelines...
|
|
74
|
+
|
|
75
|
+
[10:31:15] feat-a: Stopped
|
|
76
|
+
[10:31:15] feat-b: Stopped
|
|
77
|
+
|
|
78
|
+
Aborted. Worktrees preserved. Run 'orchestr8 parallel cleanup' to remove.
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Nothing Running
|
|
82
|
+
|
|
83
|
+
```
|
|
84
|
+
$ orchestr8 parallel abort
|
|
85
|
+
|
|
86
|
+
No parallel pipelines are currently running.
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## 4. Implementation Notes
|
|
92
|
+
|
|
93
|
+
- Read PIDs from queue file or lock file
|
|
94
|
+
- Send SIGTERM first, then SIGKILL after timeout
|
|
95
|
+
- Update queue state for each feature to 'aborted'
|
|
96
|
+
- Register handler for SIGINT (Ctrl+C) in main process
|
|
97
|
+
- `--cleanup` flag triggers worktree removal after abort
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## 5. Test Themes
|
|
102
|
+
|
|
103
|
+
- Abort stops running processes
|
|
104
|
+
- Queue state updated to 'aborted'
|
|
105
|
+
- Worktrees preserved by default
|
|
106
|
+
- `--cleanup` removes worktrees
|
|
107
|
+
- Ctrl+C triggers graceful shutdown
|
|
108
|
+
- No-op when nothing running
|
|
109
|
+
- Lock file removed after abort
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
## 6. Change Log
|
|
114
|
+
|
|
115
|
+
| Date | Change | Reason |
|
|
116
|
+
|------|--------|--------|
|
|
117
|
+
| 2026-02-25 | Initial spec | Parallel safeguards |
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
# Feature Specification — Parallel Confirm
|
|
2
|
+
|
|
3
|
+
## 1. Feature Intent
|
|
4
|
+
|
|
5
|
+
Prevent accidental execution of parallel pipelines by requiring user confirmation before starting. Users should see exactly what will happen (worktrees created, pipelines spawned, estimated resources) and explicitly confirm they want to proceed.
|
|
6
|
+
|
|
7
|
+
**Problem:** Running `orchestr8 parallel feat-a feat-b feat-c` immediately starts creating worktrees and spawning processes. Users might run this accidentally or without understanding the impact.
|
|
8
|
+
|
|
9
|
+
**Solution:** Show a summary and prompt for confirmation before execution.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 2. Scope
|
|
14
|
+
|
|
15
|
+
### In Scope
|
|
16
|
+
- Confirmation prompt showing execution plan
|
|
17
|
+
- `--yes` / `-y` flag to skip confirmation (for automation)
|
|
18
|
+
- Clear summary of what will happen
|
|
19
|
+
|
|
20
|
+
### Out of Scope
|
|
21
|
+
- Interactive editing of the plan
|
|
22
|
+
- Cost estimation (separate feature)
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 3. Behaviour Overview
|
|
27
|
+
|
|
28
|
+
### Happy Path
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
$ orchestr8 parallel user-auth dashboard notifications
|
|
32
|
+
|
|
33
|
+
This will:
|
|
34
|
+
• Create 3 git worktrees in .claude/worktrees/
|
|
35
|
+
• Start 3 parallel pipelines (max concurrent: 3)
|
|
36
|
+
• Branches: feature/user-auth, feature/dashboard, feature/notifications
|
|
37
|
+
|
|
38
|
+
Continue? [y/N] y
|
|
39
|
+
|
|
40
|
+
Starting parallel pipelines...
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### Skip Confirmation
|
|
44
|
+
|
|
45
|
+
```
|
|
46
|
+
$ orchestr8 parallel user-auth dashboard --yes
|
|
47
|
+
Starting parallel pipelines...
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### User Declines
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
$ orchestr8 parallel user-auth dashboard
|
|
54
|
+
|
|
55
|
+
This will:
|
|
56
|
+
• Create 2 git worktrees in .claude/worktrees/
|
|
57
|
+
• Start 2 parallel pipelines (max concurrent: 3)
|
|
58
|
+
|
|
59
|
+
Continue? [y/N] n
|
|
60
|
+
|
|
61
|
+
Aborted.
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## 4. Implementation Notes
|
|
67
|
+
|
|
68
|
+
- Add confirmation logic after dry-run check, before actual execution
|
|
69
|
+
- Use `readline` for prompt in Node.js
|
|
70
|
+
- Check `options.yes` flag to skip
|
|
71
|
+
- Exit with code 0 on user abort (not an error)
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## 5. Test Themes
|
|
76
|
+
|
|
77
|
+
- Confirmation shown by default
|
|
78
|
+
- `--yes` flag skips confirmation
|
|
79
|
+
- `-y` shorthand works
|
|
80
|
+
- User typing 'n' or Enter aborts
|
|
81
|
+
- User typing 'y' or 'Y' proceeds
|
|
82
|
+
- Abort exits cleanly (code 0)
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 6. Change Log
|
|
87
|
+
|
|
88
|
+
| Date | Change | Reason |
|
|
89
|
+
|------|--------|--------|
|
|
90
|
+
| 2026-02-25 | Initial spec | Parallel safeguards |
|