Tickets-in-VCS: using empty changes as structured work items for AI-assisted development

[doozMen]

Context: The Lost Mental Model Problem

As AI coding assistants become more capable, a new problem is emerging: engineers lose the mental model of systems they didn't personally build. When an AI agent produces 20+ changes in a session, the human can't reconstruct why something was built the way it was — only what was built.

Reference: Finding the Right Amount of AI

Traditional ticket systems (Jira, Linear, GitHub Issues) are separated from code by a network boundary. When agents produce changes at filesystem speed, any networked system becomes stale instantly. The intent trail breaks.

Observation: jj's Change Model Enables Something New

jj treats empty changes as first-class citizens. Combined with native trailer parsing (commit.trailers()) and revsets, this enables a pattern I haven't seen explored:

Use empty jj changes as structured work items (tickets), with implementations stacking on top.

A "ticket" as an empty change:

Refactor auth middleware to support multi-tenant tokens

Type: ticket
Priority: P0
Status: open
Acceptance: auth tests pass, tenant isolation verified

An implementation stacked on the ticket:

Implement per-tenant token scoping

Intent: implement per-tenant auth scoping
Evidence: 42 tests pass, 0 regression
Divergence: none

The Implements: trailer or the graph ancestry (implementation is a descendant of ticket) links them.

Querying with revsets:

# Open tickets
jj log -r 'description("Type: ticket") & description("Status: open")'

# Why does this code exist? Walk ancestors for tickets.
jj log -r 'ancestors(@) & description("Type: ticket")'

# What diverged from plan?
jj log -r '~description("Divergence: none") & mine()'

Why jj and Not Git

1. Empty changes are natural — no --allow-empty needed, tools don't strip them
2. Operation log — audits ticket state changes (description edits tracked)
3. Revsets — composable queries far beyond git log --grep
4. Rebase preserves history — jj's operation log survives rebases
5. Native trailer parsing — commit.trailers() already exists in the template system

What Would Make This More Ergonomic

Two small features would transform this from "works with substring matching" to "precise and fast":

1. trailer(key, value) revset filter — match commits by specific trailer key/value pairs. Follows the exact shape of the existing description() filter predicate. The trailer parser is already in jj-lib.

   jj log -r 'trailer("Type", "ticket") & trailer("Status", "open")'
   jj log -r 'trailer("Priority", "P0") & ~trailer("Status", "done")'
   

2. commit.trailer(key) template method — direct access to a specific trailer value without filtering the full .trailers() list.

   jj log -T 'change_id.short() ++ " [" ++ trailer("Priority") ++ "] " ++ description.first_line()'
   

Both follow existing patterns in the codebase and serve use cases beyond this one (Gerrit Change-Id queries, Signed-off-by filtering, any trailer-based workflow).

The Speed Argument

A typical AI-assisted session produces 20-50 changes per hour. At that rate:

• GitHub Issues API: rate-limited, 100-500ms per request. Falls behind within minutes.
• jj change: jj new --no-edit + jj describe = <10ms. The ticket system literally cannot fall behind because it IS the workspace.

Open Questions

I'd love community input on:

1. Is this a pattern jj wants to be aware of? Or should it remain purely a convention that external tools interpret?
2. Garbage collection — do abandoned ticket changes accumulate problematically?
3. Would trailer() revset and commit.trailer(key) template be welcome as PRs? They're useful independently of this pattern, but this pattern is the strongest motivating use case.
4. Visualization — jj log with templates works, but has anyone explored richer views (e.g., kanban-style TUI) built on revset queries?

This isn't a feature request — it's an exploration of something jj's design uniquely enables. Curious whether others have experimented with similar patterns.

[doozMen]

One more thought on visualization and interaction — this pattern composes naturally with MCP (Model Context Protocol).

A jj MCP server that exposes revset queries and jj describe as tools would let any MCP-connected AI assistant act as a natural language interface to the ticket system:

• "What's the P0 backlog?" → assistant runs jj log -r 'description("Priority: P0") & description("Status: open")' → renders a prioritized list
• "Move the auth ticket to P1 and assign it to me" → assistant runs jj describe <change-id> → updates the Priority and Assigned-To trailers
• "What changed since yesterday?" → assistant queries with committer_date(after:"yesterday") → summarizes recent work

This also enables an interesting standup pattern: the assistant asks the developer structured questions ("What did you accomplish? What's blocked?"), then writes the answers as a jj change with trailers — creating a queryable standup history in the same graph as the code and tickets.

The key insight is that because everything is local and filesystem-speed, the MCP tool calls return instantly. There's no API latency to work around. The AI assistant can do dozens of queries in a single conversation turn to build up a rich view.

This wouldn't require any changes to jj itself — just an MCP server that wraps the CLI. But the trailer() revset filter proposed above would make the queries precise instead of substring-based.