-
Notifications
You must be signed in to change notification settings - Fork 0
Home
A vim-flavored terminal UI for Azure DevOps: work items, pull requests, reviews, and votes — without
leaving your terminal. Built on .NET 10 and Terminal.Gui v2, shipped as the cobalt global tool.
The repository is the source of truth, not this wiki. Everything below links to a file in the repo rather than restating it, so there is nothing here to drift out of date. Before adding a page, see What belongs here.
| If you want to… | Read |
|---|---|
| Install it, configure a context, sign in | README |
| Learn the keys | README → Keys (vim layer) |
| Know what it does and doesn't do | README → Known limitations |
| See what changed | CHANGELOG |
| Report a security issue | SECURITY |
| Topic | Where |
|---|---|
| Architecture, conventions, build/test commands | CLAUDE.md |
| Why things are the way they are | docs/adr/ · index |
| The agreed v1 specification | docs/SPEC.md |
| The milestone plan | docs/PLAN.md |
The decisions worth reading before changing anything:
- ADR 0004 — the three-project layering. UI logic never touches Terminal.Gui; that is why the interesting logic is unit-testable at all.
- ADR 0007 — the vim input layer as pure data, so the product's core feel is tested without a terminal.
- ADR 0008 — client-side diff and line comments.
- ADR 0013 — the exception policy: what surfaces in the message bar versus what crashes.
- ADR 0016 — terminal driver selection. Read this first if keys drop inside a multiplexer.
- ADR 0021 — the lazygit-inspired shell chrome (an always-visible context keybar, vim showcmd, real tab strips) that frames every screen.
Two layers, answering different questions:
-
The suite —
dotnet test Cobalt.slnx. Runs headless in CI across ubuntu/windows/macos. The commands, and the clean CI-style build you need before pushing, are in CLAUDE.md. -
tools/uat — a read-only harness against a
live org, covering the routes and latency CI can only verify by shape. Deliberately outside
Cobalt.slnx, so CI never builds it.
A green suite cannot prove the product's goal: "PR review feels local" is a human judgement, in a real terminal, against a real org.
This wiki is a map, not a manual. Reference material lives in the repo, beside the code it describes, where it is reviewed in the same pull request as the change that invalidates it. A copy here would rot silently, because nothing forces the two to be updated together.
Add a page only for something with no home in the repo: a long-form walkthrough, a troubleshooting story, notes that shouldn't be pinned to a commit. Anything describing how the code works belongs in the repo, and should be linked from here instead.