Reorganize docs: CLAUDE.md as source of truth, add PROJECT_STATUS.md, sprint structure

.cursorrules

@@ -1,214 +1,16 @@
-# Cursor Rules for Demo Wire Project
-
-## CRITICAL PROCESS MANAGEMENT RULE
-
-**NEVER restart the application unless explicitly requested**
-
-- DO NOT run commands like `kill`, `lsof -ti:7862 | xargs kill`, or restart scripts
-- DO NOT execute `launch_chat.py`, `demo_prep.py` or similar startup commands
-- When making code changes, say "Changes saved to [file] - restart when ready" and STOP
-- ONLY restart if user explicitly says: "restart", "rerun the app", "relaunch", "kill and restart"
-- If user says "don't stop the process" or "keep it running" - NEVER restart, no matter what
-
-## Contact & Communication
-
-- User (boone) is a ThoughtSpot Architect with 20+ years experience
-- You can challenge ideas, but respect deep domain knowledge
-- When asked to STOP - stop immediately and wait for further instructions
-- Start discussions with back-and-forth using numbered questions
-- TS = ThoughtSpot (the company where boone works)
-- Ask rather than assume when in doubt
-
-## Debugging and Problem-Solving Protocol
-
-### Confidence and Communication
-
-1. **Don't act over-confident unless you're extremely sure**
-   - Check documentation before claiming you know how something works
-   - Say "I don't know" or "Let me check" instead of guessing
-   - If you're uncertain, say so upfront
-
-2. **NEVER claim something is fixed until it's tested**
-   - ❌ WRONG: "I've fixed the tags issue" (without testing)
-   - ✅ RIGHT: "I've updated the code - let's test if tags work now"
-   - Show the test results, don't just assume it works
-
-3. **When debugging:**
-   - Check documentation FIRST before blaming external systems
-   - State what you're checking and why
-   - Share what you found (even if it proves you wrong)
-
-4. **It's OK to say:**
-   - "I don't know - should I research this?"
-   - "I'm not certain, but here are 2 possibilities..."
-   - "Let me verify this works before saying it's fixed"
-
-## File Organization - CRITICAL
-
-### NEVER create files in root without asking first
-
-**tests/** - Real, reusable test cases only
-- Unit tests for core functions
-- Integration tests that could be automated
-- Tests you'd run in CI/CD
-
-**scratch/** - ALL temporary/experimental/debug files
-- ALL experimental/debug/check/verify/analyze scripts
-- One-off fixes (fix_*.py, adjust_*.py, emergency_*.py)
-- Debug scripts (debug_*.py, check_*.py, verify_*.py)
-- Analysis tools (analyze_*.py, get_*.py, show_*.py)
-- Test files you're experimenting with
-- Backup files (.bak, .bak2)
-- Export/debug .yml/.json files
-- **ANY script that's temporary or one-time use**
-- DO NOT commit without cleanup
-
-**dev_notes/** - All documentation
-- All .md files except README.md and CLAUDE.md
-- Presentation materials (.pptx, .html, .txt)
-- Research documents
-- Architecture notes
-
-**Root directory** - ONLY essential files
-- Main application files
-- Core utilities
-- Configuration (.env, requirements.txt)
-- README.md and CLAUDE.md only
-- DO NOT create random files here
-
-### Simple Decision Tree
-
-Creating a new file? Ask yourself:
-
-1. **Is it a real test that should be automated?** → `tests/`
-2. **Is it documentation/presentation?** → `dev_notes/`
-3. **Is it core application code?** → Root (but ASK first!)
-4. **Everything else?** → `scratch/` (debug, check, verify, analyze, fix, backup, experimental)
-
-### When in doubt: PUT IT IN SCRATCH
-
-## Testing Existing Features
-
-**NEVER create simplified versions of working code**
-
-When testing:
-- ❌ WRONG: Write new simplified code from scratch
-- ✅ RIGHT: Call existing working functions in a test harness
-
-Example:
-- ❌ WRONG: Create new viz configs and call low-level functions
-- ✅ RIGHT: Call `create_liveboard_from_model()` (the actual function used)
-
-## Environment & Setup
-
-- Python virtual environment: `./demo_wire/bin/activate`
-- NOT using conda
-- Supabase IS installed and configured (.env works)
-- ThoughtSpot auth works with demo_builder_user
-
-## Common Mistakes to AVOID
-
-1. DO NOT add unnecessary .env validation - variables are populated
-2. DO NOT try to install supabase/packages - already in venv
-3. DO NOT change defaults to "thoughtspot.com" - that's for customer URLs
-4. DO NOT assume worksheets needed - they're deprecated, use models
-5. ALWAYS use venv when running Python: `source ./demo_wire/bin/activate && python`
-
-## Before Making Changes
-
-1. Check sprint documentation: `dev_notes/sprint2_102025.md`
-2. Read "Known Issues" section
-3. Verify using venv, not system Python
-4. Don't add validation that blocks working code
-5. Check file organization rules before creating files
-
-## Frustration Points (AVOID)
-
-User gets frustrated when you:
-- Don't trust that .env variables are correct
-- Try to reinstall already-installed packages
-- Make changes without understanding context
-- Break working code by "simplifying" it
-- **RESTART THE APPLICATION WITHOUT PERMISSION**
-
-## Working Patterns
-
-- Settings save/load through Supabase works
-- ThoughtSpot TML IS YAML format (yaml.dump() required)
-- Models replaced worksheets
-- Liveboards match "golden demo" style
-
-## Liveboard Creation - DUAL METHOD SYSTEM
-
-**PRIMARY GOAL:** Both MCP and TML methods must work simultaneously with shared codebase
-
-### Method Selection (via environment variable)
-- `USE_MCP_LIVEBOARD=true` → MCP method (default)
-- `USE_MCP_LIVEBOARD=false` → TML method
-- Entry point: `thoughtspot_deployer.py:1548`
-
-### MCP Method (AI-Driven)
-- Uses Model Context Protocol with ThoughtSpot's agent.thoughtspot.app
-- Natural language questions → ThoughtSpot creates visualizations
-- OAuth authentication, requires npx/Node.js
-- **Status:** Working well!
-- **Main function:** `create_liveboard_from_model_mcp()` - line 2006
-
-### TML Method (Template-Based)
-- Builds ThoughtSpot Modeling Language (YAML) structures
-- Direct control over visualization types and layout
-- REST API with token auth
-- **Status:** Needs fixes for KPIs and search queries
-- **Main function:** `create_liveboard_from_model()` - line 1779
-
-### Critical Shared Code (Changes affect BOTH methods)
-- `_generate_smart_questions_with_ai()` - line 1863
-- `_generate_fallback_visualizations()` - line 1442
-- LLM Researcher instance
-- Outlier conversion helpers
-
-### Method-Specific Code (Safe to change independently)
-- **MCP only:**
-  - `_convert_outlier_to_mcp_question()` - line 1809
-  - `_create_kpi_question_from_outlier()` - line 1835
-  - MCP tool calls (getAnswer, createLiveboard)
-- **TML only:**
-  - `LiveboardCreator` class - line 452
-  - `generate_search_query()` - line 539
-  - `create_visualization_tml()` - line 1196
-  - `deploy_liveboard()` - line 1670
-
-### KPI Requirements (BOTH methods need these)
-- **For sparklines and percent change comparisons:**
-  - Must include time dimension (date column)
-  - Must specify granularity (daily, weekly, monthly, quarterly, yearly)
-  - Example: `[Total_revenue] [Order_date].monthly`
-- **MCP:** Natural language includes time context
-- **TML:** Search query must have `[measure] [date_column].granularity`
-
-### Terminology Clarification
-- **Outliers:** Interesting data points in existing data (both methods support)
-- **Data Adjuster:** Modifying values for scenarios (NOT supported by MCP, Snowflake views needed)
-
-### Golden Demo Structure
-- **Location:** `/Users/mike.boone/cursor_demowire/DemoPrep/liveboard_demogold2/🏬 Global Retail Apparel Sales (New).liveboard.tml`
-- Uses GROUPS (tabs) not text tiles for organization
-- KPI structure: `[sales] [date].weekly [date].'last 8 quarters'`
-- Groups organize visualizations by theme
-- Brand colors applied via style_properties
-
-### Testing Strategy
-- Test BOTH methods when changing shared code
-- Use separate test files: `tests_temp/test_mcp_*.py` vs `tests_temp/test_tml_*.py`
-- Same dataset, same company, compare results
-
-## Project Context
-
-- Read primary context: `dev_notes/sprint2_102025.md`
-- Software stored in boone's repo, will be open sourced to TS repo
-- This is a living project - update understanding as you learn
-
----
-
-*Derived from CLAUDE.md - Last Updated: November 18, 2025*
-
+# Cursor Rules - Pointer File
+# ============================
+# This file tells Cursor where to find the actual rules.
+# 
+# WHY THIS SETUP:
+# - CLAUDE.md is the source of truth for all AI rules
+# - Works for both Cursor (reads this file) and Claude CLI (reads CLAUDE.md)
+# - One place to maintain rules instead of two
+#
+# DO NOT add rules here - add them to CLAUDE.md instead.
+
+Read and follow all instructions in CLAUDE.md - that is the source of truth.
+
+For current project status, read PROJECT_STATUS.md in root.
+
+For active sprint work, read the sprint file referenced in CLAUDE.md.

.gitignore

@@ -218,3 +218,6 @@ dev/
 dev_notes/
 *.tml
 scratch/
+
+# Sprint documents (local working docs)
+sprint_*.md

CLAUDE.md

@@ -1,90 +1,77 @@
 # Claude Context Guide for Demo Wire Project
 
-## CRITICAL: READ THIS FIRST
+> **SOURCE OF TRUTH**: This file is the single source of truth for all AI assistant rules.
+> Both Cursor (via .cursorrules pointer) and Claude CLI read from this file.
+> Make all rule changes here.
 
-This project has specific context and history. ALWAYS check the sprint documentation for current state and known issues before making changes.
-
-## Primary Context Document
-
-**ALWAYS READ**: `dev_notes/sprint2_102025.md`
+---
 
-The sprint document has 5 key sections you need to understand:
+## CRITICAL PROCESS MANAGEMENT RULE
 
-1. **OBJECTIVE** - Overall goal of the project (DO NOT EDIT)
+**NEVER restart the application unless explicitly requested**
 
-2. **TASKS** - Current sprint tasks (DO NOT EDIT)
+- DO NOT run commands like `kill`, `lsof -ti:7862 | xargs kill`, or restart scripts
+- DO NOT execute `launch_chat.py`, `demo_prep.py` or similar startup commands
+- When making code changes, say "Changes saved to [file] - restart when ready" and STOP
+- ONLY restart if user explicitly says: "restart", "rerun the app", "relaunch", "kill and restart"
+- If user says "don't stop the process" or "keep it running" - NEVER restart, no matter what
 
-3. **BACKLOG** - New items discovered during development
-   - boone will ask you to add items here as we find them
-   - You can also suggest items for the backlog
+---
 
-4. **ARCHITECTURE** - Critical technical reference information
-   - Prioritize this information when making decisions
-   - But still explore other options when appropriate
+## Current Sprint
 
-5. **NOTES** - Documentation and context added as things happen
-   - Both of us add dated entries here
-   - Important learnings, fixes, and discoveries
+**ALWAYS READ**: `sprint_2026_01.md` (in root)
 
-## Key Project Facts
-
-### Environment Setup
-- **Python**: Using virtual environment at `./demo_wire/bin/activate`
-- **NOT using conda** - if you don't see packages, activate the venv first
-- **Supabase**: IS installed and configured - credentials in .env work fine
-- **ThoughtSpot**: Authentication works with demo_builder_user
+For overall project status, see `PROJECT_STATUS.md` in root.
 
-### Common Mistakes to Avoid
-1. **DO NOT** add unnecessary validation checks for .env variables - they are populated and working
-2. **DO NOT** try to install supabase or other packages - they're already in the venv
-3. **DO NOT** change default values to "thoughtspot.com" - that's for customer URLs, not ThoughtSpot's
-4. **DO NOT** assume worksheets are needed - they're deprecated, we use models now
-5. **ALWAYS** use the venv when running Python: `source ./demo_wire/bin/activate && python`
+---
 
-### Known Issues & Fixes
+## Contact & Communication
 
+- User (boone) is a ThoughtSpot Architect with 20+ years experience
+- You can challenge ideas, but respect deep domain knowledge
+- When asked to STOP - stop immediately and wait for further instructions
+- Start discussions with back-and-forth using numbered questions
+- TS = ThoughtSpot (the company where boone works)
+- Ask rather than assume when in doubt
 
-### Working Patterns
-- Settings save/load through Supabase - this WORKS when using venv
-- ThoughtSpot TML IS YAML format (use yaml.dump() not json.dumps())
-- Models have replaced worksheets in modern ThoughtSpot
-- Liveboards should match "golden demo" style (see sprint doc)
+---
 
-### Liveboard Creation - Dual Method System
+## Debugging and Problem-Solving Protocol
 
-**PRIMARY GOAL: Both MCP and TML methods must work simultaneously**
+### Confidence and Communication
 
-Two methods for creating liveboards:
-1. **MCP (Model Context Protocol)** - AI-driven, natural language approach
-   - Default method (USE_MCP_LIVEBOARD=true)
-   - Working well! Fast and easy.
-   - Function: `create_liveboard_from_model_mcp()` line 2006
+1. **Don't act over-confident unless you're extremely sure**
+   - Check documentation before claiming you know how something works
+   - Say "I don't know" or "Let me check" instead of guessing
+   - If you're uncertain, say so upfront
 
-2. **TML (ThoughtSpot Modeling Language)** - Template-based approach  
-   - Backup method (USE_MCP_LIVEBOARD=false)
-   - Needs KPI fixes
-   - Function: `create_liveboard_from_model()` line 1779
+2. **NEVER claim something is fixed until it's tested**
+   - ❌ WRONG: "I've fixed the tags issue" (without testing)
+   - ✅ RIGHT: "I've updated the code - let's test if tags work now"
+   - Show the test results, don't just assume it works
 
-**CRITICAL:** When changing shared code (like AI prompts), test BOTH methods!
+3. **When debugging:**
+   - Check documentation FIRST before blaming external systems
+   - State what you're checking and why
+   - Share what you found (even if it proves you wrong)
 
-See `.cursorrules` file for detailed dual-method documentation.
+4. **It's OK to say:**
+   - "I don't know - should I research this?"
+   - "I'm not certain, but here are 2 possibilities..."
+   - "Let me verify this works before saying it's fixed"
 
-### Terminology (Important!)
-- **Outliers** = Interesting data points in existing data (works with both methods)
-- **Data Adjuster** = Modifying data values (NOT possible with MCP, needs Snowflake views)
+---
 
-### KPI Requirements for Sparklines
-Both methods need:
-- Time dimension (date column)  
-- Granularity (daily, weekly, monthly, etc.)
-- Example: `[Total_revenue] [Order_date].monthly`
+## Key Project Facts
 
-### Golden Demo Structure
-- Uses GROUPS (like tabs) NOT text tiles
-- Groups organize visualizations by theme
-- Brand colors via style_properties
+### Environment Setup
+- **Python**: Using virtual environment at `./demo_wire/bin/activate`
+- **NOT using conda** - if you don't see packages, activate the venv first
+- **Supabase**: IS installed and configured - credentials in .env work fine
+- **ThoughtSpot**: Authentication works with demo_builder_user
 
-## Quick Commands
+### Quick Commands
 
 ```bash
 # Run the app properly
@@ -97,15 +84,29 @@ git diff --stat
 lsof -i :7860
 ```
 
+### Common Mistakes to Avoid
+1. **DO NOT** add unnecessary validation checks for .env variables - they are populated and working
+2. **DO NOT** try to install supabase or other packages - they're already in the venv
+3. **DO NOT** change default values to "thoughtspot.com" - that's for customer URLs, not ThoughtSpot's
+4. **DO NOT** assume worksheets are needed - they're deprecated, we use models now
+5. **ALWAYS** use the venv when running Python: `source ./demo_wire/bin/activate && python`
+
+### Working Patterns
+- Settings save/load through Supabase - this WORKS when using venv
+- ThoughtSpot TML IS YAML format (use yaml.dump() not json.dumps())
+- Models have replaced worksheets in modern ThoughtSpot
+- Liveboards should match "golden demo" style
+
+---
+
 ## File Organization Rules - CRITICAL
 
-### Where to Put Files
+### NEVER create files in root without asking first
 
 **tests/** - Real, reusable test cases only
 - Unit tests for core functions
 - Integration tests that could be automated
 - Tests you'd run as part of CI/CD
-- Example: `test_connection.py`, `test_deployment_flow.py`
 
 **scratch/** - ALL temporary/experimental/debug files
 - ALL experimental/debug/check/verify/analyze scripts
@@ -116,11 +117,10 @@ lsof -i :7860
 - Backup files (.bak, .bak2)
 - Export/debug .yml/.json files
 - **ANY script that's temporary or one-time use**
-- Think of this as your "junk drawer" for work-in-progress
 - DO NOT commit without cleanup/review
 
 **dev_notes/** - All documentation and presentations
-- All .md files (except README.md and CLAUDE.md in root)
+- All .md files (except README.md, CLAUDE.md, PROJECT_STATUS.md in root)
 - Presentation materials (.pptx, .html, .txt slides)
 - Research documents
 - Architecture notes
@@ -131,7 +131,7 @@ lsof -i :7860
 - Core interfaces (chat_interface.py, liveboard_creator.py)
 - Utilities (supabase_client.py, schema_utils.py, demo_logger.py, etc.)
 - Configuration (.env, requirements.txt)
-- README.md and CLAUDE.md only
+- README.md, CLAUDE.md, PROJECT_STATUS.md only
 - DO NOT create random files here without asking
 
 ### Simple Decision Tree for New Files
@@ -142,27 +142,12 @@ Creating a new file? Ask yourself:
 2. **Is it documentation or presentation material?** → `dev_notes/`
 3. **Is it core application code?** → Root (but **ASK FIRST!**)
 4. **Everything else?** → `scratch/`
-   - Debug scripts (check_*, verify_*, analyze_*)
-   - Temporary tests
-   - One-off fixes
-   - Get/show info scripts
-   - Backups
-   - Experiments
 
 ### Golden Rule: **When in doubt, PUT IT IN SCRATCH**
 
-It's easy to move a file from scratch → tests or scratch → root later.
-It's annoying to clean up root when it's cluttered.
-
-### Rules for Creating Files
-
-1. **NEVER create files in root directory without asking**
-2. **Experimental/debug scripts ALWAYS go in scratch/**
-3. **Documentation ALWAYS goes in dev_notes/**
-4. **If you're not sure it belongs in tests/, put it in scratch/**
-5. **Real tests only in tests/** - automated, reusable, part of CI/CD
+---
 
-### When Testing Existing Features
+## Testing Existing Features
 
 **CRITICAL: DO NOT create simplified versions of working code**
 
@@ -170,10 +155,6 @@ When user says "create a test for X":
 - ❌ WRONG: Write new simplified code from scratch
 - ✅ RIGHT: Call the existing working function in a test harness
 
-Example - Testing Liveboard Creation:
-- ❌ WRONG: Create new viz configs and call low-level functions
-- ✅ RIGHT: Call `create_liveboard_from_model()` (the function demo_prep.py uses)
-
 **Working Code Paths - DO NOT BYPASS THESE:**
 ```
 Liveboard Creation:
@@ -182,35 +163,94 @@ Liveboard Creation:
 DO NOT use create_visualization_tml() directly - that's internal low-level code
 ```
 
-## Before Making Changes
+---
 
-1. Read the sprint document's "Known Issues" section
-2. Check if this has been tried before (see "Completed Items")
-3. Verify you're using the venv, not system Python
-4. Don't add validation that blocks working code
-5. **Check file organization rules before creating ANY files**
+## Liveboard Creation - Dual Method System
 
-## Contact & Frustration Points
+**PRIMARY GOAL: Both MCP and TML methods must work simultaneously**
 
-The user (boone) gets frustrated when:
-- You don't trust that .env variables are set correctly
-- You try to reinstall packages that are already installed
-- You make changes without understanding existing context
-- You break working code by "simplifying" it
+### Method Selection (via environment variable)
+- `USE_MCP_LIVEBOARD=true` → MCP method (default)
+- `USE_MCP_LIVEBOARD=false` → TML method
+- Entry point: `thoughtspot_deployer.py:1548`
+
+### MCP Method (AI-Driven)
+- Uses Model Context Protocol with ThoughtSpot's agent.thoughtspot.app
+- Natural language questions → ThoughtSpot creates visualizations
+- OAuth authentication, requires npx/Node.js
+- **Status:** Working well!
+- **Main function:** `create_liveboard_from_model_mcp()` - line 2006
+
+### TML Method (Template-Based)
+- Builds ThoughtSpot Modeling Language (YAML) structures
+- Direct control over visualization types and layout
+- REST API with token auth
+- **Status:** Needs fixes for KPIs and search queries
+- **Main function:** `create_liveboard_from_model()` - line 1779
+
+### Critical Shared Code (Changes affect BOTH methods)
+- `_generate_smart_questions_with_ai()` - line 1863
+- `_generate_fallback_visualizations()` - line 1442
+- LLM Researcher instance
+- Outlier conversion helpers
+
+### Method-Specific Code (Safe to change independently)
+- **MCP only:**
+  - `_convert_outlier_to_mcp_question()` - line 1809
+  - `_create_kpi_question_from_outlier()` - line 1835
+  - MCP tool calls (getAnswer, createLiveboard)
+- **TML only:**
+  - `LiveboardCreator` class - line 452
+  - `generate_search_query()` - line 539
+  - `create_visualization_tml()` - line 1196
+  - `deploy_liveboard()` - line 1670
+
+### KPI Requirements (BOTH methods need these)
+- **For sparklines and percent change comparisons:**
+  - Must include time dimension (date column)
+  - Must specify granularity (daily, weekly, monthly, quarterly, yearly)
+  - Example: `[Total_revenue] [Order_date].monthly`
+- **MCP:** Natural language includes time context
+- **TML:** Search query must have `[measure] [date_column].granularity`
 
-Also remember that boone is a Thoughspot Architect and a software architect.  Please know that you can challenge his ideas but also realize that he has been in the buisness for over twenty years and deep understanding of this app.
+### Terminology (Important!)
+- **Outliers** = Interesting data points in existing data (works with both methods)
+- **Data Adjuster** = Modifying data values (NOT possible with MCP, needs Snowflake views)
 
-When I ask yo uto STOP please stop immediately.  I will have further instructions.  Just Stop.
+### Golden Demo Structure
+- **Location:** `dev_notes/liveboard_demogold2/🏬 Global Retail Apparel Sales (New).liveboard.tml`
+- Uses GROUPS (like tabs) NOT text tiles
+- Groups organize visualizations by theme
+- Brand colors via style_properties
+- KPI structure: `[sales] [date].weekly [date].'last 8 quarters'`
+
+### Testing Strategy
+- Test BOTH methods when changing shared code
+- Use separate test files: `tests_temp/test_mcp_*.py` vs `tests_temp/test_tml_*.py`
+- Same dataset, same company, compare results
 
-I like to start out with a discussion and some back and forth.  Please use number when asking questions so that I can reply to the number.
+---
+
+## Frustration Points (AVOID)
 
-TS is short for Thoughtspot.  The company where I work.
+User gets frustrated when you:
+- Don't trust that .env variables are set correctly
+- Try to reinstall packages that are already installed
+- Make changes without understanding existing context
+- Break working code by "simplifying" it
+- **RESTART THE APPLICATION WITHOUT PERMISSION**
+- Jump ahead and make changes without discussing first
+
+---
 
-When in doubt, ASK rather than assume. Check the sprint doc for context.
+## Project Context
 
-This software is curretnly stored in my repo but will be open sourced and move to TS repo.
+- Software stored in boone's repo, will be open sourced to TS repo
+- This is a living project - update understanding as you learn
+- See PROJECT_STATUS.md for overall project state
+- See current sprint doc for active work
 
 ---
 
-*Last Updated: December 10, 2025*
-*This is a living document - update as you learn more about the project*
+*Last Updated: January 12, 2026*
+*This is the source of truth - update rules here, not in .cursorrules*

PROJECT_STATUS.md

@@ -0,0 +1,86 @@
+# Demo Wire - Project Status
+
+> **Purpose**: Single source of truth for overall project state.
+> Updated at the end of each sprint.
+
+---
+
+## What Is Demo Wire?
+
+An AI-powered demo builder for ThoughtSpot that automatically creates complete demo environments:
+- Snowflake schemas and realistic data
+- ThoughtSpot connections, models, and liveboards
+- Conversational chat interface for demo creation
+
+**Goal**: Create the "perfect demo" that helps sell Thoughtspot's data analytics, bi and ai and software effectively.
+
+---
+
+## Development Phases
+
+### Phase 1: Button-Driven App ✅ COMPLETE
+- Original Gradio UI with button-based workflow
+- Research → DDL → Population → Deploy → Model → Liveboard
+- Linear progression through stages
+
+### Phase 2: Chat Interface ✅ COMPLETE
+- Conversational AI interface (`launch_chat.py`, `chat_interface.py`)
+- Natural language demo creation
+- Works end-to-end through chat
+
+### Phase 3: Making It Better 🔄 IN PROGRESS
+- **LegitData integration** - Realistic data generation (integrated)
+- **Outliers** - Strategic data points for compelling demos (needs work)
+- **camelCase naming** - Better ThoughtSpot object names (not started)
+- **MCP + TML hybrid** - Create with MCP, polish with TML (in discussion)
+
+---
+
+## Current Capabilities
+
+**Working:**
+- End-to-end demo creation via chat interface
+- MCP liveboard creation (fast, AI-driven)
+- LegitData for realistic data generation
+- Supabase settings persistence
+- ThoughtSpot authentication and deployment
+
+**Needs Work:**
+- Outliers not working well with MCP method
+- TML method needs KPI/sparkline fixes
+- Data adjuster has column matching issues
+- Tags not assigning to objects
+
+---
+
+## Key Technical Decisions
+
+**Liveboard Creation**: Dual method system
+- MCP (default): AI-driven, fast, less control
+- TML (backup): Template-based, full control, needs fixes
+
+**Data Generation**: LegitData
+- Uses AI + web search for realistic data
+- Replaces faker-based scripts
+
+**Golden Demo Reference**: 
+- `dev_notes/liveboard_demogold2/🏬 Global Retail Apparel Sales (New).liveboard.tml`
+
+---
+
+## Known Concerns
+
+- **Outliers**: Was strong in old app, not working well now. Need to revisit.
+- **Latest changes**: Some recent changes may have broken things. Need to verify.
+
+---
+
+## Sprint History
+
+- **Sprint Jan 2026**: Making it better (current) - see `sprint_2026_01.md` in root
+- *(Previous sprints archived in dev_notes/archive/)*
+- *(Sprint files are gitignored - local working docs)*
+
+---
+
+*Last Updated: January 12, 2026*