#Change Review

Change Review keeps a bounded set of file changes, scope summary, and final decision together so people can confirm exactly what they are accepting before they act.

npm install @a3s-lab/ui

<section
  class="change-review"
  data-state="reviewing"
  aria-labelledby="review-title"
>
  <header>
    <div>
      <h2 id="review-title">Review interface updates</h2>
      <p data-review-summary>3 files · 44 additions · 9 deletions</p>
    </div>
    <span class="status-badge" data-state="active" data-review-status>In review</span>
  </header>
  <ul data-review-files>
    <li>
      <code>src/app.css</code>
      <span data-review-delta>+4 −1</span>
    </li>
  </ul>
  <footer>
    <button type="button" class="btn" data-variant="outline">Request changes</button>
    <button type="button" class="btn">Accept changes</button>
  </footer>
</section>

import "@a3s-lab/ui/a3s.css";

#Usage

The title states the purpose of the change, the summary gives its complete scope, the file list preserves auditable paths, and decision labels name their consequences. The component does not load diffs or submit a decision for the host.

<section
  class="change-review"
  data-state="reviewing"
  aria-labelledby="review-title"
>
  <header>
    <div>
      <h2 id="review-title">Review interface updates</h2>
      <p data-review-summary>3 files · 44 additions · 9 deletions</p>
    </div>
    <span class="status-badge" data-state="active" data-review-status>In review</span>
  </header>
  <ul data-review-files>
    <li>
      <code>src/app.css</code>
      <span data-review-delta>+4 −1</span>
    </li>
  </ul>
  <footer>
    <button type="button" class="btn" data-variant="outline">Request changes</button>
    <button type="button" class="btn">Accept changes</button>
  </footer>
</section>

#Parameters

#States and variants

pending means review material is still being prepared and must not expose premature decisions. reviewing permits inspection and a decision. accepted and rejected preserve the final outcome. conflict retains the original proposal while explaining a competing revision. error explains why the material or decision could not load or submit.

<section class="change-review" data-state="conflict" aria-labelledby="change-conflict-title-en">
  <header>
    <div><h2 id="change-conflict-title-en">Changes need another review</h2><p data-review-summary>1 file changed while the review was open</p></div>
    <span class="status-badge" data-state="warning" data-review-status>Conflict</span>
  </header>
  <ul data-review-files>
    <li><code>src/css/components/device-simulator.css</code><span data-review-delta>Revision changed</span></li>
  </ul>
  <footer><button type="button" class="btn" data-size="sm" data-variant="outline">Load latest changes</button></footer>
</section>

Per-line or per-file acceptance belongs to a richer diff inspector and should not be imitated with an ordinary checkbox list. When the file set is large, show summary and filtering before entering Code Diff; do not render an unbounded list inside one card.

#Accessibility

Associate the section with its heading through aria-labelledby. State labels need text; color alone cannot communicate review, conflict, or completion. Keep long file paths available through horizontal reading or a title rather than truncating the only value. Button labels state the affected scope and result. During pending or decision submission, retain the summary and current focus context. After a conflict or error, put recovery next to its explanation instead of silently returning to a generic review state. The host owns change truth, permissions, decisions, and persistence; the component owns the review summary and action grouping.