@exaudeus/workrail 3.67.0 → 3.68.0

package/docs/discovery/workflow-selection-for-discovery-tasks.md

@@ -10,9 +10,9 @@
 
 ## Context / Ask
 
-A daemon session was dispatched using `coding-task-workflow-agentic` with a goal that said "Discovery only -- Do NOT write any code". The session ran 11 advances, produced good design candidate notes, stopped at event 74 with no `run_completed`, and the later advances had no note output (likely conditional skips).
+A daemon session was dispatched using `wr.coding-task` with a goal that said "Discovery only -- Do NOT write any code". The session ran 11 advances, produced good design candidate notes, stopped at event 74 with no `run_completed`, and the later advances had no note output (likely conditional skips).
 
-The question: for a discovery-only task (no code, just a design document), should we use `coding-task-workflow-agentic` or `wr.discovery`? And can `coding-task-workflow-agentic` be trusted to stay in discovery mode when the goal explicitly says no code?
+The question: for a discovery-only task (no code, just a design document), should we use `wr.coding-task` or `wr.discovery`? And can `wr.coding-task` be trusted to stay in discovery mode when the goal explicitly says no code?
 
 ---
 
@@ -42,11 +42,11 @@ The question: for a discovery-only task (no code, just a design document), shoul
 
 ### Current state summary
 
-`coding-task-workflow-agentic` (lean v2, v1.1.0) is a full implementation lifecycle workflow. Its `about` field says: "Use this to implement a software feature or task." Its preconditions include "A deterministic validation path exists (tests, build, or an explicit verification strategy)." It explicitly describes what it produces: `implementation_plan.md`, `spec.md`, code slices, and a PR-ready handoff with commit JSON.
+`wr.coding-task` (lean v2, v1.1.0) is a full implementation lifecycle workflow. Its `about` field says: "Use this to implement a software feature or task." Its preconditions include "A deterministic validation path exists (tests, build, or an explicit verification strategy)." It explicitly describes what it produces: `implementation_plan.md`, `spec.md`, code slices, and a PR-ready handoff with commit JSON.
 
 `wr.discovery` (v3.1.0) is a structured thinking/design workflow. Its `about` field says: "Use this to explore and think through a problem end-to-end." Its metaGuidance explicitly states: "Boundary: this workflow can end with a recommendation memo, prototype or test plan, or a research-informed direction. It should not implement production code."
 
-### Step structure analysis: coding-task-workflow-agentic
+### Step structure analysis: wr.coding-task
 
 | Step | Condition | Discovery-relevant? |
 |------|-----------|---------------------|
@@ -67,7 +67,7 @@ The question: for a discovery-only task (no code, just a design document), shoul
 
 For Medium/Large tasks, the workflow runs the full design pipeline (phases 0-4) which produces `design-candidates.md` -- but it then continues directly into implementation (phases 6-7). There is no early exit after design.
 
-**Does coding-task-workflow-agentic have a "discovery only" mode?** No. It has no `runCondition` or context variable that would stop before implementation when a goal says "no code". The only escape hatch would be the agent choosing to stop itself based on the goal text -- which is an honor-system trust, not a structural guarantee.
+**Does wr.coding-task have a "discovery only" mode?** No. It has no `runCondition` or context variable that would stop before implementation when a goal says "no code". The only escape hatch would be the agent choosing to stop itself based on the goal text -- which is an honor-system trust, not a structural guarantee.
 
 ### What phases run for Small vs Medium/Large
 
@@ -101,15 +101,15 @@ It explicitly cannot produce production code. It always ends with a design docum
 
 ### Option categories
 
-1. **Use wr.discovery** for discovery tasks, `coding-task-workflow-agentic` for implementation tasks
-2. **Use coding-task-workflow-agentic for everything**, trusting the agent to stop early when goal says "no code"
-3. **Add a discovery-mode flag** to `coding-task-workflow-agentic` via a `runCondition` on phases 6-7
+1. **Use wr.discovery** for discovery tasks, `wr.coding-task` for implementation tasks
+2. **Use wr.coding-task for everything**, trusting the agent to stop early when goal says "no code"
+3. **Add a discovery-mode flag** to `wr.coding-task` via a `runCondition` on phases 6-7
 4. **Use separate triggers** in triggers.yml with different `workflowId` per task type
 
 ### Contradictions / disagreements
 
-- The daemon session with `coding-task-workflow-agentic` produced "good design candidates notes" -- so the workflow does good design work even though it is intended for implementation. The design pipeline (phases 1-4) is legitimate and high quality.
-- The risk is not that `coding-task-workflow-agentic` does bad design work. The risk is that (a) it might not stop before phase-6 reliably, and (b) it carries implementation framing (slices, spec, PR handoff) that pollutes a pure discovery context.
+- The daemon session with `wr.coding-task` produced "good design candidates notes" -- so the workflow does good design work even though it is intended for implementation. The design pipeline (phases 1-4) is legitimate and high quality.
+- The risk is not that `wr.coding-task` does bad design work. The risk is that (a) it might not stop before phase-6 reliably, and (b) it carries implementation framing (slices, spec, PR handoff) that pollutes a pure discovery context.
 
 ### Evidence gaps
 
@@ -131,12 +131,12 @@ It explicitly cannot produce production code. It always ends with a design docum
 
 - Dispatch a session that produces a design document and nothing else
 - Know with certainty that no code will be written, regardless of agent judgment
-- Get a high-quality, structured design output comparable to what coding-task-workflow-agentic's design phases produce
+- Get a high-quality, structured design output comparable to what wr.coding-task's design phases produce
 
 ### Pains / tensions / constraints
 
 - The daemon currently has ONE `workflowId` in triggers.yml -- no per-task routing
-- `coding-task-workflow-agentic` is trusted for design quality but is not structurally bounded to stop before code
+- `wr.coding-task` is trusted for design quality but is not structurally bounded to stop before code
 - `wr.discovery` is structurally bounded to no-code but may produce different design output depth
 
 ### Success criteria
@@ -148,12 +148,12 @@ It explicitly cannot produce production code. It always ends with a design docum
 ### Assumptions
 
 - The daemon reads `workflowId` directly from triggers.yml and cannot dynamically select based on goal text
-- `wr.discovery` produces design candidates comparable in quality to what phases 1-4 of `coding-task-workflow-agentic` produce
+- `wr.discovery` produces design candidates comparable in quality to what phases 1-4 of `wr.coding-task` produce
 - triggers.yml supports multiple trigger entries with different `workflowId` values
 
 ### Reframes / HMW questions
 
-- HMW: How might we route discovery tasks to `wr.discovery` and implementation tasks to `coding-task-workflow-agentic` at the dispatcher level instead of relying on agent judgment?
+- HMW: How might we route discovery tasks to `wr.discovery` and implementation tasks to `wr.coding-task` at the dispatcher level instead of relying on agent judgment?
 - HMW: How might we make "discovery only" a structural guarantee rather than a goal-text instruction?
 
 ### What would make this framing wrong
@@ -183,15 +183,15 @@ Configure a second trigger entry in triggers.yml with `workflowId: wr.discovery`
 
 **Why it fits:** Structural guarantee. `wr.discovery` was explicitly designed for this use case. Its metaGuidance says "should not implement production code."
 
-**Strongest evidence for it:** The session incident shows the risk of relying on honor-system stop behavior in `coding-task-workflow-agentic`. Structural routing removes the risk entirely.
+**Strongest evidence for it:** The session incident shows the risk of relying on honor-system stop behavior in `wr.coding-task`. Structural routing removes the risk entirely.
 
-**Strongest risk against it:** triggers.yml currently supports one trigger per session. If it cannot support multiple triggers with per-task routing, this requires daemon work. Also, `wr.discovery` produces a recommendation memo/design doc, not the same `design-candidates.md` artifact shape that `coding-task-workflow-agentic` phases 1-4 produce.
+**Strongest risk against it:** triggers.yml currently supports one trigger per session. If it cannot support multiple triggers with per-task routing, this requires daemon work. Also, `wr.discovery` produces a recommendation memo/design doc, not the same `design-candidates.md` artifact shape that `wr.coding-task` phases 1-4 produce.
 
 **When it should win:** Always, for any task where the desired output is a design document and there is no intent to implement code in the same session.
 
 ---
 
-### Direction B: Trust coding-task-workflow-agentic with honor-system stop
+### Direction B: Trust wr.coding-task with honor-system stop
 
 Keep triggers.yml as-is. Rely on the goal text ("Discovery only -- Do NOT write any code") to instruct the agent to stop before phase-6.
 
@@ -205,27 +205,27 @@ Keep triggers.yml as-is. Rely on the goal text ("Discovery only -- Do NOT write
 
 ---
 
-### Direction C: Add discoveryMode flag to coding-task-workflow-agentic
+### Direction C: Add discoveryMode flag to wr.coding-task
 
-Modify `coding-task-workflow-agentic` to support a `discoveryMode` context variable. Add `runCondition: { var: "discoveryMode", not_equals: true }` to phases 6 and 7. Pass `discoveryMode: true` via the goal or a trigger-level context override.
+Modify `wr.coding-task` to support a `discoveryMode` context variable. Add `runCondition: { var: "discoveryMode", not_equals: true }` to phases 6 and 7. Pass `discoveryMode: true` via the goal or a trigger-level context override.
 
-**Why it fits:** Preserves the high-quality design pipeline of `coding-task-workflow-agentic` while adding a structural stop before implementation.
+**Why it fits:** Preserves the high-quality design pipeline of `wr.coding-task` while adding a structural stop before implementation.
 
-**Strongest evidence for it:** The design phases (1-4) of `coding-task-workflow-agentic` are well-designed and familiar. Reusing them avoids duplication.
+**Strongest evidence for it:** The design phases (1-4) of `wr.coding-task` are well-designed and familiar. Reusing them avoids duplication.
 
 **Strongest risk against it:** This requires modifying a core workflow file. It adds complexity to a workflow that was designed for a different purpose. It creates a hybrid that does neither thing cleanly. And triggers.yml still only has one trigger, so the `discoveryMode` value must come from somewhere (goal text parse? trigger-level context?).
 
-**When it should win:** If modifying `wr.discovery` or the daemon is unavailable, and modifying `coding-task-workflow-agentic` is cheap and acceptable.
+**When it should win:** If modifying `wr.discovery` or the daemon is unavailable, and modifying `wr.coding-task` is cheap and acceptable.
 
 ---
 
 ## Challenge Notes
 
-**Against Direction A (wr.discovery):** The design output format differs. `coding-task-workflow-agentic` produces `design-candidates.md` via the `tension-driven-design` routine, followed by a `design-review-findings.md` and a full `implementation_plan.md`. `wr.discovery` produces a design doc with Candidate Directions and a recommendation. For a technical question about workflow architecture, the `wr.discovery` output (a recommendation memo) is actually _more_ appropriate than `implementation_plan.md`. The format difference is not a disadvantage.
+**Against Direction A (wr.discovery):** The design output format differs. `wr.coding-task` produces `design-candidates.md` via the `tension-driven-design` routine, followed by a `design-review-findings.md` and a full `implementation_plan.md`. `wr.discovery` produces a design doc with Candidate Directions and a recommendation. For a technical question about workflow architecture, the `wr.discovery` output (a recommendation memo) is actually _more_ appropriate than `implementation_plan.md`. The format difference is not a disadvantage.
 
 **Against Direction B:** The incident already showed the risk. The session stopped at event 74 with no `run_completed`. We do not know if it stopped intentionally or by timeout/connection drop. If it stopped by timeout, the next session might not stop in the same place. Structural guarantees are always preferred over honor-system constraints when the downside (code written to a wrong branch) is recoverable but costly.
 
-**Against Direction C:** Modifying `coding-task-workflow-agentic` for a use case it was not designed for violates the "make illegal states unrepresentable" principle. It is better to use the right tool than to add a mode switch to the wrong tool.
+**Against Direction C:** Modifying `wr.coding-task` for a use case it was not designed for violates the "make illegal states unrepresentable" principle. It is better to use the right tool than to add a mode switch to the wrong tool.
 
 ---
 
@@ -256,7 +256,7 @@ Modify `coding-task-workflow-agentic` to support a `discoveryMode` context varia
 #### Recommendation
 
 For a discovery-only task (no code, just a design document):
-- **Use `wr.discovery`**, not `coding-task-workflow-agentic`
+- **Use `wr.discovery`**, not `wr.coding-task`
 - Add a second trigger entry to `triggers.yml` with a unique `id` and `workflowId: wr.discovery`
 - The daemon's trigger-store.ts and trigger-router.ts already support multiple triggers with different workflowIds -- no code change required
 
@@ -266,7 +266,7 @@ For a discovery-only task (no code, just a design document):
 triggers:
   - id: test-task
     provider: generic
-    workflowId: coding-task-workflow-agentic
+    workflowId: wr.coding-task
     workspacePath: /Users/etienneb/git/personal/workrail
     goal: "Add the evidenceFrom field to AssessmentDimension..."
     concurrencyMode: parallel
@@ -287,13 +287,13 @@ triggers:
 
 The caller must send the correct `triggerId` (`discovery-task` vs `test-task`) when firing the webhook.
 
-#### Why coding-task-workflow-agentic cannot be trusted in discovery mode
+#### Why wr.coding-task cannot be trusted in discovery mode
 
-`coding-task-workflow-agentic` has no structural stop before phase-6 (Implement Slice-by-Slice). For Small tasks, phase-5 (Small Task Fast Path) explicitly requires writing code. For Medium/Large tasks, the design pipeline (phases 0-4) produces good design work, then phase-6 writes code. The only protection against code-writing is the agent choosing to stop based on goal text -- an honor-system constraint that can fail under context window pressure.
+`wr.coding-task` has no structural stop before phase-6 (Implement Slice-by-Slice). For Small tasks, phase-5 (Small Task Fast Path) explicitly requires writing code. For Medium/Large tasks, the design pipeline (phases 0-4) produces good design work, then phase-6 writes code. The only protection against code-writing is the agent choosing to stop based on goal text -- an honor-system constraint that can fail under context window pressure.
 
 The prior session stopped at event 74 (likely after phase-4, before phase-6) -- but we cannot confirm whether this was agent judgment or a connection drop. With `wr.discovery`, the question is irrelevant: there are no phases 6-7 to reach.
 
-#### What phases coding-task-workflow-agentic skips for Small tasks
+#### What phases wr.coding-task skips for Small tasks
 
 - Skips: phase-1a (hypothesis), phase-1b (design), phase-1c (challenge), phase-2 (design review), phase-3 (plan), phase-3b (spec), phase-4 (plan audit), phase-6 (implementation), phase-7 (verification)
 - Runs: phase-0 (classify) and phase-5 (Small Task Fast Path -- **writes code**)
@@ -302,24 +302,24 @@ For Medium/Large tasks, all phases run in sequence, including phase-6 (implement
 
 #### Would wr.discovery have been a better choice?
 
-Yes, without qualification. `wr.discovery` was designed for exactly this use case. Its metaGuidance states: "should not implement production code." All paths end with a recommendation memo, prototype spec, or research plan. It uses the same `tension-driven-design` routine as `coding-task-workflow-agentic` phases 1b, so design quality is equivalent.
+Yes, without qualification. `wr.discovery` was designed for exactly this use case. Its metaGuidance states: "should not implement production code." All paths end with a recommendation memo, prototype spec, or research plan. It uses the same `tension-driven-design` routine as `wr.coding-task` phases 1b, so design quality is equivalent.
 
 #### How to configure triggers.yml for discovery vs implementation
 
-- **Implementation tasks**: `workflowId: coding-task-workflow-agentic` -- use the existing `test-task` trigger or rename it
+- **Implementation tasks**: `workflowId: wr.coding-task` -- use the existing `test-task` trigger or rename it
 - **Discovery tasks**: `workflowId: wr.discovery` -- add a new trigger entry (e.g., `id: discovery-task`)
 - Route by sending the correct `triggerId` in the webhook
 
 #### Workflow selection strategy when the daemon has ONE workflowId configured
 
-The current `test-task` trigger always dispatches to `coding-task-workflow-agentic`. For discovery tasks, either:
+The current `test-task` trigger always dispatches to `wr.coding-task`. For discovery tasks, either:
 1. Add a second trigger entry (preferred -- structural routing, zero code change)
 2. Temporarily change the trigger's `workflowId` to `wr.discovery` for discovery sessions, then change it back (workable but manual and error-prone)
 3. Use console AUTO dispatch and set `workflowId: wr.discovery` explicitly in the dispatch request (for console-dispatched sessions only)
 
 Option 1 is the right answer.
 
-### Strongest alternative: Direction C (add discoveryMode flag to coding-task-workflow-agentic)
+### Strongest alternative: Direction C (add discoveryMode flag to wr.coding-task)
 
 If the two-trigger routing were unavailable (it is not), adding `runCondition: { var: "discoveryMode", not_equals: true }` to phases 6-7 would also provide structural enforcement. Loses: workflow cleanliness, YAGNI compliance, reversibility. Not recommended when Direction A is available.
 

package/docs/discovery/worktrain-status-briefing.md

@@ -301,7 +301,7 @@ ACTIVE (2 sessions)
     Discovery: what data exists today that a 'worktrain status' plain-English briefing command could use
     Step: phase-3-synthesize   Running 22 min
   
-  ● coding-task-workflow-agentic
+  ● wr.coding-task
     Implement GitHub polling adapter for Issues/PRs without requiring webhooks
     Step: phase-2-implement   Running 8 min   ⚠ no activity for 18 min
 

package/docs/discovery/wr-discovery-goal-reframing.md

@@ -296,7 +296,7 @@ C2 is more structurally correct -- a mandatory separate step enforces that goal
 
 ### Next actions
 
-These findings are the input to Phase 2: the `workflow-for-workflows` workflow will design the implementation based on this diagnosis.
+These findings are the input to Phase 2: the `wr.workflow-for-workflows` workflow will design the implementation based on this diagnosis.
 
 1. The wfw workflow should receive: the full diagnosis (Phase 0 is the root cause), the specific changes needed (5 changes listed above), the priority order (Phase 0 goalType classification is highest priority), and the decision to implement the C1+C3 hybrid, not C2.
 2. After wfw produces the improved workflow, write it to `workflows/wr.discovery.json`.

package/docs/docker.md

@@ -70,7 +70,7 @@ echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | docker run -
 echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"workflow_list","arguments":{}}}' | docker run --rm -i workrail-mcp
 
 # Test getting a specific workflow
-echo '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"workflow_get","arguments":{"id":"coding-task-workflow-agentic","mode":"metadata"}}}' | docker run --rm -i workrail-mcp
+echo '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"workflow_get","arguments":{"id":"wr.coding-task","mode":"metadata"}}}' | docker run --rm -i workrail-mcp
 ```
 
 ## Custom Workflows

package/docs/ideas/backlog.md

@@ -7577,3 +7577,230 @@ Discovery session `ecf359d7` running: 77 turns, 11 step advances (active, making
 **Priority:** High. Every daemon crash currently wastes all in-flight work and waits up to 56 min before retrying. With even basic resume (step > 0 → resume, step = 0 → discard + fast re-dispatch), we'd recover most of the lost work and reduce retry latency from 56 min to < 5 min.
 
 **Depends on:** Conversation history persistence (for high-quality resume context).
+
+---
+
+## Current state update (Apr 23, 2026)
+
+**npm version: v3.66.0** | Daemon: stopped (intentionally, undergoing MCP reconnect) | MCP: reconnecting to updated binary
+
+---
+
+### What shipped in this session (Apr 22-23, 2026)
+
+This was a major session covering daemon/console separation, metrics infrastructure, and workflow stability fixes.
+
+**Architecture -- daemon/console/MCP separation:**
+- ✅ **Delete daemon-console.ts** (#753) -- daemon no longer bundles an embedded console; `worktrain console` is now the sole console entry point
+- ✅ **Remove dead steer/poll endpoints** (#755) -- deleted `worktrain trigger poll` CLI and the steer/poll HTTP endpoints that were only used by the deleted daemon-console
+- ✅ **Wire workflow catalog into standalone console** (#783, open) -- `worktrain console` Workflows tab now works without the MCP server running; `EnhancedMultiSourceWorkflowStorage` constructed directly in `standalone-console.ts`
+
+**Metrics infrastructure (6-step sequence, all merged):**
+- ✅ **timestampMs on events** (#768, #772) -- `DomainEventEnvelopeV1Schema` now has required `timestampMs`; backfill script at `scripts/backfill-timestamps.ts`
+- ✅ **`run_completed` event** (#773) -- emitted on successful session completion with `startGitSha`, `endGitSha`, `agentCommitShas`, `captureConfidence`, `durationMs`
+- ✅ **Authoring docs: metrics_* keys** (#767) -- `metricsProfile` field and SHA accumulation convention documented in `docs/authoring-v2.md`
+- ✅ **`projectSessionMetricsV2` projection** (#771) -- pure projection reading `run_completed` + `context_set metrics_*` keys, wired into `ConsoleSessionSummary`
+- ✅ **Console metrics display** (#777) -- `SessionMetricsSection` in session detail view; `GET /api/v2/sessions/:id/diff-summary` endpoint
+- ✅ **`stats-summary.json` writer** (#769) -- `~/.workrail/data/stats-summary.json` aggregated from `execution-stats.jsonl`, written post-session and every 30s heartbeat
+
+**Engine improvements:**
+- ✅ **Execution time tracking** (#756) -- `execution-stats.jsonl` per session in finally block
+- ✅ **Worktree orphan leak fix** (#756) -- sidecar deletion deferred to `maybeRunDelivery()` for worktree sessions
+- ✅ **assertNever for ReviewSeverity** (#756)
+- ✅ **Crash recovery phase A** (#759) -- `clearQueueIssueSidecars()` fixes 56-min re-dispatch block; sidecar preservation for sessions with progress
+- ✅ **Conversation history persistence** (#762) -- `<sessionId>-conversation.jsonl` per daemon session, append-only delta flush at each turn
+- ✅ **queue-poll.jsonl rotation** (#761) -- 10 MB size cap with `.1` backup
+- ✅ **Remove WorkTrain-owned label writes** (#765) -- `worktrain:in-progress`, `worktrain:generated` labels removed; deduplication now purely internal (sidecar + dispatchingIssues + session scan)
+- ✅ **metricsProfile footer injection** (#779) -- engine injects `metrics_*` accumulation footers based on `metricsProfile` workflow field; all 35 bundled workflows assigned profiles
+
+**Workflow namespace:**
+- ✅ **Rename all bundled workflows to `wr.*`** (#782, open) -- `coding-task-workflow-agentic` → `wr.coding-task`, `mr-review-workflow-agentic` → `wr.mr-review`, etc. Prevents local project source from shadowing bundled workflows on version mismatch.
+
+---
+
+### Open PRs (waiting for WorkRail MCP review before merge)
+
+| PR | Title | Status |
+|---|---|---|
+| #782 | Rename all bundled workflows to `wr.*` namespace | CI passing, needs `wr.mr-review` |
+| #783 | Wire workflow catalog into standalone console | CI pending, needs `wr.mr-review` |
+
+**Do not merge #782 or #783 without running `wr.mr-review` on each.** The MCP needs to reconnect to the updated 3.66.0 binary first.
+
+---
+
+### Active bugs (investigated, not yet fixed)
+
+1. **`additionalProperties: false` not enforced in Ajv** -- `src/application/validation.ts` uses `strict: false`, making schema's `additionalProperties` advisory only. A workflow with an unknown field passes `validate:registry`. Discovery+shaping in progress (agent running). **High priority -- fix before next release.**
+
+2. **`wr.mr-review` NOT_FOUND from MCP** -- `list_workflows` finds it but `start_workflow` returns NOT_FOUND. Root cause: MCP process is still running old 3.60.0 binary (global npm was stale). Fixed by `npm update -g @exaudeus/workrail` (done). Requires MCP reconnect to take effect.
+
+3. **User's `wr.discovery` VALIDATION_ERROR** -- stale `npx` cache pre-3.11.2. Fix: `npm cache clean --force && npx @exaudeus/workrail`. No code change needed.
+
+---
+
+### Known gaps (not yet started)
+
+- **Phase B crash recovery** -- actual agent loop restart after crash (not just sidecar preservation). Blocked on conversation history being tested end-to-end. See "Autonomous crash recovery" entry above.
+- **`workrail cleanup` command** -- removes dead managed sources, old sessions. Still needed.
+- **console-routes.ts dispatch coupling** -- `POST /api/v2/auto/dispatch` still imports `runWorkflow` from `src/daemon/`. See backlog entry.
+- **`wr.*` list/get inconsistency** -- user-source `wr.*` copies appear in list but execution uses bundled. Low priority.
+
+---
+
+### Current system state (for next engineer picking this up)
+
+**Daemon:** Stopped intentionally. Unload: `launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/io.worktrain.daemon.plist`
+**To restart daemon:** `launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/io.worktrain.daemon.plist`
+**MCP server:** Reconnecting -- run `/mcp` in Claude Code to get fresh 3.66.0 process
+**Global npm:** Updated to 3.66.0 (`npm update -g @exaudeus/workrail`)
+**Local build:** Built from main at 3.66.0 (`npm run build` done)
+**triggers.yml:** Must update `workflowId` values to new `wr.*` IDs after #782 merges (e.g. `coding-task-workflow-agentic` → `wr.coding-task`)
+
+**Immediate next actions:**
+1. Reconnect MCP (`/mcp` in Claude Code)
+2. Run `wr.mr-review` on PR #782 (rename) and PR #783 (console fix)
+3. Merge both PRs
+4. Wait for validation fix shaping to complete, then code and ship it
+5. Update `triggers.yml` with new `wr.*` workflow IDs
+6. Restart daemon and monitor first pipeline run with new IDs
+
+---
+
+## Daemon agent loop stall detection (Apr 23, 2026)
+
+**The problem:** When a subagent (workrail-executor) stalls with no progress for 600s, the stream watchdog kills it with "Agent stalled: no progress for 600s (stream watchdog did not recover)". The daemon has no equivalent mechanism. A daemon session that stops making LLM API calls (e.g. waiting on a hung tool, a network issue with no timeout, or a silent deadlock) will spin until the wall-clock timeout fires -- which can be up to 55-65 minutes. No indication to the operator, no early abort, no event emitted.
+
+**What we want:** The daemon's `AgentLoop` should detect when no LLM turn starts within a configurable window (e.g. 120s) and abort the session with a `'stuck'` result. This is different from the existing `repeated_tool_call` / `no_progress` stuck detection, which watches for behavioral loops. This is a liveness check: if the loop simply isn't making any API calls at all, something is frozen.
+
+**Design sketch:**
+- In `src/daemon/agent-loop.ts`, add a per-turn heartbeat timer that resets each time an LLM call starts
+- If the timer fires (120s with no new turn), call `agent.abort()` and emit `agent_stuck` with `reason: 'no_llm_turn'`
+- Configurable via `agentConfig.stallTimeoutSeconds` in `triggers.yml` (default 120s)
+- Distinct from wall-clock timeout (`maxSessionMinutes`) which covers the full session
+
+**Where to look:**
+- `src/daemon/agent-loop.ts` -- `_runLoop()`, where LLM calls are made
+- `src/daemon/workflow-runner.ts` -- existing stuck detection and abort logic
+- `src/daemon/daemon-events.ts` -- `AgentStuckEvent` already has `reason` union (add `'no_llm_turn'`)
+
+**Priority:** Medium. The wall-clock timeout provides a safety net, but 55 minutes is a long time to wait for a frozen session. A 2-minute liveness check would dramatically improve operator experience.
+
+---
+
+## Versioned workflow schema validation (Apr 23, 2026)
+
+### The problem
+
+WorkRail validates workflow files against the schema bundled in the currently-running MCP binary. This creates a bidirectional version mismatch problem:
+
+**New binary, old workflow:** Binary's schema has tightened validation (new required field, removed enum value) → old workflow fails → silently dropped from registry.
+
+**Old binary, new workflow:** Workflow has new fields the old schema doesn't know about → `additionalProperties: false` rejects it → silently dropped from registry.
+
+Both directions cause the same symptom: workflow disappears from `list_workflows` with no explanation. This is what we hit Apr 22-23: local `workflows/` directory (v3.66.0 with `metricsProfile`) was loaded by an old global npm binary (v3.60.0) whose schema didn't know `metricsProfile`, causing the entire registry to appear empty.
+
+The `wr.*` rename solves the specific case of bundled workflows being shadowed by local project files. But the version mismatch problem affects any non-bundled workflow (user, managed source, project) when the binary and the workflow file are at different schema versions.
+
+### The right long-term fix: versioned schema validation (like Android Room migrations)
+
+**Model:** Each workflow declares `"schemaVersion": 2` (integer). The binary ships validator copies for every schema version it supports. When loading a workflow, pick the validator matching the declared version -- not the current one.
+
+```json
+{ "schemaVersion": 2, "id": "my-workflow", ... }
+```
+
+**Load-time logic:**
+1. Read `schemaVersion` from the workflow file (default to 1 if absent -- legacy workflows)
+2. If `schemaVersion === current`: validate against current schema directly
+3. If `schemaVersion < current` (binary newer): validate against the declared schema version (workflow is valid for its era)
+4. If `schemaVersion > current` (binary too old): load leniently with warnings -- binary doesn't know this schema version, so `additionalProperties: false` doesn't apply
+
+This gives you full schema freedom going forward. You can add required fields, tighten enums, rename things -- without breaking workflows written for older schema versions.
+
+### Why NOT migrations (yet)
+
+A migration chain (v1→v2→v3 transform functions like Room) is the logical extension but adds complexity:
+- Migration functions on JSON documents with free-form prose are harder to write correctly than SQL schema migrations
+- The forward direction (binary too old for workflow) can't be migrated -- you'd have to downgrade the workflow, which is lossy
+- Requires process discipline: every schema change must increment the version AND write a migration. Easy to forget.
+- Migration chain length grows over time -- a v1 workflow loading against a v10 binary runs 9 migrations
+
+**Recommended phased approach:**
+- **Phase 1 (ship first):** Schema version dispatch without migrations. Keep old schema files (`spec/workflow.schema.v1.json`, `v2.json`, etc.). Validate each workflow against its declared version. No migration functions yet. Simple, no bugs, covers the backward direction.
+- **Phase 2 (add when needed):** Add migration functions when you actually need to make a breaking schema change that would invalidate old workflows. Not before.
+
+### Gaps and known issues with this approach
+
+1. **Forward direction still requires leniency.** When a workflow declares `schemaVersion: 5` and the binary only knows up to `schemaVersion: 4`, the only option is lenient loading with warnings. This is the `additionalProperties: true` approach, scoped to the mismatch case. This is acceptable -- if the binary is too old, it can still try to run the workflow with unknown fields ignored.
+
+2. **Schema version vs. authoring spec version.** WorkRail already has `validatedAgainstSpecVersion` on workflows (authoring spec -- style/quality). `schemaVersion` is separate (structural validity). Two version numbers with similar names need clear documentation.
+
+3. **External author burden.** When a new schema version ships, teams using managed sources need to know what changed and whether their workflows need updating. A changelog per schema version is required.
+
+4. **Default for legacy workflows.** Workflows without `schemaVersion` should default to `1` (oldest supported), not current. This means they get validated against the oldest schema -- which is lenient and permissive -- rather than the current strict one. Acceptable tradeoff.
+
+5. **`workflow-for-workflows` should stamp `schemaVersion`.** When authoring or modernizing a workflow, `wfw` should set `schemaVersion` to the current version automatically. This keeps the version accurate without requiring manual maintenance.
+
+### What's already in place
+
+- `validatedAgainstSpecVersion` field exists on workflows (authoring spec version, different concept)
+- `workflow.schema.json` has a `$id` with a version string (`v0.3.0`) but it's decorative -- not used at runtime
+- Validation warnings in `list_workflows` (PR #787) give users visibility when their workflow is silently dropped -- this is the interim fix until versioned validation ships
+
+### Files to change (Phase 1)
+
+- `spec/workflow.schema.json` -- add `schemaVersion` as an optional integer field (default 1 if absent)
+- `spec/workflow.schema.v1.json` -- snapshot of the current schema as "v1" (baseline)
+- `src/application/validation.ts` -- version dispatch: load the right schema based on `schemaVersion`
+- `src/types/workflow-definition.ts` -- add `readonly schemaVersion?: number` to `WorkflowDefinition`
+- `workflow-for-workflows.json` -- add step that stamps `schemaVersion` on the authored workflow
+- All bundled workflows -- add `"schemaVersion": 1` (once Phase 1 ships, bump to whatever the current version is)
+
+### Priority
+
+Medium-High. The `wr.*` rename (PR #782) is the immediate fix. This is the permanent architectural solution that prevents the problem for all workflow sources, not just bundled ones. Should ship after the rename stabilizes.
+
+**Implementation note (Apr 23):** Start with v1 = current schema. A git history audit is running to check whether any breaking changes have already been shipped. If none found: all existing workflows are valid against the current schema, v1 = today, no reconstruction needed. If breaking changes are found: snapshot the pre-break schema as v1, declare current as v2 (or higher), and existing workflows without `schemaVersion` default to v1. **Do not ship schema versioning until the audit completes and this determination is made.**
+
+**Audit result (Apr 23):** Exactly one breaking change found -- commit `b3212b45` (Apr 5, 2026) restructured `assessmentConsequenceTrigger` (`dimensionId`/`equalsLevel` → `anyEqualsLevel`). This affected only the `assessmentConsequences` feature which was introduced 4 days earlier (Apr 1). The bundled workflows that used it were migrated atomically in the same commit. No external workflows could have adopted this feature in that 4-day window. All other 14 schema changes in history are additive or loosening -- fully backward compatible.
+
+**Decision: v1 = current schema. No historical reconstruction needed.** The one breaking change was fully contained within the bundled workflow corpus at the time it shipped.
+
+---
+
+## Consider rewriting WorkRail engine in Kotlin (Apr 23, 2026)
+
+### The argument
+
+WorkRail's coding philosophy demands "make illegal states unrepresentable" and "type safety as the first line of defense." TypeScript is structurally at odds with this: the compiler is advisory, not enforcing. `as unknown as`, `any`, and type assertion casts are always one line away. In a codebase where autonomous agents write and merge code without deep human review, the compiler is the reviewer -- and TypeScript's escape hatches make it too easy for an agent to paper over a real design problem with a cast.
+
+Evidence from today's work: the `RunCompletedDataExpected` intermediate interface and the `as unknown as` cast in `session-metrics.ts` both existed for weeks. TypeScript didn't prevent them. A stricter compiler -- one where bypass requires genuine effort -- raises the bar the agent has to clear before code is valid.
+
+### What Kotlin actually buys
+
+- **Sealed classes** -- exhaustive `when` is a compile error, not a runtime `assertNever` pattern that convention must enforce
+- **No easy escape hatch** -- `as` in Kotlin throws at runtime on type mismatch; there's no equivalent of `as unknown as` that silently lies to the compiler
+- **Null safety by default** -- `String` vs `String?` is a language distinction, not a `strict: true` compiler flag that can be turned off
+- **Value classes and data classes** -- less boilerplate for domain types, stronger invariants
+
+### What TypeScript + current tooling already covers
+
+- Zod at boundaries provides runtime validation that Kotlin's type system would provide at compile time -- this gap is smaller than it looks
+- `neverthrow` gives Result types
+- Discriminated unions + `assertNever` give exhaustiveness -- but enforced by convention, not the compiler
+
+### Real costs
+
+- JVM startup latency for an MCP server that starts/stops frequently -- mitigable with GraalVM native image, but adds build complexity
+- Full rewrite of `src/` -- months of work, not weeks
+- Console stays TypeScript/React regardless
+- The Kotlin MCP SDK exists but the ecosystem tooling (npm, Node.js file I/O patterns) needs reimplementation
+
+### The honest tradeoff
+
+Convention drift is a recurring tax. Migration is a one-time cost. In a codebase driven heavily by autonomous agents, the compiler is the last line of defense against accumulated drift. TypeScript's permissiveness means that defense has holes.
+
+This is not urgent -- the current codebase is working well. But if autonomous agent usage grows and human review per-PR decreases further, the compiler enforcement gap becomes more important, not less.
+
+**Priority:** Low / long-term. Worth revisiting when the agent is writing the majority of new code. Requires a concrete spike: rewrite one module (e.g. `src/v2/durable-core/domain/`) in Kotlin and measure the real friction before committing to a full migration.

package/docs/ideas/third-party-workflow-setup-design-thinking.md

@@ -1460,7 +1460,7 @@
 Available Workflows
 
 ## workrail (built-in)
-- coding-task-workflow-agentic
+- wr.coding-task
 
 ## personal/workrail (repo root)
 - team-code-review

package/docs/integrations/claude-code.md

@@ -144,7 +144,7 @@ agent = Agent(
     subagent_type="workrail-executor",
     description="Execute context gathering",
     prompt="""
-    Start the routine-context-gathering workflow.
+    Start the wr.routine-context-gathering workflow.
 
     Workspace: /path/to/project
     Focus: COMPLETENESS
@@ -156,7 +156,7 @@ agent = Agent(
 Or from the main agent in Claude Code:
 
 ```
-Please use the workrail-executor agent to run the bug-investigation-agentic workflow
+Please use the workrail-executor agent to run the wr.bug-investigation workflow
 ```
 
 ---
@@ -273,15 +273,15 @@ Later repositories override earlier ones with the same workflow ID.
 ### Running a workflow directly
 
 ```
-> Use the bug-investigation-agentic workflow to investigate the cache expiration issue
+> Use the wr.bug-investigation workflow to investigate the cache expiration issue
 ```
 
 ### Delegating to workrail-executor
 
 ```
 > Spawn two workrail-executor agents in parallel:
-> 1. One running routine-context-gathering with focus=COMPLETENESS
-> 2. One running routine-context-gathering with focus=DEPTH
+> 1. One running wr.routine-context-gathering with focus=COMPLETENESS
+> 2. One running wr.routine-context-gathering with focus=DEPTH
 ```
 
 ### Resuming a checkpointed workflow

package/docs/integrations/firebender.md

@@ -101,7 +101,7 @@ Run the diagnostic workflow to test your configuration:
 
 ```bash
 # In Firebender, ask the main agent:
-"Run the workflow-diagnose-environment workflow"
+"Run the wr.diagnose-environment workflow"
 ```
 
 This will:

package/docs/plans/agentic-orchestration-roadmap.md

@@ -22,7 +22,7 @@ The rollout is structured in **3 Phased Tiers**, gated by feature flags, ensurin
     *   Creation of `bug-investigation.agentic.json` with manual delegation instructions.
     *   Implementation of the "Delegate or Proxy" prompt pattern directly in the JSON.
 3.  **The Diagnostic Suite:**
-    *   `workflow-diagnose-environment.json`: Agent-driven wizard to probe capabilities and generate config.
+    *   `wr.diagnose-environment.json`: Agent-driven wizard to probe capabilities and generate config.
     *   `docs/integrations/firebender.md`: Documentation on tool whitelisting constraints.
 
 **User Experience:**
@@ -83,7 +83,7 @@ The rollout is structured in **3 Phased Tiers**, gated by feature flags, ensurin
 **Why it matters:**
 *   Keeps the primary step prompt user-voiced while still allowing start/resume-only guidance.
 *   Makes current runtime-owned supplement behavior explicit and eventually authorable.
-*   Gives workflow-for-workflows and future linting a real schema surface instead of relying on hidden server policy.
+*   Gives wr.workflow-for-workflows and future linting a real schema surface instead of relying on hidden server policy.
 
 **Constraints:**
 *   Should be a **narrow, typed feature**, not arbitrary extra prompt sludge.

package/docs/plans/mr-review-workflow-redesign.md

@@ -299,11 +299,11 @@ The redesign currently references a few routines conceptually, but it should mak
 
 High-value candidates include:
 
-- `routine-context-gathering`
-- `routine-hypothesis-challenge`
-- `routine-execution-simulation`
-- `routine-philosophy-alignment`
-- `routine-final-verification`
+- `wr.routine-context-gathering`
+- `wr.routine-hypothesis-challenge`
+- `wr.routine-execution-simulation`
+- `wr.routine-philosophy-alignment`
+- `wr.routine-final-verification`
 
 These should be treated as current reusable building blocks, not future ideas.
 
@@ -786,9 +786,9 @@ The workflow should further strengthen:
 
 This phase should explicitly consider use of:
 
-- `routine-hypothesis-challenge` for adversarial reviewer challenge
-- `routine-execution-simulation` when runtime behavior or branch-sensitive behavior is material
-- `routine-philosophy-alignment` when policy-context is important enough to affect recommendation quality
+- `wr.routine-hypothesis-challenge` for adversarial reviewer challenge
+- `wr.routine-execution-simulation` when runtime behavior or branch-sensitive behavior is material
+- `wr.routine-philosophy-alignment` when policy-context is important enough to affect recommendation quality
 
 ## Phase 4: Contradiction, Gap, and Boundary Resolution Loop
 
@@ -822,7 +822,7 @@ The current final validation idea remains useful, but it should explicitly valid
 
 Final validation should also ensure the handoff reflects uncertainty honestly instead of over-stating confidence.
 
-The current WorkRail routine catalog suggests the redesign should strongly consider `routine-final-verification` as either:
+The current WorkRail routine catalog suggests the redesign should strongly consider `wr.routine-final-verification` as either:
 
 - a delegated verifier
 - an injected routine template

package/docs/plans/ui-ux-workflow-design-candidates.md

@@ -58,7 +58,7 @@
 - **Tensions resolved**: all 6 failure categories; forces alternatives at hypothesis stage; evidence-based per-dimension findings
 - **Tensions accepted**: inherent visual limitations; spec not mockup
 - **Failure mode**: reviewer families produce generic UX advice not tied to actual design context
-- **Repo pattern**: directly adapts `production-readiness-audit.json` structure; auditComplexity branching from `adaptive-ticket-creation.json`
+- **Repo pattern**: directly adapts `wr.production-readiness-audit.json` structure; auditComplexity branching from `wr.adaptive-ticket-creation.json`
 - **Gains**: comprehensive, structured freedom, all failure categories covered
 - **Losses**: heavier than minimal for simple tasks (mitigated by Simple fast path)
 - **Scope**: best-fit for feature-level and screen-level design work
@@ -73,7 +73,7 @@
 - **Tensions resolved**: single-solution anchoring; forces genuine exploration
 - **Tensions accepted**: UX laws/accessibility not explicitly enforced
 - **Failure mode**: 3 directions are superficially different (same IA, different metaphors)
-- **Repo pattern**: adapts `architecture-scalability-audit.json` dimension-declaration
+- **Repo pattern**: adapts `wr.architecture-scalability-audit.json` dimension-declaration
 - **Gains**: best for exploring solution space; documents tradeoffs
 - **Losses**: lighter on UX law enforcement; accessibility second-class
 - **Scope**: best as a mechanism within B rather than a standalone workflow
@@ -90,11 +90,11 @@
 - **Tensions resolved**: turns agent UX knowledge into structured application; fully evidence-based
 - **Tensions accepted**: doesn't help with design-from-scratch; requires existing design as input
 - **Failure mode**: agent audits what's in the spec but misses implicit design assumptions not stated
-- **Repo pattern**: directly adapts `architecture-scalability-audit.json`
+- **Repo pattern**: directly adapts `wr.architecture-scalability-audit.json`
 - **Gains**: actionable per-dimension findings with references; complements B
 - **Losses**: review only, not creation
 - **Scope**: best-fit as standalone for design review; or used after B to audit the output
-- **Philosophy**: all principles satisfied; mirrors architecture-scalability-audit exactly
+- **Philosophy**: all principles satisfied; mirrors wr.architecture-scalability-audit exactly
 
 ## Comparison and Recommendation