valent-pipeline 0.6.0 → 0.6.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "valent-pipeline",
-  "version": "0.6.0",
+  "version": "0.6.1",
   "description": "v3 multi-agent AI pipeline for software development lifecycle",
   "type": "module",
   "bin": {

package/pipeline/orchestrators/claude-code/plan.workflow.js

@@ -392,11 +392,14 @@ if (!validation.valid) {
 // before its dependent) and sprint.workflow.js runs the batch SEQUENTIALLY in array order on a
 // shared branch — so a dependent must not precede its prerequisite. This is what lets a dependency
 // chain ship together in one sprint.
+// `groomed: true` — these stories were fully specced + passed the READINESS gate during grooming
+// above, and their reqs-brief/uxa-spec/qa-test-spec are on disk. sprint.workflow.js reads this flag
+// and SKIPS its Spec + Readiness phases, so execution doesn't redundantly re-spec and re-gate.
 const sizedById = new Map(sizedStories.map((s) => [s.storyId, s]))
 const plannedStories = pack.sprint_stories
   .map((id) => sizedById.get(id))
   .filter(Boolean)
-  .map((s) => ({ storyId: s.storyId, projectType: s.projectType, profiles: s.profiles }))
+  .map((s) => ({ storyId: s.storyId, projectType: s.projectType, profiles: s.profiles, groomed: true }))
 
 return {
   sprintId,

package/pipeline/orchestrators/claude-code/sprint.workflow.js

@@ -33,8 +33,15 @@
  * their structured returns.
  *
  * args (either form):
- *   { stories: [{ storyId, projectType?, profiles? }, ...], projectType?, profiles?, maxRejectionCycles?, models?, reasoning? }
- *   { storyId, projectType, profiles?, maxRejectionCycles?, models?, reasoning? }   // single-story (back-compat)
+ *   { stories: [{ storyId, projectType?, profiles?, groomed? }, ...], projectType?, profiles?, preGroomed?, maxRejectionCycles?, models?, reasoning? }
+ *   { storyId, projectType, profiles?, groomed?, maxRejectionCycles?, models?, reasoning? }   // single-story (back-compat)
+ *
+ * `groomed` (per story) / `preGroomed` (batch-wide): the story was already specced + passed the
+ * READINESS gate during sprint planning (plan.workflow.js sets groomed:true on every story it
+ * returns), and its reqs-brief/uxa-spec/qa-test-spec are on disk. When true, this script SKIPS its
+ * Spec + Readiness phases and goes straight to Build — re-running them would be duplicated token
+ * spend. The standalone single-story path (valent-run-story-workflow) omits it, so an un-groomed
+ * story still gets Spec + Readiness here.
  *
  * `models` is the pipeline-config.yaml `models` tier->roles map (e.g. { opus:[...], sonnet:[...],
  * haiku:[...] }); the invoking skill passes it through so per-agent model tiers stay config-driven
@@ -196,8 +203,9 @@ const batch = Array.isArray(a.stories) && a.stories.length
       storyId: s.storyId,
       projectType: s.projectType || a.projectType,
       profiles: s.profiles || a.profiles || [],
+      groomed: s.groomed === true || a.preGroomed === true,
     }))
-  : [{ storyId: a.storyId, projectType: a.projectType, profiles: a.profiles || [] }]
+  : [{ storyId: a.storyId, projectType: a.projectType, profiles: a.profiles || [], groomed: a.groomed === true || a.preGroomed === true }]
 
 const maxRejectionCycles = a.maxRejectionCycles ?? 5
 
