[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.
<!-- SYNC:critical-thinking-mindset -->
Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act.
Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.
<!-- /SYNC:critical-thinking-mindset -->
<!-- SYNC:ai-mistake-prevention -->
AI Mistake Prevention — Failure modes to avoid on every task:
- Check downstream references before deleting. Deleting components causes documentation and code staleness cascades. Map all referencing files before removal.
- Verify AI-generated content against actual code. AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing.
- Trace full dependency chain after edits. Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain.
- Trace ALL code paths when verifying correctness. Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path.
- When debugging, ask "whose responsibility?" before fixing. Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site.
- Assume existing values are intentional — ask WHY before changing. Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code.
- Verify ALL affected outputs, not just the first. Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks.
- Holistic-first debugging — resist nearest-attention trap. When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis.
- Surgical changes — apply the diff test. Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly.
- Surface ambiguity before coding — don't pick silently. If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path.
<!-- /SYNC:ai-mistake-prevention -->
<!-- SYNC:understand-code-first -->
Understand Code First — HARD-GATE: Do NOT write, plan, or fix until you READ existing code.
- Search 3+ similar patterns (
grep/glob) — cite file:line evidence
- Read existing files in target area — understand structure, base classes, conventions
- Run
python .claude/scripts/code_graph trace <file> --direction both --json when .code-graph/graph.db exists
- Map dependencies via
connections or callers_of — know what depends on your target
- Write investigation to
.ai/workspace/analysis/ for non-trivial tasks (3+ files)
- Re-read analysis file before implementing — never work from memory alone
- NEVER invent new patterns when existing ones work — match exactly or document deviation
BLOCKED until: - [ ] Read target files - [ ] Grep 3+ patterns - [ ] Graph trace (if graph.db exists) - [ ] Assumptions verified with evidence
<!-- /SYNC:understand-code-first -->
<!-- SYNC:graph-assisted-investigation -->
Graph-Assisted Investigation — MANDATORY when .code-graph/graph.db exists.
HARD-GATE: MUST ATTENTION run at least ONE graph command on key files before concluding any investigation.
Pattern: Grep finds files → trace --direction both reveals full system flow → Grep verifies details
| Task | Minimum Graph Action |
|---|
| Investigation/Scout | trace --direction both on 2-3 entry files |
| Fix/Debug | callers_of on buggy function + tests_for |
| Feature/Enhancement | connections on files to be modified |
| Code Review | tests_for on changed functions |
| Blast Radius | trace --direction downstream |
CLI: python .claude/scripts/code_graph {command} --json. Use --node-mode file first (10-30x less noise), then --node-mode function for detail.
<!-- /SYNC:graph-assisted-investigation -->
<!-- SYNC:cross-service-check -->
Cross-Service Check — Microservices/event-driven: MANDATORY before concluding investigation, plan, spec, or feature doc. Missing downstream consumer = silent regression.
| Boundary | Grep terms |
|---|
| Event producers | Publish, Dispatch, Send, emit, EventBus, outbox, IntegrationEvent |
| Event consumers | Consumer, EventHandler, Subscribe, @EventListener, inbox |
| Sagas/orchestration | Saga, ProcessManager, Choreography, Workflow, Orchestrator |
| Sync service calls | HTTP/gRPC calls to/from other services |
| Shared contracts | OpenAPI spec, proto, shared DTO — flag breaking changes |
| Data ownership | Other service reads/writes same table/collection → Shared-DB anti-pattern |
Per touchpoint: owner service · message name · consumers · risk (NONE / ADDITIVE / BREAKING).
BLOCKED until: Producers scanned · Consumers scanned · Sagas checked · Contracts reviewed · Breaking-change risk flagged
<!-- /SYNC:cross-service-check -->
<!-- SYNC:fix-layer-accountability -->
Fix-Layer Accountability — NEVER fix at the crash site. Trace the full flow, fix at the owning layer.
AI default behavior: see error at Place A → fix Place A. This is WRONG. The crash site is a SYMPTOM, not the cause.
MANDATORY before ANY fix:
- Trace full data flow — Map the complete path from data origin to crash site across ALL layers (storage → backend → API → frontend → UI). Identify where the bad state ENTERS, not where it CRASHES.
- Identify the invariant owner — Which layer's contract guarantees this value is valid? That layer is responsible. Fix at the LOWEST layer that owns the invariant — not the highest layer that consumes it.
- One fix, maximum protection — Ask: "If I fix here, does it protect ALL downstream consumers with ONE change?" If fix requires touching 3+ files with defensive checks, you are at the wrong layer — go lower.
- Verify no bypass paths — Confirm all data flows through the fix point. Check for: direct construction skipping factories, clone/spread without re-validation, raw data not wrapped in domain models, mutations outside the model layer.
BLOCKED until: - [ ] Full data flow traced (origin → crash) - [ ] Invariant owner identified with file:line evidence - [ ] All access sites audited (grep count) - [ ] Fix layer justified (lowest layer that protects most consumers)
Anti-patterns (REJECT these):
- "Fix it where it crashes" — Crash site ≠ cause site. Trace upstream.
- "Add defensive checks at every consumer" — Scattered defense = wrong layer. One authoritative fix > many scattered guards.
- "Both fix is safer" — Pick ONE authoritative layer. Redundant checks across layers send mixed signals about who owns the invariant.
<!-- /SYNC:fix-layer-accountability -->
docs/project-reference/domain-entities-reference.md — domain entity catalog, relationships, cross-service sync (when task involves business entities/models). (content auto-injected by hook — check for [Injected: ...] header before reading)
Quick Summary
Goal: READ-ONLY exploration — understand how code works, zero changes.
Workflow:
- Phase 0: Classify — Determine scope (quick / deep / debug / recommendation) before acting
- Discovery — Search codebase for related files (Entities > Commands > Events > Controllers)
- Graph Expand — Run graph queries on 2-3 key files (MANDATORY, main agent only)
- Knowledge Graph — Read + document purpose, symbols, dependencies per file
- Flow Mapping — Trace entry points through pipeline to exit points
- Analysis — Extract business rules, validation, authorization, error handling
- Synthesis — Write executive summary to
.ai/workspace/analysis/[feature]-investigation.md
- Present — Deliver structured findings, offer deeper dives
Key Rules:
- Strictly READ-ONLY — NEVER make code changes
- Every claim needs
file:line proof — mark unverified as "inferred"
- MUST ATTENTION run at least ONE graph command on key files before concluding
- MUST ATTENTION Plan ToDo Task to READ
project-structure-reference.md (if not found, search: project documentation, coding standards, architecture docs)
<!-- SYNC:root-cause-debugging -->
Root Cause Debugging — Systematic approach, never guess-and-check.
- Reproduce — Confirm issue exists with evidence (error message, stack trace, screenshot)
- Isolate — Narrow to specific file/function/line using binary search + graph trace
- Trace — Follow data flow from input to failure point. Read actual code, don't infer.
- Hypothesize — Form theory with confidence %. State what evidence supports/contradicts it
- Verify — Test hypothesis with targeted grep/read. One variable at a time.
- Fix — Address root cause, not symptoms. Verify fix doesn't break callers via graph
connections
NEVER: Guess without evidence. Fix symptoms instead of cause. Skip reproduction step.
<!-- /SYNC:root-cause-debugging -->
Phase 0: Scope Classification
Classify before acting — route to correct depth:
| Scope | Signals | Depth |
|---|
| Quick | Single feature/function, clear entry point | grep → trace → answer (no analysis file needed) |
| Deep | Multi-service, cross-boundary, ambiguous scope | Full workflow + knowledge graph template + analysis file |
| Debug | Error/crash/unexpected behavior | Root-cause-debugging protocol above |
| Recommendation | Code change suggested (removal, refactor) | Validation chain protocol below — MANDATORY |
Quick scope: Skip knowledge graph template + analysis file. Grep → graph trace → present findings.
Deep scope: MUST ATTENTION write to .ai/workspace/analysis/[feature]-investigation.md.
Investigation Mindset (NON-NEGOTIABLE)
Skeptical. Every claim needs file:line traced proof. Confidence >80% to act.
- NEVER assume code works as named — verify by reading actual implementations
- MUST ATTENTION include
file:line for every finding; unproven claims MUST ATTENTION be marked "inferred"
- ALWAYS grep related usages, consumers, cross-service references — NEVER assume completeness
- ALWAYS trace actual call paths with evidence — NEVER rely on signatures alone
Workflow
- Discovery — Search for all related files. Priority: Entities > Commands/Queries > EventHandlers > Controllers > Consumers > Components.
- Graph Expand (MANDATORY — DO NOT SKIP) — YOU (main agent) MUST ATTENTION run graph queries YOURSELF on key files from Step 1. Sub-agents CANNOT use graph — only you can. Pick 2-3 key files (entities, commands, bus messages):
bash
1python .claude/scripts/code_graph connections <key_file> --json
2python .claude/scripts/code_graph query callers_of <FunctionName> --json
3python .claude/scripts/code_graph query importers_of <file_path> --json
4# "ambiguous" → search to disambiguate, retry with qualified name
5python .claude/scripts/code_graph search <keyword> --kind Function --json
6# Trace how two nodes connect
7python .claude/scripts/code_graph find-path <source> <target> --json
8# Filter by service, limit results
9python .claude/scripts/code_graph query callers_of <name> --limit 5 --filter "ServiceName" --json
Graph reveals complete dependency network (callers, importers, tests, inheritance) grep alone misses. Also run /graph-connect-api for frontend-to-backend API mapping.
- Knowledge Graph — Read + analyze each file (from grep + graph results). Document purpose, symbols, dependencies, data flow. Batch in groups of 10; update progress after each batch. Per-file template:
<!-- SYNC:knowledge-graph-template -->
Knowledge Graph Template — For each analyzed file, document: filePath, type (Entity/Command/Query/EventHandler/Controller/Consumer/Component/Store/Service), architecturalPattern, content summary, symbols, dependencies, businessContext, referenceFiles, relevanceScore (1-10), evidenceLevel (verified/inferred), frameworkAbstractions, serviceContext. Investigation fields: entryPoints, outputPoints, dataTransformations, errorScenarios. Consumer/bus fields: messageBusMessage, messageBusProducers, crossServiceIntegration. Frontend fields: componentHierarchy, stateManagementStores, dataBindingPatterns, validationStrategies.
<!-- /SYNC:knowledge-graph-template -->
- Flow Mapping — Trace entry points through processing pipeline to exit points. Map data transformations, persistence, side effects, cross-service boundaries.
- Analysis — Extract business rules, validation, authorization, error handling. Document happy path AND edge cases.
- Synthesis — Executive summary answering original question. Key files, patterns used, text-based flow diagrams.
- Present — Structured output (see Output Format). Offer deeper dives on subtopics.
If preceded by /scout: Use Scout's numbered file list as analysis targets. Skip redundant discovery. Prioritize HIGH PRIORITY files.
Investigation Techniques
Discovery Search Patterns
Grep {FeatureName} combined with: EventHandler, BackgroundJob, Consumer, Service, Component.
Priority order: (1) Entities → (2) Commands/Queries (UseCaseCommands/) → (3) Event Handlers (UseCaseEvents/) → (4) Controllers → (5) Consumers (*BusMessage.cs) → (6) Background Jobs → (7) Components/Stores → (8) Services/Helpers
Dependency Tracing
Backend: method callers (grep *.cs), service injectors (grep interface in constructors), entity events (EntityEvent<Name>), cross-service (*BusMessage across services), repository usage (IRepository<Name>).
Frontend: component users (grep selector in *.html), service importers (grep class in *.ts), store chains (effectSimple → API → tapResponse → state), routes (grep component in *routing*.ts).
Data Flow Mapping
Document as: [Entry] → [Validation] → [Processing] → [Persistence] → [Side Effects]
MUST ATTENTION trace: (1) Entry points, (2) Processing pipeline, (3) Data transformations, (4) Persistence points, (5) Exit points/responses, (6) Cross-service message bus boundaries.
Common Investigation Scenarios
| Question Type | Steps |
|---|
| "How does X work?" | Entry points → command/query handlers → entity changes → side effects |
| "Where is logic for Y?" | Keywords in commands/queries/entities → event handlers → helpers → frontend stores |
| "What happens when Z?" | Identify trigger → trace handler chain → document side effects + error handling |
| "Why does A behave like B?" | Find code path → identify decision points → check config/feature flags → document rules |
Project Pattern Recognition
Backend (search for backend-patterns-reference in docs/): CQRS commands/queries, entity event handlers, message bus consumers, repository extensions, validation fluent API, authorization attributes.
Frontend (search for frontend-patterns-reference in docs/): store component base, store base, effectSimple/tapResponse, observerLoadingErrorState, API service base class.
Graph Intelligence (MANDATORY when graph.db exists)
MUST ATTENTION orchestrate grep → graph → grep dynamically: (1) Grep key terms to find entry files, (2) Use connections/batch-query/trace --direction both to expand dependency network, (3) Grep again to verify content. trace follows ALL edge types including MESSAGE_BUS and TRIGGERS_EVENT.
bash
1python .claude/scripts/code_graph connections <file> --json # Full picture
2python .claude/scripts/code_graph query callers_of <name> --json
3python .claude/scripts/code_graph query importers_of <file> --json
4python .claude/scripts/code_graph query tests_for <name> --json
5python .claude/scripts/code_graph batch-query <f1> <f2> --json
Evidence Collection
Deep scope — MANDATORY: Write analysis to .ai/workspace/analysis/[feature-name]-investigation.md. MUST ATTENTION re-read ENTIRE file before presenting findings.
Structure: Metadata (original question) → Progress → File List → Knowledge Graph (per-file entries per SYNC:knowledge-graph-template) → Data Flow → Findings.
Rule: Every 10 files → MUST ATTENTION update progress, re-check alignment with original question.
Analysis Phases
Comprehensive: (1) Happy path, (2) Error paths, (3) Edge cases, (4) Authorization checks, (5) Validation per layer. Extract: core business rules, state transitions, side effects.
Synthesis: Executive summary (1-para answer, top 5-10 key files, patterns used) + step-by-step walkthrough with file:line references + flow diagrams.
MUST ATTENTION include: (1) Direct answer (1-2 paragraphs), (2) Step-by-step "How It Works" with file:line refs, (3) Key Files table, (4) Data Flow diagram, (5) "Want to Know More?" subtopics.
Guidelines
- Evidence-based — every claim needs code evidence; MUST ATTENTION mark unverified as "inferred"
- Question-focused — ALWAYS tie findings back to original question
- Read-only — NEVER suggest changes unless explicitly asked
- Layered — Start simple, offer deeper detail on request
scout (pre-discovery) | feature (implementation) | debug-investigate (debugging) | graph-query (natural language queries)
Investigation & Recommendation Protocol
Applies when recommending code changes (removal, refactoring, replacement). MUST ATTENTION complete full validation chain.
Validation Chain (NEVER skip steps)
NEVER recommend code changes without completing ALL steps:
- Interface/API identified → 2. ALL implementations found → 3. ALL registrations traced → 4. ALL usage sites verified → 5. Cross-service impact (ALL services) → 6. Impact assessment → 7. Confidence declaration → ONLY THEN output recommendation.
If ANY step incomplete → STOP. State "Insufficient evidence to recommend."
Breaking Change Risk Matrix
| Risk | Criteria | Required Evidence |
|---|
| HIGH | Removing registrations, deleting classes, changing interfaces | Full usage trace + impact + cross-service check (all services) |
| MEDIUM | Refactoring methods, changing signatures | Usage trace + test verification + cross-service check |
| LOW | Renaming variables, formatting, comments | Code review only |
Removal Checklist (ALL MUST ATTENTION pass)
Incomplete checklist → state: Confidence: <90% — did not verify [missing items]
Evidence Hierarchy
(1) Code evidence (grep/read) → (2) Test evidence → (3) Documentation → (4) Inference. Recommendations based on inference alone FORBIDDEN — MUST ATTENTION upgrade to code evidence.
Confidence Levels
95-100% full trace + all services | 80-94% main paths verified | 60-79% partially traced | <60% DO NOT RECOMMEND
Format: Confidence: 85% — Verified main usage in ServiceC, did not check ServiceA/ServiceB
Service Comparison Pattern
Find working reference → compare implementations → identify differences → verify WHY each difference exists → recommend based on proven pattern, NEVER assumptions.
Closing Reminders
- MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using
TaskCreate BEFORE starting
- MANDATORY IMPORTANT MUST ATTENTION Phase 0: classify scope (quick/deep/debug/recommendation) before acting
- MANDATORY IMPORTANT MUST ATTENTION cite
file:line evidence for every claim (confidence >80% to act, <60% DO NOT recommend)
- MANDATORY IMPORTANT MUST ATTENTION run at least ONE graph command on key files before concluding any investigation
- MANDATORY IMPORTANT MUST ATTENTION deep scope → write analysis to
.ai/workspace/analysis/[feature]-investigation.md; re-read ENTIRE file before presenting
- MANDATORY IMPORTANT MUST ATTENTION recommendation scope → complete ALL validation chain steps before any code change suggestion
<!-- SYNC:understand-code-first:reminder -->
- MANDATORY IMPORTANT MUST ATTENTION search 3+ existing patterns and read code BEFORE any modification. Run graph trace when graph.db exists.
<!-- /SYNC:understand-code-first:reminder -->
<!-- SYNC:graph-assisted-investigation:reminder -->
- MANDATORY IMPORTANT MUST ATTENTION run at least ONE graph command on key files when graph.db exists. Pattern: grep → graph trace → grep verify.
<!-- /SYNC:graph-assisted-investigation:reminder -->
<!-- SYNC:evidence-based-reasoning:reminder -->
- MANDATORY IMPORTANT MUST ATTENTION cite
file:line evidence for every claim. Confidence >80% to act, <60% = do NOT recommend.
<!-- /SYNC:evidence-based-reasoning:reminder -->
<!-- SYNC:knowledge-graph-template:reminder -->
- MANDATORY IMPORTANT MUST ATTENTION document per-file: type, pattern, symbols, dependencies, relevanceScore, evidenceLevel.
<!-- /SYNC:knowledge-graph-template:reminder -->
<!-- SYNC:fix-layer-accountability:reminder -->
- IMPORTANT MUST ATTENTION trace full data flow and fix at the owning layer, not the crash site. Audit all access sites before adding
?..
<!-- /SYNC:fix-layer-accountability:reminder -->
<!-- SYNC:critical-thinking-mindset:reminder -->
- MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact.
<!-- /SYNC:critical-thinking-mindset:reminder -->
<!-- SYNC:ai-mistake-prevention:reminder -->
- MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction.
<!-- /SYNC:ai-mistake-prevention:reminder -->
Anti-Rationalization:
| Evasion | Rebuttal |
|---|
| "Simple investigation, skip graph" | Graph reveals callers + bus consumers grep misses. Run it anyway. |
| "Already grepped, enough evidence" | Show file:line proof. No citation = no evidence. |
| "Quick task, skip TaskCreate" | Still need tracking. Create tasks, mark done immediately. |
| "Recommendation is obvious, skip validation chain" | Risk matrix applies regardless of confidence. Complete ALL steps. |
| "Deep scope wastes time for this" | Classify first. If quick, fine — but DECLARE scope before skipping steps. |
[TASK-PLANNING] Before acting, analyze task scope and systematically break it into small todo tasks and sub-tasks using TaskCreate.