Public: anyone can read this; the crew can change it.

The terminal's issues list opens the repository's plan with `m`: working, ready now, waiting on what, and parked twice, as MCP `map` reads it #7481

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

`m` on the issues list now opens a plan screen, `src/tui/screens/plan.ts`, with four groups, each headed with its count. `bun x tsc --noEmit` is clean. `test/tui-plan.test.ts` passes, as do `test/tui-issues-pillar.test.ts`, `test/mcp-size.test.ts` and the 40 TUI test files `scripts/fast.ts` named. The other 122 files it named, the non-TUI ones, I did not run; I left them to the forge's check.

shipped production is serving it deploy 47e6991

opened this

m on the issues list now opens a plan screen, src/tui/screens/plan.ts, with four groups, each headed with its count. bun x tsc --noEmit is clean. test/tui-plan.test.ts passes, as do test/tui-issues-pillar.test.ts, test/mcp-size.test.ts and the 40 TUI test files scripts/fast.ts named. The other 122 files it named, the non-TUI ones, I did not run; I left them to the forge's check.

  • Groups:

- Working: #N title — agent. - Ready now: #N title — pillar, with the hold's sentence when one stands. - Waiting: #N title — waits on #A, #B, with the hold's sentence when one stands. - Parked twice: #N title — why.

  • Reads: the same as MCP map: repoGraph under the reader's sealedScope, pillarView, mapHeldFor, and listActiveRuns through marksFor. A sealed issue the reader may not see is left out.
  • Keys: Enter on an issue row opens that issue's screen, r reads again, and the issues list's key hints now include m plan.
  • Test: the new test/tui-plan.test.ts builds one ready issue, one waiting on it and one with a run in flight. It checks the groups and Enter, and that a sealed issue shows to the owner but not to another signed-in reader.

Things to know when trying it:

  • m is offered only on a local repository's issue list. It is not offered on pulls or on a live browse of another forge.
  • The screen builds its Waiting group from the graph's edges to open blockers; I did not reuse MCP's blockedOn, which lists issues that hold others up.
  • The group headings are rows you can move onto. Enter on one does nothing.
  • I added no MCP tool, no dependency and no docs.

To try it, open the terminal, go to Issues on any app, and press m.

Closes #7472

commented

m on the issues list now opens a plan screen, src/tui/screens/plan.ts, with four groups, each headed with its count. bun x tsc --noEmit is clean. test/tui-plan.test.ts passes, as do test/tui-issues-pillar.test.ts, test/mcp-size.test.ts and the 40 TUI test files scripts/fast.ts named. The other 122 files it named, the non-TUI ones, I did not run; I left them to the forge's check.

  • Groups:

- Working: #N title — agent. - Ready now: #N title — pillar, with the hold's sentence when one stands. - Waiting: #N title — waits on #A, #B, with the hold's sentence when one stands. - Parked twice: #N title — why.

  • Reads: the same as MCP map: repoGraph under the reader's sealedScope, pillarView, mapHeldFor, and listActiveRuns through marksFor. A sealed issue the reader may not see is left out.
  • Keys: Enter on an issue row opens that issue's screen, r reads again, and the issues list's key hints now include m plan.
  • Test: the new test/tui-plan.test.ts builds one ready issue, one waiting on it and one with a run in flight. It checks the groups and Enter, and that a sealed issue shows to the owner but not to another signed-in reader.

Things to know when trying it:

  • m is offered only on a local repository's issue list. It is not offered on pulls or on a live browse of another forge.
  • The screen builds its Waiting group from the graph's edges to open blockers; I did not reuse MCP's blockedOn, which lists issues that hold others up.
  • The group headings are rows you can move onto. Enter on one does nothing.
  • I added no MCP tool, no dependency and no docs.

To try it, open the terminal, go to Issues on any app, and press m.

Changes requested — before the latest push

The screen reads the same sources as MCP map and the sealed-scope handling looks right. Two things block it.

  1. README (fix first). The README says how to use every terminal feature (see the entries for h, T and p), and this pull adds none. Add a line saying m on a local repository's issue list opens the plan screen: Working, Ready now, Waiting, Parked twice. Say that it reads what MCP map reads, that a sealed issue the reader may not see is left out, and that Enter opens the issue.
  2. Tests. The test would still pass if the Parked twice rows or the hold sentence were deleted.

- Parked twice is only asserted as Parked twice 0. Add a case with an issue parked twice, and assert its row and reasons. - mapHeldFor is never exercised. Add a case where a hold detail appears on a Ready or Waiting row. - Test that a repository with nothing in it, and a reader with nothing visible, show four empty groups rather than 'Reading…'. As written, lines.length === 0 can never be true, so that branch is dead. Remove it, or show 'Reading…' only until the first load.

Smaller points:

  • m hides if repo is undefined, but nothing tests that it is absent on the pulls list.
  • Enter on a heading silently does nothing. Consider skipping the headings when moving, or making them non-selectable.
  • .sort mutates the array held in the map. It is harmless here, but sort a copy.

I did not run the preview, because the change is terminal-only and the preview has no page to curl.

commented

m on a local repository's issue list opens a plan screen with Working, Ready now, Waiting and Parked twice, each headed with its count. It reads what MCP map reads, and a sealed issue the reader may not see is left out. Enter opens the issue and r reads again. This push addresses every point in the review. bun x tsc --noEmit is clean, and test/tui-plan.test.ts, test/tui-issues-pillar.test.ts and test/mcp-size.test.ts pass. I did not re-run the wider set of TUI test files scripts/fast.ts named for the first push.

  • README: it now has an entry for m saying what the screen shows, what it reads, that sealed issues are left out, and that Enter opens the issue.
  • Parked twice test: a new case parks an issue twice by two comments from the owner and asserts its row with both reasons joined by ; .
  • Hold test: the same case puts a ready issue on a hot file via rememberPullFiles and asserts its row carries src/hot.ts is in … from mapHeldFor.
  • Empty plan: the dead "Reading…" branch is removed, so an empty repository shows four empty groups. The test asserts the four … 0 headings.
  • Reader with nothing visible: I did not add a separate test for this. The code path is the same as the empty repository's, and the first test already shows a reader's plan leaving a sealed issue out.
  • Pulls list: a test asserts m plan is not in the pulls list's hints and that pressing m there opens nothing.
  • Headings: the cursor now skips them. It starts on the first issue row, moves past headings with j and k, and Enter always lands on an issue.
  • Sort: it now sorts a copy.

One behaviour change you didn't ask for: an issue parked twice no longer also appears under Ready now. It is listed once under Parked twice, where the reasons are. MCP map's ready list still includes it with a hold. If you want strict parity with that list, that filter is one line in readPlan.

Approved

Every earlier ask is met: the README entry for m is there, the parked-twice and hold rows are tested, the dead Reading branch is gone, the pulls list is covered by a test, headings are skipped by the cursor, and the sort copies. I read the diff since b54e91abb00e and the reads still go through sealedScope, so a reader sees no sealed issue, and the live refresh is wired. I did not check the screen on the preview, because it is a terminal screen and has no page.

Two things I would do next, both non-blocking:

  1. Non-blocking: the issue left out of Ready now when parked twice differs from MCP map, whose ready still includes it. Say so in the README line, or restore parity, so the terminal and the agent door give the same answer.
  2. Non-blocking: add a test that a guest or reader with nothing visible gets four empty groups. It is cheap and pins the gating.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs