@exaudeus/workrail 3.45.0 → 3.47.0

package/dist/v2/durable-core/schemas/artifacts/review-verdict.js

@@ -14,6 +14,18 @@ exports.ReviewVerdictArtifactV1Schema = zod_1.z
         .object({
         severity: zod_1.z.enum(['critical', 'major', 'minor', 'nit']),
         summary: zod_1.z.string().min(1),
+        findingCategory: zod_1.z
+            .enum([
+            'correctness',
+            'security',
+            'architecture',
+            'ux',
+            'performance',
+            'testing',
+            'style',
+        ])
+            .optional()
+            .describe('Category of the finding. Used by coordinators to route audit chains.'),
     })
         .strict()),
     summary: zod_1.z.string().min(1),

package/dist/v2/durable-core/schemas/compiled-workflow/index.d.ts

@@ -22,8 +22,8 @@ export declare const CompiledWorkflowSnapshotV1Schema: z.ZodDiscriminatedUnion<"
 }, "strip", z.ZodTypeAny, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_preview";
     preview: {
@@ -34,8 +34,8 @@ export declare const CompiledWorkflowSnapshotV1Schema: z.ZodDiscriminatedUnion<"
 }, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_preview";
     preview: {
@@ -132,8 +132,8 @@ export declare const CompiledWorkflowSnapshotV1Schema: z.ZodDiscriminatedUnion<"
 }, "strip", z.ZodTypeAny, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_pinned";
     definition?: unknown;
@@ -168,8 +168,8 @@ export declare const CompiledWorkflowSnapshotV1Schema: z.ZodDiscriminatedUnion<"
 }, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_pinned";
     definition?: unknown;
@@ -226,8 +226,8 @@ export declare const CompiledWorkflowSnapshotSchema: z.ZodDiscriminatedUnion<"so
 }, "strip", z.ZodTypeAny, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_preview";
     preview: {
@@ -238,8 +238,8 @@ export declare const CompiledWorkflowSnapshotSchema: z.ZodDiscriminatedUnion<"so
 }, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_preview";
     preview: {
@@ -336,8 +336,8 @@ export declare const CompiledWorkflowSnapshotSchema: z.ZodDiscriminatedUnion<"so
 }, "strip", z.ZodTypeAny, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_pinned";
     definition?: unknown;
