Claude in Our Dev Lifecycle

# one worktree per concern
git worktree add ../TM-routing      feature.routing
git worktree add ../TM-merge-fix    bugfix.merge-accounts
git worktree add ../TM-llm-tuning   feature.llm-tuning

# open one Claude per worktree (CLI)
cd ../TM-routing      && claude
cd ../TM-merge-fix    && claude
cd ../TM-llm-tuning   && claude

# or in the Desktop app: New Session per path

# branch already exists? Use it directly:
git worktree add ../TM-hotfix hotfix.SP-Logo-update

# inspect what's checked out
git worktree list

# cleanup when done
git worktree remove ../TM-routing
git worktree prune                 # GC stale entries

Tip: name your worktrees by concern not by branch (TM-routing beats TM-feature-routing-v2) — it's what shows up in your shell prompt and Desktop session list.

Spawn 4 Explore sub-agents in parallel (single message,
multiple tool calls) to research these areas independently:

  1. Search TaskManager/app/Services for any direct usage of
     AzureOpenAIService — list all consumers and their patterns.

  2. Search DTLR-IQ for prompt-template patterns we should reuse
     when wiring an LLM into other background jobs.

  3. Search DevAgent for sandbox + secret-handling patterns,
     specifically how it isolates per-ticket workspaces.

  4. Search ResearchAgent for the SK -> MAF migration TODOs
     and Dtlr.Agents.Abstractions usage.

Once all four return, synthesize a single architecture note
describing how to extract Dtlr.Agents.Abstractions to /Shared/
when the second consumer lands. Save to docs/abstractions-extraction.md.

This is the fan-out / fan-in pattern: 4 sub-agents work in parallel, your main context stays clean, you get one synthesized output back.

1) From the repo root:
   git worktree add ../TM-feature.routing feature.routing
   cd ../TM-feature.routing

2) Open Claude (CLI or Desktop session pointed at this path),
   then paste:

Read CLAUDE.md and the last 10 commits on this branch. Then:
  - Read all relevant order-routing services and their tests
  - Propose a design.md for routing-by-inventory-and-distance
  - Do NOT write code yet — I want to review the plan first

3) Review design.md. When ready:
   "Implement the plan from design.md. Commit incrementally
    with conventional-commit messages. Run tests after each
    commit. Stop and ask if a test fails."

4) When done:
   git worktree remove ../TM-feature.routing
   (the branch lives on; only the working dir is removed)

Each step in this flow happens in a separate thread. The worktree is the container. The Claude session is the worker. You are the orchestrator.

Pick one Tier-3 table from DTLR-MCP/Toolbox/tools.yaml that
currently has only a stub description. Using:

  - hellcat-list-columns to get the schema
  - 2-3 small hellcat-execute-query SELECTs (LIMIT 50) to
    sample real values
  - get-schema-summary to see what neighbors it joins to

Produce, for that table:

  1. Column-by-column purpose inferred from naming + values + FKs
  2. Join keys to nearby tables (with example join clauses)
  3. 1-2 "BEST FOR" usage hints
  4. Any non-obvious gotchas (NULL semantics, legacy names, etc.)

Then update tools.yaml AND DTLR-MCP/Toolbox/CLAUDE.md and open a
draft doc-PR tagged schema-doc:auto with me as reviewer.

Hard constraints:
  - Description fields only — no logic changes
  - Read-only — no INSERT/UPDATE/DELETE
  - If you're unsure about a column, say "purpose unclear"
    rather than guess.

Run this in a worktree on DTLR-MCP. Each table you process leaves the corpus permanently smarter for every future agent.

Audit this repo's CLAUDE.md against the current state of the codebase.
Check:

  1. Architecture in 5 bullets — is each one still accurate?
     Verify by reading Program.cs / Startup / DI registrations.

  2. Run / test / deploy steps — do they still work?
     Actually try them. Don't skip.

  3. Gotchas — any new ones from the last 30 commits?
     Pay special attention to commits with "fix" or "hotfix"
     in the subject — those usually surface gotchas worth
     documenting.

  4. Pointers — are linked docs / files still in those
     locations? Run a path check.

  5. Effort — is the file under ~200 lines? If not, what's
     redundant or outdated?

