Skip to content

brief.md

Latest commit

 

History

History
483 lines (312 loc) · 32.4 KB

brief.md

File metadata and controls

483 lines (312 loc) · 32.4 KB

Project Brief: ThreeDoors

Project Repository: github.com/arcavenae/ThreeDoors.git Document Version: 1.0 Last Updated: 2025-11-07 Source: Brainstorming session results (docs/brainstorming-session-results.md)

Executive Summary

ThreeDoors is a personal achievement partner disguised as a todo app. Unlike traditional task managers that create anxiety through demands for perfect planning and complete information, ThreeDoors works with human psychology to help users make any improvement—in what they work on, what they track, or how they align actions with values—right now, better than yesterday.

The app addresses dual goals: learning the BMAD methodology through real-world application, and creating a todo app that actually helps with organization. Traditional todo lists often make things worse—they enable procrastination, drain energy, and create anxiety. ThreeDoors inverts this by embodying "progress over perfection"—encouraging imperfect action over perfect planning.

Built initially for the developer's own use, with potential to help others who struggle with similar challenges around task management and organization.

Key value proposition: A todo app that reduces friction, respects human psychology, and helps you get organized while demonstrating the BMAD method in practice.

Problem Statement

The Problem

There are two interconnected problems being addressed:

  1. Learning BMAD effectively requires a real goal. Academic exercises and "hello world" examples don't provide the authentic stakes needed to truly internalize a methodology. Real needs drive better learning outcomes than theoretical requirements.

  2. Traditional todo apps create more problems than they solve. They demand perfect planning upfront, enable procrastination, drain creative energy, and frequently cause anxiety rather than alleviating it. Users end up with scattered, partially completed lists that become intimidating rather than helpful. The act of list-making itself often becomes a procrastination tactic.

The current state is inefficiency on both fronts: no effective way to learn BMAD through practical application, and existing todo solutions that work against human psychology rather than with it.

Why now: The tech industry continuously reinvents itself—Internet, Web Services, Cloud, SaaS, now AI. Professionals either keep learning or retire. This project serves both: mastering BMAD through authentic application, creating a todo app that actually helps. Real needs drive real learning.

Proposed Solution

Core Concept

ThreeDoors is a personal achievement partner that works with human psychology instead of against it. The fundamental principle: progress over perfection. Any improvement—in what you work on, what you track, or how you align actions with values—matters. Better today than yesterday.

Key Differentiators

  1. Works with your existing tools, not against them. ThreeDoors doesn't replace what you already use—it connects to where your tasks live. Storage of todo items is the least interesting part. ThreeDoors integrates with Apple Notes, Linear, Jira, Google Calendar, Obsidian, Todoist, and other systems as backends, bringing work together from wherever it already exists.

  2. Works with human nature. Reduces friction to starting. Respects varying energy states. Encourages imperfect action over perfect planning. Recognizes that action brings understanding, then you adjust.

  3. Enables your best self. Not optimized for corporate efficiency or being a better employee—optimized for becoming who you want to be.

Why This Succeeds

Traditional todo apps fail because they're another boss, another obligation, another source of anxiety. ThreeDoors inverts this: it's a partner that meets you where you are, helps you take the next small step, and gets out of your way. Starting brings the light that reveals the path forward.

In a sense, it's an anti-todo app—but that's the side story. The main story is building progressively more user-enabling technology while mastering BMAD methodology through authentic application.

Long-term Vision

While starting as task management, ThreeDoors could evolve toward a personal operating system that aligns daily actions with deeper goals and values. But first: build something useful. Progress over perfection.

Target Users

Primary User: The Developer

ThreeDoors is built first for its creator—a tech professional navigating continuous industry reinvention, juggling multiple responsibilities, and seeking better organization without the anxiety traditional todo apps create.

