Migrate to Tauri desktop app with terminal, file watcher, and table support

CLAUDE.md

@@ -0,0 +1,20 @@
+<!-- BEGIN BRAIN-IMPLANT -->
+## Knowledge Base (Brain Implant)
+
+This project uses [brain-implant](https://github.com/jalexray/Brain-Implant) for knowledge management.
+
+### Brain Structure
+- Brain root: `docs/`
+- Session logs: `docs/sessions/`
+- Decision records: `docs/decisions/`
+- Development history: `docs/history.md`
+- Config: `brain.yaml`
+
+### Session Workflow
+- `/checkin` — Load context from previous session
+- `/checkout` — Document session + capture decisions + doc staleness check
+
+### Doc Maintenance
+- `/update-brain` — Scan changes, update stale docs, sync memories, append to history
+- `/audit-docs` — Full documentation health audit with freshness grading
+<!-- END BRAIN-IMPLANT -->

brain.yaml

@@ -0,0 +1,65 @@
+project:
+  name: "docugit"
+  description: ""
+  repo: "jalexray/docugit"
+
+paths:
+  brain_root: "docs"
+  session_logs: "docs/sessions"
+  decisions: "docs/decisions"
+  sprints: "docs/sprints"          # null if no sprints
+  reports:
+    daily: "docs/reports/daily"    # null to disable
+    weekly: "docs/reports/weekly"  # null to disable
+
+team:
+  members: []
+  audience: ""                               # Who reads reports (e.g., "engineering team")
+
+sprints:
+  naming: "v{N}-{slug}"                     # v1-POC, sprint-1-launch, etc.
+
+reports:
+  daily:
+    enabled: false
+    data_sources: []
+    # Example pluggable data source:
+    # - name: "API Health"
+    #   type: "shell"
+    #   command: "curl -s https://myapp.com/api/health"
+  weekly:
+    enabled: false
+    tone: "casual-collegial"                 # casual-collegial | professional | technical
+    signoff: ""
+
+staleness:
+  warn_days: 14
+  critical_days: 30
+  ignore_patterns:
+    - "**/reports/daily/*"
+    - "**/reports/weekly/*"
+    - "**/sessions/*"
+    - "**/.gitkeep"
+
+memory:
+  sync_enabled: true
+  promote_types:
+    - project
+    - reference
+    - feedback
+
+schedule:
+  audit:
+    enabled: false
+    cron: "0 18 * * 0"                      # Weekly Sunday 6pm
+    action: "/audit-docs"
+    on_stale: "log-only"                    # github-issue | slack | email | log-only
+  reflection:
+    enabled: false
+    cron: "0 9 * * 1"                       # Monday 9am
+    action: "/update-brain"
+    auto_apply: false
+
+# Reserved for future typed integrations (PostHog, Stripe, Linear, etc.)
+# See README for data_sources recipes that work today.
+integrations: {}

docs/.brain-state.json

@@ -0,0 +1,14 @@
+{
+  "schema_version": 1,
+  "last_update_brain_run": "2026-05-20T00:00:00-07:00",
+  "last_update_brain_commit": "d1d1cf0e76e3be7a8b0d00c0f80195a5bb7d98f9",
+  "last_audit_run": "2026-05-21T00:00:00-07:00",
+  "audit_results": {
+    "grade": "A",
+    "total_audited": 6,
+    "fresh": 6,
+    "aging": 0,
+    "stale": 0,
+    "critical": 0
+  }
+}

docs/backlog/items.md

@@ -0,0 +1,29 @@
+# Backlog
+
+## Open
+
+<!-- Add items using this format:
+
+### [XS/S/M/L] Item Title
+
+- **Priority**: high | medium | low
+- **Type**: feature | bugfix | enhancement | research | chore
+- **Sprint target**: backlog
+- **Description**: What needs to be done and why
+- **Acceptance criteria**:
+  - [ ] Criterion 1
+  - [ ] Criterion 2
+
+-->
+
+## Completed
+
+<!-- Move completed items here with completion date:
+
+### [S] Example Item
+
+- **Completed**: YYYY-MM-DD
+- **Type**: feature
+- **Description**: What was done
+
+-->

docs/backlog/questions.md

@@ -0,0 +1,27 @@
+# Open Questions
+
+Questions that need answers before work can proceed. Move answered questions to the bottom.
+
+## Open
+
+<!-- Add questions using this format:
+
+### Question Title
+
+**Question**: What specifically needs to be answered?
+**Context**: Why does this matter?
+**Blocked work**: What can't proceed without an answer?
+
+-->
+
+## Answered
+
+<!-- Move answered questions here:
+
+### Question Title
+
+**Question**: What was asked?
+**Answer** (YYYY-MM-DD): The answer.
+**Impact**: How this was resolved.
+
+-->

docs/decisions/2026-05-15-migrate-to-tauri.md

@@ -0,0 +1,32 @@
+# Migrate from Flask to Tauri Desktop App
+
+**Date**: 2026-05-15
+**Status**: accepted
+
+## Context
+
+DocuGit started as a Flask+Vite two-process web app. The user runs a Python backend and a Vite dev server, then opens a browser tab. This worked for prototyping but had friction: two processes to manage, no native OS integration, no access to PTY for an embedded terminal, and the app felt like a web page rather than a tool.
+
+## Decision
+
+Replace Flask+Vite with a single Tauri 2 macOS desktop app. The React frontend runs in a native WebView, and a Rust backend handles file I/O, git operations, and config via IPC commands.
+
+## Reasoning
+
+- **Single binary**: One process to launch, no port management, no browser tab
+- **Native feel**: macOS window chrome, document-edited indicator, native file dialogs
+- **PTY support**: Rust's `portable-pty` enables an embedded terminal — not feasible from Flask
+- **Performance**: Rust file I/O and git operations (via subprocess) are fast with no HTTP overhead
+- **Distribution**: Tauri builds `.dmg` and `.app` bundles for macOS
+- **Alternatives considered**:
+  - **Electron**: Heavier runtime (~100MB+ vs ~5MB for Tauri), less native feel
+  - **Keep Flask**: No path to PTY, terminal, or native integration
+  - **Wails (Go)**: Smaller ecosystem, less mature than Tauri 2
+
+## Consequences
+
+- **macOS only for now** — Tauri supports Windows/Linux but we haven't tested or configured those targets
+- **Rust required** — contributors need the Rust toolchain, which is a higher bar than Python
+- **No web access** — the app is local-only (was also true with Flask, but now it's structural)
+- **GitPython replaced** — git operations are now via CLI subprocess, which is actually more transparent and debuggable
+- **Frontend unchanged** — React + TipTap + Tailwind carried over with only import path changes (`fetch` → `invoke`)

docs/decisions/2026-05-20-file-watching-with-notify.md

@@ -0,0 +1,31 @@
+# File Watching with Rust notify Crate
+
+**Date**: 2026-05-20
+**Status**: accepted
+
+## Context
+
+DocuGit had no mechanism to detect external file changes. If a user edited a `.md` file outside the app (e.g., via an LLM tool, terminal, or another editor), the UI wouldn't reflect the change until the user manually re-opened the file. For a tool designed around LLM-assisted doc workflows, this was a significant gap.
+
+## Decision
+
+Use the Rust `notify` crate (v6.1) to watch the repo directory recursively for `.md` file changes. The watcher emits Tauri events (`fs:file-changed`, `fs:tree-changed`) that the React frontend listens for and reacts to.
+
+## Reasoning
+
+- **Event-driven**: macOS FSEvents via `notify` is efficient — no polling, no wasted CPU
+- **Filtered and debounced**: Only `.md` files trigger events, with 1-second per-path debouncing to avoid rapid-fire updates during saves
+- **Two event types**: `fs:file-changed` (content modification) refreshes the active editor; `fs:tree-changed` (create/delete) refreshes the sidebar file tree
+- **Self-save handling**: When the user saves via the app, the watcher fires but the frontend compares content and skips redundant updates — no flicker or cursor loss
+- **Alternatives considered**:
+  - **`tauri-plugin-fs-watch`**: Extra plugin dependency, less control over filtering and debouncing
+  - **`setInterval` polling**: Simple but wasteful, introduces latency, harder to get right
+  - **No watching**: Viable but poor UX for the LLM-assisted workflow where files change externally
+
+## Consequences
+
+- **Immediate refresh**: External edits appear in the editor within ~1 second
+- **Dirty files protected**: If the user has unsaved changes, external updates are ignored (no data loss)
+- **Editor remounts on external change**: Uses a `contentRevision` key bump to force TipTap to re-initialize — cursor position is lost, but this is acceptable for external changes
+- **Watcher lifecycle tied to repo**: Starts when a repo is selected, stops on cleanup or repo switch
+- **Resource cost**: One FSEvents stream per repo — negligible on macOS

docs/decisions/_template.md

@@ -0,0 +1,20 @@
+# [Decision Title]
+
+**Date**: YYYY-MM-DD
+**Status**: proposed | accepted | superseded by [link]
+
+## Context
+
+What prompted this decision? What problem were we solving?
+
+## Decision
+
+What did we decide?
+
+## Reasoning
+
+Why this over alternatives? What trade-offs did we consider?
+
+## Consequences
+
+What follows from this decision? What doors does it open or close?

docs/design-system-prompt.md

@@ -0,0 +1,148 @@
+# DocuGit Design System Brief
+
+## What is DocuGit?
+
+DocuGit is a macOS desktop application for editing markdown files with built-in git integration. Think of it as a lightweight, Word-like writing environment that lives on top of a git repository.
+
+### The problem it solves
+
+Developers and technical writers increasingly use LLMs (Claude, ChatGPT, etc.) to generate markdown documentation — project specs, READMEs, design docs, technical guides. These documents end up in git repos, but editing them is awkward:
+
+- **IDEs** (VS Code, JetBrains) treat markdown as code. You're staring at raw syntax, managing split previews, and fighting an interface built for programming.
+- **Dedicated markdown editors** (Obsidian, Typora) don't understand git. You lose staging, diffing, branching, and commit workflows.
+- **Google Docs / Notion** aren't local-first, don't output clean markdown, and don't integrate with git at all.
+
+DocuGit bridges this gap: a clean WYSIWYG editor where markdown looks like a finished document, with git operations always one click away.
+
+### Target audience
+
+- **Developers** who write and maintain documentation alongside code
+- **Technical writers** working in git-based repos
+- **LLM power users** who generate markdown docs as part of AI-assisted workflows and need a comfortable place to review, edit, and version them
+- **Solo creators and small teams** who want a simple, local-first writing tool without SaaS overhead
+
+The common thread: people who work with markdown in git repos and want a writing-first experience, not a coding-first one.
+
+## Current state of the app
+
+DocuGit is functional but visually undesigned. The UI was built pragmatically with Tailwind utility classes — it works, but there's no intentional design system, no visual identity, and several inconsistencies. It's ready for a real design pass.
+
+### Tech stack
+
+- **Desktop shell:** Tauri 2 (Rust backend, WebView frontend) — macOS only for now
+- **Frontend:** React 19, Tailwind CSS 4, TipTap v3 (WYSIWYG editor)
+- **Embedded terminal:** xterm.js with PTY support
+- **File watching:** Rust `notify` crate — auto-refreshes editor when files change on disk
+
+### Application structure
+
+The app is a single-window, multi-panel layout:
+
+```
++-------+----------------------------+---------+
+| Header (logo, panel toggles, repo path)      |
++-------+----------------------------+---------+
+|       |                            |         |
+| Side  |        Editor              |  Git    |
+| bar   |     (TipTap WYSIWYG)       | Panel   |
+| 256px |                            | 320px   |
+|       |                            |         |
+|       |                            |         |
++-------+----------------------------+---------+
+|         Terminal (xterm.js, collapsible)      |
++----------------------------------------------+
+```
+
+**Header bar (~40px):** "DocuGit" text logo, three toggle buttons (Files / Git / Terminal), and the current repo path right-aligned.
+
+**Sidebar (256px, collapsible):**
+- Repo picker with four modes (open doc, choose folder, scan for repos, detect from path)
+- Hierarchical file tree showing only `.md` files
+- "New File" creation form
+- Active file highlighted in blue
+
+**Editor (flexible center):**
+- Formatting toolbar: headings (H1-H3), bold/italic/strike/code, lists, blockquote, code block, horizontal rule, undo/redo, save button
+- TipTap WYSIWYG area with prose typography (styled via @tailwindcss/typography)
+- File path display with dirty indicator (orange asterisk)
+- Empty state when no file is open
+
+**Git panel (320px, collapsible):**
+- Branch selector with create-new-branch form
+- Changed/untracked files list with checkboxes for selective staging
+- Staged files list with unstage option
+- Commit form with message textarea
+- Push button with unpushed commit list
+
+**Terminal panel (~288px, collapsible):**
+- Dark-themed xterm.js terminal with full PTY support
+- Header bar with close button
+
+### Current visual style
+
+The app uses an ad-hoc gray palette with minimal color accents:
+
+- **Backgrounds:** White (editor), Gray-50 (sidebar, git panel, header), #1e1e1e (terminal)
+- **Interactive elements:** Gray-700 for primary buttons, Blue-600 for save/links, Green-600 for commit
+- **Text:** Gray-400 through Gray-700 for varying emphasis
+- **Borders:** Gray-200 (light dividers), Gray-300 (inputs)
+- **Typography:** System font, mostly xs (0.75rem) for UI chrome, prose sizing in editor
+- **Active states:** Inconsistent — sometimes blue highlight (file tree), sometimes gray-700 with white text (toolbar, toggles)
+
+### Known design issues
+
+- No visual identity — "DocuGit" is just text, no logo or brand treatment
+- No dark mode (terminal is dark but everything else is light-only)
+- Active/selected states use two different color systems (blue vs. gray) with no clear logic
+- UI text is uniformly tiny (xs/0.75rem) — functional but cramped
+- No spacing rhythm or consistent sizing scale
+- Toolbar buttons are text-only with no icons
+- No visual hierarchy between panels — everything is the same gray
+- No transitions or micro-animations
+- File tree has no file type icons
+- Git status labels are plain text with no color coding
+- No empty states with personality (just gray text)
+- Accessibility gaps: missing ARIA labels, no focus management for dropdowns
+
+## What I need
+
+Design a **design system** for DocuGit — a cohesive set of foundations and components that can be applied across the entire app. This should feel like a polished, native-quality macOS writing tool, not a web app crammed into a window.
+
+### Design system deliverables
+
+**1. Foundations**
+
+- **Color palette:** Light mode and dark mode tokens. The app should feel calm and paper-like in the editor area but capable and dense in the chrome (sidebar, git panel). Consider how the terminal's dark theme coexists with both modes.
+- **Typography scale:** A clear type ramp for UI chrome (labels, buttons, file names) vs. editor content (prose). Include font recommendations — system fonts are fine, but specify the stack and any weight/size pairings.
+- **Spacing and sizing:** A consistent spacing scale and component sizing system (button heights, input heights, panel padding, icon sizes).
+- **Elevation and layering:** How panels, dropdowns, modals, and tooltips relate spatially. Shadow and border treatments.
+- **Iconography direction:** Style recommendation for icons (outlined, solid, stroke weight). Don't need individual icons designed, just the system.
+- **Motion principles:** Guidelines for transitions (panel show/hide, dropdown open, state changes). Keep it subtle and fast.
+
+**2. Core components**
+
+Design these key components within the system:
+
+- **Buttons:** Primary, secondary, ghost, destructive. Active/disabled/loading states.
+- **Toggle buttons:** For panel visibility (Files/Git/Terminal). On/off states that are immediately readable.
+- **Text inputs and textareas:** For file names, commit messages, branch names. Focus, error, disabled states.
+- **File tree item:** File and folder variants. Selected, hover, and depth-indentation treatment. Consider file status indicators (modified, staged, new) that align with git panel.
+- **Toolbar button:** For the editor formatting bar. Active (format applied), hover, disabled. Consider icon+text vs. icon-only.
+- **Dropdown / select:** For branch picker and any future selects. Open/closed states, selected item treatment.
+- **Status badges:** For git file statuses (modified, added, deleted, untracked, staged). Small, color-coded, readable at a glance.
+- **Panel chrome:** Header/title treatment for sidebar, git panel, terminal. Collapse/expand affordance.
+
+**3. Layout system**
+
+- Panel structure and resizing behavior
+- How panels collapse and expand (animation, toggle affordance)
+- Responsive behavior as the window resizes (minimum widths, what collapses first)
+- Editor area treatment — should it feel like a page (centered, max-width) or fill available space?
+
+### Design direction
+
+- **Native feel:** Should feel at home on macOS — respect platform conventions for window chrome, control sizing, and interaction patterns
+- **Writing-first:** The editor is the hero. Everything else should support the writing experience without competing for attention
+- **Professional but approachable:** This isn't a toy or a hacker tool. It should feel trustworthy for real work while still being pleasant to use
+- **Information density:** The sidebar and git panel should be compact and scannable. Don't waste space, but don't cram things either
+- **Calm:** Muted palette with purposeful color. Reserve bright colors for meaningful signals (unsaved changes, git status, errors)