@rickylabs/dsh-app

Configuration

The bundle explicitly selects @rickylabs/routing/config/routing.v1.json in the harness-routing row. This is a packaged compatibility transcription, not a fleet-parity result. To replace it, set config.document in your profile patch to your complete routing JSON path (use ./ for a relative path) or a package subpath. There is no merge or hidden fallback. createService always throws RangeError: routing-document-not-configured for absent/empty selection; load refusals contain fixed safe codes. harness-llm stays pending until routing is available and refuses an unsupported placement backend before registering any adapter.

Render changes to the bundle rows with pnpm --filter @rickylabs/dsh-app run bundle:render, then run pnpm run golden:bless -- "reason" and inspect the resulting row diff.

Each row takes its options from the profile's own patch layer, in the ordinary cordis way:

- id: harness-board
  config:
    lanePrefix: topic

• harness-board — lanePrefix (default lane). The repository's actual prefix; topic: is the known divergence in rickylabs/harness itself.
• harness-coordinator — policy, one of opposite-family (default) or seam-or-family. An unknown name is a RangeError at boot, never a silent fallback: a deployment that misspells its evaluator policy must not quietly get the other one, because the whole point of the policy is that no implementation lane certifies its own work.
• harness-telemetry — home (default: this user's). DSH_TELEMETRY_DIR and friends are read once, at construction, so a snapshot taken after a rotation reads the directory the sink was writing to.
• harness-routing — document, a required explicit path or package subpath. Provides frozen configuration and raw-byte source provenance.
• harness-llm — lmStudioUrl, llamaRocmUrl, openrouterUrl, all defaulting to "", which means "use @rickylabs/llm-local's backend table". Base URLs and nothing else. There is no credential key and there will not be one: the profile is committed, so OPENROUTER_API_KEY is read from the daemon's environment at dispatch, and a request that needs it and cannot find it is refused by name before a socket is opened.

Board session projection

When dsh provides ctx.sessionProjections, harness-board also registers the strict harnessBoard projection. The service's synchronous refresh(session, input) accepts a caller-fetched GitHub issue cut and telemetry runs, derives the public milestone → epic → task → child-run tree, and appends two adjacent whole-value events: todo/write, followed by harness/board-write. GitHub remains authoritative. A model may replace its local todo list during a turn, and the next refresh replaces that list from the next board snapshot.

BoardRefreshInput.observations optionally carries telemetry's typed governance view from the same caller-owned evidence cut. The strict projection keeps its account windows, provider spend, local capacity, and item-scoped refused admissions. Omitting it publishes explicit unavailable governance rather than dropping the field or implying that every regime allows dispatch.

Refresh fails before either append when the projection registry or published todos projection is absent, board-item normalization fails, or the strict public DTO rejects the result. The board service itself still loads without either optional dsh capability, so profiles that only use the pure projector keep working.

Run the executable integration smoke with no agent or model:

pnpm --filter @rickylabs/dsh-app run smoke:board-projection

It composes the published SessionStore, SessionProjectionRegistry, ToolRuntime, and dsh-tool-todo plugin with allowParallelInProgress: true, loads harness-board, refreshes a live session twice, checks todo authority, a parent/child run attachment, and explicit unavailable governance, then verifies projection removal on plugin disposal. The focused composition test also passes a fresh synthetic refusal through refresh and checks the published admission fields.