Characteristics:

  • Operates across multiple platforms and contexts: Mac, Linux, Geodesic, iPhone, voice interfaces, Slack, Google Workspace, Apple Notes
  • Manages work across multiple systems (Jira, Linear, email, notes, calendars)
  • Embodies multiple roles simultaneously: employee, parent, partner, student, teacher, expert, novice
  • Needs seamless navigation between contexts as opportunity presents—minimal friction between roles
  • Values progress over perfection; prefers starting imperfectly to planning endlessly
  • Experiences varying energy states—sometimes focused, sometimes overwhelmed, sometimes stuck
  • Recognizes procrastination patterns and wants tools that work with psychology, not against it

Why Multiple Archetypes Matter

None of us is a single persona. We all hold multiple truths simultaneously. ThreeDoors recognizes three recurring patterns that the same person may experience in different contexts:

  1. The Hyperfocus Navigator - Works with ADHD tendencies as fuel. Needs variety to combat subject fatigue, momentum transfer between tasks, ways to sneak progress toward intimidating long-term goals.

  2. The Overwhelmed Juggler - Balancing multiple demand sources. Needs to trust nothing falls through cracks while maintaining flexibility. Seeks to "be the dog, not the tail being wagged."

  3. The Stuck Starter - Struggles with inertia. Needs low barriers to re-engagement, gentle encouragement without guilt, belief that any movement matters.

The same person experiences all three states. ThreeDoors helps navigate between them seamlessly as context shifts.

Goals & Success Metrics

Business Objectives

  1. Master BMAD methodology through authentic application - Complete project demonstrating effective product development process, documented thoroughly enough to teach others and apply to future projects.

  2. Achieve measurably better organization - Reduce scattered task lists, increase visibility into what matters, decrease time lost to decision fatigue and unclear priorities.

  3. Create usable tool for daily use - Build something good enough to use every day, progressively improving based on real needs.

  4. Capture the full story, not just the checklist - Track not only WHAT was done, but WHY it mattered and why it was important. Reduce friction in preparing meaningful summaries, improve alignment between effort and goals, help others (spouse, boss, coworkers) understand the value of work completed.

User Success Metrics

Since the primary user is the developer, success is measured by personal experience:

  • Reduced friction to starting - Lower barrier to taking action on tasks vs. previous methods
  • Better today than yesterday - Any measurable improvement in what you work on, what you track, or alignment with goals
  • Decreased anxiety - Less stress around task management vs. traditional todo apps
  • Increased completion rate - More tasks moving from intention to action
  • Cross-context fluidity - Easier navigation between roles and platforms without losing track
  • Meaningful context capture - Easier to record and recall why tasks mattered, improving communication with stakeholders and personal reflection
  • Administrative ease - Less time/effort preparing timesheets, status reports, achievement summaries that convey actual value

Key Performance Indicators (KPIs)

  • Daily use rate: Tool is opened and used daily for at least 1 week straight (habit formation)
  • "Better than yesterday" streak: Number of consecutive days showing improvement on any dimension
  • Integration breadth: Number of external systems successfully connected (Notes, Jira, Linear, etc.)
  • BMAD documentation completeness: Project brief, PRD, and development process fully documented
  • Administrative time saved: Time to prepare weekly timesheet/status summary vs. previous method
  • Context richness: Percentage of completed tasks with captured "why" context vs. bare checklist items
  • Personal assessment: Monthly self-evaluation—"Is this actually helping?" scored 1-10

MVP Success Criteria

MVP succeeds if:

  • Used daily for organization (replaces or augments current scattered approach)
  • Demonstrates BMAD process clearly enough to explain to colleagues
  • Reduces anxiety around task management vs. previous state
  • Shows measurable progress (any dimension) compared to yesterday
  • Makes it easier to explain what was accomplished and why it mattered

Implementation Approach: Phased Validation

Phase 1: Technical Demo & Validation (Current - Week 1)

Before investing in Apple Notes integration and full MVP development, ThreeDoors validates the core UX concept through a minimal Technical Demo:

Technical Demo Features:

  • Three Doors Interface - Present three randomly selected tasks from local text file, validate that random selection reduces friction vs. scrolling traditional lists
  • Door Selection & Expanded Detail View - Select doors with keyboard (A/W/D or arrow keys), view task details in expanded view with status actions
  • Quick Search & Command Palette - Press / for live task search with bottom-up display; vi-style :commands for power-user actions (:add, :mood, :stats, :edit, :help, :quit)
  • Mood Tracking - Press M anytime to log emotional state (Focused, Tired, Stressed, Energized, Distracted, Calm, or custom text); creates data foundation for future learning features
  • Task Status Management - Mark tasks complete (C), blocked (B), in progress (I), expand (E), fork (F), procrastinate (P), or rework (R)
  • Session Metrics Tracking - Silent background collection of door selection patterns, task bypass behaviors, status changes, mood entries, and timestamps—provides objective data for validation decision
  • "Progress over perfection" messaging - Embedded throughout interface to reinforce core philosophy

Validation Success Criteria:

  • Developer uses tool daily for 1 week
  • Three Doors selection feels meaningfully different from traditional list scrolling
  • Session metrics provide objective evidence that UX reduces friction
  • Decision gate: Metrics + subjective experience inform proceed/pivot/abandon decision

Why Technical Demo First:

  • Risk reduction: Validates core UX concept before investing in complex Apple Notes integration
  • Fast feedback: 4-8 hours development time, 1 week validation period
  • Data-driven decision: Session metrics (door selections, bypasses, mood correlation) provide objective validation evidence, not just gut feel
  • Learning foundation: Mood tracking and pattern capture in Technical Demo creates data infrastructure needed for future learning features (Epic 4)

If Technical Demo validation succeeds → proceed to Full MVP with Apple Notes integration.

MVP Scope

Core Features (Must Have)

  1. Simple task capture with Apple Notes integration - Dead simple way to capture tasks with optional context (what and why). Apple Notes as storage backend—can be updated on mobile even when app isn't in hand. CLI/TUI interface (iTerm2-friendly).

  2. Task viewing and checking off - View tasks from Apple Notes, mark items complete. Bring existing notes into workflow seamlessly.

  3. "Better than yesterday" tracking - Show any improvement across dimensions: what you worked on, what you tracked, or alignment with values/goals. Visible progress comparison. (Definition will evolve—progress over perfection applies here too.)

  4. Values/goals always visible - Keep big picture in sight during task work. Prevent getting lost in minutiae. User-defined values remain present throughout session.

  5. Choose-your-own-adventure flow - Interactive CLI/TUI navigation that respects current state (focused, overwhelmed, stuck). Options rather than demands. Meet user where they are.

  6. One improvement prompt per session - Single question: "What's one thing you could improve about this list/task/goal right now?" Forces continuous improvement without overwhelming.

  7. Progress over perfection messaging - Core philosophy embedded in interaction patterns and copy. Encourages starting imperfectly, celebrates any movement.

Out of Scope for MVP

  • Additional system integration (Jira, Linear, Slack, Google Calendar) - Future phase
  • LLM-powered assumption challenging and dependency collapse
  • Trading mechanic (easy tasks unlock rewards)
  • Gamification and fandom-based elements
  • Advanced replanning capabilities
  • Task emotional weighting system
  • Multi-mode engagement (audio, games, notifications beyond CLI/TUI)
  • Dedicated mobile apps (Apple Notes provides mobile bridge for MVP)
  • Voice interface integration
  • Habit-based gentle check-ins

MVP Success Criteria

MVP is successful when:

  • Used regularly for task management (realistic timeline: could take a couple weeks to reach this point)
  • Replaces or meaningfully augments current scattered task management approach
  • Demonstrates all core features working together cohesively
  • Reduces anxiety vs. previous methods (subjective but honest assessment)
  • Apple Notes integration works bidirectionally (update in app or on iPhone)
  • Shows "better than yesterday" on any dimension (measured imperfectly—will improve over time)
  • Captures enough context (why) to make timesheet/status prep easier
  • Code quality and documentation demonstrate BMAD methodology clearly

Post-MVP Vision

Phase 2 Features (Near-term)

