@exaudeus/workrail 3.45.0 → 3.47.0

package/docs/design/queue-label-support-design-review.md

@@ -0,0 +1,62 @@
+# Design Review: Label-Based Queue Filter for github_queue_poll
+
+## Tradeoff Review
+
+**T1: `name?` stays alongside `queueLabel?`**
+- Acceptable. Load-time validation in `loadQueueConfig()` requires `queueLabel` when `type==='label'`. A user who writes `"name": "my-label"` in config.json gets an error at load time (queueLabel absent), not a silent failure.
+- Fails if: user somehow bypasses `loadQueueConfig()` and constructs `GitHubQueueConfig` directly with `name` but not `queueLabel`. Poller returns `not_implemented` (else branch). Acceptable - direct construction is a test-only pattern.
+
+**T2: `polling-scheduler.ts` guard remains blocking**
+- Acceptable within task scope. Unit tests validate at the poller level. End-to-end production use requires a follow-up PR to update the scheduler guard. Document in PR description.
+- Fails if: task author requires end-to-end production functionality. Risk level: medium for production, zero for acceptance criteria.
+
+**T3: Optional `queueLabel?` (not required at type level)**
+- Acceptable. Mitigated by load-time validation. The `pollGitHubQueueIssues` else branch returns `not_implemented` if `queueLabel` is absent, which is correct defensive behavior.
+
+## Failure Mode Review
+
+**FM1 (highest risk): Existing test at line 126 must be replaced**
+- Test currently expects `not_implemented` for `{type: 'label', name: 'my-label'}`.
+- After change: test will fail. Must replace with: (a) label success test, (b) label missing-queueLabel error test, (c) assignee regression test.
+- Mitigation: explicit action in implementation plan.
+
+**FM2: URL encoding**
+- Handled automatically by `URLSearchParams.set()` (established pattern in codebase).
+
+**FM3: GitHub API filter behavior**
+- Not our responsibility. Tests verify the URL contains the correct `labels=` param.
+
+**FM4: Scheduler guard**
+- Filed as known limitation (T2 above). Document in PR.
+
+## Runner-Up / Simpler Alternative Review
+
+- Discriminated union: more type-safe but requires files outside scope. Nothing worth borrowing.
+- Skipping trigger-store changes: fails acceptance criteria. Not viable.
+- Skipping types.ts extension: TypeScript would flag unused parsed values. Necessary.
+
+## Philosophy Alignment
+
+- Result types: satisfied throughout
+- Validate at boundaries: satisfied - `loadQueueConfig()` validates label requires `queueLabel`
+- Immutability: satisfied - all new fields are `readonly`
+- YAGNI: satisfied - no new abstractions
+- Make illegal states unrepresentable: partially satisfied (load-time, not compile-time). Accepted tension.
+
+## Findings
+
+**YELLOW - polling-scheduler.ts guard**: Feature works at unit test level but not in production. The scheduler guard at line 393 (`queueConfig.type !== 'assignee'`) will still block label-type configs. This is a known, accepted, out-of-scope issue. Document in PR.
+
+**YELLOW - test replacement**: The test at line 126 uses `{type: 'label', name: 'my-label'}` and expects `not_implemented`. This test MUST be replaced or it will fail after the change. High likelihood of causing CI failure if missed.
+
+No RED findings.
+
+## Recommended Revisions
+
+1. In implementation: replace test at line 126 with three new tests (label success, label missing queueLabel, assignee regression).
+2. In PR description: note that `polling-scheduler.ts` guard is a follow-up item.
+
+## Residual Concerns
+
+- `name?` field in `GitHubQueueConfig` is now superseded by `queueLabel?`. Future cleanup: remove `name?` and update any remaining references. Out of scope for this PR.
+- No other residual concerns.

package/docs/design/queue-label-support-implementation-plan.md