Produce a unified diff. DO NOT commit yet — I want to review.

Generate a runtime architecture diagram for this service by reading:

  - Program.cs and any Startup.cs
  - All AddSingleton/AddScoped/AddTransient calls
  - All IOptions bindings and configuration sections
  - All Hangfire job registrations and schedules
  - All HttpClient registrations and their target URLs
  - appsettings.*.json connection strings + dependencies

Render with the drawio MCP. The diagram should show:

  - External dependencies (DBs, MCP servers, queues, APIs)
    grouped by direction (in / out / bidirectional)
  - Internal services + their wiring
  - Background jobs labeled with their cron / triggers
  - Secrets sources annotated (env, secretref, IConfiguration)

Save the source to docs/architecture.drawio and a PNG to
docs/architecture.png. Add a paragraph to CLAUDE.md pointing
to both.

Crawl this repo and rank documentation gaps by impact.

For each public class, controller, job, and service:
  - Does it have a doc-comment / summary?
  - Does CLAUDE.md mention it?
  - Has it been changed in the last 90 days?

Compute an "impact * staleness" score and produce a prioritized
list of the top 15 gaps. For each:
  - File + line
  - Why it matters
  - One-paragraph proposed doc

Save to docs/doc-gaps.md. Don't fill the gaps yet — we'll triage
the list together first.

Source: our existing Datadog setup on TaskManager + APIs.

Triggers: error-rate spike, new exception class, P95 latency breach, Hangfire job failure, custom log signals.

Webhook target: a "Triage Agent" endpoint (mirrors DevAgent's GitHub webhook handler) that receives the alert payload + correlation IDs.

• Today: alerts post to Slack/Teams
• Next: webhook → Triage Agent (auto-classify + auto-ticket)

Triage Agent receives the Datadog payload, dedupes against open tickets (fingerprint = exception class + service + last-N stack frames), and creates or comments on the right Jira ticket.

Each ticket gets:

• Full stack trace
• Correlated log window (5 min before/after)
• Affected hosts / users / transaction IDs
• First-seen / last-seen / occurrence count
• Auto-tagged AI-assignable if confidence > threshold

Reuses DevAgent's existing Jira OAuth + Basic auth integration — no new auth surface.

New service. Same .NET runtime as DevAgent + ResearchAgent. Built on Dtlr.Agents.Abstractions (IAgent<TRequest,TResult>).

Job:

• Classify: bug? config? data? infra?
• Decide ownership: which repo, which CODEOWNERS group?
• Decide assignability: confidence high enough for AI to attempt?
• Decorate the ticket with all of the above
• Hand off to DevAgent if AI-assignable

Critically: the Triage Agent never writes code. Its only output is a well-decorated ticket. That separation keeps the failure mode contained.

DevAgent picks up the ticket, sandbox-clones, then:

• Pulls relevant data via DTLR-Database-Tools MCP (read-only)
• Spins up the affected service locally in the sandbox
• Uses chrome-devtools MCP to drive the broken UI flow
• Captures screenshot of the failure
• Captures console + network logs of the bad request
• Attaches all of it to the PR description as evidence

If repro fails: posts a "cannot repro — need more info" comment back on the ticket and stops. No silent failures, no fabricated fixes.

Same flow as today's DevAgent:

• Plan with confidence score
• Implement
• Run existing tests
• If tests fail → iterate (max 3 attempts)
• If still failing → open the PR as draft with a needs-human label

Hard rules:

• Never bypass tests or hooks
• Never force-push
• Always ask before destructive ops
• File-change limits enforced at the agent level

Draft PR includes:

• Original Datadog alert
• Stack trace
• Repro screenshots (before)
• Fix screenshots (after)
• Test results
• Datadog dashboard link the reviewer can hit to see error-rate impact
• Confidence score from the planner
• Reviewer auto-assigned via CODEOWNERS

Posted to a Teams Adaptive Card with approve / request-changes buttons — senior reviewers can ship from their phone.

Two paths:

• Dev branch: high-confidence fixes auto-merge after CI green; deployed by the existing TeamCity pipeline.
• Main branch: always human-gated. The reviewer's "Approve" is what triggers the merge.

The deploy pipeline itself stays the same. This loop adds a smart feeder upstream of it, not a replacement.

Using the DTLR-Database-Tools MCP, answer this without writing
SQL by hand — let the tool descriptions route you:

  "What were our top 5 selling SKUs last week chain-wide?
   Show units, revenue, and which department they belong to.
   Use the most recent fully-closed week."

After it answers, follow up with:

  "Now break that down by region. Did any region rank a SKU
   significantly differently than the chain? Flag anything
   with a rank delta of 3 or more."

Notice what the agent picks: it should land on
delorean.sales_transactions_daily for the chain query,
and use store_master + the location join for the regional
break — without you ever telling it which tables to use.

This is the demo that makes business stakeholders' jaws drop. No SQL, no schema knowledge, no help from us. Just a question.

Hunt for anomalies in our last 7 days of sales data. Look for:

  - SKU velocity z-scores that have flipped sign
  - Categories with WoW deltas outside their 28-day baseline
  - Stores where total revenue dropped > 20% but traffic
    (RetailNext exits) was flat or up
  - Products that climbed > 10 ranks vs last week

Use TaskManager's discipline rules:

  - Weather and holidays are CONTRIBUTORS, never whole
    explanations
  - Do not fabricate fallback explanations — say "no clear
    cause" if the data doesn't support one
  - Surface only signals significant at the chain (>=90)
    or region (>=85) level

Produce a 4-bullet anomaly digest with each bullet citing
the SQL it ran.

This is exactly how the TaskManager Analyst Reporting flow works under the hood — only here you're running it ad-hoc instead of on a schedule.

# Generate the secrets locally
DEVAGENT_API_KEY=$(openssl rand -hex 32)
CALLBACK_API_KEY=$(openssl rand -hex 32)
GITHUB_WEBHOOK_SECRET=$(openssl rand -hex 32)

# Create the Container App with secrets + env-var refs
az containerapp create \
  --name devagent \
  --resource-group dtlr-devagent \
  --environment dtlr-devagent-env \
  --image dtlrdevagent.azurecr.io/devagent:latest \
  --secrets \
      "devagent-api-key=$DEVAGENT_API_KEY" \
      "callback-api-key=$CALLBACK_API_KEY" \
      "github-webhook-secret=$GITHUB_WEBHOOK_SECRET" \
      "claude-api-key=<sk-ant-...>" \
  --env-vars \
      "DevAgent__ApiKey=secretref:devagent-api-key" \
      "Callback__ApiKey=secretref:callback-api-key" \
      "GitHubWebhook__Secret=secretref:github-webhook-secret" \
      "CodingAgent__ClaudeApiKey=secretref:claude-api-key"

# Rotate any secret in place — no commit, no redeploy
az containerapp secret set -n devagent -g dtlr-devagent \
  --secrets "devagent-api-key=$(openssl rand -hex 32)"
az containerapp revision restart -n devagent -g dtlr-devagent \
  --revision "$(az containerapp revision list -n devagent \
    -g dtlr-devagent --query '[0].name' -o tsv)"

The full playbook lives in DTLR-Agents/docs/deploy-devagent-container-app.md — including paired-secret coordination with the Teams bot and GitHub webhook secret rotation.

Post-deploy:

• Watcher polls Datadog for the original alert signal for 30 minutes
• If error rate drops to zero: ticket auto-closes with a "verified by datadog" note + a link to the dashboard
• If error persists or a new error appears: ticket reopens, posts a follow-up Teams card "fix did not resolve, manual review needed"

This is the closing of the loop. Without verification it's just a fancy ticket-creator. With verification, the system has feedback — and that's what makes it self-improving.