Once MVP proves the core philosophy and daily utility:

  1. Highest-value integrations - Connect to the systems that matter most first. Candidates: Jira (work tasks), Linear (project management), Google Calendar (time blocking). Prove the integration pattern works before expanding.

  2. LLM-powered assistance - Rudimentary capabilities to start: help break down intimidating tasks, challenge assumptions, suggest next steps. Support multiple providers (local via Ollama/vLLM, OpenRouter, Claude, OpenAI, Gemini) with clear configuration for which is used when. Start simple, expand as patterns emerge.

  3. Exercising the WHY - Regular prompts and patterns to capture why tasks matter. Build the habit of context capture before attempting automated summaries. Learn what "meaningful context" actually looks like in practice.

  4. Cross-platform consistency - Ensure experience works well across Mac, Linux, and Geodesic environments. Apple Notes continues providing mobile bridge.

  5. Door theme system - Replace the uniform rounded-border door appearance with visually distinct themed doors using ASCII/ANSI art frames. Each door gets its own visual personality (e.g., minimalist, sci-fi, Japanese shoji). Users can browse and select a door theme during first-run onboarding (scroll through previews), change themes later via a settings/preferences view in the TUI, or override the theme via config file edits (config.yaml). Themed doors add personality and delight, combat interface fatigue, and create stronger mental associations with tasks. Start with 3 high-reliability themes, expand the collection over time.

Long-term Direction (12+ months)

As understanding deepens from real use:

  1. Context-aware summaries - Once WHY capture is habitual and patterns are clear, generate timesheet entries, status updates, achievement summaries automatically. Requires Phase 2 WHY practice first.

  2. Emotional intelligence - Learn which tasks cause avoidance. Adapt presentation based on current state. Gentle re-engagement without guilt.

  3. Momentum and flow - Features that help enter and maintain flow states. Work with energy rather than against it.

  4. Broader integration - Expand to additional systems as patterns prove out: Slack, Obsidian, Todoist, email, voice memos, etc.

  5. Multi-mode engagement - Voice interface, mobile-optimized modes, notification strategies. Meet user in whatever context they're in.

Aspirational Territory

Ideas worth keeping in mind without committing to specific implementation:

  • Learning system that helps identify and pursue what matters most
  • Psychology-validated design patterns
  • Adaptive partnership that evolves with the user
  • Tool that helps you become who you want to be

Guiding Principle

Roadmap details emerge from real use. Start doing. Build what's useful today. Let tomorrow's improvements reveal themselves through authentic application. Progress over perfection applies to planning too.

Technical Considerations

Platform Requirements

  • Target Platform: Mac (primary and MVP focus)
  • Mobile Access: iPhone via Apple Notes integration (bidirectional sync)
  • Primary Interface: CLI/TUI optimized for iTerm2 and similar terminal emulators
  • Future Remote Access: Small agent for connecting from internet-connected environments (e.g., Geodesic docker images) to process running with local Apple Notes access. Allows quick grooming, consultation, note-taking from remote contexts. (Future goal, not MVP.)

Technology Preferences

  • Language: Go (already established)
  • TUI Framework: Bubbletea/Charm Bracelet ecosystem - use existing, proven framework
  • Storage: Apple Notes (user-facing tasks) + local enrichment layer (metadata, cross-references, relationships)
  • Enrichment Storage: SQLite and/or vector database for ThreeDoors-specific metadata that shouldn't or can't live in source systems
  • Build System: Make or Task for builds
  • Code Quality: gofumpt for formatting, idiomatic Go patterns

Architecture Considerations

