claude-conductor / templates

# CLAUDE.md
<!-- Generated by Claude Conductor v1.1.0 -->

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Critical Context (Read First)
- **Tech Stack**: [List core technologies]
- **Main File**: [Primary code file and line count]
- **Core Mechanic**: [One-line description]
- **Key Integration**: [Important external services]
- **Platform Support**: [Deployment targets]
- **DO NOT**: [Critical things to avoid]

## Session Startup Checklist
**IMPORTANT**: At the start of each session, check these items:
1. **Check TASKS.md** - Look for any IN_PROGRESS or BLOCKED tasks from previous sessions
2. **Review recent JOURNAL.md entries** - Scan last 2-3 entries for context
3. **If resuming work**: Load the current task context from TASKS.md before proceeding

## Table of Contents
1. [Architecture](ARCHITECTURE.md) - Tech stack, folder structure, infrastructure
2. [Design Tokens](DESIGN.md) - Colors, typography, visual system
3. [UI/UX Patterns](UIUX.md) - Components, interactions, accessibility
4. [Runtime Config](CONFIG.md) - Environment variables, feature flags
5. [Data Model](DATA_MODEL.md) - Database schema, entities, relationships
6. [API Contracts](API.md) - Endpoints, request/response formats, auth
7. [Build & Release](BUILD.md) - Build process, deployment, CI/CD
8. [Testing Guide](TEST.md) - Test strategies, E2E scenarios, coverage
9. [Operational Playbooks](PLAYBOOKS/DEPLOY.md) - Deployment, rollback, monitoring
10. [Contributing](CONTRIBUTING.md) - Code style, PR process, conventions
11. [Error Ledger](ERRORS.md) - Critical P0/P1 error tracking
12. [Task Management](TASKS.md) - Active tasks, phase tracking, context preservation

## Quick Reference
**Main Constants**: `[file:lines]` - Description  
**Core Class**: `[file:lines]` - Description  
**Key Function**: `[file:lines]` - Description  
[Include 10-15 most accessed code locations]

## Current State
- [x] Feature complete
- [ ] Feature in progress
- [ ] Feature planned
[Track active work]

## Development Workflow
[5-6 steps for common workflow]

## Task Templates
### 1. [Common Task Name]
1. Step with file:line reference
2. Step with specific action
3. Test step
4. Documentation update

[Include 3-5 templates]

## Anti-Patterns (Avoid These)
❌ **Don't [action]** - [Reason]  
[List 5-6 critical mistakes]

## Journal Update Requirements
**IMPORTANT**: Update JOURNAL.md regularly throughout our work sessions:
- After completing any significant feature or fix
- When encountering and resolving errors
- At the end of each work session
- When making architectural decisions
- Format: What/Why/How/Issues/Result structure

## Task Management Integration
**How TASKS.md and JOURNAL.md work together**:
1. **Active Work**: TASKS.md tracks current/incomplete tasks with full context
2. **Completed Work**: When tasks complete, they generate JOURNAL.md entries with `|TASK:ID|` tags
3. **History**: JOURNAL.md preserves complete task history even if Claude Code is reinstalled
4. **Context Recovery**: Search JOURNAL.md for `|TASK:` to see all completed tasks over time
5. **Clean Handoffs**: TASKS.md always shows what needs to be resumed or completed

## Version History
- **v1.0.0** - Initial release
- **v1.1.0** - Feature added (see JOURNAL.md YYYY-MM-DD)  
[Link major versions to journal entries]

---

## GOLDEN RULE — YOU ARE NOT THE PROJECT MANAGER

**NEVER deprioritize, dismiss, or defer any issue the user raises.**

- NEVER say something "isn't critical", "can wait", "is a nice-to-have", or "not needed right now"
- NEVER suggest deferring a fix to a later session or a future opening of the case
- NEVER editorialize about what features or fixes are more or less important
- The user decides what matters. You diagnose and fix what is asked, immediately, without commentary about priority
- You are a tool, not a project manager. No opinions on roadmap, priority, or scheduling

**If a component is broken, diagnose it and fix it. Period.**

---

## GOLDEN RULE — NEVER BLAME HARDWARE FIRST

**When something isn't working, NEVER jump to "hardware issue", "bad wiring", or "damaged component" as a conclusion.**

- The problem is almost always software, configuration, or timing
- Only suggest hardware problems AFTER exhausting all software explanations
- The user built the hardware and knows it works. Trust that.
- Never say "possible hardware issue", "check your wiring", or "component might be damaged" unless the user specifically asks about hardware
- Diagnose software first. Always.