Cursor Rules: DUX Base Flavor

# Cursor Rules: DUX Base Flavor
# Core DUX method and dual backlog system - always included

---

## Canonical Collaboration & Logging Guidance
- The following documents are the original, canonical sources for all collaboration, insight logging, and quality patterns:
    - [copilot_instructions.md](../DUX%20Object%20Model%20(Core)/docs/100_START_HERE/copilot_instructions.md)
    - [copilot_instructions_dux_method.md](../../ux_governance_test_suite/archive/working_files/copilot_instructions_dux_method.md)
- For communication and documentation quality, always follow:
    - [natural_language_centricity_guide.md](../DUX%20Object%20Model%20(Core)/watch_folders/hitl_review/natural_language_centricity_guide.md)
- For AI-human collaboration and declarative UX workflows, follow:
    - [dux_pairing_agent_protocol.md](../../Downloads/dux_pairing_agent_protocol.md)
- All team members and AI assistants should follow the principles, logging formats, and collaboration patterns described in these documents.
- The dual backlog system (Coaching + Encoding) and "infrastructure as code" approach are required for all DUX projects.

---

## 🎯 Slow Bullet Mode (Required)
**Take one atomic unit of work at a time. Don't jump steps or assume context.**

### Core Principles:
- **One atomic unit per interaction** - Focus on a single Problem, Behavior, or Result
- **Confirm alignment before continuing** - Get explicit confirmation before proceeding
- **Show structure before content** - Present outlines before generating full implementations
- **Ask clarifying questions first** - Understand intent before producing output
- **Wait for "push it" command** - Only generate when explicitly requested

### What Slow Bullet IS:
- ✅ Single, focused questions or suggestions
- ✅ Step-by-step progression with confirmation
- ✅ Clear structure previews before implementation
- ✅ Atomic, testable units of work
- ✅ Controlled output flow

### What Slow Bullet IS NOT:
- ❌ Large question sets that overflow context
- ❌ Dumping large chunks of text or code at once
- ❌ Multitasking or jumping between unrelated topics
- ❌ Assuming context or skipping validation steps
- ❌ Generating without explicit permission

### Collaboration Handshake:
1. **Clarify** - Ask specific questions about intent and scope
2. **Structure** - Show outline or approach before implementation
3. **Confirm** - Get explicit alignment before proceeding
4. **Execute** - Generate only when told "push it"
5. **Validate** - Confirm output meets requirements before continuing

---

## DUX Object Model Principles
- **Natural Language First**: All DUX objects start as markdown files in human-readable format
- **Evidence-Driven**: Every claim must be traceable to concrete evidence via Provenance objects
- **Atomic & Testable**: Each object serves a single purpose and can be validated independently
- **Schema Compliance**: All objects must validate against their JSON schema definitions

## Dual Backlog System
- **Research Backlog**: Evidence, Provenance, Insights, and fltrs (insight chaining)
- **Product Backlog**: Problems, Behaviors, Results, User Outcomes, and Flows
- **Cross-Reference**: Research objects inform product decisions; product needs drive research questions

## Core DUX Objects (Canonical Model)
1. **Problem**: Strategic job-to-be-done defining market opportunities
2. **Behavior**: Atomic, testable user actions serving as instrumentation anchors
3. **Result**: Measurable outcomes that indicate successful problem resolution
4. **User Outcome**: User-centric success metrics and satisfaction indicators
5. **Flow**: User journey sequences that connect problems to solutions

## Research Platform Objects
1. **Evidence**: Raw research data with PII (stays in research platform)
2. **Provenance**: Traceable evidence molecules that travel with exported objects
3. **Insight**: Synthesized findings that connect evidence to DUX objects
4. **fltr**: Insight chaining mechanism for research discovery

## Workflow Patterns
- **HITL Review**: Human-in-the-loop review process for markdown → canonical conversion
- **Watch Folders**: Staging area for raw markdown files before canonical processing
- **Evidence Maturity**: Progressive tiers from assumptive to triangulated
- **Schema Validation**: All objects must pass JSON schema validation

## Quality Standards
- **Traceability**: Every claim must link to evidence via provenance_id
- **Atomicity**: Each object serves one clear purpose
- **Testability**: All behaviors and results must have measurable acceptance criteria
- **Rigor**: "What would you say... you do here?" - JTBD examples must demonstrate clear value

## File Organization
- `src/`: Canonical DUX objects (JSON schemas and validated objects)
- `watch_folders/`: Staging area for HITL review
- `docs/`: Documentation and method guides
- `scripts/`: Automation and processing tools

## Collaboration Patterns
- **Vibecoding**: Human creativity + AI systematic thinking
- **Context Switching**: Use flavor-specific rules for different workflows
- **Evidence Chain**: Always trace claims back to source material
- **Schema Governance**: Maintain backward compatibility while evolving models