Skip to content

Render before/after pairs side by side in the managed comment #419

Description

@zachdunn

Problem

When a PR's attachments include a before/after pair, the managed comment renders them as independent images in upload order. The reader does the pairing in their head. Seen in practice on PR #417's own attachments comment: hero-before and hero-after render stacked, not side by side.

The data to pair them already exists: #365/#370 put path and state metadata into the comment pipeline (--state before|after|empty|error|loading is the documented capture habit), and the skills teach agents to tag both sides.

Proposal

In gatherCommentBody's rendering: when two attachments form a pair, render them as one side-by-side row (two-column table cell or equivalent GitHub-markdown-safe layout), labeled before / after.

Pairing rule, in order:

  1. Same path metadata, one state=before and one state=after.
  2. No path: filename stems that differ only by a before/after token (hero-before.webp / hero-after.webp, before.png / after.png).

Unpaired attachments render exactly as today. A pair where one side updates keeps the pairing (keys are stable per filename, so re-captures replace in place).

Notes

  • GitHub markdown constraint: side-by-side generally means a <table> or | | markdown table with images — verify rendering on github.com including mobile width before committing to a layout.
  • Same rendering applies everywhere the comment is produced (client sync, webhook promote, reconcile) since they share the render path — no per-trigger work.
  • Sequenced states beyond the pair (empty/error/loading) stay unpaired in v1.

Related: #365 (deferred this grouping), #370, the file-page counterpart view issue (filed alongside this one).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions