@3xhaust/oh-my-design 0.16.1

package/core/composition/bento-grid.md

@@ -0,0 +1,223 @@
+# Bento grid
+
+> Candidate hypothesis only. Revalidate its condition, values, and responsive transition
+> against the current composition contract; do not transfer this page recipe unchanged.
+
+A bento grid divides a section into cells of intentionally different sizes, arranged as a
+mosaic. The cell size hierarchy communicates content hierarchy: the largest cell holds
+the most important content, and the eye reads that before anything else. The grid earns
+its distinctiveness from non-uniformity — if all cells are the same size, it is a card
+grid, not a bento grid, regardless of what it is called.
+
+## When it earns its place / When it does not
+
+Condition: the section contains varied content types that benefit from non-uniform visual
+weight — a primary feature with more depth, supporting features with less, and perhaps a
+decorative or data element at a different proportion. The arrangement must be a statement
+of hierarchy: the user can tell at a glance which cell matters most because it is largest.
+A homepage overview where one product capability is the anchor and three or four support
+it, a feature highlight section where capabilities are genuinely asymmetric — these earn
+the grid.
+
+`core/theory/layout.md` on card hierarchy: "Every card must have an internal hierarchy:
+one primary piece of information that the eye finds first, and secondary information that
+serves it." The bento grid applies this principle at the section level: one cell is the
+primary; all others serve it.
+
+**Anti-slop clause.** A bento grid that fills all cells with equal-weight cards is
+SLOP-TRIPLE-CARD rendered at scale. The grid earns its place only when the cell-size
+hierarchy is non-recoverable: the arrangement itself tells the reader what matters most.
+If you can swap cells without loss of meaning, the bento grid is the wrong layout.
+The `SLOP-TRIPLE-CARD` slop rule fires on three or more identically-treated cards
+regardless of whether they are arranged in a standard grid or a bento mosaic — the
+violation is in the equal treatment, not in the grid structure.
+
+Condition against: content where all items are genuinely equal in importance — a pricing
+table, a team member grid, a portfolio gallery. Forced hierarchy on equal content
+misinforms the user. Also: narrow viewports where the bento mosaic must collapse to a
+single column, losing the hierarchical arrangement that justified it. If the layout reads
+as a simple stacked list on mobile, the bento grid is carrying the hierarchy only on
+desktop — which means the hierarchy is not in the content, it is in the layout trick.
+
+## Parameters
+
+```css
+:root {
+  /* Grid gap between cells. Consistent gap size is important — uneven gaps
+     read as different object weights. Use a single token. */
+  --bento-gap: clamp(8px, 1.5vw, 16px);
+
+  /* Base grid unit. All cell spans are multiples of this.
+     A 4-column base allows: 1 (quarter), 2 (half), 3 (three-quarter), 4 (full).
+     A 6-column base allows more granular spans. */
+  --bento-columns: 4;
+
+  /* Minimum row height. Cells taller than this are defined by row-span.
+     This sets the rhythm of the grid. */
+  --bento-row-height: clamp(160px, 22vw, 280px);
+
+  /* Cell radius: consistent across all cells.
+     Bento grids on award-winning sites use a consistent radius to read as one object.
+     Inconsistent radii break the mosaic reading. */
+  --bento-radius: var(--radius-card, 12px);
+}
+```
+
+## Implementation
+
+```html
+<!-- The grid container defines the column structure.
+     Each cell declares its own span — no JavaScript layout library needed.
+     The hierarchy is declared in the HTML: the primary cell comes first
+     and spans the largest area. -->
+<div class="bento-grid">
+  <!-- Primary cell: largest, most important content. Spans 2 columns, 2 rows. -->
+  <div class="bento-cell bento-cell--primary">
+    <h2>The primary capability.</h2>
+    <p>The claim with the most depth, given the most space.</p>
+  </div>
+
+  <!-- Supporting cells: smaller, each with a distinct capability. -->
+  <div class="bento-cell bento-cell--secondary">
+    <h3>Supporting capability one.</h3>
+  </div>
+
+  <div class="bento-cell bento-cell--secondary">
+    <h3>Supporting capability two.</h3>
+  </div>
+
+  <!-- Accent cell: a data point, a decorative element, or a CTA at smaller scale. -->
+  <div class="bento-cell bento-cell--accent">
+    <span class="bento-stat">48ms</span>
+    <span class="bento-stat-label">median response time</span>
+  </div>
+
+  <!-- Wide secondary: spans the full width below the primary cluster. -->
+  <div class="bento-cell bento-cell--wide">
+    <h3>The wider supporting context.</h3>
+    <p>Content that benefits from a wider canvas than the narrow supporting cells.</p>
+  </div>
+</div>
+```
+
+```css
+.bento-grid {
+  display: grid;
+  grid-template-columns: repeat(var(--bento-columns), 1fr);
+  grid-auto-rows: var(--bento-row-height);
+  gap: var(--bento-gap);
+  padding-inline: var(--space-page-margin, 5vw);
+}
+
+/* All cells share the base styling: the radius and background.
+   Differentiation comes from content hierarchy, not from different styling. */
+.bento-cell {
+  border-radius: var(--bento-radius);
+  background-color: var(--surface-subtle, #f5f5f3);
+  padding: var(--space-6, 1.5rem);
+  overflow: hidden;
+  /* Cells do not have individual box-shadows — the gap performs the separation. */
+}
+
+/* Primary cell: the largest. The hierarchy is in the span, not in extra decoration. */
+.bento-cell--primary {
+  grid-column: span 2;
+  grid-row: span 2;
+  /* The primary cell may have a distinct background only if it is the section's
+     anchor — not as generic differentiation. */
+  background-color: var(--surface-emphasis, #0f0f0f);
+  color: var(--on-surface-emphasis, #f5f5f3);
+}
+
+.bento-cell--secondary {
+  grid-column: span 1;
+  grid-row: span 1;
+}
+
+.bento-cell--accent {
+  grid-column: span 1;
+  grid-row: span 1;
+  display: flex;
+  flex-direction: column;
+  align-items: flex-start;
+  justify-content: flex-end;
+}
+
+.bento-cell--wide {
+  grid-column: span var(--bento-columns); /* full width */
+  grid-row: span 1;
+}
+
+.bento-stat {
+  font-size: clamp(2rem, 6vw, 4rem);
+  font-weight: var(--weight-display, 700);
+  letter-spacing: -0.04em;
+  line-height: 1;
+}
+
+.bento-stat-label {
+  font-size: var(--text-xs, 0.75rem);
+  color: var(--text-secondary);
+  margin-top: var(--space-1, 0.25rem);
+}
+```
+
+## Responsive behavior
+
+**375px (mobile):** The multi-column mosaic collapses to a single column. The hierarchy
+must still read — the primary cell appears first in DOM order, retaining its importance
+through position even when size parity is lost.
+
+```css
+@media (max-width: 600px) {
+  .bento-grid {
+    grid-template-columns: 1fr;
+    grid-auto-rows: auto; /* height driven by content on mobile */
+  }
+
+  .bento-cell--primary,
+  .bento-cell--secondary,
+  .bento-cell--accent,
+  .bento-cell--wide {
+    grid-column: 1 / -1;
+    grid-row: auto;
+    min-height: var(--bento-row-height); /* preserve breathing room */
+  }
+}
+```
+
+**768px (tablet):** A two-column variant works well at tablet width. Reduce
+`--bento-columns` to 2 and verify that the primary cell's two-column span still reads
+as dominant — at 768px with two columns, a `span 2` cell occupies the full row, which
+may remove the mosaic effect. Consider a `span 1` tall primary at tablet.
+
+```css
+@media (min-width: 601px) and (max-width: 1024px) {
+  .bento-grid {
+    --bento-columns: 2;
+  }
+
+  .bento-cell--primary {
+    grid-column: span 2;
+    grid-row: span 1; /* adjust: span 2 at 2-col is full-width */
+  }
+}
+```
+
+**1280px (desktop):** Full 4-column mosaic. The `--bento-row-height` ceiling of 280px
+keeps cells within a readable range; taller cells are appropriate only when they hold
+content that genuinely requires height (an image, a chart, a demonstration). An empty
+tall cell is wasted space, not visual breathing room.
+
+## Do not combine with
+
+**asymmetric-diagonal-grid.md** — both techniques restructure the spatial grid at the
+same level. Applying both in a single section produces competing spatial logics.
+
+**section-inversion.md** inside individual bento cells — switching background colour per
+cell introduces a fourth surface level (page → section → cell → inverted cell) that
+obscures the hierarchy the bento grid was designed to communicate.
+
+**A bento grid where every cell has the same span** — this collapses back into
+`SLOP-TRIPLE-CARD` territory. The anti-slop clause above applies: if the spans are
+uniform, use a standard grid or card layout and state the reason.

package/core/composition/editorial-index-labels.md

@@ -0,0 +1,173 @@
+# Editorial index labels (01, 02, 03)
+
+> Candidate hypothesis only. Revalidate its condition, values, and responsive transition
+> against the current composition contract; do not transfer this page recipe unchanged.
+
+A large ordinal number — set at display scale, typically 10–15% opacity — anchors each
+section to its position in a sequence. The number reads as background field before it
+reads as a numeral; it reinforces order and creates depth without competing with the
+section's primary content.
+
+`expressive.md` on this technique: "The large number (set at display scale, often 10–15%
+opacity as a background element) reinforces the ordered reading without becoming the
+dominant visual."
+
+## When it earns its place / When it does not
+
+Condition: the content has a genuine sequence — steps in a process, chapters in a
+narrative, items in an ordered argument. The numbering must correspond to a sequence the
+user will perceive as sequential; the label confirms what the user already suspects. A
+case study with four distinct phases, a feature walkthrough with a natural order, a
+methodology page with numbered stages — each earns the label because the sequence is real.
+
+`core/theory/layout.md` — von Restorff and the one memorable thing: the large number
+differentiates each section from the others through the isolation effect. Used across all
+sections, each number is equally differentiated, which means none of them is — the effect
+cancels itself. Applied to a genuine sequence, the number adds the memory hook von Restorff
+describes; applied arbitrarily, it is visual noise.
+
+Condition against: fake sequences — content enumerated to look ordered when the items have
+no natural sequence. A features section with three independent capabilities numbered 01–03
+implies the user should attend to them in order; if they should not, the numbering lied.
+`expressive.md`: "Numerical labels that carry no sequential meaning are decoration, and
+decoration at display scale is noise." Also: navigation lists, card grids, or any context
+where the user is scanning rather than reading in order.
+
+This specific tell — large low-opacity ordinals on unordered sections — is a documented
+signature of generated pages: giant faint numerals that imply sequence where none exists. The counter-condition is this recipe: ordinals on
+sections whose content has a genuine sequence (methodology phases, walkthrough steps,
+ordered chapters). When the label earns its place the ordinal confirms what the user
+already suspects; when it does not, it is decoration at display scale and should be removed.
+The SLOP-TRIPLE-CARD rule fires on the underlying grid structure that often accompanies
+unearned numbering; adding ordinals to a triple-card grid resolves neither finding.
+
+## Parameters
+
+```css
+:root {
+  /* Font size for the index number.
+     Large enough to read as a background field, not a foreground label.
+     Typical range: clamp(5rem, 15vw, 12rem). */
+  --index-font-size: clamp(5rem, 15vw, 12rem);
+
+  /* Opacity: low enough to read as depth, not text.
+     10–15% is the operative range; above 20% the number competes with the heading. */
+  --index-opacity: 0.1;
+
+  /* Position within the section grid.
+     Typically anchored to the left or top-left, offset behind the heading. */
+  --index-offset-top: -0.15em; /* nudge behind the heading's cap-height */
+  --index-offset-left: -0.05em; /* slight bleed into the margin */
+
+  /* Font weight.
+     Heavy weight at low opacity reads as texture; light weight at low opacity disappears.
+     700 or 800 is the operative range. */
+  --index-font-weight: 700;
+}
+```
+
+## Implementation
+
+```html
+<!-- Each section carries its own index number.
+     aria-hidden: the number is decorative; screen readers skip it.
+     The section heading carries the actual label for assistive technology. -->
+<section class="indexed-section" data-index="01">
+  <span class="indexed-section__number" aria-hidden="true">01</span>
+  <div class="indexed-section__content">
+    <h2 class="indexed-section__heading">Discovery</h2>
+    <p>The phase where assumptions are tested against the real problem.</p>
+  </div>
+</section>
+
+<section class="indexed-section" data-index="02">
+  <span class="indexed-section__number" aria-hidden="true">02</span>
+  <div class="indexed-section__content">
+    <h2 class="indexed-section__heading">Definition</h2>
+    <p>Where the real problem is named, with evidence.</p>
+  </div>
+</section>
+```
+
+```css
+.indexed-section {
+  position: relative;
+  padding-block: var(--space-section, 6rem);
+  padding-inline: var(--space-page-margin, 5vw);
+  /* Overflow hidden: the large number must not create horizontal scroll */
+  overflow: hidden;
+}
+
+.indexed-section__number {
+  position: absolute;
+  top: var(--index-offset-top);
+  left: var(--index-offset-left);
+  font-size: var(--index-font-size);
+  font-weight: var(--index-font-weight);
+  font-family: var(--font-display);
+  line-height: 1;
+  letter-spacing: -0.04em;
+  opacity: var(--index-opacity);
+  /* Prevent the number from intercepting pointer events on content above */
+  pointer-events: none;
+  user-select: none;
+  /* z-index: below the content, above the background */
+  z-index: 0;
+}
+
+.indexed-section__content {
+  position: relative;
+  z-index: 1; /* above the index number */
+  /* The content column stays within the readable measure — max 72ch for body,
+     narrower for the heading. */
+  max-width: 60ch;
+}
+
+.indexed-section__heading {
+  font-size: var(--text-2xl, 2rem);
+  font-weight: var(--weight-heading, 600);
+  margin-bottom: var(--space-4, 1rem);
+}
+```
+
+## Responsive behavior
+
+**375px (mobile):** The large number at `clamp(5rem, 15vw, 12rem)` computes to
+`max(5rem, 56px) = 80px` at 375px — small enough to not dominate the viewport. The
+absolute-positioned number may overlap the heading at this size; verify the heading remains
+legible. If contrast is compromised, increase the `--index-offset-top` negative value to
+push the number further behind or reduce `--index-opacity` to 0.06 at narrow viewports.
+
+```css
+@media (max-width: 600px) {
+  .indexed-section {
+    --index-opacity: 0.07; /* reduce further at narrow viewports to preserve legibility */
+    padding-block: var(--space-section-mobile, 3rem);
+  }
+}
+```
+
+**768px (tablet):** The number at `15vw` computes to ~115px. The absolute positioning works
+well; the heading and body copy are clearly in the foreground. No structural change needed;
+adjust offset if the number's baseline aligns uncomfortably with the heading's cap height.
+
+**1280px (desktop):** The ceiling `12rem` (192px at 16px root) governs. At this size the
+number reads as a large background field. The content column at `max-width: 60ch` leaves
+significant space on the right at full viewport — the index number fills that zone
+naturally. The composition reads as editorial depth, not as an oversized ordinal.
+
+## Do not combine with
+
+**sidebar-margin-annotation.md** in the same section — both create competing secondary
+reading tracks in the peripheral field (left side for the index, right margin for
+annotations). The eye cannot establish which secondary track is the intended one.
+
+**section-inversion.md** per section — when every section inverts, the index number's
+opacity calibration breaks across light and dark surfaces. Calibrate separately for each
+surface or avoid the combination.
+
+**editorial-index-labels with fake sequences** — this bears repeating because the temptation
+is real: do not apply index labels to a grid of independent features to make the page look
+more structured. `expressive.md` names this directly as decoration. The slop linter's
+`SLOP-TRIPLE-CARD` rule fires on the underlying grid; adding index numbers to that grid
+does not resolve the finding.

