opencastle 0.29.0 → 0.30.1

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.
@@ -309,6 +309,29 @@ For complex tasks, consider using `steps` to break the prompt into sequential su
309
309
  >
310
310
  > **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."
311
311
 
312
+ ### Chain Mode (Subset Generation)
313
+
314
+ 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:
315
+
316
+ ```json
317
+ {
318
+ "mode": "chain_subset",
319
+ "group_name": "database-setup",
320
+ "group_description": "Schema changes and migrations",
321
+ "group_phases": [1],
322
+ "depends_on_groups": [],
323
+ "total_groups": 3,
324
+ "group_index": 1
325
+ }
326
+ ```
327
+
328
+ When this context is present:
329
+ - **Only** generate tasks for the phases listed in `group_phases`. Do not include tasks from other phases.
330
+ - Use `version: 1` — this spec is a single convoy, not a pipeline.
331
+ - Derive the convoy `name` from `group_name` (e.g., "Database Setup").
332
+ - Derive the `branch` from the PRD's feature name, but it will be overridden by the pipeline anyway.
333
+ - Keep all other conventions (prompts, files, gates, etc.) the same as for single-spec generation.
334
+
312
335
  ### 6. Validate Before Outputting
313
336
 
314
337
  Before presenting the YAML, mentally verify:
@@ -22,9 +22,12 @@ You are the Team Lead. Convert the feature request below into a structured Produ
22
22
 
23
23
  ## Research Before Writing
24
24
 
25
- If the feature request involves a specific person, place, organization, topic, or any real-world subject you are not confident you have accurate knowledge about — **you MUST search the internet first** using any available web search or fetch tools (e.g. `fetch_webpage`, web search MCP, or similar). Use the search results to gather accurate facts, names, dates, descriptions, and other details.
25
+ If the feature request involves a specific person, place, organization, topic, or any real-world subject:
26
26
 
27
- **Never fabricate or hallucinate content** about real-world subjects. If you cannot verify a claim through web search, state what is unknown rather than inventing plausible-sounding text. This applies to all content: bios, descriptions, histories, statistics, quotes, and any factual claims.
27
+ 1. **Search the internet first** if web search or fetch tools are available (e.g. `fetch_webpage`, web search MCP, or similar). Use the search results to gather accurate facts, names, dates, descriptions, and other details.
28
+ 2. **If web search tools are unavailable or return no useful results**, you may use your training knowledge — but clearly mark any such content with:
29
+ > ℹ️ Content based on training data — verify before launch.
30
+ 3. **Never fabricate or hallucinate content.** If you genuinely have no knowledge about a real-world subject and cannot search, state what is unknown and use placeholder text. This applies to all content: bios, descriptions, histories, statistics, quotes, and any factual claims.
28
31
 
29
32
  ## Required PRD Structure
30
33
 
@@ -124,3 +127,35 @@ Measurable, binary checks that confirm the feature is shippable:
124
127
  - **[Open question]**: [What needs to be decided before implementation can start]
125
128
 
126
129
  If there are no risks or open questions, write "None identified."
130
+
131
+ ## Complexity Assessment
132
+
133
+ 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.
134
+
135
+ ```json
136
+ {
137
+ "total_tasks": 12,
138
+ "total_phases": 4,
139
+ "domains": ["database", "api", "frontend", "testing"],
140
+ "estimated_duration_minutes": 120,
141
+ "complexity": "low",
142
+ "recommended_strategy": "single",
143
+ "chain_rationale": "",
144
+ "convoy_groups": [
145
+ {
146
+ "name": "full-implementation",
147
+ "description": "All phases in a single convoy",
148
+ "phases": [1, 2, 3, 4],
149
+ "depends_on": []
150
+ }
151
+ ]
152
+ }
153
+ ```
154
+
155
+ **Strategy decision rules:**
156
+ - Use `"single"` when: total tasks ≤ 8, or total phases ≤ 3, or all tasks are tightly coupled with heavy cross-phase file sharing.
157
+ - 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.
158
+ - When `"single"`: provide exactly one convoy group covering all phases.
159
+ - When `"chain"`: provide 2–4 convoy groups with explicit `depends_on` order. Each group should cover a coherent domain boundary.
160
+ - `complexity` values: `"low"` (1–4 tasks), `"medium"` (5–8 tasks), `"high"` (9+ tasks).
161
+ - `chain_rationale` is only filled when `recommended_strategy` is `"chain"` — explain WHY splitting benefits this specific feature.