@productbrain/mcp 0.0.1-beta.5806 → 0.0.1-beta.5831

package/dist/{chunk-NCVHDVO2.js → chunk-4SG5IWOJ.js}

@@ -10735,13 +10735,13 @@ Use \`workflows action=checkpoint\` after each round to persist progress to the
       label: "Find the Elements",
       type: "open",
       instruction: "What are the solution elements? Think breadboard level \u2014 places, affordances, connections. What's the architecture?",
-      facilitatorGuidance: "**Investigate first.** Spawn sub-agents to search the codebase for affected modules, existing architecture patterns, and API boundaries. Synthesize findings into 3-5 proposed solution elements at breadboard level, citing specific files and modules. **Five-path trace per element:** For each element, trace: (1) what data flows through it, (2) what contracts it relies on, (3) what contracts it alters, (4) what second-order effects downstream, (5) what happens at boundaries (batch, error, empty, scale). Present proposals for user reaction: 'Based on the codebase, here are the elements I'd suggest.' For each confirmed element, use `capture` with collection='features' to create a features entry linked to the work package via part_of. For Big Batch: also investigate architecture \u2014 search for layer boundaries and dependency directions, then propose architecture. Check business rules: do any elements conflict with governance surfaced in Round 1? Capture new glossary terms and decisions as they surface. Aim for 3-5 elements. When elements and architecture are well-covered, present for confirmation.",
+      facilitatorGuidance: "**Investigate first.** Spawn sub-agents to search the codebase for affected modules, existing architecture patterns, and API boundaries. Synthesize findings into 3-5 proposed solution elements at breadboard level, citing specific files and modules. **Five-path trace per element:** For each element, trace: (1) what data flows through it, (2) what contracts it relies on, (3) what contracts it alters, (4) what second-order effects downstream, (5) what happens at boundaries (batch, error, empty, scale). Present proposals for user reaction: 'Based on the codebase, here are the elements I'd suggest.' For each confirmed element, use `capture` with collection='tasks' to create a task entry linked to the work package via part_of (DEC-1560: a slice is a Task). `capture` sets no workflow status, so immediately initialize it: `entries action=update entryId=<elementId> workflowStatus=\"todo\"`. For Big Batch: also investigate architecture \u2014 search for layer boundaries and dependency directions, then propose architecture. Check business rules: do any elements conflict with governance surfaced in Round 1? Capture new glossary terms and decisions as they surface. Aim for 3-5 elements. When elements and architecture are well-covered, present for confirmation.",
       outputSchema: {
         field: "elements",
         description: "Core solution elements and architecture",
         format: "structured"
       },
-      kbCollection: "features",
+      kbCollection: "tasks",
       maxDurationHint: "15 min"
     },
     {
@@ -10811,7 +10811,8 @@ Use \`workflows action=checkpoint\` after each round to persist progress to the
     emits: [
       {
         kind: "entry",
-        collection: "features",
+        collection: "tasks",
+        // a slice is a Task, related part_of its work package
         description: "Solution elements captured during shaping."
       },
       {
@@ -16920,4 +16921,4 @@ export {
   createProductBrainServer,
   initFeatureFlags
 };
-//# sourceMappingURL=chunk-NCVHDVO2.js.map
+//# sourceMappingURL=chunk-4SG5IWOJ.js.map