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

Every issue carries its pillar, and the map and board show merged work by pillar for the last 7 days #708

Merged opened this in answer to

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

Merged

Closes #610

shipped production is serving it for issue #610 — its issue is already done deploy 2fa0c24

opened this

Closes #610

In progress (steward build team). The first commit is the data only: which issues are pillar umbrellas, and the label an issue under one carries. The automatic labelling, the plan tool's pillar, the map's by-pillar view and the board's 7-day line follow on this branch.

🤖 Generated with Claude Code

commented

The description, now that the work is done (the forge has no route to edit a pull's body).

What a person sees. On the map, beside the drawing, By pillar: each pillar with what is open, ready and blocked, and no pillar with the issues that name none. On the board, Landed leads with what merged in the last 7 days by pillar. Each pillar is a link to its issues.

What a pillar is. An umbrella issue titled P0 Trust: … (any P<n> Name:) or Later: …, opened by someone who can write the repository. So the set is fixed by its umbrellas: a stranger's issue with the same title names nothing, and a plan cannot invent one. The pillar's label has the same name and is made on first use.

How an issue gets its pillar.

  • Linked under an umbrella (the page, the API, the MCP's link): it carries the label; unlinked, it loses it.
  • A plan item that says pillar: filed under that umbrella and labelled. An unknown pillar refuses the plan and names the pillars.
  • A split: each part that names no pillar carries its parent's.
  • At boot: whatever an umbrella already waited for is labelled, without events.

What changed.

  • src/core/pillars.ts (data), src/actions/pillars.ts (the labelling and its events), hooks in linkIssue, unlinkIssue, setIssueState (split) and openPlan, and one call at boot in src/main.ts.
  • src/web/pages/map.ts: the By pillar list; pillar on every issue in the map's data, plus pillars and mergedByPillar.
  • src/web/pages/board.ts: the 7-day line at the head of Landed.
  • src/http/mcp.ts: plan takes pillar; map returns the pillar data.

What it removes. Nothing. It adds one list on the map and one line on the board; no surface showed pillars before, so there was nothing doing this job to delete.

Done means reachable.

  • Page: /:owner/:name/map (By pillar) and /board (the line in Landed).
  • MCP: map → each issue's pillar, pillars, mergedByPillar: { days: 7, counts }. plan → pillar per item.
  • Test: test/pillars.test.ts, in the gate.
  • Look: taken locally at phone and desktop widths, because the preview's own look is the signed-out front door. The pictures are with the steward.

To know before it lands.

  • On the first boot with this change, every issue already under an umbrella gets its label (about 150 on this forge). That writes labels and no events.
  • A pull is counted under the pillar of the first issue it closes that has one; a pull that closes nothing counts as no pillar.
  • Membership is direct only: an issue an umbrella waits for. An issue that only a pillar's issue waits for reads no pillar until it is linked or split off.

🤖 Generated with Claude Code

commented

Restacked on #706 (head 80f88d1). This pull is now on top of steward/612-planner-defers, so its diff against main includes #706 until that lands. There is one definition of a pillar.

Which module owns what.

  • src/core/pillars.ts (from #706) is the one reader. pillarsOf says which pillars, gate and Later umbrella a repository has. This pull adds to it: the rule that an umbrella, the gate and the Later umbrella count only when someone who can write the repository opened them; servedBy, which pillar each issue serves by the edges (an umbrella waits for it; behind the gate reads Later); and mergedByPillar / pillarView for the map and the board. Nothing is stored there.
  • src/actions/pillars.ts owns the label, which is that reading made visible. It writes the label where the edges change (link, unlink, plan, split) and at boot, and nothing reads the label back. A pillar label set by hand does not survive the next boot.
  • src/actions/plan.ts is #706's. My own plan change is gone; the only addition is one call so a plan's items are labelled.

What changed in behaviour since the description above.

  • Deferred work reads Later when it waits behind the gate, not only when the Later umbrella waits for it.
  • A split no longer copies the label: each umbrella that waited for the whole now waits for its parts, and the label follows the edges.
  • The map and the board count from the edges, so they are right even where a label is missing.

🤖 Generated with Claude Code

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs