[UX][Workflow] Make phase ownership visible without requiring hover

[tt-a1i]

Context

I used Archify 2.14.0 to map a consumer-product development workflow with five phases and approval gates. The diagram passed showcase validation, but a non-technical reader could not reliably tell which phase some nodes belonged to at rest.

For example, Development confirmation and Second proposal both belong to Phase 2, but their visual positions made them feel close to the neighboring Phase 1 and Phase 3 headers. Hovering a node opens the semantic passport and reveals the phase, which helps during exploration, but the static first read and exported image still require inference.

Minimal structure

{
  "schema_version": 1,
  "diagram_type": "workflow",
  "meta": { "title": "Product development", "quality_profile": "showcase" },
  "lanes": [
    { "id": "p1", "label": "P1 | Initiation" },
    { "id": "p2", "label": "P2 | Development" },
    { "id": "p3", "label": "P3 | Validation" }
  ],
  "nodes": [
    { "id": "proposal_1", "lane": "p1", "col": 1, "type": "security", "label": "First proposal" },
    { "id": "development", "lane": "p2", "col": 2, "type": "backend", "label": "Development confirmation" },
    { "id": "proposal_2", "lane": "p2", "col": 3, "type": "security", "label": "Second proposal" },
    { "id": "validation", "lane": "p3", "col": 4, "type": "backend", "label": "Validation" }
  ],
  "edges": [
    { "from": "proposal_1", "to": "development" },
    { "from": "development", "to": "proposal_2" },
    { "from": "proposal_2", "to": "validation" }
  ]
}

Actual behavior

• Phase membership is technically available through hover/focus state.
• At rest, the node-to-phase relationship is visually weaker than the left-to-right flow.
• Static screenshots and presentation views cannot depend on hover discovery.

Expected behavior

Phase membership should be understandable on the first static read. Possible directions include stronger phase bands, full-height guide lines, a restrained phase tint, or another renderer-owned cue derived from the existing lane field.

Acceptance criteria

• A reader can assign each node to its phase without hovering.
• The cue remains legible in both themes and exports.
• It does not add duplicate phase text inside every node.
• Existing workflow JSON remains valid.

Environment

• Archify 2.14.0
• macOS, Node.js 24.19.0
• Codex Desktop

Final checks

• I searched existing issues for the same problem.
• The reproduction contains no secrets, private repository content, personal data, or customer data.

[Irfan-lab700]

/assign

[maheshsingh20]

I'd like to take this on. Proposed approach:

Since nodes already carry a lane field, this can be handled entirely in the renderer, no schema changes needed.

Per-lane background bands: compute each lane's horizontal bounds and draw a full-height, low-opacity rect behind its nodes, drawn first so it sits behind nodes/edges.
Theme-aware tints: define lane colors as CSS variables (consistent with the existing theme system) so they stay legible in both dark and light modes and in exports.
Boundary cue: a subtle guide line or tint step at each lane transition, so adjacent lanes read as distinct without relying on color alone.
No node changes: lane is already labeled once at the header, so nodes stay untouched, avoiding duplicate text.
Validation: hook into the existing layout/overlap checks so bands can't cause new clearance violations.

Happy to open a PR

[maheshsingh20]

Hi @tt-a1i, I've opened a PR (#197) with a complete solution for this issue. It adds a renderPhaseBand() function that renders a full-height, low-opacity phase band per lane, using the existing theme CSS variables so it works correctly across both themes and exports. All golden tests pass and the acceptance criteria in this issue are all covered.

Could you please take a look when you get a chance? Happy to make any changes if needed. Thanks!