package/core/composition/form-wizard-stepper.md

@@ -0,0 +1,132 @@
+# Form wizard stepper
+
+> Candidate hypothesis only. Revalidate its condition, values, and responsive transition
+> against the current composition contract; do not transfer this page recipe unchanged.
+
+A focused multi-step flow — onboarding, signup, checkout, complex creation — composed as
+one narrow column with a visible progress model, one decision cluster per step, and an
+exit from every state. The composition suppresses everything that is not the flow: no
+global navigation pulling the user mid-task, no marketing panel repeating the pitch they
+already accepted. `core/theory/ux.md` §Forms owns the step-count evidence (Baymard: a
+visible progress indicator reduces perceived effort; only the steps the user's task
+requires); `core/theory/layout.md` §Forms owns field-row grammar.
+
+## When it earns its place / When it does not
+
+Condition: the task has 8+ fields or genuinely dependent decisions (later fields depend
+on earlier answers), or the user's mental load per screen must stay low (first-run
+onboarding). Each step is one decision cluster the user can name ("계정", "팀 초대",
+"결제") — a step that exists because an engineer needed the data, not because the user
+makes a decision there, is merged away.
+
+Condition against: under ~8 independent fields — a single-page form shows the full cost
+upfront and is cheaper (`theory/ux.md` §Forms). Also against: pull-based product
+onboarding where the product is usable immediately — prefer contextual empty-state
+guidance over a forced wizard (§First-run experience: forced tutorials retain worse).
+
+**Anti-trap clause.** Every step has an escape: back to the previous step without data
+loss, save-and-exit or an explicit cancel with consequence named. A wizard whose only
+exits are "다음" and the browser's back button is a dead end factory. Entered values
+survive navigation in both directions and validation failure (value preservation is the
+UX acceptance contract, not polish).
+
+## Parameters
+
+```css
+:root {
+  /* One-column measure. Forms read and complete fastest in a single column
+     (theory/layout.md §Forms); 44-52ch keeps labels+inputs scannable. */
+  --wizard-measure: 48rem;
+
+  /* Progress model: steps are few, named, and visible. */
+  --wizard-step-gap: 8px;
+  --wizard-accent: var(--accent, #1f6f5c);
+
+  /* Primary action anchors the step end; back is quiet, never competing. */
+  --wizard-cta-h: 48px;
+}
+```
+
+## Implementation
+
+```html
+<main class="wizard">
+  <!-- Progress: named steps, current marked, completed steps revisitable. -->
+  <nav class="wizard-progress" aria-label="진행 단계">
+    <ol>
+      <li><a href="#step-account" class="done">계정</a></li>
+      <li aria-current="step">팀 초대</li>
+      <li>결제</li>
+    </ol>
+  </nav>
+
+  <form class="wizard-step" aria-labelledby="step-title">
+    <h1 id="step-title">팀원을 초대해요</h1>
+    <p class="wizard-why">건너뛰어도 돼요 — 나중에 설정에서 초대할 수 있어요.</p>
+
+    <!-- One decision cluster: fields in one column, labels above,
+         errors adjacent to their field, values preserved on failure. -->
+
+    <div class="wizard-actions">
+      <button type="button" class="wizard-back">이전</button>
+      <button type="submit" class="wizard-next">다음: 결제</button>
+      <button type="button" class="wizard-skip">건너뛰기</button>
+    </div>
+  </form>
+</main>
+```
+
+```css
+.wizard {
+  max-width: var(--wizard-measure);
+  margin-inline: auto;
+  padding-inline: 16px;
+}
+
+.wizard-progress li[aria-current="step"] { color: var(--wizard-accent); font-weight: 600; }
+
+.wizard-step { display: grid; row-gap: 16px; }
+
+.wizard-actions {
+  display: flex;
+  align-items: center;
+  gap: 12px;
+  /* One primary per view: "다음" is filled; back/skip are quiet. */
+}
+
+.wizard-next { min-height: var(--wizard-cta-h); }
+```
+
+The primary button predicts the next step by name ("다음: 결제" — a CTA predicts what
+happens after activation, per the copy-deck protocol). The final step ends on a designed
+confirmation that restates what was created and names the first real action in the
+product (§Peak-end rule: the end is a deliberate moment, not a redirect).
+
+## Responsive behavior
+
+**1280px (desktop):** the column centers at `--wizard-measure`; surrounding space stays
+empty — a wizard earns air (density follows task frequency; this is a low-frequency,
+high-attention surface).
+
+**768px (tablet):** identical structure; the progress list may compress to
+"2/3 — 팀 초대" numeric form when horizontal room runs out, but the current step stays
+named.
+
+**375px (mobile):** actions dock to the bottom within thumb reach; the keyboard must not
+cover the focused field or the primary action (test with the on-screen keyboard open —
+the bottom-CTA-under-keyboard failure is the classic mobile wizard defect). Back remains
+visible without scrolling. At 320px nothing two-dimensional remains.
+
+## Do not combine with
+
+**app-shell-workbench.md global navigation** — a focused flow suppresses global nav;
+offering the whole product map mid-checkout invites abandonment and half-created state.
+Show at most a logo-exit with a named consequence.
+
+**split-screen-hero.md as a signup decoration panel** — the persuasion already happened;
+a marketing half-panel steals half the viewport from the form on every step and doubles
+the reflow work at 768px for nothing the task needs.
+
+**Progress bars without step names** — a bare percentage tells the user neither where
+they are nor what remains; the anti-pattern version of the visible-progress evidence this
+recipe cites.