@@ -0,0 +1,158 @@
+# Implementation Plan: Label-Based Queue Filter for github_queue_poll
+
+## Problem Statement
+
+The `github_queue_poll` trigger supports `queueType: label` and `queueLabel: "worktrain:ready"` in `triggers.yml`, but these fields are silently ignored. The `GitHubQueueConfig` type supports `type: 'label'` but throws `not_implemented` at runtime. Label-based queue filtering lets WorkTrain pick up issues without a dedicated bot account -- any issue labeled `worktrain:ready` becomes a candidate.
+
+---
+
+## Acceptance Criteria
+
+1. `pollGitHubQueueIssues()` with `config.type === 'label'` and `config.queueLabel === 'worktrain:ready'` sends `GET /repos/:owner/:repo/issues?state=open&labels=worktrain%3Aready&per_page=100`
+2. `pollGitHubQueueIssues()` with `config.type === 'label'` and no `config.queueLabel` returns `err({ kind: 'not_implemented', ... })` (config validation error path)
+3. `pollGitHubQueueIssues()` with `config.type === 'assignee'` still works (regression)
+4. `loadQueueConfig()` with `type: 'label'` and no `queueLabel` field in config.json returns `err(...)` (not `ok`)
+5. `loadQueueConfig()` with `type: 'label'` and `queueLabel: 'worktrain:ready'` returns `ok(config)` with `config.queueLabel === 'worktrain:ready'`
+6. `trigger-store.ts` parses `queueType` and `queueLabel` from triggers.yml into `GitHubQueuePollingSource`
+7. `npm run build` succeeds (no TypeScript errors)
+8. `npx vitest run tests/unit/github-queue-poller.test.ts` -- all tests pass
+9. `npx vitest run` -- no regressions
+
+---
+
+## Non-Goals
+
+- Do not touch `src/mcp/`
+- Do not touch `polling-scheduler.ts`
+- Do not implement `mention` or `query` queue types
+- Do not refactor surrounding code
+- Do not remove the existing `name?` field from `GitHubQueueConfig`
+
+---
+
+## Philosophy-Driven Constraints
+
+- All boundary functions return `Result<T, E>` -- no throws
+- All new interface fields are `readonly`
+- Validation at load time (`loadQueueConfig`): err if `type==='label'` and `queueLabel` absent
+- Defensive else branch in `pollGitHubQueueIssues`: unknown types return `not_implemented`
+- `encodeURIComponent` / URLSearchParams for URL safety
+
+---
+
+## Invariants
+
+- I1: `pollGitHubQueueIssues` with `type='assignee'` and `config.user` sends `assignee=<user>` param (unchanged)
+- I2: `pollGitHubQueueIssues` with `type='label'` and `config.queueLabel` sends `labels=<encoded>` param
+- I3: `pollGitHubQueueIssues` with `type='label'` and no `config.queueLabel` returns `err({ kind: 'not_implemented' })`
+- I4: `pollGitHubQueueIssues` with any other type returns `err({ kind: 'not_implemented' })`
+- I5: `loadQueueConfig` with `type='label'` and no `queueLabel` key in config.json returns `err(string)`
+- I6: No throws at any boundary
+
+---
+
+## Selected Approach
+
+**Additive optional field + load-time validation + poller URL branch**
+
+Four changes:
+1. `GitHubQueueConfig` interface: add `readonly queueLabel?: string`
+2. `loadQueueConfig()`: parse `q['queueLabel']`, validate it when `type==='label'`
+3. `GitHubQueuePollingSource` (types.ts): add `readonly queueType?: string`, `readonly queueLabel?: string`
+4. `trigger-store.ts`: parse `queueType`/`queueLabel` in `ParsedTriggerRaw` + `setTriggerField()` + assembly block
+5. `pollGitHubQueueIssues()`: replace hard not_implemented guard with assignee/label/else branching
+
+Runner-up was discriminated union -- rejected due to scope constraint and unnecessary complexity for this bounded change.
+
+---
+
+## Vertical Slices
+
+### Slice 1: `github-queue-config.ts` -- add `queueLabel` field + validation
+**Files**: `src/trigger/github-queue-config.ts`
+**What**: Add `readonly queueLabel?: string` to `GitHubQueueConfig` interface. In `loadQueueConfig()`, parse `q['queueLabel']` and add validation: if `rawType === 'label'` and `!queueLabel`, return `err('config.queue.queueLabel is required when type is "label"')`. Build the return object with `queueLabel` when present.
+**Done when**: Interface has `queueLabel?`, validation fires correctly, `npm run build` clean.
+
+### Slice 2: `types.ts` -- extend `GitHubQueuePollingSource`
+**Files**: `src/trigger/types.ts`
+**What**: Add `readonly queueType?: string` and `readonly queueLabel?: string` to `GitHubQueuePollingSource`.
+**Done when**: Fields present in interface, build clean.
+
+### Slice 3: `trigger-store.ts` -- parse `queueType`/`queueLabel` from YAML
+**Files**: `src/trigger/trigger-store.ts`
+**What**: 
+- Add `queueType?: string` and `queueLabel?: string` to `ParsedTriggerRaw` interface
+- Handle them in `setTriggerField()` switch
+- In the `github_queue_poll` assembly block, read `raw.queueType` and `raw.queueLabel` and include them in the `GitHubQueuePollingSource` object
+**Done when**: `triggers.yml` `self-improvement` trigger parses correctly with these fields; build clean.
+
+### Slice 4: `github-queue-poller.ts` -- implement label branch
+**Files**: `src/trigger/adapters/github-queue-poller.ts`
+**What**: Replace the current `if (config.type !== 'assignee') return err(not_implemented)` guard with:
+```typescript
+if (config.type === 'assignee' && config.user) {
+  url.searchParams.set('assignee', config.user);
+} else if (config.type === 'label' && config.queueLabel) {
+  url.searchParams.set('labels', config.queueLabel);
+} else {
+  return err({ kind: 'not_implemented', message: `Queue type "${config.type}" is not yet implemented` });
+}
+```
+Remove the old `if (config.user)` block that was AFTER the guard.
+Update JSDoc to reflect both supported types.
+**Done when**: Function correctly handles both assignee and label, build clean.
+
+### Slice 5: Tests -- update + add new tests
+**Files**: `tests/unit/github-queue-poller.test.ts`
+**What**:
+- REPLACE existing test at line 126 (`returns not_implemented for non-assignee queue type`) -- this test currently expects not_implemented for `{type: 'label', name: 'my-label'}`. It MUST be replaced, not kept.
+- ADD: `type: 'label'` with `queueLabel: 'worktrain:ready'` -> fetches with `labels=worktrain%3Aready` param
+- ADD: `type: 'label'` without `queueLabel` -> returns err with kind not_implemented (or config validation path)
+- KEEP as regression: `type: 'assignee'` test at line 105 (already tests assignee param)
+- Update `makeConfig()` helper: `name?` field can stay but add examples with `queueLabel`
+**Done when**: `npx vitest run tests/unit/github-queue-poller.test.ts` all pass.
+
+---
+
+## Test Design
+
+| Test | Expected behavior | Assertion |
+|------|-------------------|-----------|
+| label type + queueLabel | fetches with `labels=` param | URL contains `labels=worktrain%3Aready` |
+| label type + no queueLabel | returns not_implemented | `result.error.kind === 'not_implemented'` |
+| assignee type + user (regression) | fetches with `assignee=` param | URL contains `assignee=bob` |
+
+Existing tests for network_error, http_error, rate_limit, field mapping, maturity, idempotency: unchanged.
+
+---
+
+## Risk Register
+
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| Forgetting to replace test at line 126 | High | CI fails | Explicit: replace that test first |
+| `polling-scheduler.ts` guard still blocks end-to-end | Certain | Production feature blocked | Document in PR description as follow-up |
+| URL encoding of `:` in `worktrain:ready` | Low | Wrong API call | Use `url.searchParams.set()` which encodes automatically |
+
+---
+
+## PR Packaging Strategy
+
+Single PR: `feat/queue-label-support`
+Commit: `feat(trigger): implement label-based queue filter for github_queue_poll`
+
+PR description should note: the `polling-scheduler.ts` guard at line 393 still checks `queueConfig.type !== 'assignee'` and will need a follow-up update for end-to-end production use. This PR implements the foundational layer.
+
+---
+
+## Philosophy Alignment Per Slice
+
+| Slice | Principle | Status |
+|-------|-----------|--------|
+| 1 (config) | validate-at-boundaries | satisfied: err if type=label and queueLabel absent |
+| 1 (config) | immutability by default | satisfied: readonly field |
+| 2 (types) | explicit domain types | satisfied: typed fields not raw strings |
+| 3 (trigger-store) | validate-at-boundaries | satisfied: queueType parsed and stored |
+| 4 (poller) | Result types, no throws | satisfied: err() return, no throw |
+| 4 (poller) | exhaustiveness | tension: else branch catches unknowns but not exhaustive switch |
+| 5 (tests) | prefer fakes over mocks | satisfied: injectable fetchFn mock |

