Thank you! I too am excited about next steps. There are a lot of interesting paths to explore still, and I do agree that the web interface would be a natural evolvement.
Thanks for the kind feedback! My initial motivation was of lack ergonomics in the tools I used. I had a vision of what I wished issue tracking was like, and the tools we were using were nothing like that. In my opinion they were hard to navigate, slow, unreliable and prompted you to login every once in a while. I thought I’d be able to make something useful in a weekend. It took me a year of on and off coding, but its been a great journey!
That is a known limitation as of now. Text updates are currently handled as whole chunks, so Epiq does not implement character-level CRDT merging.
In the event of conflicting updates to the same text block (currently title or description fields), later events take precedence.
What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previous states and manually recover overwritten changes if needed.
1. I envision people already comfortable with the terminal as the first to pick it up, but as someone else pointed out, a considerable amount of effort has gone into lowering the threshold and making it usable for people with limited command-line experience. I can also definitely see a future web UI being added over time.
2. There is no requirement to run Epiq alongside your codebase - you could also use a separate repository dedicated to issue tracking. When you run epiq, it traverses upward until it finds the nearest project definition. In theory, you could initialize Epiq at a higher-level scope and have multiple child repositories share the same board state, although that setup has not been officially verified or supported yet, so I would wait until there is a version that explicitly supports it.
It's mainly about robustness and deterministic outcomes.
There is a small level of noise in TUI output, and structures that are easily parsed by a human can be ambiguous for an agent (for instance column layouts). You could definitely let agents interact with Epiq purely through the CLI, but the idea behind the MCP server is to provide stable, predictable interfaces where determinism matters.
Good point. A local web UI is probably one of the highest priorities from here. The UI, persistence and materialization layers are already fairly separated architecturally.
The current TUI is built with Ink, which is a React renderer for the terminal, so conceptually the UI structure already maps naturally to the web.
Thanks for input. Interesting list. A few notes on that:
- Issue state is not tied to commits in the checked out repo. Events live in append-only user-scoped logs and are materialized independently of the checked out branch, so switching branches does not change issue state. This is solved with git worktrees.
- Epiq keeps state in a dedicated state branch and does not put issue data into normal code history. The working branch stays clean.
- Sync uses normal git push/pull semantics.
- Multi-user conflicts are prevented because each user writes only to their own immutable event log file. You never co edit a file. Logs converge state in memory from the combined event stream. There’s no shared mutable issue document being edited.
- The non-developer distribution can be addressed with exported state .md files (with the board as ascii). They are currently not generated automatically, but you can generate them at will. [edit - addition: Considerable effort has also been put into making the tool accessible to non-technical people, so there is auto completion, hints, a command palette with descriptions of each command, arrow key navigation and so on. It is my hope that anyone can pick it up rapidly. And a web interface could definitely be crafted for that usecase]
Hey! Creator of Epiq here. Epiq is platform agnostic mening that it is doing its own thing and does not connect to github issues. Epiq maintains its own board definition as an immutable (append only) event log, which is synchronized using git.
An integration layer with github issues or other platforms is definitely not unthinkable.
Epiq is a CLI/TUI issue tracker that lives entirely inside your repo - no accounts, no SaaS, no context switching. Issues and kanban boards are stored as an event log on a dedicated Git branch, so everything is versioned, time-travelable, and syncs with regular git push/pull.
Built as a response to the frustrating hurdles with the current tooling. It has Vim-style keyboard navigation, works offline, supports multiple user collab via Git, and includes an MCP server so agents like Claude can read/write issues directly.