@@ -374,7 +382,7 @@ async function runIntegrationGate(shipped) {
 // runStory: the per-story pipeline (kept inline, not a nested workflow(), so the single
 // workflow() nesting level stays free for plan/retro — see reimplementation-plan §5b).
 async function runStory(story) {
-  const { storyId, projectType, profiles } = story
+  const { storyId, projectType, profiles, groomed } = story
   const profilesCsv = profiles.join(',')
 
   phase('Resolve')
@@ -417,22 +425,30 @@ async function runStory(story) {
       model: opts.model || modelFor(role),
     })
 
-  phase('Spec')
-  await spawn('REQS', 'reqs.md', 'Analyze the story and produce reqs-brief.md.', { phase: 'Spec' })
-  if (has('uxa')) {
-    await spawn('UXA', 'uxa.md', 'Translate the brief into uxa-spec.md.', { phase: 'Spec' })
-  }
-  await spawn('QA-A', 'qa-a.md', 'Produce qa-test-spec.md before any code is written.', { phase: 'Spec' })
-
-  phase('Readiness')
-  await runGate(storyId, 'READINESS', 'readiness.md', 'Validate the spec chain (reqs/uxa/qa) is implementation-ready.',
-    'Readiness', (verdict) => {
-      const target = verdict.rejectionTarget || 'REQS'
-      return spawn(target, `${target.toLowerCase()}.md`, 'Address the READINESS rejection and rewrite the affected spec.', {
-        label: `rework:${target.toLowerCase()}:${storyId}`,
-        phase: 'Readiness',
+  // Spec + Readiness are SKIPPED for pre-groomed stories. plan.workflow.js already specced them
+  // (reqs-brief/uxa-spec/qa-test-spec are on disk) and passed the READINESS gate at planning time,
+  // so re-running here is duplicated token spend. The standalone single-story path leaves `groomed`
+  // false, so an un-groomed story still gets fully specced + gated before Build.
+  if (groomed) {
+    log(`${storyId}: pre-groomed at sprint planning — skipping Spec + Readiness (specs on disk, readiness already passed)`)
+  } else {
+    phase('Spec')
+    await spawn('REQS', 'reqs.md', 'Analyze the story and produce reqs-brief.md.', { phase: 'Spec' })
+    if (has('uxa')) {
+      await spawn('UXA', 'uxa.md', 'Translate the brief into uxa-spec.md.', { phase: 'Spec' })
+    }
+    await spawn('QA-A', 'qa-a.md', 'Produce qa-test-spec.md before any code is written.', { phase: 'Spec' })
+
+    phase('Readiness')
+    await runGate(storyId, 'READINESS', 'readiness.md', 'Validate the spec chain (reqs/uxa/qa) is implementation-ready.',
+      'Readiness', (verdict) => {
+        const target = verdict.rejectionTarget || 'REQS'
+        return spawn(target, `${target.toLowerCase()}.md`, 'Address the READINESS rejection and rewrite the affected spec.', {
+          label: `rework:${target.toLowerCase()}:${storyId}`,
+          phase: 'Readiness',
+        })
       })
-    })
+  }
 
   phase('Build')
   // Genuine barrier: CRITIC needs ALL active dev agents' work before reviewing.

package/skills/valent-run-story-workflow/SKILL.md

@@ -72,6 +72,7 @@ Every Workflow invocation returns a `runId`. If a run is interrupted — context
 
 - **State model.** The **journal is the state of record.** `pipeline-state.json`, `sprint-{n}-status.yaml`, and the markdown handoffs are **derived, human-readable views** that agents write for visibility — the orchestrator never reads them back to make a control-flow decision (its state lives in JS variables the journal captures). A non-atomic multi-file state desync is structurally impossible here.
 - **Planned sprint batches.** To run a planned batch instead of one story, pass `args: { stories: [{ storyId, projectType, profiles }, ...], maxRejectionCycles, models, reasoning }`. Produce that batch by running `plan.workflow.js` first (`args: { stories: [{ storyId, projectType }], sprintId, velocity, models, reasoning }`), then feed its `{ sprintId, stories: [...] }` straight into `sprint.workflow.js`. After a batch ships, run `retro.workflow.js` (`args: { batchNumber, sprintId, models, reasoning }`) to learn from it. Pass the same `config.models` and `config.reasoning` maps to all three. There is no `sprint-cycle` wrapper yet — run the three in sequence.
+  - `plan.workflow.js` marks each returned story `groomed: true` (it already specced them and passed the READINESS gate). `sprint.workflow.js` honors that flag and **skips its Spec + Readiness phases** for those stories — execution goes straight to Build, so a planned batch isn't re-specced or re-gated. A standalone single story (this skill's default args, no `groomed`) is still fully specced + gated. To force the skip manually, pass `preGroomed: true` (batch-wide) or `groomed: true` per story.
 - **Per-agent reasoning effort.** The `reasoning` arg is a config-driven control surface (level→roles) that injects a thinking trigger into a role's prompt — blank by default, so it changes nothing until you fill it. Levels: `think` < `think-hard` < `think-harder` < `ultrathink`. Deeper thinking raises quality and token cost; check `valent audit` after enabling it. Edit it in `.valent-pipeline/pipeline-config.yaml` under `reasoning:`.
 - **Per-agent models.** Each workflow assigns a model tier per agent: gates (READINESS/CRITIC/JUDGE) → opus, spec/build → sonnet, CLI-runner/IO steps → haiku. This comes from `config.models` (passed as the `models` arg); edit it with `/valent-configure` → "Model Assignments". Omitting the arg falls back to the same assignment baked into the script.
 - **Known simplifications.** A CRITIC rejection currently re-runs ALL dev agents (not just the targeted one); there is no PMCP/visual-validation stage in the Workflow path yet. See `.valent-pipeline/orchestrators/claude-code/README.md`.