davstack

Strip the stray leading `@` from unpushed commit messages (a PowerShell here-string glitch that buries the real subject under a bare `@` line). Use when commits show up as `@ <subject>` in git log or the first line looks blank/invisible.

DEFAULT for multi-file codebase exploration ("how does X work / where is Y", tracing an unfamiliar subsystem, log analysis). Delegate the read-only sweep instead of self-grepping — protects your context. Never delegate design/synthesis. Self-check ONLY the most imporant load-bearing files/lines; delegate breadth you wouldn't otherwise open.

Large, mechanical, low-complexity edits you can convey in a SHORT intent+constraints spec that the executor will then fully apply on its own — simple refactors, rote multi-file changes, repeated patterns. Worth delegating even if you've already read the files. Do it yourself if 1-2 line edit, or conveying it correctly would need exhaustive line-by-line detail right. Never use critical, complex edits that require careful judgement.

Disciplined diagnosis loop for hard bugs and performance regressions. Frame → reproduce the USER's failure → hypothesis tree → pre-registered experiment → instrument (delegated) → interpret with a confound gate → root cause → fix-as-hypothesis. Backed by a local Sentry log-ingest sink + `diag` query CLI and a Vitest daemon for fast unit/storybook reruns. Use when the user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

Query a local Sentry-shaped log sink (per-session SQLite under `.davstack/logs/<name>.db`) for cross-service timelines, error windows, or `trace_id` / `run_id` slices. Use when the user references a failed request, agent run, or test invocation and you need the actual log timeline rather than guessing. Also use when planting hypothesis-driven probes during a `diagnose` loop. Skip for tail-following live stdout (use the dev server directly) or for prod logs (this is local-only).

Rerun a vitest test or storybook story file against a warm long-lived daemon — story/unit reruns drop from ~50s cold to ~3-15s warm. Use when the user asks to run / rerun a specific `.test.ts` / `.stories.tsx` file, or you've just edited code and want a fast pass/fail cycle. Skip for cold one-off CI checks (`vitest run` is fine) or when configuring vitest itself (daemon caches go stale).