fix(slice-05): strip hardcoded scanner default from router contract (guard B1 repair on a2726e8f) (OPR.0.3.2.5)

Per velocity-guard BLOCKING-CONCERN on a2726e8f (qitem-…b257db38): the
prior contract repair correctly pointed at <workspace.specs_root>/workflows
but named the wrong fresh-default path
(<openrigHome>/specs/workflows). Actual SettingsStore default is
<openrigHome>/workspace/specs/workflows (settings-store.ts:27-30 +
236-242: workspace.root = OPENRIG_HOME/workspace, then workspace.specs_root
= <workspace.root>/specs). Same drift class as the original 08a74cea
finding, narrower scope.

Took guard fix-option-A: remove the hardcoded default path entirely from
both the router doc comment AND the test TARGET. Single source of truth
for the path is now `ContextPackSettingsStore.resolveConfig().workspace
SpecsRoot` — repeating any specific layout in a doc comment is a drift
hazard if SettingsStore changes its workspace-default layering.

bundle-workflow-specs-router.ts: CALLER CONTRACT doc now reads "this MUST
be exactly nodePath.join(ContextPackSettingsStore.resolveConfig()
.workspaceSpecsRoot, 'workflows')" with an explicit "do NOT hardcode a
default here" warning. The pointers to scanner.ts:320-342 + startup.ts:
903-916 are preserved; the literal-default sentence is removed.

bundle-workflow-specs-router.test.ts: TARGET changed from
"/operator/.openrig/specs/workflows" (a default-shape claim that was
wrong) to "/test/workflow-specs-target" — an arbitrary fixture path
that makes no claim about operator-host layout. Comment above TARGET
notes the router is parametric, the live integration resolves via
SettingsStore, and the integration dogfood proves the wiring.

No algorithmic change to routeWorkflowSpecs. 8/8
bundle-workflow-specs-router tests pass with the neutral fixture.
25/25 across all 3 router test files unchanged.

Fifth same-class contract incident on this slice's tail (handoff
claim/contract overstatements caught by guard ground-truth). Step-3
will explicitly grep the SettingsStore resolution path + dogfood the
real wiring via the install integration test fixture before authoring
the handoff body.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

packages/daemon/src/domain/bundle-workflow-specs-router.ts

@@ -45,17 +45,20 @@ export interface RouteWorkflowSpecsInput {
   /**
    * Absolute path to the operator workflow-specs library that the
    * spec-library-workflow-scanner ACTUALLY reads from. **CALLER CONTRACT**:
-   * this MUST be `<workspace.specs_root>/workflows` — the folder discovered
-   * by `scanWorkflowSpecFolder` in
+   * this MUST be exactly
+   *   `nodePath.join(ContextPackSettingsStore.resolveConfig().workspaceSpecsRoot, "workflows")`
+   * — the folder discovered by `scanWorkflowSpecFolder` in
    * `packages/daemon/src/domain/spec-library-workflow-scanner.ts:320-342`
    * and exposed via `deps.workflowsFolderDir` in
-   * `packages/daemon/src/startup.ts:903-916` (resolved from
-   * ContextPackSettingsStore: env > config > workspace-default, default
-   * `<openrigHome>/specs/workflows`). Writing anywhere else (e.g.
-   * `~/.openrig/workflow-specs/`) will succeed silently but be invisible
-   * to the live workflow scanner — operator dead-end. The /install
-   * integration helper (Checkpoint 7.3e step 3) MUST resolve this path
-   * before calling routeWorkflowSpecs.
+   * `packages/daemon/src/startup.ts:903-916`. SettingsStore is the sole
+   * authority for the actual operator-host path; do NOT hardcode a default
+   * here — settings layering (env > config > workspace-default) can shift
+   * the resolved root, so any literal default repeated in this comment
+   * would be a drift hazard. Writing anywhere else will succeed silently
+   * but be invisible to the live workflow scanner — operator dead-end.
+   * The /install integration helper (Checkpoint 7.3e step 3) MUST resolve
+   * this path via the SettingsStore call shown above before invoking
+   * routeWorkflowSpecs.
    */
   targetWorkflowSpecsDir: string;
 }

packages/daemon/test/bundle-workflow-specs-router.test.ts

@@ -24,16 +24,16 @@ function mockFs(initialFiles: Record<string, string> = {}): WorkflowSpecsRouterF
 }
 
 const BUNDLE_ROOT = "/bundle/root";
-// TARGET reflects the CALLER CONTRACT documented in
-// bundle-workflow-specs-router.ts RouteWorkflowSpecsInput.targetWorkflowSpecsDir:
-// the operator workflow-specs library is `<workspace.specs_root>/workflows`,
-// the path the live spec-library-workflow-scanner reads from
-// (see daemon startup.ts:903-916 + scanner.ts:320-342). Default
-// workspace.specs_root layout = <openrigHome>/specs, so the workflows folder
-// resolves to <openrigHome>/specs/workflows. The router itself is parametric
-// on targetWorkflowSpecsDir; this test fixture pins the contract so step 3
-// integration cannot drift to an unscanned location.
-const TARGET = "/operator/.openrig/specs/workflows";
+// TARGET is an arbitrary fixture path — the router is parametric on
+// targetWorkflowSpecsDir and the unit tests do not depend on any specific
+// operator-host layout. The CALLER CONTRACT documented in
+// bundle-workflow-specs-router.ts RouteWorkflowSpecsInput.targetWorkflowSpecsDir
+// requires step 3 integration to resolve this via
+// `nodePath.join(ContextPackSettingsStore.resolveConfig().workspaceSpecsRoot,
+// "workflows")` — SettingsStore is the sole authority. Hardcoding the
+// scanner-default path here would be a drift hazard if SettingsStore
+// changes its default; the integration-level dogfood proves the wiring.
+const TARGET = "/test/workflow-specs-target";
 
 function makeInput(overrides?: Partial<RouteWorkflowSpecsInput>): RouteWorkflowSpecsInput {
   return {