package/docs/ideas/backlog.md

@@ -6395,3 +6395,163 @@ When a post-implementation MR review finds a UI/UX finding (wrong affordance, mi
 ### Priority
 
 Design this as part of the adaptive coordinator (#3). The `touchesUI` flag belongs on the classification output alongside `taskComplexity` and `maturity`. The UI detection logic and the design workflow insertion are both coordinator-level concerns, not engine-level.
+
+---
+
+## Current state update (Apr 20, 2026)
+
+**npm version: v3.45.0**
+
+### What shipped in this session (Apr 19-20, 2026)
+
+All five top-priority autonomous pipeline items shipped:
+
+- ✅ **#1 -- Worktree isolation + auto-commit** (PR #630) -- Each WorkTrain coding session now runs in an isolated git worktree (`~/.workrail/worktrees/<sessionId>`). `trigger.workspacePath` is never mutated; all tool factories receive `sessionWorkspacePath`. Crash recovery sidecar persists `worktreePath` for orphan cleanup. `delivery-action.ts` asserts HEAD branch before push. `test-task` trigger: `branchStrategy: worktree`, `autoCommit: true`, `autoOpenPR: true`.
+
+- ✅ **#2 -- Stuck detection escalation** (PR #636) -- New `WorkflowRunResult._tag: 'stuck'` discriminant. When `repeated_tool_call` heuristic fires and `stuckAbortPolicy !== 'notify_only'` (default: `'abort'`), daemon aborts the session immediately instead of burning the 30-min wall clock. Writes structured entry to `~/.workrail/outbox.jsonl`. `stuckAbortPolicy` and `noProgressAbortEnabled` configurable per trigger in `agentConfig`. `ChildWorkflowRunResult` updated atomically.
+
+- ✅ **#3 -- Adaptive pipeline coordinator** (PR #639) -- `worktrain run pipeline --issue N --workspace path` routes tasks to the right pipeline via pure static routing:
+  - dep-bump + PR number → QUICK_REVIEW (delegates to `runPrReviewCoordinator`)
+  - PR/MR number → REVIEW_ONLY
+  - `current-pitch.md` exists → IMPLEMENT (coding + PR + review + merge)
+  - Default → FULL (discovery → shaping → coding → PR → review → merge)
+  - Fix loop cap: 2 iterations max. Escalating audit chain for Critical findings. UX gate for UI-touching tasks. 6 hardcoded timeout constants. Pitch archived after IMPLEMENT/FULL completes.
+
+- ✅ **#4 -- GitHub issue queue poll trigger** (PR #637) -- New `github_queue_poll` trigger provider. Polls GitHub issues matching `GitHubQueueConfig` (assignee-based MVP, `label`/`mention`/`query` typed but `not_implemented`). Maturity inference from 3 deterministic heuristics. Idempotency check (conservative: parse errors = active). JSONL decision log at `~/.workrail/queue-poll.jsonl`. `maxTotalConcurrentSessions` cap. Bot identity config (`botName`, `botEmail`).
+
+- ✅ **#5 -- Context assembly layer** (PR #624, shipped earlier) -- `ContextAssembler` injects git diff summary + prior session notes before turn 1. Feeds into coordinator pre-dispatch.
+
+- ✅ **Performance sweep** (all 10 issues #248-257 -- already confirmed complete)
+- ✅ **Console session tree** (PR #607 -- parentSessionId rendered in UI)
+- ✅ **Daemon file-nav tools** (PR #619) -- Glob, Grep, Edit + upgraded Read/Write with staleness guard
+- ✅ **`spawn_agent` artifacts** (PR #613) -- `lastStepArtifacts` surfaced through spawn_agent return
+- ✅ **`wr.shaping` workflow** (PR #610) -- faithful Shape Up shaping, 9 steps
+- ✅ **Coding workflow Phase 0.5** (PR #610) -- upstream context detection, three-workflow pipeline
+
+### WorkTrain current capabilities (v3.45.0)
+
+**Autonomous workflow execution -- confirmed working:**
+- `worktrain run pipeline --issue N` routes to the right pipeline and runs it end-to-end
+- `worktrain run pr-review` autonomous PR review with structured verdicts and auto-merge
+- Coding sessions run in isolated worktrees, auto-commit, auto-open PR
+- Sessions abort when stuck (instead of burning 30-min wall clock)
+- GitHub issue queue polling: assign issue to `worktrain-etienneb` → daemon picks it up automatically
+- All sessions start with git diff + prior session notes injected (ContextAssembler)
+- Daemon file-nav tools: Glob, Grep, Edit, Read (paginated), Write (staleness guard)
+- Escalating audit chain: Critical findings → prod audit → re-review → escalate if still Critical
+- Fix loop: minor findings → max 2 fix iterations before escalation
+
+**WorkTrain agent tool set (v3.45.0):**
+`complete_step`, `continue_workflow` (deprecated), `Bash`, `Read`, `Write`, `Glob`, `Grep`, `Edit`, `report_issue`, `spawn_agent`, `signal_coordinator`
+
+**Trigger system:**
+- Generic webhook, GitLab MR polling, GitHub Issues polling, GitHub PR polling
+- **NEW: `github_queue_poll`** -- assignee-based issue queue with maturity inference
+- `branchStrategy: worktree` -- isolated worktree per session
+- `autoCommit: true` / `autoOpenPR: true` -- full delivery pipeline
+- `stuckAbortPolicy: 'abort' | 'notify_only'`
+- `goalTemplate`, `referenceUrls`, `contextMapping`, `agentConfig`
+
+### Accurate limitations (v3.45.0)
+
+1. **`dispatchAdaptivePipeline()` not yet connected** -- `TriggerRouter.dispatchAdaptivePipeline()` exists but `polling-scheduler.ts` still calls `router.dispatch()`. Queue poll sessions run as generic sessions, not routed through the adaptive coordinator. Cross-PR gap documented with TODO.
+
+2. **`findingCategory` not on review-verdict** -- Audit chain always dispatches `production-readiness-audit` for Critical findings regardless of finding type. `findingCategory` field on `findings[]` items needs to be added to `wr.review_verdict` schema as a follow-up so architecture findings can route to `architecture-scalability-audit` correctly.
+
+3. **Bot account setup required before first queue run** -- `worktrain-etienneb` GitHub account must be created, PAT generated with `repo:read` scope, stored as `WORKTRAIN_BOT_TOKEN`, and added as repo collaborator. Commit identity: `worktrain-etienneb@users.noreply.github.com`. Without this, `github_queue_poll` trigger has no bot identity.
+
+4. **No auto-merge setting in `worktrain init`** -- Auto-merge policy is hardcoded in the coordinator. Should be a `~/.workrail/config.json` setting exposed during `worktrain init`.
+
+5. **Grooming loop not built** -- Three open design decisions must be settled before building (human-ack boundary, compute budget, priority signal source). Deferred until Level 1 usage data exists.
+
+6. **Knowledge graph not wired** -- `src/knowledge-graph/` module exists (DuckDB + ts-morph), `ts-morph` in devDependencies. No daemon tool yet. Architecture decision: belongs in context assembly layer, not as a daemon tool.
+
+7. **`worktrain inbox --watch` stub** -- Prints "not yet implemented." The outbox mechanism exists; just needs a polling loop.
+
+8. **Artifact store not built** -- Agents dump markdown in the repo. `~/.workrail/artifacts/` not created.
+
+### Next priorities (groomed Apr 20)
+
+1. **Connect `dispatchAdaptivePipeline()`** -- Wire `polling-scheduler.ts` to call `TriggerRouter.dispatchAdaptivePipeline()` when `context.taskCandidate` is present. Small change, unlocks the full autonomous queue → pipeline connection.
+
+2. **`findingCategory` on review-verdict schema** -- Add `findingCategory: 'correctness' | 'security' | 'architecture' | 'ux' | 'performance' | 'testing'` to `findings[]` in `ReviewVerdictArtifactV1Schema`. Update `mr-review-workflow-agentic` final step to emit it. Unlocks correct audit routing.
+
+3. **Bot account setup + `worktrain init` overhaul** -- Create `worktrain-etienneb`, add `worktrain daemon --check` command (API key + git fetch dry run), expose auto-merge policy in `worktrain init`.
+
+4. **Level 1 usage: run WorkTrain on its own backlog** -- Create `worktrain:ready` issues for the top 10 ready tasks, assign to `worktrain-etienneb`, observe one full queue → pipeline run. Collect data on misclassifications and weak PRs before designing the grooming loop.
+
+5. **`worktrain inbox --watch`** -- Close the notification loop. Outbox exists, just needs the polling implementation.
+
+---
+
+## WorkTrain identity model: act as the user, not as a bot (Apr 20, 2026)
+
+**Design decision:** WorkTrain acts as the configured user, not as a separate bot account.
+
+### Why bot accounts are the wrong default
+
+Most developers -- especially at companies -- cannot create separate bot GitHub accounts. Jira, GitLab, and other enterprise systems tie authentication to employee identity. Requiring a separate account creates friction that blocks adoption entirely.
+
+WorkTrain's attribution signal is the **work pattern**, not the identity:
+- Branch name: `worktrain/<sessionId>` -- immediately recognizable
+- PR body footer: "🤖 Automated by WorkTrain" + session ID + workflow name
+- Commit co-author: `Co-Authored-By: WorkTrain <worktrain@noreply>`
+
+Anyone reviewing a PR knows it was autonomous. The developer's name on the PR is not a lie -- they configured WorkTrain to do this work on their behalf.
+
+### Queue membership without a bot account
+
+Assignee-based opt-in only works with a dedicated bot account. Label-based opt-in works with any setup:
+- Apply `worktrain:ready` label to an issue → WorkTrain picks it up
+- The queue poll trigger uses `queueType: label` + `queueLabel: "worktrain:ready"`
+- No bot account, no special permissions, no friction
+
+`workOnAll: true` (future) processes any open issue -- also requires no bot account.
+
+### Token: use your own PAT
+
+`$GITHUB_TOKEN` (your personal token) or a fine-grained PAT scoped to the target repo. WorkTrain uses it for API calls; the commit identity (`git user.name`, `git user.email`) is set separately in the worktree and can be whatever you want.
+
+---
+
+## Jira + GitLab integration for WorkTrain (Apr 20, 2026)
+
+**Context:** Most enterprise developers use Jira for tickets and GitLab for code hosting. WorkTrain should work in this environment without requiring GitHub or a bot account.
+
+### What exists
+
+`gitlab_poll` trigger already exists -- polls GitLab MR list and dispatches sessions when new/updated MRs appear. WorkTrain can already do autonomous MR review on GitLab.
+
+### What's missing
+
+**`jira_poll` trigger:** Poll a Jira board/sprint/filter for issues in a specific status (e.g., "In Progress", "Ready for Dev") assigned to the configured user, and dispatch WorkTrain sessions for them. The developer labels Jira issues for WorkTrain the same way they'd assign to a teammate.
+
+Proposed `jira_poll` config:
+```yaml
+- id: jira-queue
+  provider: jira_poll
+  jiraBaseUrl: https://zillow.atlassian.net
+  token: $JIRA_API_TOKEN
+  project: ACEI
+  statusFilter: "Ready for Dev"
+  assigneeFilter: "$JIRA_USERNAME"
+  workspacePath: /path/to/repo
+  branchStrategy: worktree
+  autoCommit: true
+  autoOpenPR: true
+  agentConfig:
+    maxSessionMinutes: 90
+```
+
+**GitLab issue queue:** Same as `github_queue_poll` but for GitLab issues. Dispatch coding sessions for GitLab issues labeled `worktrain` or in a specific milestone.
+
+### Implementation notes
+
+- `jira_poll` follows the same `PollingSource` discriminated union pattern as `gitlab_poll` and `github_queue_poll`
+- Jira REST API v3: `GET /rest/api/3/search?jql=project=X+AND+status="Ready for Dev"+AND+assignee=currentUser()`
+- Token: Jira API token (not OAuth -- simpler for developer tools)
+- `jira_poll` should extract issue title + description as the goal, and the Jira issue URL as `upstreamSpecUrl` in `TaskCandidate`
+
+### Priority
+
+Medium. GitLab MR review already works. Jira issue queue is the next most impactful integration for enterprise users. Design alongside the label-based GitHub queue -- the patterns are identical, just different API shapes.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@exaudeus/workrail",
-  "version": "3.45.0",
+  "version": "3.47.0",
   "description": "Step-by-step workflow enforcement for AI agents via MCP",
   "license": "MIT",
   "repository": {

package/workflows/mr-review-workflow.agentic.v2.json

@@ -312,7 +312,7 @@
     {
       "id": "phase-6-final-handoff",
       "title": "Phase 6: Final Handoff",
-      "prompt": "Provide the final MR review handoff.\n\nInclude:\n- MR title and purpose\n- review mode used\n- final recommendation and confidence band\n- confidence assessment summary, including the most important reason confidence was capped if it was not High\n- counts of Critical / Major / Minor / Nit findings\n- top findings with rationale\n- strongest remaining areas of uncertainty, if any\n- summary of the coverage ledger, especially any still-uncertain domains\n- ready-to-post MR comments summary\n- any validation outcomes a human reviewer should see\n- review environment status:\n  - what review target/context sources were successfully used\n  - what important sources were missing or ambiguous\n  - boundary confidence and context confidence\n  - how those limits affected the review\n- path to the full human-facing review artifact (`reviewDocPath`) only if one was created\n\nRules:\n- the final recommendation assists a human reviewer; it does not replace them\n- if `reviewDocPath` exists, treat it as a human-facing companion artifact only\n- be explicit when missing PR/ticket/doc/boundary context limited confidence\n- do not post comments, approve, reject, or merge unless the user explicitly asks\n\nIMPORTANT: After writing your notes, emit a structured verdict via complete_step's artifacts[] parameter using EXACTLY this schema (no extra fields):\n{\n  \"kind\": \"wr.review_verdict\",\n  \"verdict\": \"clean\" | \"minor\" | \"blocking\",\n  \"confidence\": \"high\" | \"medium\" | \"low\",\n  \"findings\": [ { \"severity\": \"critical\" | \"major\" | \"minor\" | \"nit\", \"summary\": \"one-line description\" } ],\n  \"summary\": \"one-line overall verdict summary\"\n}\nFor a clean review with no findings, use findings: []. The verdict field maps to severity: clean = no blocking issues, minor = small issues only, blocking = critical or major issues found.",
+      "prompt": "Provide the final MR review handoff.\n\nInclude:\n- MR title and purpose\n- review mode used\n- final recommendation and confidence band\n- confidence assessment summary, including the most important reason confidence was capped if it was not High\n- counts of Critical / Major / Minor / Nit findings\n- top findings with rationale\n- strongest remaining areas of uncertainty, if any\n- summary of the coverage ledger, especially any still-uncertain domains\n- ready-to-post MR comments summary\n- any validation outcomes a human reviewer should see\n- review environment status:\n  - what review target/context sources were successfully used\n  - what important sources were missing or ambiguous\n  - boundary confidence and context confidence\n  - how those limits affected the review\n- path to the full human-facing review artifact (`reviewDocPath`) only if one was created\n\nRules:\n- the final recommendation assists a human reviewer; it does not replace them\n- if `reviewDocPath` exists, treat it as a human-facing companion artifact only\n- be explicit when missing PR/ticket/doc/boundary context limited confidence\n- do not post comments, approve, reject, or merge unless the user explicitly asks\n\nIMPORTANT: After writing your notes, emit a structured verdict via complete_step's artifacts[] parameter using EXACTLY this schema (no extra fields):\n{\n  \"kind\": \"wr.review_verdict\",\n  \"verdict\": \"clean\" | \"minor\" | \"blocking\",\n  \"confidence\": \"high\" | \"medium\" | \"low\",\n  \"findings\": [ { \"severity\": \"critical\" | \"major\" | \"minor\" | \"nit\", \"summary\": \"one-line description\", \"findingCategory\": \"correctness\" | \"security\" | \"architecture\" | \"ux\" | \"performance\" | \"testing\" | \"style\" } ],\n  \"summary\": \"one-line overall verdict summary\"\n}\nFor a clean review with no findings, use findings: []. The verdict field maps to severity: clean = no blocking issues, minor = small issues only, blocking = critical or major issues found. For findingCategory use: correctness = wrong behavior/logic errors, security = auth/authz issues/injection/data exposure, architecture = wrong abstraction/tight coupling/invariant violations, ux = usability/accessibility/interaction design, performance = inefficiency/N+1/blocking operations, testing = missing tests/wrong test approach, style = naming/formatting/conventions.",
       "outputContract": {
         "contractRef": "wr.contracts.review_verdict",
         "required": false