opencastle 0.29.0 → 0.30.0

package/src/orchestrator/prompts/generate-convoy.prompt.md

@@ -309,6 +309,29 @@ For complex tasks, consider using `steps` to break the prompt into sequential su
 >
 > **Strong prompt:** "Write unit tests for `libs/auth/src/server.ts` covering token refresh, expiry edge cases, and invalid signatures. Place tests in `libs/auth/src/__tests__/server.test.ts`. Follow the existing test conventions. Achieve ≥ 95 % coverage for `server.ts`. Run the project's test command with coverage and fix any failures."
 
+### Chain Mode (Subset Generation)
+
+When the `{{context}}` field contains a JSON object with `"mode": "chain_subset"`, you are generating ONE convoy spec that is part of a larger convoy chain. The context will look like:
+
+```json
+{
+  "mode": "chain_subset",
+  "group_name": "database-setup",
+  "group_description": "Schema changes and migrations",
+  "group_phases": [1],
+  "depends_on_groups": [],
+  "total_groups": 3,
+  "group_index": 1
+}
+```
+
+When this context is present:
+- **Only** generate tasks for the phases listed in `group_phases`. Do not include tasks from other phases.
+- Use `version: 1` — this spec is a single convoy, not a pipeline.
+- Derive the convoy `name` from `group_name` (e.g., "Database Setup").
+- Derive the `branch` from the PRD's feature name, but it will be overridden by the pipeline anyway.
+- Keep all other conventions (prompts, files, gates, etc.) the same as for single-spec generation.
+
 ### 6. Validate Before Outputting
 
 Before presenting the YAML, mentally verify:

package/src/orchestrator/prompts/generate-prd.prompt.md

@@ -124,3 +124,35 @@ Measurable, binary checks that confirm the feature is shippable:
 - **[Open question]**: [What needs to be decided before implementation can start]
 
 If there are no risks or open questions, write "None identified."
+
+## Complexity Assessment
+
+Produce a fenced JSON block with the following fields. This is consumed programmatically by the pipeline to decide whether to generate a single convoy spec or a convoy chain.
+
+```json
+{
+  "total_tasks": 12,
+  "total_phases": 4,
+  "domains": ["database", "api", "frontend", "testing"],
+  "estimated_duration_minutes": 120,
+  "complexity": "low",
+  "recommended_strategy": "single",
+  "chain_rationale": "",
+  "convoy_groups": [
+    {
+      "name": "full-implementation",
+      "description": "All phases in a single convoy",
+      "phases": [1, 2, 3, 4],
+      "depends_on": []
+    }
+  ]
+}
+```
+
+**Strategy decision rules:**
+- Use `"single"` when: total tasks ≤ 8, or total phases ≤ 3, or all tasks are tightly coupled with heavy cross-phase file sharing.
+- Use `"chain"` when: total tasks > 8 AND total phases > 3 AND domains have natural boundaries (e.g., database changes are independent from frontend components from test suites) — AND splitting would improve failure isolation, observability, or retry granularity.
+- When `"single"`: provide exactly one convoy group covering all phases.
+- When `"chain"`: provide 2–4 convoy groups with explicit `depends_on` order. Each group should cover a coherent domain boundary.
+- `complexity` values: `"low"` (1–4 tasks), `"medium"` (5–8 tasks), `"high"` (9+ tasks).
+- `chain_rationale` is only filled when `recommended_strategy` is `"chain"` — explain WHY splitting benefits this specific feature.