pm.html: make a project's dependency structure viewable by a human #111

Open
opened 2026-07-20 16:31:44 +01:00 by vnprc-agent · 0 comments
Contributor

The rendered PM board does not give a human an easy view of a project's dependency structure. The gate DAG renders as a flat text list of "X blocked by Y" edges, with no project-level grouping and no visual tree, so understanding how the issues in a multi-issue effort depend on each other means reading the raw pm.json.

Primary goals:

  • Surface dependency structure — let a human see a project's issues and how they block each other at a glance, not as a flat edge list.
  • Project-level view — group or roll up the issues of one effort so a project reads as a unit.

Current state

render emits the gate DAG as a flat "Gates" section, one list item per blocked-by edge; there is no visual or project-grouped presentation. Constraint: pm.html must stay self-contained — no <script>, no external URLs (the forge sandboxes committed HTML). Any solution must work within that.

Scope

In: how the renderer presents dependency and project structure, within the self-contained-HTML constraint. Out: changes to the pm.json schema or overlay model unless the chosen approach requires them — call that out if so. The implementing agent chooses the approach.

The rendered PM board does not give a human an easy view of a project's dependency structure. The gate DAG renders as a flat text list of "X blocked by Y" edges, with no project-level grouping and no visual tree, so understanding how the issues in a multi-issue effort depend on each other means reading the raw `pm.json`. Primary goals: - **Surface dependency structure** — let a human see a project's issues and how they block each other at a glance, not as a flat edge list. - **Project-level view** — group or roll up the issues of one effort so a project reads as a unit. ### Current state `render` emits the gate DAG as a flat "Gates" section, one list item per blocked-by edge; there is no visual or project-grouped presentation. Constraint: `pm.html` must stay self-contained — no `<script>`, no external URLs (the forge sandboxes committed HTML). Any solution must work within that. ### Scope In: how the renderer presents dependency and project structure, within the self-contained-HTML constraint. Out: changes to the `pm.json` schema or overlay model unless the chosen approach requires them — call that out if so. The implementing agent chooses the approach.
Sign in to join this conversation.
No description provided.