package/core/composition/master-detail-flow.md

@@ -0,0 +1,129 @@
+# Master-detail flow
+
+> Candidate hypothesis only. Revalidate its condition, values, and responsive transition
+> against the current composition contract; do not transfer this page recipe unchanged.
+
+A list (master) and the selected object's workspace (detail) presented as one continuous
+loop: select → inspect → act → return. The composition decision is where the detail
+lives — beside the list, over it, or as a separate screen — and that decision is made
+from loop frequency and context needs, not from viewport fashion. `core/theory/ux.md`
+§Flows: every step that exists only because the layout forced a round-trip is an obstacle.
+`core/theory/layout.md` §Density governs the master's row height and scan columns.
+
+## When it earns its place / When it does not
+
+Condition: the primary task is processing or inspecting items from a collection —
+tickets, orders, documents, contacts, messages — and the user alternates between
+scanning the collection and working on one item many times per session.
+
+Choose the detail presentation by two questions:
+
+1. **Does acting on the item require seeing the list?** (triage, comparison, queue
+   awareness) → side-by-side split. The list keeps its scan columns visible; the detail
+   never fully covers them.
+2. **Is the item work immersive and self-contained?** (long editing, composition) →
+   full-screen detail with an explicit return path, or an overlay panel when the visit
+   is brief (peek, quick edit).
+
+Condition against: collections the user visits rarely or only reads linearly (an archive,
+a blog index) — a plain list with navigation is cheaper. Also against: splitting the
+viewport when the detail needs the full width to do its job (a canvas editor) — that is
+an app-shell question, not master-detail.
+
+**Anti-overlay clause.** An overlay detail that hides the list's status/assignee columns
+while the loop still needs them breaks queue awareness — the failure seen whenever a
+"slick" slide-over covers exactly the columns the user was triaging by. If the loop needs
+the list, the split is side-by-side and the list keeps `minmax(0, …)` room for its scan
+columns.
+
+## Parameters
+
+```css
+:root {
+  /* Master:detail ratio. 7:5 favors scanning; 5:7 favors item work.
+     Choose from the frame's frequent action, then verify at 1280. */
+  --md-master-fr: 7fr;
+  --md-detail-fr: 5fr;
+
+  /* Minimum master width before the split collapses to stacked navigation.
+     Below this the scan columns compress into unreadability. */
+  --md-master-min: 480px;
+
+  /* Selected-row marker: structural (inset bar + tint), never tint alone. */
+  --md-selected-bg: color-mix(in srgb, var(--accent, #1f6f5c) 8%, transparent);
+}
+```
+
+## Implementation
+
+```html
+<div class="master-detail">
+  <section class="md-master" aria-label="목록">
+    <!-- Toolbar: search + filters + primary action. Then the collection at
+         working density. Selection state is visible and persistent. -->
+    <table class="md-table">
+      <!-- Scan columns: the nouns the user triages by (status, owner, time).
+           The row's open control is a real button/link for keyboard reach. -->
+    </table>
+  </section>
+
+  <section class="md-detail" aria-label="상세">
+    <!-- Item header: title + status control + explicit return path ("목록으로").
+         Then the item workspace: content, then the action surface (reply box,
+         form) at the end of the loop, sticky on mobile. -->
+  </section>
+</div>
+```
+
+```css
+.master-detail {
+  display: grid;
+  grid-template-columns: minmax(var(--md-master-min), var(--md-master-fr)) minmax(0, var(--md-detail-fr));
+  min-height: 0;
+}
+
+.md-master { border-right: 1px solid var(--line, #e5e7e5); min-width: 0; }
+
+.md-table tr[aria-selected="true"] {
+  background: var(--md-selected-bg);
+  box-shadow: inset 3px 0 0 var(--accent, #1f6f5c);
+}
+
+.md-detail { min-width: 0; display: flex; flex-direction: column; }
+```
+
+The empty-detail state is designed, not blank: when nothing is selected, the detail
+region says what selecting does ("왼쪽 목록에서 티켓을 열면 여기에 대화가 보여요") — a
+dead pane teaches nothing. Acting in the detail updates the master in place (status
+badge, ordering) so the loop's feedback is visible where the next scan happens.
+
+## Responsive behavior
+
+**1280px (desktop):** side-by-side split at the declared ratio. Both regions scroll
+independently; the detail's action surface stays reachable without scrolling past the
+full conversation when the loop is reply-heavy.
+
+**768px (tablet):** the split usually no longer fits `--md-master-min`; collapse to
+stacked navigation — list screen ↔ detail screen — with the selection remembered on
+return (scroll position and selected row preserved). An overlay panel is acceptable here
+only when the loop does not need the list's columns while acting.
+
+**375px (mobile):** always stacked navigation: full-screen list → full-screen detail
+with a visible "목록으로" return in the top zone and the action surface sticky at the
+bottom within thumb reach. DOM order stays list-then-detail so focus order and back
+navigation match the visual model. At 320px the list rows recompose (title line +
+meta line + status mark) instead of compressing table columns.
+
+## Do not combine with
+
+**app-shell-workbench.md side nav at tablet width** — an expanded side nav plus a
+side-by-side split leaves the master below its minimum; collapse the nav to the icon
+rail before collapsing the split.
+
+**sticky-sidebar-scroll.md** — a sticky editorial sidebar and a master pane are competing
+persistent regions with different scroll models; a surface gets one persistent
+navigation-like region beside the work, not two.
+
+**Modal dialogs as the default detail** — a modal steals the list, traps scroll, and
+forgets position; it is for confirmations and small focused inputs, not for the loop's
+main workspace.