# Observations

## Exported Component Path

- The live `ListTableV2` used by the examples page is exported from [packages/base/index.ts](../../../../packages/base/index.ts) via `./data/list-table-v2/list-table-v2.vue`.
- Earlier styling work had touched a different file, `packages/base/data/list-table-v2.vue`, which is not the component currently exported to the examples app.

## Section 8 Fixed Row Height Behavior

- Section 8 of the demo page uses plain columns without explicit widths.
- In the exported component, fixed row height mode had not originally changed the width path directly, but row-height handling and width/render behavior were easy to confuse because the exported implementation diverged from the older wrapper file.

## Wrapping Logic

- There is no explicit semantic classifier for “wrappable” vs “unwrappable” values.
- For normal body cells, width estimation uses shrink-wrap text measurement, which is effectively an unwrapped width preference.
- For normal body cells, row-height estimation uses wrapped text measurement at the current column width.
- Rendered body cells are wrappable by default through CSS:
  - `white-space: normal`
  - `word-break: break-word`
- Header text is explicitly non-wrapping through CSS:
  - `white-space: nowrap`
- Custom renderer / slot cells are not text-measured with pretext; they use fallback height behavior instead.

## Minimum Width Logic

- If a column has explicit `width`, runtime style sets:
  - `width = explicitWidth`
  - `minWidth = explicitWidth`
  - `maxWidth = explicitWidth`
- If a column has explicit `minWidth`, that value becomes the computed `minWidth`.
- Otherwise, automatic `minWidth` is derived from measured text statistics:
  - measure shrink-wrap width of header text
  - measure shrink-wrap width of sampled cell text
  - compute `mean` and `variance`
  - set `minWidth = max(mean - 2 * sqrt(variance), MIN_BASE_WIDTH) + CELL_PADDING`
- This means auto `minWidth` is a statistical lower bound, not the width of the longest value.
- If computed config is unavailable, the runtime fallback path uses `col.minWidth ?? 120` with a floor of `50px`.

## Timestamp Width Bug Root Cause

- Timestamp columns were rendered using formatted values, but width estimation had been measuring raw values.
- Example:
  - rendered timestamp looked like `2026-04-08 12:34:56`
  - width estimation measured the raw Unix value like `1712579696`
- This mismatch caused timestamp columns to be under-sized relative to their actual displayed content.
- The discrepancy between section 1 and section 4 timestamp-related widths came from the width hook deriving stats from sampled measured values, combined with the mismatch between raw and formatted text.

## Fix Applied During This Session

- `usePretextColumnWidths` now accepts `formatCellValue` so width estimation uses the same displayed text as the rendered cell.
- The exported `ListTableV2` passes its `formatCellValue` implementation into the width hook.
- Scoped lint passed on the touched table-v2 files after this change.