arthurpanhku/dvalincode

Good first issue — a frontend-only first slice of #53 (structured approval engine). A maintainer will help you land it; comment to claim. Goal In the web approval prompt, add an "Allow for this run" option next to the existing approve/deny buttons. This issue is UI only — render the option and surface the user's choice; the backend grant semantics (scope, expiry, audit) are tracked in #53 and are explicitly out of scope here. Where The approval UI component in web/src/ (look for the existing approve/deny prompt; PlanCard.tsx and the onProceed pattern are nearby examples of a button that sends an action). Types in web/src/types.ts (PendingApproval). Acceptance The approval prompt shows a third choice, "Allow for this run". Choosing it is distinguishable from a one-off approve in the value passed up (e.g. a scope: 'run' field) — even though the backend doesn't act on it yet. Existing approve/deny behavior is unchanged. Not in scope Backend enforcement of the run-scoped grant,

Why #117 surfaces recovered (crashed) turns in the web UI, but the notice is client-side ephemeral — it's built from a live recovered_turn WebSocket event (web/src/hooks/useChat.ts) and disappears on page refresh or session re-open. A user who reloads before re-sending loses the recovered text and the fact that anything was interrupted. Sketch Persist the recovered marker so it re-renders on session restore, either by (a) journaling a lightweight recovered record and replaying it in mapBackendMessages, or (b) re-emitting recovered_turn on reconnect when the session still has an unresolved recovered turn. Keep the one-click Re-send working after restore. No change to what data is stored — the recovered text is already session-journal state. Acceptance Kill the process mid-turn, resume, then reload the web UI → the recovered notice and Re-send button are still there. No notice when there's nothing to recover. Good first issue Self-contained, one hook + one mapper, existing test

Why src/harness/run.ts (executeHarnessRun) is the headless entrypoint (docs/HARNESS-MODE.md) and is currently only exercised indirectly via tests/mcp/server.test.ts and tests/commands/run.test.ts. There's no tests/harness/ and, critically, no dedicated test pinning unattended-tier behavior — the most governance-sensitive path, since it runs without a human in the loop. Sketch tests/harness/run.test.ts driving executeHarnessRun directly: happy path, policy-denied tool, and approval-required tool under each UnattendedPermissionMode. A bypass-proof assertion: under the unattended tier, an action that policy forbids is refused and audited — it must not silently auto-approve. Assert the run still produces a verifiable audit chain (run_start … tamper-evident) in headless mode. Acceptance Changing unattended/approval semantics can't regress without a red test. npm run check covers the harness path directly, not just transitively.

Why (roadmap: Next) Every model provider is an egress destination that user prompts — often proprietary source — get routed to. Today src/providers/ (anthropic.ts, openaiCompatible.ts) has per-adapter tests, but there's no shared contract every provider must satisfy. That makes "should we trust a new provider?" a subjective call each time (cf. #109). A conformance suite turns it into an objective, reviewable gate. Sketch A single parametrized suite in tests/providers/conformance.test.ts that runs the same assertions against each registered adapter. Contract covers: streaming token deltas, tool/function-call round-trips, error/timeout normalization, and — most importantly for governance — that every request goes through the egress chokepoint (src/providers/egress.ts + trustedBaseUrls.ts), honors redaction, and produces the expected audit events. A bypass-style assertion proving an adapter cannot reach a non-allow-listed base URL. Fixture/mock transport so no real network calls

Why (roadmap: Next) Per docs/GOVERNED-MCP.md (deferred item): MCP tool calls are audited against the live per-run sink, but the pre-run discovery connection (initialize / tools/list in registerMcpServers, src/agent/session.ts) runs before the run's AuditSink exists — its egress is enforced but not recorded in the run chain. Sketch Options (design discussion welcome): Buffer discovery mcp_request events and append them right after run_start. Record a per-session discovery record in the session journal with connection summaries + anchor. Acceptance A reviewer reading one run's chain can see which MCP servers were contacted during discovery, with host + outcome, under the same minimization rules (no headers/args/bodies).