@specship/specship-win32-arm64 0.24.0 → 0.28.0

package/lib/dist/workflows/defaults/spec-fix.yaml

@@ -14,8 +14,10 @@ inputs:
 systemPromptAppend: |
   You are fixing code so a spec's link returns to "verified" state.
   Call specship_spec($INPUT.SPEC_ID) first to see the current state and
-  drift_axis. After fixing, call specship_link_verify({result: "pass"})
-  on each affected link before reporting done.
+  drift_axis. Link state changes only in the link_verify node, only after
+  the reviewer's approval, and only as the run's VERIFY_RESULT marker
+  allows — a verify leg that was skipped or never got past install/build
+  proves nothing and promotes nothing (REQ-REVINT-006).
 
 nodes:
   - id: diagnose
@@ -78,33 +80,122 @@ nodes:
     output_type: test_results
     timeout: 600000
     bash: |
+      # Same VERIFY_RESULT marker contract as spec-implement
+      # (REQ-REVINT-006.A2): the link_verify node routes on the marker, so a
+      # skipped run can never be mistaken for a passing one, and an
+      # environment or build failure is never attributed to the tests.
       if [ -f package.json ]; then
-        npm test
+        # A fresh worktree has no node_modules/ or build output.
+        if [ ! -d node_modules ]; then
+          if ! { npm ci --no-audit --no-fund || npm install --no-audit --no-fund; }; then
+            echo "VERIFY_RESULT=env-failed"; exit 1
+          fi
+        fi
+        if ! npm run build --if-present; then echo "VERIFY_RESULT=build-failed"; exit 1; fi
+        if npm test; then echo "VERIFY_RESULT=ran-and-passed"; else echo "VERIFY_RESULT=ran-and-failed"; exit 1; fi
       elif [ -f Cargo.toml ]; then
-        cargo test
+        if ! cargo build; then echo "VERIFY_RESULT=build-failed"; exit 1; fi
+        if cargo test; then echo "VERIFY_RESULT=ran-and-passed"; else echo "VERIFY_RESULT=ran-and-failed"; exit 1; fi
       elif [ -f pyproject.toml ] || [ -f requirements.txt ]; then
-        python -m pytest
+        if ! python -c 'import pytest' 2>/dev/null; then echo "VERIFY_RESULT=env-failed"; exit 1; fi
+        if python -m pytest; then echo "VERIFY_RESULT=ran-and-passed"; else echo "VERIFY_RESULT=ran-and-failed"; exit 1; fi
       else
-        echo "no recognised test framework; skipping"
+        echo "no recognised test framework; tests did NOT run"
+        echo "VERIFY_RESULT=skipped"
       fi
 
+  - id: route_verify
+    kind: bash
+    depends_on: [verify]
+    output_type: verify_route
+    bash: |
+      # Deterministic verify routing (REQ-VSTATE-005.A1): code parses the
+      # VERIFY_RESULT marker and emits the LINK_ACTION the link node obeys, so
+      # the decision that governs link promotion isn't a prompt's reading of a
+      # test log. env-failed / build-failed halt here, before the approval gate
+      # and before any link mutation, naming the cause (REQ-VSTATE-005.A3).
+      VERIFY_OUT=$verify.output
+      MARKER=$(printf '%s' "$VERIFY_OUT" | grep -oE 'VERIFY_RESULT=[a-z-]+' | tail -n 1 | cut -d= -f2)
+      [ -n "$MARKER" ] || MARKER=missing
+      echo "VERIFY_RESULT=$MARKER"
+      case "$MARKER" in
+        ran-and-passed)
+          echo "LINK_ACTION=verify-pass" ;;
+        ran-and-failed)
+          echo "LINK_ACTION=verify-fail" ;;
+        skipped)
+          echo "LINK_ACTION=no-verify" ;;
+        env-failed)
+          echo "HALT_CAUSE=environment setup failed (dependency install) — nothing is known about the tests"
+          exit 1 ;;
+        build-failed)
+          echo "HALT_CAUSE=build failed — nothing is known about the tests"
+          exit 1 ;;
+        *)
+          echo "HALT_CAUSE=no VERIFY_RESULT marker found in the verify output — an unknown result is never a pass"
+          exit 1 ;;
+      esac
+
+  - id: approve_links
+    kind: approval
+    depends_on: [route_verify]
+    message: |
+      Fix applied for $INPUT.SPEC_ID — approve before any link changes state
+      (REQ-REVINT-006.A4).
+
+      Files changed:
+      $apply.output
+
+      Verify routing (computed in code, REQ-VSTATE-005.A1 — `no-verify`
+      means no test ran, so nothing here can reach `verified`):
+      $route_verify.output
+
+      Test results:
+      $verify.output
+
+      Approve to let the link states be updated, or reject to leave every
+      link exactly as it is.
+    capture_response: true
+
   - id: link_verify
     kind: prompt
-    depends_on: [verify]
+    depends_on: [approve_links]
     output_type: link_summary
     allowed_tools:
       - mcp__specship__specship_spec
       - mcp__specship__specship_link_assert
       - mcp__specship__specship_link_verify
     prompt: |