@@ -372,8 +372,8 @@ export declare const CompiledWorkflowSnapshotSchema: z.ZodDiscriminatedUnion<"so
 }, {
     workflowId: string;
     name: string;
-    description: string;
     version: string;
+    description: string;
     schemaVersion: 1;
     sourceKind: "v1_pinned";
     definition?: unknown;

package/docs/design/connect-adaptive-dispatch-candidates.md

@@ -0,0 +1,153 @@
+# Design Candidates: Connect adaptive dispatch in polling-scheduler.ts
+
+**Task:** Connect `TriggerRouter.dispatchAdaptivePipeline()` in `doPollGitHubQueue()` so queue poll sessions route through the adaptive coordinator instead of generic `dispatch()`.
+
+**Scope:** `src/trigger/polling-scheduler.ts` and `src/trigger/trigger-router.ts` only.
+
+---
+
+## Problem Understanding
+
+### Tensions
+
+1. **Fire-and-forget vs. async coordination**: `dispatch()` is synchronous and returns a `string` immediately. `dispatchAdaptivePipeline()` is `async` and returns `Promise<PipelineOutcome>`. The scheduler calls both as void fire-and-forget. The tension is that the pipeline outcome is never surfaced to the scheduler -- errors are only logged, never propagated.
+
+2. **Deps ownership vs. scheduler simplicity**: `dispatchAdaptivePipeline()` currently requires `AdaptiveCoordinatorDeps` and `ModeExecutors` from the caller. The scheduler has neither. Either the router must own these deps (stored via DI), or the scheduler must carry them (wrong boundary), or the method builds them internally (violates DI principle).
+
+3. **Type safety vs. runtime flexibility**: The task requests a duck-type guard (`'dispatchAdaptivePipeline' in this.router`) rather than relying on TypeScript's static type. This is unusual for a strongly-typed codebase but necessary for test fakes that may not implement the method.
+
+4. **Production readiness vs. YAGNI**: Wiring `AdaptiveCoordinatorDeps` in production requires `spawnSession`, `awaitSessions`, `getAgentResult`, etc. -- HTTP-based, port-dependent. Providing that wiring now is out of scope for a "connect" task.
+
+### Likely seam
+
+`doPollGitHubQueue()` in `polling-scheduler.ts`, line 494: `this.router.dispatch(workflowTrigger)`. This is the correct seam -- it's where the dispatch decision is made, and where `context.taskCandidate` is available.
+
+### What makes this hard
+
+- `dispatchAdaptivePipeline` was added incomplete by design (JSDoc: "intentionally unconnected until that branch is rebased onto main"). It's a placeholder with a signature that requires caller-supplied deps that the scheduler cannot provide.
+- Production `AdaptiveCoordinatorDeps` wiring does not yet exist on `TriggerRouter`.
+- A naive swap crashes at runtime (deps are `undefined`, `runAdaptivePipeline` calls `deps.now()` immediately).
+
+---
+
+## Philosophy Constraints
+
+From CLAUDE.md and repo patterns:
+
+- **DI for boundaries**: inject external effects (I/O, clocks) -- do not construct them inside logic modules
+- **YAGNI with discipline**: avoid speculative abstractions; the task is to "connect" not to "fully implement"
+- **Immutability by default**: all TriggerRouter fields are `private readonly`
+- **Type safety first**: prefer compile-time guarantees -- but the type guard is an accepted runtime concession for mock compatibility
+
+### Conflicts
+
+- Stated philosophy ("type safety first") vs. requested duck-type guard. The runtime guard exists because test fakes may not implement `dispatchAdaptivePipeline`. This is an intentional concession to test flexibility, not a philosophical violation.
+
+---
+
+## Impact Surface
+
+- `TriggerRouter` constructor signature (minor -- optional params only, no breaking change)
+- All existing `TriggerRouter` tests -- must continue to pass without supplying new optional params
+- `PollingScheduler` -- minimal change at the dispatch call site
+- All existing `PollingScheduler` tests -- must continue to pass; the type guard means mock routers without `dispatchAdaptivePipeline` silently fall back to `dispatch()`
+- Production bootstrap (e.g. `src/trigger/trigger-listener.ts`) -- NOT changed in this PR (wiring `coordinatorDeps` is a follow-up task)
+
+---
+
+## Candidates
+
+### Candidate A: Store optional coordinator deps on TriggerRouter (DI pattern)
+
+**Summary**: Add optional `coordinatorDeps?: AdaptiveCoordinatorDeps` and `modeExecutors?: ModeExecutors` constructor params to `TriggerRouter`. Simplify `dispatchAdaptivePipeline` to use stored fields (not caller-provided params). In `doPollGitHubQueue`, type-guard check and call `void this.router.dispatchAdaptivePipeline(goal, workspace, context)`; fall back to `dispatch()` when the method is absent or deps are missing.
+
+**Tensions resolved**: DI boundary (router owns deps). Fire-and-forget preserved. Type guard enables test fallback.
+
+**Tensions accepted**: Production adaptive dispatch deferred (always falls back to `dispatch()` until deps are wired). Adds optional params to TriggerRouter constructor.
+
+**Boundary**: `TriggerRouter` -- correct. It already owns `execFn`, `emitter`, `notificationService`, `steerRegistry` via the same pattern.
+
+**Why this boundary**: The scheduler's job is to poll and dispatch. It should not know what `AdaptiveCoordinatorDeps` is. The router is the infrastructure boundary.
+
+**Failure mode**: If `coordinatorDeps` is never injected in production, adaptive dispatch silently falls back to `dispatch()`. Mitigated by a `console.warn` log.
+
+**Repo pattern**: Follows the existing TriggerRouter optional DI pattern exactly. No new patterns invented.
+
+**Gains**: Clean separation; minimal change; all existing tests pass unchanged.
+
+**Gives up**: Production adaptive dispatch doesn't work until a follow-up PR wires `coordinatorDeps`.
+
+**Scope judgment**: Best-fit. The task says "connect" -- this creates the wiring path without full production readiness.
+
+**Philosophy fit**: Honors DI for boundaries, YAGNI, immutability. Minor concession: duck-type guard is necessary for mock compatibility.
+
+---
+
+### Candidate B: Add coordinator deps to PollingScheduler constructor
+
+**Summary**: Leave `TriggerRouter.dispatchAdaptivePipeline` signature as-is. Add `coordinatorDeps?` and `modeExecutors?` to `PollingScheduler` constructor. Pass them through to `dispatchAdaptivePipeline` in `doPollGitHubQueue`.
+
+**Tensions resolved**: No TriggerRouter API change.
+
+**Tensions accepted**: `PollingScheduler` becomes responsible for coordinator wiring -- wrong boundary. Scheduler's constructor grows with unrelated concerns.
+
+**Boundary**: `PollingScheduler` -- wrong. The scheduler manages polling intervals; it should not know about `AdaptiveCoordinatorDeps`.
+
+**Failure mode**: Two-level optional param threading. If either is absent, must guard in two places (scheduler constructor + method call).
+
+**Repo pattern**: Departs -- nothing in `PollingScheduler` currently takes coordinator-level dependencies.
+
+**Scope judgment**: Too broad -- changes the wrong boundary.
+
+**Philosophy conflict**: Violates DI for boundaries (wrong injection point) and YAGNI.
+
+---
+
+### Candidate C: Lazily construct AdaptiveCoordinatorDeps inside dispatchAdaptivePipeline
+
+**Summary**: No constructor changes. `dispatchAdaptivePipeline` builds `AdaptiveCoordinatorDeps` lazily from `this.ctx`, dynamically imports mode executors (same as CLI pattern), and calls `runAdaptivePipeline` self-contained. In the scheduler, type-guard + call with just `(goal, workspace, context)`.
+
+**Tensions resolved**: No constructor API change. Self-contained per call.
+
+**Tensions accepted**: Requires full `AdaptiveCoordinatorDeps` implementation inside `trigger-router.ts` -- requires console port, HTTP client, `gh` CLI. Major scope increase. Violates DI principle (building deps inside module).
+
+**Failure mode**: Incomplete impl crashes at `deps.now()` or later; requires entire `AdaptiveCoordinatorDeps` surface implemented.
+
+**Scope judgment**: Too broad. This is a separate task ("implement coordinator deps for TriggerRouter").
+
+**Philosophy conflict**: Violates DI for boundaries.
+
+---
+
+## Comparison and Recommendation
+
+**Recommendation: Candidate A.**
+
+All meaningful tensions favor Candidate A:
+
+- **Right boundary**: TriggerRouter already uses the exact same DI pattern for `execFn`, `emitter`, `notificationService`, `steerRegistry`. Adding `coordinatorDeps` and `modeExecutors` extends an established pattern at the established boundary.
+- **Most manageable failure mode**: The fallback to `dispatch()` with a warning log is explicit and visible. Candidate B has the same fallback complexity but at the wrong boundary. Candidate C crashes if not fully implemented.
+- **Scope fit**: The task is explicitly a "connect" task. Candidate A makes the connection; production wiring is deferred to a follow-up (which is correct -- the pitch says "wire queue poller -> runAdaptivePipeline()" as a modification to `trigger-router.ts`, not as production bootstrap wiring).
+- **Easiest to evolve**: When the production `AdaptiveCoordinatorDeps` is ready, it's injected once at the bootstrap level. No changes to scheduler or method internals required.
+
+---
+
+## Self-Critique
+
+**Strongest counter-argument**: If `coordinatorDeps` is always `undefined` in production, this PR "connects" nothing in practice -- the fallback to `dispatch()` always fires. The connection exists in the code but not in behavior.
+
+Response: This is the explicitly stated intent. The JSDoc says "intentionally unconnected until that branch is rebased onto main." The task is to create the call path; making it operational is a separate step.
+
+**Narrower option considered**: Don't change `trigger-router.ts` at all -- add the type guard in `polling-scheduler.ts` and call the existing method with `undefined` for the `coordinatorDeps`/`modeExecutors` params. Problem: the existing method has those params as required (not optional). This requires making them optional in `trigger-router.ts` anyway, which is essentially the same as Candidate A without the constructor injection.
+
+**Broader option that might be justified**: Candidate C, if the production deps implementation already existed elsewhere and just needed wiring. Evidence required: a `makeAdaptiveCoordinatorDeps(ctx, port)` factory function somewhere. None found.
+
+**Assumption that could invalidate this design**: If `dispatchAdaptivePipeline` was intended to always receive fresh deps from the caller (not stored), and the production caller is NOT `PollingScheduler` but some higher-level bootstrap that wraps the router. In that case, the method signature should stay as-is and the scheduler should call a different wrapper. However, the task description explicitly says to call `router.dispatchAdaptivePipeline()` from the scheduler, which rules out this interpretation.
+
+---
+
+## Open Questions for Main Agent
+
+1. Should the fallback log a `console.warn` (visible noise) or `console.log` (informational)? The pattern for "expected missing optional dep" in this codebase is `console.warn` (see TriggerRouter constructor for missing `maxConcurrentSessions`).
+
+2. Should the async `dispatchAdaptivePipeline` fire-and-forget (same as `dispatch()`) or should errors be awaited and logged? The existing `dispatch()` pattern uses `void this.queue.enqueue(...)` for fire-and-forget with result logging inside the callback. The adaptive dispatch should do the same: `void (async () => { ... })()` with outcome logging inside.

package/docs/design/connect-adaptive-dispatch-design-review.md

@@ -0,0 +1,88 @@
+# Design Review: Connect adaptive dispatch in polling-scheduler.ts
+
+**Design under review:** `connect-adaptive-dispatch-candidates.md`, Candidate A (with hybrid revision)
+
+---
+
+## Tradeoff Review
+
+| Tradeoff | Status |
+|----------|--------|
+| Production activation deferred | Acceptable -- documented, warned, follow-up task |
+| Duck-type guard instead of static narrowing | Acceptable -- required for test mock compatibility |
+| Signature change removes 2 required params | Safe -- no tests call `dispatchAdaptivePipeline` directly |
+| Async fire-and-forget via void IIFE | Acceptable -- consistent with `dispatch()` pattern |
+
+All tradeoffs were verified against acceptance criteria and invariants. None violates the task's stated requirements.
+
+---
+
+## Failure Mode Review
+
+| Failure Mode | Mitigation | Risk Level |
+|-------------|-----------|-----------|
+| `coordinatorDeps` absent -- silent fallback | `console.warn` log | Low (documented deferral) |
+| `runAdaptivePipeline` throws | Try-catch in IIFE + scheduler-level catch | Low |
+| Type guard false for real TriggerRouter | Cannot happen -- method on prototype | N/A |
+| Interface drift (new required deps method) | TypeScript compile-time catch | Low |
+| Concurrent poll cycles | Skip-cycle guard already prevents | N/A |
+
+No unmitigated failure modes identified.
+
+---
+
+## Runner-Up / Simpler Alternative Review
+
+**Simpler variant considered**: Keep `dispatchAdaptivePipeline` signature with `coordinatorDeps` and `modeExecutors` as optional method params (not stored on constructor). Scheduler calls with `(goal, workspace, undefined, undefined, context)`.
+
+**Why rejected as-is**: 5-param call site with two explicit `undefined` arguments at the scheduler call site is noisy and implies the caller is responsible for deps it cannot provide.
+
+**Hybrid adopted**: Keep optional method params (for flexibility) AND store them as constructor fields (for default injection). The scheduler calls with `(goal, workspace, context)` -- 3 params, no explicit `undefined`. Production can inject deps at construction; tests can pass them per-call if needed. This is strictly more flexible than the original Candidate A.
+
+---
+
+## Philosophy Alignment
+
+- **DI for boundaries**: Satisfied. Deps injected at construction, scheduler passes nothing.
+- **Immutability by default**: Satisfied. New fields are `private readonly`.
+- **YAGNI with discipline**: Satisfied. No production deps wiring in this PR.
+- **Type safety first**: Minor tension with duck-type guard. Acceptable -- required for test mock compatibility.
+- **Make illegal states unrepresentable**: Minor tension -- `coordinatorDeps` and `modeExecutors` are independent optionals. Acceptable -- consistent with existing router pattern.
+
+---
+
+## Findings
+
+### Yellow: Deferred production activation
+
+**Severity**: Yellow (informational, not a blocker)
+
+`coordinatorDeps` and `modeExecutors` will be `undefined` in production until a follow-up PR wires them into the `TriggerRouter` constructor. The `console.warn` log makes this visible. This is intentional per the pitch's "connect" framing, but should be tracked as a follow-up task.
+
+**No revision required.** The warning log is sufficient mitigation.
+
+### Yellow: Method signature flexibility
+
+**Severity**: Yellow (quality, not a correctness issue)
+
+The hybrid approach (optional params + stored fields) adds slight complexity to `dispatchAdaptivePipeline` internals (must merge caller-provided and stored fields). The precedence rule (caller-provided params override stored fields when both are present) should be documented in the method's JSDoc to prevent future confusion.
+
+**Revision required**: Add JSDoc note to `dispatchAdaptivePipeline` clarifying that caller-provided `coordinatorDeps`/`modeExecutors` override the stored fields.
+
+---
+
+## Recommended Revisions
+
+1. **Adopt hybrid approach**: `dispatchAdaptivePipeline` accepts optional `coordinatorDeps?` and `modeExecutors?` params (caller override) with fallback to `this._coordinatorDeps` and `this._modeExecutors` (stored fields). Three-param call site from scheduler: `(goal, workspace, context)`.
+
+2. **Add JSDoc clarification**: Document the precedence rule (caller params override stored fields) in `dispatchAdaptivePipeline`'s JSDoc.
+
+3. **Warning log text**: The fallback warning should include: triggerId, reason ("coordinatorDeps not injected -- falling back to dispatch()"), and suggest where to inject.
+
+---
+
+## Residual Concerns
+
+- **Production wiring gap**: The adaptive coordinator will not activate in production until `AdaptiveCoordinatorDeps` is implemented and injected. This is tracked as a follow-up task by the task description. No action required in this PR.
+
+- **Test coverage gap**: No test verifies that `dispatchAdaptivePipeline` is called instead of `dispatch()` for queue-poll sessions when deps are present. This would require adding `dispatchAdaptivePipeline` to the mock router in `polling-scheduler.test.ts`. Out of scope for this PR per the "small targeted change" instruction, but recommended as a follow-up.

package/docs/design/connect-adaptive-dispatch-implementation-plan.md

@@ -0,0 +1,209 @@
+# Implementation Plan: Connect adaptive dispatch in polling-scheduler.ts
+
+## Problem Statement
+
+`TriggerRouter.dispatchAdaptivePipeline()` was added in PR #639 but left unconnected. `polling-scheduler.ts` still calls `router.dispatch()` for all sessions including `github_queue_poll` ones. The queue poll sessions run as generic workflow sessions instead of being routed through the adaptive coordinator. This PR creates the wiring connection.
+
+---
+
+## Acceptance Criteria
+
+1. In `doPollGitHubQueue()`, when a task candidate is dispatched, `router.dispatchAdaptivePipeline()` is called (via type guard) instead of `router.dispatch()` -- when `dispatchAdaptivePipeline` exists on the router.
+
+2. When `dispatchAdaptivePipeline` is absent on the router (test mocks), `dispatch()` is called as fallback -- no crash, no error.
+
+3. When `dispatchAdaptivePipeline` exists but `coordinatorDeps` is not injected, a `console.warn` is emitted and the method falls back gracefully (returns a dry_run outcome or delegates to dispatch-equivalent behavior). The polling loop continues normally.
+
+4. `TriggerRouter` accepts optional `coordinatorDeps?: AdaptiveCoordinatorDeps` and `modeExecutors?: ModeExecutors` constructor params. When provided, `dispatchAdaptivePipeline` uses them as defaults.
+
+5. `dispatchAdaptivePipeline` signature is simplified: takes `(goal, workspace, context?, coordinatorDeps?, modeExecutors?)` -- last two are caller overrides (take precedence over stored fields). Returns `Promise<PipelineOutcome>`.
+
+6. `npm run build` produces no TypeScript errors.
+
+7. `npx vitest run` -- all 353 test files pass, no regressions.
+
+---
+
+## Non-Goals
+
+- Do NOT implement `AdaptiveCoordinatorDeps` production wiring inside `TriggerRouter` (that's a follow-up PR).
+- Do NOT wire `coordinatorDeps` in `trigger-listener.ts` or any bootstrap file.
+- Do NOT modify any `src/mcp/` files.
+- Do NOT change `AdaptiveCoordinatorDeps` or `ModeExecutors` interface definitions.
+- Do NOT add new tests for the adaptive dispatch path (test mock router doesn't implement `dispatchAdaptivePipeline`; the fallback path is the tested path).
+- Do NOT change `PollingScheduler` constructor signature.
+
+---
+
+## Philosophy-Driven Constraints
+
+- **DI for boundaries**: `coordinatorDeps` stored on `TriggerRouter`, not constructed inside it.
+- **Immutability by default**: New fields are `private readonly`.
+- **YAGNI**: Only the wiring is added; no production deps implementation.
+- **Errors as data**: Absent deps produce a logged warning and graceful fallback, never a thrown error.
+- **Determinism**: Fallback behavior (when deps absent) is always the same -- log warn + skip adaptive dispatch.
+
+---
+
+## Invariants
+
+1. At-least-once delivery ordering is preserved: adaptive dispatch fires BEFORE `appendQueuePollLog` records the event (same ordering as the `dispatch()` call it replaces).
+
+2. Fire-and-forget semantics preserved: `doPollGitHubQueue` does not await the adaptive dispatch outcome.
+
+3. Fallback to `dispatch()` when `dispatchAdaptivePipeline` is absent on the router (type guard false).
+
+4. `dispatchAdaptivePipeline` never throws: any internal errors are caught and logged; the method returns `PipelineOutcome { kind: 'escalated' }` on unexpected errors.
+
+5. Existing `TriggerRouter` tests pass without modification -- new constructor params are optional.
+
+---
+
+## Selected Approach
+
+**Hybrid approach (Candidate A refined):**
+
+### In `trigger-router.ts`
+
+1. Add to constructor parameters (after `steerRegistry?`):
+   - `coordinatorDeps?: AdaptiveCoordinatorDeps`
+   - `modeExecutors?: ModeExecutors`
+
+2. Store as `private readonly _coordinatorDeps?: AdaptiveCoordinatorDeps` and `private readonly _modeExecutors?: ModeExecutors`.
+
+3. Change `dispatchAdaptivePipeline` signature from:
+   ```typescript
+   async dispatchAdaptivePipeline(
+     goal: string,
+     workspace: string,
+     coordinatorDeps: AdaptiveCoordinatorDeps,
+     modeExecutors: ModeExecutors,
+     context?: Readonly<Record<string, unknown>>,
+   )
+   ```
+   to:
+   ```typescript
+   async dispatchAdaptivePipeline(
+     goal: string,
+     workspace: string,
+     context?: Readonly<Record<string, unknown>>,
+     coordinatorDeps?: AdaptiveCoordinatorDeps,
+     modeExecutors?: ModeExecutors,
+   )
+   ```
+   Effective deps = caller-provided (override) OR stored fields (default).
+
+4. Inside `dispatchAdaptivePipeline`, if no effective deps are available:
+   - Log `console.warn('[TriggerRouter] dispatchAdaptivePipeline called but coordinatorDeps not injected -- adaptive dispatch disabled. Inject coordinatorDeps in TriggerRouter constructor to activate.')`
+   - Return `{ kind: 'escalated', escalationReason: { phase: 'dispatch', reason: 'coordinatorDeps not injected' } }` as PipelineOutcome.
+
+5. Update JSDoc to document:
+   - The `@see feat/github-queue-poll` comment (already there -- keep it)
+   - The caller-override vs. stored-field precedence rule
+   - That absent deps produce a warn + escalated outcome (not a throw)
+
+### In `polling-scheduler.ts`
+
+1. In `doPollGitHubQueue`, replace line:
+   ```typescript
+   this.router.dispatch(workflowTrigger);
+   ```
+   with:
+   ```typescript
+   if ('dispatchAdaptivePipeline' in this.router && typeof (this.router as { dispatchAdaptivePipeline?: unknown }).dispatchAdaptivePipeline === 'function') {
+     void (this.router as { dispatchAdaptivePipeline: (goal: string, workspace: string, context?: Readonly<Record<string, unknown>>) => Promise<unknown> }).dispatchAdaptivePipeline(
+       workflowTrigger.goal,
+       workflowTrigger.workspacePath,
+       workflowTrigger.context,
+     );
+   } else {
+     this.router.dispatch(workflowTrigger);
+   }
+   ```
+   Note: The type cast is necessary because `TriggerRouter` is imported as a type (not class) in `polling-scheduler.ts`. The duck-type check is the runtime safety mechanism.
+
+2. Add a log line after the adaptive dispatch call:
+   ```typescript
+   console.log(`[QueuePoll] dispatched via adaptivePipeline: goal="${workflowTrigger.goal.slice(0, 80)}"`);
+   ```
+
+---
+
+## Runner-Up
+
+**Candidate B** (PollingScheduler carries coordinator deps) -- rejected because it places infrastructure-level deps at the wrong boundary. PollingScheduler should only know about the router interface.
+
+---
+
+## Vertical Slices
+
+### Slice 1: Modify `trigger-router.ts`
+- Add optional constructor params `coordinatorDeps?` and `modeExecutors?`
+- Store as `private readonly` fields
+- Simplify `dispatchAdaptivePipeline` signature (context before deps)
+- Add absent-deps fallback with `console.warn` and `escalated` return
+- Update JSDoc
+
+**Done when**: `npm run build` succeeds; `dispatchAdaptivePipeline` method compiles with new signature.
+
+### Slice 2: Modify `polling-scheduler.ts`
+- Replace `this.router.dispatch(workflowTrigger)` with type-guard + adaptive dispatch call + fallback
+- Add log line for adaptive dispatch path
+
+**Done when**: `npm run build` succeeds; existing `polling-scheduler.test.ts` tests pass (mock router only has `dispatch`, type guard falls back -- no regressions).
+
+---
+
+## Test Design
+
+**No new test files.** The task says "small targeted change" and the adaptive path requires `coordinatorDeps` injection which the existing test infrastructure doesn't support. Existing tests verify:
+- The fallback path: mock router only has `dispatch()`, type guard is `false`, `dispatch()` is called (existing tests already verify this behavior -- they just don't explicitly test the type guard).
+
+**Manual verification**: After implementation, verify that `npm run build` and `npx vitest run` both pass cleanly.
+
+**Follow-up test** (not in this PR): Add `dispatchAdaptivePipeline` to the mock router in `polling-scheduler.test.ts` and assert it's called for queue-poll sessions.
+
+---
+
+## Risk Register
+
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|-----------|
+| Type cast for duck-type check causes TS error | Low | Build failure | Use `as { dispatchAdaptivePipeline?: unknown }` minimal cast; verify in Slice 2 |
+| `dispatchAdaptivePipeline` return type mismatch after signature change | Low | Build failure | Verify `ReturnType<typeof runAdaptivePipeline>` still matches `Promise<PipelineOutcome>` |
+| Missing `(this.router as TriggerRouter).dispatchAdaptivePipeline` direct call | None | N/A | The import in `polling-scheduler.ts` is `import type { TriggerRouter }` -- the type guard is the correct approach |
+| Existing trigger-router.test.ts fails after constructor change | Low | Test failure | New params are optional -- all existing test construction sites pass `undefined` implicitly |
+
+---
+
+## PR Packaging Strategy
+
+**Single PR**: `fix/connect-adaptive-dispatch`
+
+Commit: `fix(trigger): connect queue poll dispatch to adaptive coordinator`
+
+All changes in one commit: `trigger-router.ts` + `polling-scheduler.ts` + design docs.
+
+---
+
+## Philosophy Alignment
+
+| Principle | Status | Reason |
+|-----------|--------|--------|
+| DI for boundaries | Satisfied | `coordinatorDeps` injected at construction, not built internally |
+| Immutability by default | Satisfied | New fields are `private readonly` |
+| YAGNI with discipline | Satisfied | No production deps wiring; only the call path is connected |
+| Errors as data | Satisfied | Absent deps return `escalated` PipelineOutcome, never throw |
+| Type safety first | Minor tension | Duck-type guard is runtime check; acceptable for mock compatibility |
+| Make illegal states unrepresentable | Minor tension | `coordinatorDeps` and `modeExecutors` are independent optionals; acceptable per existing router pattern |
+
+---
+
+## Estimation
+
+- **`unresolvedUnknownCount`**: 0
+- **`planConfidenceBand`**: High
+- **`estimatedPRCount`**: 1
+- **`followUpTickets`**:
+  1. Wire `AdaptiveCoordinatorDeps` into `TriggerRouter` constructor in `trigger-listener.ts` bootstrap
+  2. Add test for `dispatchAdaptivePipeline` call path in `polling-scheduler.test.ts`

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

@@ -0,0 +1,83 @@
+# Design Candidates: Label-Based Queue Filter for github_queue_poll
+
+## Problem Understanding
+
+### Tensions
+1. **Trigger YAML config vs runtime config.json**: `queueType`/`queueLabel` appear in triggers.yml (per-trigger), but `GitHubQueueConfig` is loaded from `~/.workrail/config.json` (global daemon-level config). Both need to converge on the same data at poll time. The test surface validates at the poller level, which takes a `GitHubQueueConfig` directly - meaning the poller just needs to handle label type correctly, regardless of which source built the config.
+
+2. **Additive field vs type-safe discriminated union**: Adding `queueLabel?: string` (optional) to `GitHubQueueConfig` makes the illegal state (`type==='label'` without `queueLabel`) detectable only at load time. A discriminated union would catch it at compile time. The 3-file scope constraint makes the discriminated union approach infeasible.
+
+3. **Existing `name?` field vs new `queueLabel?` field**: `GitHubQueueConfig` already has `name?: string` (read from `q['name']` in `loadQueueConfig()`). Adding `queueLabel?` alongside it creates two optional label fields. This is a naming inconsistency from an earlier design iteration.
+
+### Likely Seam
+`pollGitHubQueueIssues()` in `github-queue-poller.ts` - the URL construction is where the actual behavior diverges between filter types.
+
+### What Makes This Hard
+- The existing test at line 126 (`returns not_implemented for non-assignee queue type`) tests that label returns `not_implemented`. After this change, label with `queueLabel` succeeds. This test must be replaced, not kept alongside new tests.
+- `polling-scheduler.ts` has a guard at line 393 that still checks `queueConfig.type !== 'assignee'` - this file is out of scope. The scheduler will remain blocking for label type from config.json after our changes. Tests at the poller unit level bypass the scheduler.
+
+## Philosophy Constraints
+
+From `CLAUDE.md` and repo patterns:
+- **Result types, no throws**: all boundary functions return `Result<T, E>`. `err({ kind: 'not_implemented', ... })` is the established pattern for unimplemented branches.
+- **Validate at boundaries**: `loadQueueConfig()` must return `err` if `type === 'label'` and `queueLabel` is absent.
+- **Immutability by default**: new fields must be `readonly`.
+- **YAGNI**: no mention/query stubs, no new abstractions.
+- **Make illegal states unrepresentable**: satisfied at load time by validation; compile-time enforcement would require discriminated union (out of scope).
+
+No philosophy conflicts in this case.
+
+## Impact Surface
+
+- `polling-scheduler.ts` line 393: guard `queueConfig.type !== 'assignee'` remains. Out of scope. Label type from config.json will still be blocked by the scheduler even after our changes. This is an intentional stepping stone.
+- `tests/unit/github-queue-poller.test.ts` line 126: existing test must be replaced/updated (not just added to).
+- `src/trigger/types.ts`: `GitHubQueuePollingSource` needs `queueType?`/`queueLabel?` fields to store trigger YAML values. Not restricted by scope.
+
+## Candidates
+
+### Candidate 1: Additive optional field + load-time validation + poller branch (SELECTED)
+
+**Summary**: Add `readonly queueLabel?: string` to `GitHubQueueConfig`, validate it in `loadQueueConfig()` (err if `type==='label'` and `queueLabel` absent), add `labels=` branch in `pollGitHubQueueIssues()`, parse `queueType`/`queueLabel` in trigger-store, extend `GitHubQueuePollingSource` in types.ts.
+
+**Tensions resolved**: Label config is validated at load time; assignee path unchanged; no new abstractions.
+**Tension accepted**: `name?` field remains alongside `queueLabel?` (minor naming inconsistency).
+**Boundary**: `pollGitHubQueueIssues()` for URL construction; `loadQueueConfig()` for validation.
+**Failure mode**: Forgetting to update the existing `not_implemented` test for label type. The test at line 126 will fail if not replaced.
+**Repo pattern**: Follows exactly - mirrors how `user?` is handled for assignee type.
+**Gain**: Minimal change surface, no breaking changes.
+**Give up**: `name?` naming inconsistency stays.
+**Scope**: best-fit.
+**Philosophy fit**: Honors validate-at-boundaries, immutability, YAGNI, Result types.
+
+### Candidate 2: Discriminated union for GitHubQueueConfig (type-safe)
+
+**Summary**: Refactor `GitHubQueueConfig` into `AssigneeQueueConfig | LabelQueueConfig | MentionQueueConfig | QueryQueueConfig` so `queueLabel` is `string` (not optional) in `LabelQueueConfig`.
+
+**Tensions resolved**: Makes illegal states unrepresentable at compile time.
+**Tension accepted**: Breaks all existing callers; touches files outside scope.
+**Boundary**: Entire `GitHubQueueConfig` interface plus all callers.
+**Failure mode**: Cascading type errors in polling-scheduler.ts and tests.
+**Repo pattern**: Departs - no discriminated union for config types in this codebase.
+**Gain**: Compile-time safety.
+**Give up**: Simplicity, scope compliance.
+**Scope**: too broad.
+**Philosophy fit**: Honors make-illegal-states-unrepresentable but conflicts with YAGNI and scope constraint.
+
+## Comparison and Recommendation
+
+**Selected: Candidate 1.**
+
+All acceptance criteria are satisfied at minimum change surface. Load-time validation in `loadQueueConfig()` catches the illegal state (`type==='label'` without `queueLabel`) before any poll cycle runs. The `pollGitHubQueueIssues()` change is purely additive - the assignee branch is unchanged.
+
+## Self-Critique
+
+**Strongest counter-argument**: The `name?` field in `GitHubQueueConfig` was the original design for label support. Adding `queueLabel?` alongside it creates two ways to express the same concept. The cleaner fix would remove `name?` and replace it, but that's a breaking change to anyone who already uses `config.name` in code paths we're not touching (polling-scheduler at line 471 uses `queueConfig.type` but not `queueConfig.name`).
+
+**Pivot conditions**: If end-to-end testing (not just unit tests) is required, we'd need to update `polling-scheduler.ts` too. That's out of scope per the task description.
+
+**Invalidating assumption**: If `polling-scheduler.ts` is required for the feature to work at all, then the scope restriction is wrong. But the task explicitly says to verify with unit tests at the poller level.
+
+## Open Questions for the Main Agent
+
+1. Should the `name?` field be deprecated or removed? The task says add `queueLabel?` - leaving `name?` creates naming confusion. Recommend leaving it as-is and not removing it (YAGNI, out of scope).
+2. Should `GitHubQueuePollingSource` in `types.ts` gain `queueType?`/`queueLabel?` fields? Yes - trigger-store.ts parses them from YAML and needs somewhere to store them.