# Non-Linear: Product Vision

## One-liner

A graph-native issue tracker for small IT teams where both humans and AI agents navigate a shared decomposition tree of components and issues, with first-class multi-repo integration.

## Core Thesis

Software projects are easier to conceptualize top-down using graphs. Traditional issue trackers (Jira, Linear, GitHub Issues) are flat or loosely hierarchical — they force teams to reverse-engineer structure from ticket lists and labels. Non-Linear makes the graph the first-class data model, so both humans and AI agents can reason about project topology directly.

## Why Now

1. **AI agents need topology.** Current tools bolt on AI after the fact. An agent that wants to understand "what should I work on next?" or "what's blocked?" has to reverse-engineer structure from flat ticket lists. A graph-native model gives agents *rails to traverse*.

2. **Small teams are underserved.** There's a gap between "too simple" (Trello, GitHub Issues) and "too heavy" (Jira, Azure DevOps). Small teams need more structure than a Kanban board but can't justify Jira administration overhead.

3. **Agent ecosystems are emerging.** Teams are beginning to use agents for code review, task decomposition, triage, and status reporting. An agent-native tracker is positioned for this shift.

4. **Code structure is the natural skeleton.** Most projects already have a structure — it's in their repos. Connecting code and inferring the project skeleton eliminates the cold-start problem that kills adoption of structured tools.

## Target Users

- **Startup dev teams** (3-10 people) building software products
- **Freelancers managing multiple client projects** with cross-project dependencies
- **One-person teams with AI agents** where the agent acts as a focused collaborator

## Competitive Landscape

| Tool | Strength | Gap |
|------|----------|-----|
| Linear | Fast, opinionated, clean | Flat structure, AI retrofitted, no code-aware skeleton |
| Jira | Powerful, extensible | Heavy, complex, AI bolted on |
| GitHub Issues/Projects | Integrated with code | Minimal structure, single-repo |
| Plane.so | Open-source Linear alternative | Same flat model |
| Trello | Simple, visual | No hierarchy, no agent support |
| Kumu / Obsidian Canvas | Graph modeling | Not issue trackers |

**The gap:** No tool combines graph-native project modeling, multi-repo code integration, layered information architecture (structure / work / dependencies / context), and AI-agent-first API design.

## Design Principles

1. **Graph is the spine.** The decomposition tree defines project structure. Everything else — views, permissions, agent navigation — derives from graph position.
2. **Four layers, one topology.** The graph is organized as four independent overlays on a shared spatial structure — like layers in a GIS. Layer 1 (Structure) is the component skeleton. Layer 2 (Work) is issues and coordination. Layer 3 (Code Connections) is technical dependencies between components. Layer 4 (Artifacts) is external context — docs, designs, media. Each layer answers a different question, has its own update cadence, and can be toggled independently in the UI and agent API.
3. **Three node types.** Components are the skeleton (stable, map to code). Issues are the work (flow through statuses, get assigned). Artifacts are the context (docs, designs, screenshots attached to any node). Cleaner than untyped depth-as-type.
4. **Code is the skeleton.** Connect your repos, infer the component tree. The fastest path from "nothing" to "structured project" is through code you already have. Code analysis also feeds Layer 3 — import graphs and API calls become visible dependency edges.
5. **Agents are first-class actors.** Not assistants bolted on — agents have accounts, roles, permissions, and can traverse the graph independently. Agents can scope their view to specific layers — a triage agent sees only Layer 2, an impact analysis agent sees Layers 1+3.
6. **Granular trust.** The permission system is policy-based from day one. Roles are convenience bundles over a granular engine, not hardcoded ceilings.
7. **Keyboard-first.** Every action has a shortcut. The command palette is the primary navigation method.
8. **Plan-then-apply.** Structural changes show a preview of consequences before committing.

## Three Fast-Start Paths

1. **Connect your code:** OAuth to GitHub/GitLab → select repos → AI infers component skeleton → adjust → start adding issues
2. **Clean start:** Create project → root node → add components and issues manually
3. **Import from tracker (v0.2+):** Import from Linear/Jira/GitHub Issues → infer hierarchy → adjust