-      For each link that was drifted/broken on $INPUT.SPEC_ID, now that
-      the fix has been applied and tests pass, call specship_link_verify
-      with result="pass" (or "fail" if a test failed for that link).
+      The reviewer has approved updating link state for $INPUT.SPEC_ID.
+
+      Act on LINK_ACTION — a bash node already derived it from the
+      VERIFY_RESULT marker (REQ-VSTATE-005.A1). Do NOT re-derive it from the
+      test log; read it here:
+
+      $route_verify.output
+
+      - LINK_ACTION=verify-pass → for each link that was drifted/broken, call
+        specship_link_verify with result="pass" (or "fail" if a test failed
+        for that link specifically).
+      - LINK_ACTION=verify-fail → call specship_link_verify with
+        result="fail" for the affected links. Never "pass".
+      - LINK_ACTION=no-verify → no test ran, so nothing is proven. Do NOT
+        call specship_link_verify at all; no link may reach `verified`
+        (REQ-REVINT-006.A3). Report that verification was skipped.
+
+      A run whose environment or build broke never reaches this node — the
+      routing step halts it first (REQ-VSTATE-005.A3).
 
       If a link is orphaned because the symbol moved, call
-      specship_link_assert at the new location.
+      specship_link_assert at the new location. Never pass kind: 'tests' —
+      test evidence is file-derived (`verifies:` block or an `@verifies`
+      comment), never minted by this workflow (REQ-REVINT-005.A1).
+
+      Reviewer feedback (if any):
+      $approve_links.output
 
       Test results:
       $verify.output
 
-      Output: one line per link with the new state.
+      Output: one line per link with the new state, ending with one line
+      stating whether verification ran, failed, or was skipped.

package/lib/dist/workflows/defaults/spec-implement-mixed.yaml

@@ -1,197 +1,25 @@
 name: spec-implement-mixed
 description: Implement a spec with mixed models — sonnet plans, haiku executes, tests + gates verify. Same steps and gates as spec-implement at a fraction of the token cost.
 tags: [spec, default, mixed-model]
-requires: [specship, git]
 
