End-to-end workflows

03:28 · While Wahlberg's still eating breakfast

Somewhere a celebrity is two bites into his 3:15 a.m. breakfast, twelve minutes out from the 3:40 workout he'll caption about discipline. Your phone logs a different personal record at 3:28 — and you are unconscious for it. A vault_status() digest shows the overnight /loop already closed the last research note and stamped forty tool calls in query_log before the man has even laced up. No plunge, no caption, no "who's up?" — the reps that count ran while you recovered. You'll read about them at 8:45 like a normal person.

06:58 · Doomscroll, productively

Between two LinkedIn "I'm humbled to announce" posts you hit a genuinely interesting article. You clip it with /vdb-research-assistant and a one-line instruction — "research how this applies to our stack" — and put the phone down. A note lands in the vault with the source URL and an open question. That's the whole interaction.

Overnight · The robots earn their keep

While you slept (unlike the on-call rotation), a scheduled agent — a Hermes cron or a /loop — swept the notes flagged for research, ran each one, and wrote the findings back as a wiki note, attributed in query_log so the morning briefing knows it's new.

08:45 · The only standup that respects your time

The '63 Studebaker Avanti doesn't have a touchscreen and that's the point — so at the light, a Hermes cron runs /vdb-morning-briefing and pushes it to your phone via the gateway (Telegram / WhatsApp / Slack): priority tasks, open incidents, expiring certs, unhealthy services — and a summary of last night's research. You read it; the supercharger reads the room. No one says "let's circle back."

→ Detail: Start your day

09:12 · A CVE, from the train

The brief flags a CVE in a dependency. You don't wait for the 14-slide security deck — you tell Hermes to open it. /vdb-incident-response records and documents the incident; you dispatch the patch to a background worktree agent. By the time you reach your desk, the fix is in review.

→ Detail: Incident, end to end

09:50 · Close the loop (before the cold brew kicks in)

vault_agent_sessions says the patch agent finished. You review its branch, run /vdb-impact-analysis on the patched service to confirm no regressions, then merge. /vdb-change-log records the change, the incident flips to resolved, and /vdb-runbook-manager captures a runbook — the one future-on-call-you will thank you for at 2 a.m.

→ Detail: Incident, end to end · Ship a change safely

11:00 · Review the fleet

A quick vault_agent_sessions(status="running"): two story agents are done (review + merge), one failed (re-dispatch), and one is stalled on a question — you take it over with vdb sessions --inject and unblock it. A team that never books a 1:1.

→ Detail: Hand it to a background agent

13:30 · The meeting that could've been an email

A "quick sync" runs forty-five minutes. Before it eats your context, /vdb-handoff stashes the half-done task to a durable note — so it survives "let's take this offline" — and you resume exactly where you were once everyone's done aligning on alignment.

→ Detail: Stash a task for later

15:00 · OKRs that actually compile

Something from the research sparks a feature. /vdb-po shapes it into a goal → epic → stories, /vdb-sprint ranks them by WSJF, and the first epic's ready stories get delegated to background agents that claim and work them in parallel. Here metric_type is a column, not a vibe.

→ Detail: Roadmap pipeline

17:30 · "Visibility," they call it

The end-of-day questions — what shipped, what the agents touched (query_log by VAULT_AGENT), what's blocked, what's due tomorrow — are a few queries, not a status meeting. On the way to the parking lot, a late story agent finishes and pings your phone; you approve the merge from the gateway.

19:30 · Clock out, load up

The work vault goes dark. The lifted truck — the one on 40s that needs a running start at the drive-thru — gets pointed at the Thursday-night dirt oval, with Catfish riding shotgun and the Hubbard brothers following in something that shouldn't still run. The other vault — the one that doesn't pay you — wakes up, and so does its resident Hermes instance, the one you named Son of Anton. Homelab notes live in a separate vault, so one command repoints every call at it — no cross-contamination between the day job and the dirt.

vdb context use homelab     # point every vdb/MCP call at the homelab vault
vdb status                  # confirm: resolved vault = homelab, and why

20:30 · Between heats, the homelab owes you nothing

Son of Anton runs the evening sweep while you're staging — no SLA, no Jira: from the pit wall you glance at your phone between runs and /vdb-vm-health-check + /vdb-host-inventory-sync have flagged a drifted Proxmox node and an unhealthy container; /vdb-cert-monitor says the *.home cert expires in nine days (renew it before Home Assistant dies and the family files a Sev-1); /vdb-network-audit finds an unknown device on the IoT VLAN — almost certainly the new smart toaster. You thumb-type one renewal and make your heat with thirty seconds to spare.

21:10 · The question only the vault can answer

Roy-Lee, two trailers down and mid-argument about gear ratios, texts: "didn't you already price the bigger GPU? what'd the idle one land at?" You don't remember; the vault does. One vault_search() from the staging lanes pulls last month's decision note — numbers, vendor, the part you talked yourself out of. He gets an answer; you get back in line.

21:30 · Capacity for the dream

You want to self-host a model. /vdb-capacity-planner reads the spare-hardware inventory and finds the idle GPU and the RAM scattered across the fleet, then proposes where it lands. No procurement ticket. No six-week lead time. No VP sign-off — just Catfish saying it'll "probably draw too much off the garage circuit," which, fair.

22:30 · Synthesize, then sleep

Truck parked, fender liner one zip-tie closer to optional. /vdb-wiki-ingestion folds the day's research and the homelab notes into durable wiki pages. Tomorrow's questions, pre-answered — which is more than you can say for the all-hands.

Generate the briefing

/vdb-morning-briefing synthesizes from vault data: priority + due tasks, open incidents, certs nearing expiry, unhealthy services, and agent activity since the last briefing.

Deliver it

Print it to the terminal, save it to the daily note, or — with Hermes — schedule a cron that runs it and pushes it to your phone through the gateway.

Act on it

The briefing is a launchpad: claim a due task, open an incident, start a cert renewal, or dispatch a fix. Each routes into the guides below.

# what the briefing pulls from
vault_due_tasks(date="today")
vault_incidents(status="open")
vault_cert_expiry(days=30)

Capture it

Invoke /vdb-handoff — "save this bug for later."

It lands in the vault

A durable type: handoff note in Handoffs/ with the goal, the relevant files, what you already know about the cause, and the next steps — secrets redacted, existing artifacts linked not pasted.

Move on

It reindexes so the note is searchable and returns the path. You keep working on the feature; the bug is safely parked.

Find it later

After a context clear or days later, list what's still waiting:

# list everything still waiting
vault_sql("SELECT path, title, created FROM notes
           WHERE type='handoff' AND status='open' ORDER BY created DESC")

# or full-text search the bodies
vault_search("payment retry timeout")

Write the handoff

Capture it with /vdb-handoff as above — goal, cause, acceptance criteria.

Dispatch it

Hand the note to /vdb-dispatch. It creates an isolated git worktree, installs the handoff as handoff.md there (plus a durable vault copy), and launches a headless agent under systemd-run --user seeded with "read handoff.md and implement".

It's logged

A type: agent-session ledger note is written and the watch command printed.

Check back whenever

Keep working; look in on the job on your own schedule:

# what's running, and how to take over each one
vault_agent_sessions(status="running")

# tail the headless job's output
journalctl --user -u vdb-<name> -f

Frame the question

Hermes invokes /vdb-handoff to capture exactly what to research and what a good answer looks like — links to the code in question, the versions to compare, the decision the answer feeds.

Spawn Claude Code

/vdb-handoff-session --harness claude: a worktree is created, the handoff installed, and Claude Code launches in a tmux session seeded to read it and produce findings.

Watch or take over

The session is takeoverable — Hermes (or you) can attach to steer, answer a prompt, or read progress; or observe read-only via vdb sessions:

# take over the research session
tmux attach -t research-retry-semantics

# or just watch it read-only
vdb sessions --name research-retry-semantics

Fold the answer back in

Claude writes its findings into the vault (a research/wiki note); Hermes reads that note and continues the original task. The session note is flipped to status: done.

Map the impact

/vdb-impact-analysis walks the service / call graph: what the change can reach (vault_blast_radius), which QA scenarios it touches, and where there's no coverage (vault_coverage_gaps).

Get a test plan

It emits a row-by-row plan — re-run these scenarios, author these new ones — saved as a vault note. It does not write the tests itself.

Delegate the tests

Hand that plan to /vdb-handoff-session (or /vdb-dispatch): an agent in a worktree authors the missing tests and runs the re-run set.

Keep the graph honest

After merging, /vdb-graph-sync refreshes graph_nodes / graph_edges from the updated relationship frontmatter so the next analysis is accurate.

vault_blast_radius(nodes="checkout-service", depth=3)
vault_coverage_gaps(node="checkout-service")

Open it

/vdb-incident-response creates a structured type: incident note — severity, affected host, timeline.

Investigate

It correlates: vault_recent_changes on the affected host (what deployed lately?), vault_incidents for prior matches, vault_search for related notes. Findings go in the timeline.

Fix — inline or delegated

For a known fix, delegate remediation to a worktree agent (/vdb-handoff-session, interactive preferred for anything production), and record the change with /vdb-change-log.

Capture the runbook

Resolve the incident, then /vdb-runbook-manager writes a runbook from what worked — so the same symptom is a lookup next time, not an investigation.

vault_recent_changes(host="db-01")
vault_incidents(status="resolved", host="db-01")

Index the repo

/vdb-source-ingestor records it in source_repos: local path, remote, language, tech stack, related IaC — queryable via vault_source_repos.

Capture how it works

Pull architecture notes, conventions, and entry points into vault notes (or a wiki page) so any agent dispatched there starts with context instead of cold.

Dispatch work into it

Point /vdb-dispatch / /vdb-handoff-session at the repo: an agent runs in a worktree of that repo, seeded with a handoff. The repo is the "external source location" the vault delegates to.

Track what's running there

vault_agent_sessions shows every delegated session and its worktree, so parallel work across repos stays visible from the hub.

vault_source_repos(language="python")
vault_agent_sessions(status="running")

Plan

With /vdb-po: capture goals → epics → stories, score them, and mark the well-formed ones status: ready. Stories with needs_technical_input stay back.

Sequence & fan out

/vdb-sprint ranks ready stories by WSJF and works the top of the queue — spawning one worktree agent per story via /vdb-dispatch instead of doing each inline.

Claim atomically

Each spawned agent calls vault_claim_story, which returns the full story note (acceptance criteria + epic context) and prevents two agents grabbing the same story.

Work & report

The agent works the story, then reports with vault_update_story_status (blocked / in-review / done) — appending to the activity log and optionally firing a notification.

Close the ticket with what only the vault knows

On done, the integration pushes the status back to the external tracker (Jira / GitLab / Linear) — and enriches the ticket with the context the tracker never had: the story's WSJF score and rank, its parent epic and goal, the worktree branch and the agent session that did the work, and the vault_blast_radius() the change touched. The ticket stops being a title and a guess; it carries the decision trail.

# auto-posted on done — fields the tracker couldn't have:
done via wt-checkout-retry (agent: claude-code) · WSJF 18.5 (rank 2/14)
epic: Checkout resilience  ·  goal: Cut cart-abandon 15%
blast radius: checkout-service → [payments, inventory, email] (depth 3)

Watch the fleet

Track everything from the vault — no need to attach to anything:

# what's ready, what's in flight, where it all stands
vault_ready_stories(limit=10)
vault_agent_sessions(status="running")
vault_roadmap_summary()