Apple Notes Integration:

  • Research Go options for AppleScript bridge (test what's available/recommended from Go)
  • Investigate: Can we read/write Apple Notes effectively from Go? Performance characteristics?
  • Design data model compatible with Notes structure (checklists, plain text, links)
  • Bidirectional sync: changes in either direction reflect in both
  • Consider: Direct enrichment of Notes (e.g., embed JIRA slugs directly in note content)

Enrichment Layer:

  • Core concept: ThreeDoors needs its own metadata storage for cross-linking, relationships, and enrichment that can't or shouldn't modify source systems
  • Direct enrichment: When safe and authorized (e.g., add JIRA slug to Apple Notes content)
  • Separate enrichment: When modifications would "poison" source or lack permissions (e.g., can't edit Atlassian Polaris project, can't modify Linear tickets, shouldn't pollute Jira labels)
  • Cross-linking: Track when same task exists in multiple systems (Apple Notes + Jira, Calendar + Linear, etc.)
  • Storage options: SQLite for relational metadata, vector database for semantic search/similarity (both permissible alongside Apple Notes)

LLM Provider Flexibility (Phase 2):

  • Support multiple providers: Local (Ollama, vLLM), Cloud (OpenRouter, Claude, OpenAI, Gemini)
  • Configuration: File-based (YAML/TOML) and/or interactive setup, possibly with OIDC option
  • Clear mapping: Which provider for which purposes
  • Fallback strategy: Work without LLM if unavailable
  • Cost/privacy awareness: Local when possible, cloud when quality matters

Integration Architecture:

  • Plugin/adapter pattern for external systems (Jira, Linear, Calendar, etc.)
  • Each integration optional and independently configurable
  • Respect permissions: Read-only when lacking edit access, graceful degradation
  • Data flows bidirectionally where safe and authorized
  • Common abstraction: "Task" regardless of source, with source-specific metadata

Repository Structure:

  • Clear separation: core engine, TUI layer, integration adapters, LLM providers, enrichment storage
  • Plugin architecture allows independent development of integrations
  • Documentation lives with code

Security & Privacy:

  • Local-first: All data stored locally or in user's iCloud (Apple Notes)
  • No telemetry: No tracking, no analytics sent anywhere
  • LLM privacy: User controls which provider sees what data. Local models for sensitive context.
  • API keys/OIDC tokens: Stored securely (OS keychain), never committed
  • Credentials: Never log sensitive data

Constraints & Assumptions

Constraints

Time:

  • Development time: 2-4 hours per week
  • Expected use when functioning: 3-4 times per work day
  • No fixed deadline, but aim for meaningful progress within weeks
  • MVP timeline realistic: couple of weeks to get something working

Resources:

  • Solo developer (learning BMAD while building)
  • No budget for paid services initially (can add LLM API costs later if value proven)
  • Development time carved from existing schedule

Technical:

  • Mac-first (that's where the developer works)
  • Must integrate with Apple Notes (primary task storage for MVP)
  • Unknown: Go's capabilities for AppleScript interaction (needs research/testing)
  • CLI/TUI interface (no GUI development)
  • Must work within iTerm2 and similar terminal environments
  • State/storage on iCloud or Google Drive for cross-computer sync
  • External API fragility: Any external system (Apple Notes, Jira, Linear, LLM providers) may break randomly due to API changes, potentially delaying features or blocking continued use

Scope:

  • Building for one user initially (the developer)
  • Can't promise features to others or commit to public release timeline
  • Focus on daily utility over feature completeness
  • Progress over perfection applies to development too

Key Assumptions

  1. Apple Notes is accessible from Go - Assumption: There's a viable path to read/write Apple Notes from Go application, whether via AppleScript bridge, native APIs, or alternative approach. (Needs validation.)

  2. Cloud storage provides cross-computer sync - Assumption: Storing ThreeDoors state (SQLite, config, enrichment data) on iCloud or Google Drive enables seamless experience across multiple Macs. Files sync reliably enough for this use case.

  3. Integration is MVP-feasible - Assumption: At least basic Apple Notes integration can be achieved within MVP timeline. If not, fallback to local JSON storage.

  4. CLI/TUI is sufficient - Assumption: Core workflows (task capture, review, completion, improvement prompts) work effectively in terminal interface. No GUI needed for meaningful utility.

  5. WHY capture happens naturally - Assumption: Users will provide context (why tasks matter) when prompted, and this context will be valuable for summaries/communication later. Unproven until tested.

  6. Bubbletea suits the use case - Assumption: Charm Bracelet's Bubbletea framework supports the "choose-your-own-adventure" interactive flows needed. (High confidence, but unverified.)

  7. Daily use is achievable - Assumption: Despite limited development time (2-4 hours/week), the tool will become useful enough for daily task management (3-4x per work day) within a few weeks. This assumes MVP features align with actual needs.

  8. BMAD documentation emerges naturally - Assumption: Following BMAD process while building will produce quality documentation without separate "documentation phase." Working in the open creates the artifacts.

  9. Local enrichment solves integration challenges - Assumption: SQLite/vector DB for ThreeDoors metadata alongside source system storage is architecturally sound and solves cross-linking, permission, and enrichment problems.

  10. "Better than yesterday" is motivating - Assumption: Tracking improvement across dimensions will feel rewarding and encourage continued use. Psychological theory sounds good, but untested in this implementation.

  11. External API breakage is manageable - Assumption: When external APIs break (Apple, Jira, Linear, LLM providers), workarounds or alternative approaches exist. Delays are acceptable given project nature. Worst case: temporarily revert to local-only operation.

  12. Multi-provider LLM strategy is practical - Assumption: Supporting multiple LLM providers (local + cloud) is manageable complexity vs. benefit of flexibility and cost control. Could be over-engineering for Phase 2.

Risks & Open Questions

Key Risks

  1. Apple Notes integration may be harder than expected - Risk: Go's AppleScript bridge capabilities are unknown. Could discover integration is too slow, too brittle, or too limited. Impact: MVP delayed or requires fallback to local JSON storage. Mitigation: Research and spike early (first development session). Have fallback plan ready.

  2. Tool doesn't get used despite good intentions - Risk: Building yet another productivity tool that gets abandoned after initial enthusiasm. Impact: BMAD learning happens, but organization goal fails. Time invested doesn't yield daily utility. Mitigation: Prioritize features that solve immediate pain points. Use "better than yesterday" to celebrate any use, not just perfect adherence.

  3. Limited development time (2-4 hrs/week) stalls momentum - Risk: Progress too slow to maintain interest or reach useful state before motivation wanes. Impact: Project abandoned incomplete. Mitigation: Tight MVP scope. Focus ruthlessly on minimum viable features. Progress over perfection applies to development pace too.

  4. External API changes break functionality - Risk: Apple changes Notes structure, Jira changes API, LLM provider changes pricing/access. Impact: Features stop working, requires rework. Mitigation: Abstract integrations behind adapters. Plan for read-only fallbacks. Accept that maintenance is part of the deal.

  5. "Better than yesterday" proves unmeasurable or unmotivating - Risk: Core philosophical concept doesn't translate to actual feature implementation that feels good to use. Impact: Key differentiator becomes empty promise. Mitigation: Start simple (any completed task = progress). Iterate based on what feels rewarding in practice.

  6. WHY capture becomes burden rather than benefit - Risk: Prompting for context feels like extra work, gets skipped, provides little value. Impact: Context-aware summaries (future feature) has no data to work with. Mitigation: Make WHY capture optional. Experiment with timing (capture when? during task creation? completion? reflection?). Learn what works through use.

  7. Complexity creeps beyond solo developer capacity - Risk: Multiple LLM providers, numerous integrations, enrichment layer, etc. becomes too much to build/maintain alone in 2-4 hrs/week. Impact: Development stalls, code quality suffers, bugs accumulate. Mitigation: Phase features aggressively. Keep core simple. Add complexity only when previous phase proves value.

  8. Multi-computer sync via cloud storage causes conflicts - Risk: Opening app on two Macs simultaneously could corrupt SQLite database or create sync conflicts. Impact: Data loss, broken state, frustration. Mitigation: Research SQLite cloud storage best practices. Consider lock files or last-write-wins strategy. Document limitations clearly.

Open Questions

Technical:

  • What's the best way to interact with Apple Notes from Go? (AppleScript bridge? Native API? File system access to Notes database?)
  • Can Bubbletea support the "choose-your-own-adventure" interaction model we envision?
  • How do we handle SQLite on iCloud/Google Drive without corruption? (Write-ahead logging? Lock mechanisms?)
  • What's the data model for Apple Notes integration? (Dedicated note per task? Single note with checklist? Multiple notes?)
  • Should enrichment data live in SQLite, vector DB, both, or something else?

Design:

  • What does "better than yesterday" look like as actual UI? (Dashboard? Comparison view? Simple counter?)
  • When should we prompt for WHY context? (Task creation? Completion? Dedicated reflection session?)
  • How do we present "values/goals always visible" in terminal interface? (Header? Sidebar? Dedicated view?)
  • What's the flow for "choose-your-own-adventure"? (What options? When do they appear? How do states transition?)
  • How does the "one improvement prompt per session" actually work? (When? What questions? What happens with answers?)

Integration:

  • Which system integration should be first after Apple Notes? (Jira? Linear? Google Calendar?)
  • How do we handle authentication across multiple systems? (OAuth flows in terminal? Token management?)
  • What's the data model for cross-linked tasks? (Same task in Notes + Jira - how do we track that relationship?)
  • When should we enrich source systems directly vs. keep separate metadata?

Product:

  • Will daily use actually happen, or is this aspirational?
  • Is the CLI/TUI constraint too limiting for mobile-heavy workflows?
  • Should we build web interface eventually, or stay terminal-only?
  • How do we know when MVP is "done enough" to use daily?
  • What's the definition of success for Phase 2? (What triggers moving beyond MVP?)

BMAD Process:

  • How detailed should documentation be? (Every decision? Just major ones?)
  • What's the right balance between doing and documenting?
  • Should we plan to share BMAD learnings publicly, or keep internal?

Areas Needing Further Research

  1. Go + Apple Notes integration patterns - Research existing libraries, bridges, approaches. Spike basic read/write operations to validate feasibility.

  2. Bubbletea capabilities - Build quick prototype to test interaction model fits framework constraints.

  3. SQLite on cloud storage - Research best practices for database files on iCloud/Google Drive. Understand risks and mitigations.

  4. Terminal UI design patterns - Study how other CLI/TUI apps handle complex workflows (gh dash, lazygit, etc.). Learn what works well in terminal constraints.

  5. LLM provider comparison - Understand cost, latency, quality trade-offs between local (Ollama) and cloud (Claude, OpenAI, Gemini) for task breakdown use case.

  6. Apple Notes data structure - Understand how Notes stores checklists, links, formatting. Design data model that works with Notes' natural structure.

  7. Authentication patterns for CLI - Research how other terminal apps handle OAuth, API keys, OIDC in CLI/TUI context.

Next Steps

Immediate Actions

  1. Validate Apple Notes integration feasibility - First development session: Research Go options for AppleScript bridge. Spike basic read/write operations. Determine if viable for MVP or if fallback to JSON needed.

  2. Prototype Bubbletea interaction model - Build quick proof-of-concept for "choose-your-own-adventure" flow. Test if framework supports envisioned interaction patterns. Validate terminal UI can feel good.

  3. Research SQLite on cloud storage - Understand best practices for database files on iCloud/Google Drive. Test basic read/write operations. Identify potential corruption risks and mitigations.

  4. Set up project structure - Establish idiomatic Go project layout. Configure gofumpt, set up build system (Make or Task), prepare for cross-computer development via cloud-synced repository.

  5. Implement MVP core features - Build in order of dependency: (1) Task capture, (2) Apple Notes integration, (3) Values/goals display, (4) Basic interaction flow, (5) "Better than yesterday" tracking, (6) Improvement prompts.

  6. Document BMAD process as you go - Capture decisions, trade-offs, learnings in real-time. Don't wait for "documentation phase." Working in the open creates the artifacts.

  7. Use the tool daily once minimally functional - Don't wait for perfection. Start using as soon as basic task capture works. Real use reveals what matters.

  8. Review and create PRD - Once brief is complete, transition to PRD generation to detail specific features, user stories, and implementation approach.

PM Handoff

This Project Brief provides the full context for ThreeDoors. The next step is creating a Product Requirements Document (PRD) that translates this vision into detailed, implementable specifications.

When ready to create the PRD, review this brief thoroughly and work section by section through the PRD template, asking for necessary clarification or suggesting improvements based on discoveries during development.

Remember: Progress over perfection applies to the PRD too. Start with what's known, refine as understanding deepens through building.

Project Brief created using the BMAD-METHOD™ framework Session Date: 2025-11-07 Facilitator: Business Analyst Mary