-worktree:
-  enabled: true
-
-inputs:
-  - name: SPEC_ID
-    description: The spec ID to implement (e.g. REQ-AUTH-005)
-    required: true
-
-systemPromptAppend: |
-  You are implementing a specific requirement. Before editing code, call
-  specship_spec($INPUT.SPEC_ID) to see the spec body and any code it
-  already links to. After editing, call specship_link_assert with the
-  spec_id and the symbol you implemented BEFORE reporting done.
-
-nodes:
-  - id: fetch_spec
-    # MIXMODEL-DOC: mechanical step → haiku
-    model: haiku
-    kind: prompt
-    output_type: spec_summary
-    allowed_tools:
-      - mcp__specship__specship_spec
-      - mcp__specship__specship_explore
-    prompt: |
-      Spec ID: $INPUT.SPEC_ID
-
-      Call specship_spec to fetch the spec. Then call specship_explore on
-      a small bag of terms drawn from the spec title and acceptance
-      criteria to find the relevant code area.
-
-      Output: a short summary (≤300 words) of (a) what the spec asks for,
-      (b) which code areas / symbols are most relevant, and (c) whether
-      any code currently claims to implement it (look at linked_code).
-
-  - id: plan
-    # MIXMODEL-DOC: judgment step → sonnet
-    model: sonnet
-    kind: prompt
-    depends_on: [fetch_spec]
-    output_type: plan
-    allowed_tools:
-      - mcp__specship__specship_explore
-      - mcp__specship__specship_node
-      - mcp__specship__specship_spec
-      - Read
-    prompt: |
-      Based on this spec summary, write a concrete implementation plan:
-
-      $fetch_spec.output
-
-      The plan should list:
-      - Files to create or modify (with project-relative paths)
-      - Specific functions/methods/classes to add or change
-      - Tests to add or update
-      - Order of changes
-
-      Keep it tight (≤500 words). Do NOT edit code in this step.
-
-  - id: approve_plan
-    kind: approval
-    depends_on: [plan]
-    message: |
-      Plan ready for $INPUT.SPEC_ID. Review the plan output and approve
-      to proceed with implementation, or reject with feedback to revise.
-    capture_response: true
-    on_reject:
-      prompt: |
-        The plan was rejected with this feedback. Revise:
-
-        $approve_plan.output
-      max_attempts: 3
-
-  - id: implement
-    # MIXMODEL-DOC: mechanical step → haiku
-    model: haiku
-    kind: prompt
-    depends_on: [approve_plan]
-    output_type: diff
-    allowed_tools:
-      - Read
-      - Edit
-      - Write
-      - Bash
-      - mcp__specship__specship_explore
-      - mcp__specship__specship_node
-      - mcp__specship__specship_spec
-    prompt: |
-      Implement the approved plan. Follow it closely.
-
-      Plan:
-      $plan.output
-
-      Approval feedback (if any):
-      $approve_plan.output
-
-      When done, output a short diff summary (which files changed and why).
-
-  - id: verify
-    kind: bash
-    depends_on: [implement]
-    output_type: test_results
-    timeout: 600000
-    bash: |
-      # Run the project's test suite. The verify node's exit code drives
-      # the gating for the link node — non-zero halts the workflow.
-      # The VERIFY_RESULT marker is the machine-readable contract the link
-      # node routes on (REQ-IMPLINT-001.A1): a skipped run must never be
-      # mistaken for a passing one.
-      if [ -f package.json ]; then
-        # A fresh worktree has no node_modules/ or build output — a verify
-        # failure must mean the tests failed, not that the environment was
-        # missing (WF-REJECT-DOC, REQ-WFREJ-005).
-        if [ ! -d node_modules ]; then npm ci --no-audit --no-fund || npm install --no-audit --no-fund; fi
-        npm run build --if-present
-        if npm test; then echo "VERIFY_RESULT=ran-and-passed"; else echo "VERIFY_RESULT=ran-and-failed"; exit 1; fi
-      elif [ -f Cargo.toml ]; then
-        if cargo test; then echo "VERIFY_RESULT=ran-and-passed"; else echo "VERIFY_RESULT=ran-and-failed"; exit 1; fi
-      elif [ -f pyproject.toml ] || [ -f requirements.txt ]; then
-        if python -m pytest; then echo "VERIFY_RESULT=ran-and-passed"; else echo "VERIFY_RESULT=ran-and-failed"; exit 1; fi
-      else
-        echo "no recognised test framework; tests did NOT run"
-        echo "VERIFY_RESULT=skipped"
-      fi
-
-  - id: link
-    # MIXMODEL-DOC: mechanical step → haiku
-    model: haiku
-    kind: prompt
-    depends_on: [verify]
-    output_type: link_summary
-    allowed_tools:
-      - mcp__specship__specship_link_assert
-      - mcp__specship__specship_link_verify
-      - mcp__specship__specship_spec
-    prompt: |
-      Assert spec→code links for the changes made in the implement step.
-      For each symbol that implements $INPUT.SPEC_ID (or its child
-      requirements), call specship_link_assert with the spec_id, the
-      file path, and the qualified symbol name.
-
-      Then route on the VERIFY_RESULT marker in the test results below
-      (REQ-IMPLINT-001):
-      - VERIFY_RESULT=ran-and-passed → after each assert, call
-        specship_link_verify with result="pass".
-      - VERIFY_RESULT=skipped → do NOT call specship_link_verify at all;
-        the links stay in the `implemented` state. Tests that did not run
-        are never reported as passing.
-
-      Implementation diff summary:
-      $implement.output
-
-      Test results:
-      $verify.output
-
-      Output: a short list of "spec_id → file:symbol [verified|implemented]"
-      lines, ending with one line stating whether verification ran or was
-      skipped.
-
-  - id: coverage
-    # MIXMODEL-DOC: mechanical step → haiku
-    model: haiku
-    kind: prompt
-    depends_on: [link]
-    output_type: coverage_summary
-    allowed_tools:
-      - mcp__specship__specship_spec
-    prompt: |
-      Report acceptance-criteria test coverage for $INPUT.SPEC_ID
-      (REQ-IMPLINT-002). Call specship_spec with the spec_id, count its
-      acceptance criteria (the .A<N> children; if the spec has none,
-      treat the requirement itself as one criterion), and count how many
-      of them carry a `tests`-kind link.
-
-      Output exactly one or two lines:
-      - "N of M acceptance criteria for $INPUT.SPEC_ID have linked tests."
-      - If N < M, add: "Close the gap with /specship:spec behaviour
-        $INPUT.SPEC_ID."
-
-  - id: final_review
-    kind: approval
-    depends_on: [coverage]
-    message: |
-      Implementation complete for $INPUT.SPEC_ID.
-
-      Links asserted:
-      $link.output
-
-      Acceptance-criteria test coverage:
-      $coverage.output
-
-      Approve to finalize the run (worktree is left for you to inspect
-      and merge), or reject to abandon.
+# THROUGHPUT-DOC, REQ-THRU-004 — one source of truth for the implement
+# pipeline. This variant inherits every node, gate and prompt from
+# spec-implement and states only what differs: which model runs each step
+# (MIXMODEL-DOC). Judgment steps are pinned up (sonnet); mechanical steps are
+# pinned down (haiku); bash gates, approvals, verify, routing and coverage are
+# model-free and identical by construction.
+extends: spec-implement
+
+node_overrides:
+  fetch_spec:
+    model: haiku      # mechanical: read the spec and summarize
+  plan:
+    model: sonnet     # judgment: the plan the human approves
+  implement:
+    model: haiku      # mechanical: execute the approved plan
+  fix_quality:
+    model: haiku      # mechanical: fix what the linter named
+  link:
+    model: haiku      # mechanical: record implementations bullets
+  adversarial_review:
+    model: sonnet     # judgment: try to break the change