# Product Brief — MVP: jcv (JSON Canvas Viewer)

> **Type:** MVP
> **Author:** Henrique Lima
> **Date:** 2026-04-29
> **Version:** 1.0
> **Status:** Draft

---

## Problem

Users who work with `.canvas` files (JSON Canvas format) have no way to visualize the diagram fully inside the terminal. Today, viewing or editing a `.canvas` requires a GUI app (typically Obsidian), which is not available or convenient in terminal-first, SSH, or headless workflows.

**Evidence:** [To be defined — anecdotal pain from terminal-first devs working with JSON Canvas; no known terminal-native viewer for the JSON Canvas spec.]

---

## Target User

**Who:** Devs and power users of the terminal — people who live in the CLI and rely on terminal-native tooling for their daily workflow.

**Usage context:** When the user needs to inspect, navigate, or quickly edit a `.canvas` diagram without leaving the terminal — e.g. while reviewing notes over SSH, working on a remote machine, or simply preferring to stay in the keyboard-driven CLI environment.

---

## Proposed Solution

A CLI tool, `jcv`, that renders `.canvas` (JSON Canvas) diagrams directly in the terminal with full visualization and editing capabilities. The tool watches the open file and live-reloads the view whenever the file changes on disk. It also exports diagrams to PNG and ships with a companion native (non-CLI) app for users who want a GUI option without leaving the same toolchain.

---

## Must-Haves

1. **View and edit `.canvas` in the terminal, with live reload** — render the diagram in the TTY and reflect on-disk changes to the open file in real time.
2. **Export the diagram to PNG** — produce a static image of the current canvas.
3. **Native (non-CLI) app for viewing and editing** — a desktop GUI counterpart to the terminal tool, sharing the same canvas semantics.

### Out of scope (for now)
- Multi-user collaboration / real-time co-editing
- Cloud sync or hosted service
- Plugin system / extensions
- Mobile clients

---

## Success Metrics

| Metric | Baseline | Target | Timeframe |
|--------|----------|--------|-----------|
| GitHub stars | 0 | [to be defined] | 30 days after launch |
| GitHub adoption signals (forks, issues opened, PRs) | 0 | [to be defined] | 30 days after launch |

---

## Constraints

- **Deadline:** Fixed — MVP must launch in less than 1 month.
- **Team / capacity:** Solo (personal project).
- **Budget:** [to be defined]
- **Technical:** Must conform to the JSON Canvas spec; terminal renderer must work across common terminals; native app adds a second runtime to maintain.
- **Regulatory:** None.

---

## Risks

| Risk | Likelihood | Impact | Mitigation |
|------|:---:|:---:|------------|
| Scope too large for <1 month (CLI + native app + export) | High | High | Cut native app or PNG export from v0 if needed; ship CLI viewer first |
| Rendering complex canvases legibly in a TTY | High | Medium | Define a minimal supported subset of JSON Canvas for v0 |
| Low adoption / discoverability | Medium | Medium | Launch on relevant channels (HN, Obsidian community, r/commandline) |
| JSON Canvas spec evolves or is ambiguous | Low | Medium | Pin to a spec version and document compatibility |

---

## Stakeholders

| Role | Name | Responsibility |
|------|------|----------------|
| PM Owner | Henrique Lima | Approval and direction |
| Tech Lead | Henrique Lima | Technical feasibility |
| Design | Henrique Lima | User experience |

---

## Next Steps

- [ ] Define the minimal JSON Canvas subset supported by v0 — Henrique — [date]
- [ ] Choose terminal rendering approach (TUI lib, layout strategy) — Henrique — [date]
- [ ] Decide whether the native app ships in v0 or v0.1 — Henrique — [date]
- [ ] Set the concrete launch date within the <1-month window — Henrique — [date]
