Main Kanban view with tickets
Tickets with list view
Individual ticket view with functionalities
Ticket pipeline view
Ticket activity and history
Ticket reasoning
Ticket assigning team
Team management view

TheManager

What if your kanban board could think, code, and remember?

TheManager is a desktop project manager that turns tickets into shipped projects. A 7-agent AI pipeline plans, architects, codes, tests, reviews, debugs, and documents your work. Every prompt, decision, and commit is saved as a searchable engineering memory, so nothing ever gets solved twice.

Inspiration

Every engineer has lived this moment: a bug pops up, it feels familiar, and somewhere (a Slack thread, a closed PR, a teammate's head) the answer already exists. But finding it costs more than fixing it from scratch. Diffs tell you what changed; nothing tells you why.

We wanted to build the tool we kept wishing existed: a project manager that doesn't just track work, but does it, and remembers exactly how. Jira shows you the ticket. Cursor writes the code. Git stores the commit. But none of them connect the reasoning that ties them together. TheManager closes that loop.

The deeper inspiration: engineering's biggest hidden tax is rediscovery. Teams spend more time relearning past decisions than making new ones. TheManager's goal is to drive that cost to zero by making every past decision queryable.

What it does

Kanban board with five columns (Backlog → Todo → In Progress → Review → Done), structured user stories, priorities, and tags.
7-agent AI pipeline (Planner → Architect → Coder → Tester → Reviewer → Debugger → Docs) that takes a ticket from idea to working project, writing files directly into your repo.
Auditable reasoning trees with confidence scores and per-step execution logs (Intake → Scan → Research → Analysis → Architecture → Alternatives → Implementation → Edge Cases → Validation).
Engineering memory that persists every prompt, decision tree, and linked git commit, searchable next time something similar shows up.
Real-time git integration via post-commit, post-checkout, and post-merge hooks, with polling fallback.
MCP server exposing 11 tools to Cursor, Claude Code, and Windsurf. Your editor and your board are the same surface.
File bridge (.decidr/inbox/) so any script, CI job, or external tool can drop in JSON to create a ticket.
Phase 3 adds JWT auth, workspaces, team roles (owner / manager / member), and invite flows.

How we built it

Architecture

Tauri (Rust shell) ─┐
React + Vite UI ────┼──► Express REST API (:3117) ──► Headless Core (TS) ──► PostgreSQL 16
MCP Server (stdio) ─┤                                       │
File Bridge ────────┘                                  Drizzle ORM

A monorepo with six packages: core (headless business logic, zero UI/HTTP deps), server (Express REST), mcp (Model Context Protocol server), web (React + Vite + Zustand), file-bridge (folder watcher), and vscode-ext. Every layer is a thin wrapper over a single source of truth.

Stack

Layer	Tech
Desktop shell	Tauri v2 (Rust), ~5–10 MB, system webview, sidecar-managed
Frontend	React 18, Vite, Tailwind, Zustand
API	Express 4 on port 3117
Core	TypeScript 5, repository + service pattern
DB	PostgreSQL 16 via Drizzle ORM (schema-as-code, no codegen)
AI	Google Gemini API with `gemini-2.0-flash` and open-weight Gemma (Apache 2.0)
Editor	MCP 1.0, 11 tools, 3 resources, 2 prompts
Auth	JWT + bcrypt, workspace-scoped roles

The agent pipeline

Each agent has a system prompt in agents/*.md and a TypeScript implementation extending BaseAgent. The Orchestrator runs them in sequence, threading state through a shared agent_context table. Agent outputs aren't returned to a sandbox; they're written directly to the project folder via writeAgentOutputInline, so the Planner produces real package.json and tsconfig.json files, the Coder produces real source modules, and the Tester drops real test suites alongside them.

We log every run (agent_runs) with input, output, reasoning, token counts, and duration. That log is the engineering memory.

Memory & retrieval

The reasoning table stores decision trees as JSONB with eight node types: problem, investigation, discovery, root_cause, decision, chosen, rejected, ruled_out. Combined with git_branches, git_commits, agent_runs, and hook_events, every ticket becomes a fully reconstructable artifact, queryable by tag, file path, commit hash, or fuzzy text.

Challenges we ran into

1. Agents return broken JSON

LLMs love trailing commas, markdown fences, and "here's your JSON:" preambles. We wrote a four-stage safeJsonParse fallback in the base agent: direct parse → strip fences → strip trailing commas → balanced-brace extraction → raw text dump. Result: agents almost never fail on malformed output.

2. Gemma ≠ Gemini, even on the same API

Gemma served via the Gemini API silently rejects systemInstruction, responseMimeType: 'application/json', and thinkingConfig. Worse, thinking tokens count against the output budget, so any "reasoning" the model does eats directly into the room left for the actual response. We added model-prefix detection in BaseAgent to dynamically rewrite request configs and pad token budgets. One code path, two model families.

3. Inter-agent handoffs

The Planner's output is the Architect's input is the Coder's input. Threading typed payloads through seven agents without losing fidelity took a few iterations. We landed on a shared contextStore keyed by ticket ID and topic, with each agent reading the predecessors it needs rather than receiving a giant blob.

4. Packaging Tauri + Node sidecar

Tauri runs Rust; our server runs Node. We used pkg to compile the Express server into a single binary, then registered it as a Tauri sidecar that boots and dies with the app. Getting paths, ports, and lifecycle right across macOS/Windows builds was a long afternoon.

5. Real-time git tracking without polling everything to death

Polling every 30 seconds is wasteful; relying purely on hooks misses users who don't install them. We do both. Git hooks push events to /api/git/* immediately, and a background poller fills in gaps for unhooked repos.

6. Writing AI output to disk safely

Letting agents write to your project folder is powerful and terrifying. We added path validation, a project-folder root, and refused any write that resolved outside it: no .. escapes, no absolute paths.

What we learned

Headless cores pay for themselves. Building packages/core with zero UI or HTTP dependencies meant we could plug in a REST server, an MCP server, and a file bridge without ever duplicating logic. Three integration surfaces, one source of truth.
MCP changes the integration story. Once the board exposed itself as an MCP server, "Cursor support" and "Claude Code support" became free. The protocol is the integration.
Multi-agent is not the same as multi-prompt. Specialization beats one giant prompt every time. A Planner that only plans outperforms a generalist that does everything, because the system prompt can be ruthlessly focused.
Open-weight models matter. Picking Gemma (Apache 2.0) means a team's reasoning trail is portable. They can rerun any past decision on self-hosted infra without us.
Memory is a product, not a feature. The moment we started persisting prompts and reasoning alongside commits, the tool stopped feeling like "AI for tickets" and started feeling like a second brain for the codebase.

What's next

Semantic search across memory: vector embeddings over reasoning trees and prompts, so similar past tickets surface automatically.
Reviewer-agent on real PRs: auto-review every push against the project's own historical decisions.
Flow diagrams (architecture / data / lifecycle / reasoning) generated and kept in sync from the same memory store.
Real-time team collaboration via WebSockets, plus full Phase 3 invite acceptance and per-project permissions.
Self-hosted deployment with a one-command Docker Compose stack for teams that want their memory to never leave their network.
Integrations with Slack, Linear, GitHub Actions, and GitLab CI, so the engineering memory captures decisions wherever they happen.