# 016 — Ragged CSV rows silently lose data in the rendered table (server doesn't normalize row width)

**Status:** Open
**Severity:** Low-Medium — silent data loss in the primary rendered view;
raw sidecar is unaffected, so it's a fidelity/display bug, not permanent
loss.

Round-3 probe of the `csv` kind (ragged rows, from the #013 handover).
Confirmed with an actual headless-Chrome render, not just server inspection.

## Description

`wrap_csv_viewer` (`artifacts/views.py`) parses CSV server-side and hands
Grid.js `{columns: rows[0], data: rows[1:]}` **without reconciling each
data row's width against the header**. Grid.js keys body cells by
column-id, so any row that doesn't match the header column count renders
wrong:

- **Row longer than header → extra cells silently dropped.**
- **Row shorter than header → missing cells rendered blank.**

Daybook's stated principle is "the server owns normalization," but row
width isn't normalized here, so the display silently disagrees with the
data.

## Reproduction (verified via headless Chrome render)

Posted `csv` content:

```
a,b,c
1,2,3,4,5
6,7
```

Server hands Grid.js: `{"columns": ["a","b","c"], "data": [["1","2","3","4","5"], ["6","7"]]}`

Rendered DOM (headless Chrome, JS executed):

```
| a | b | c |
| 1 | 2 | 3 |      <- values 4 and 5 are GONE, not shown anywhere
| 6 | 7 |   |      <- third cell blank
```

The `4` and `5` from the first data row do not appear in the rendered
table at all. `GET /a/{id}?raw=1` still returns the original CSV intact, so
the data isn't destroyed — but a user browsing the artifact (the normal
path, and the shared-link path) sees fewer values than the CSV contains,
with no truncation indicator.

This is realistic input: trailing commas, inconsistent exports, and
hand-edited CSVs routinely produce rows that don't all match the header
width.

## Other CSV edge cases tested (all fine)

For the record — these were probed in the same pass and behaved correctly:

- Embedded commas, quotes (`""` escaping), and newlines inside quoted
  fields: parsed correctly (Python's `csv` module).
- `duplicate columns` (`id,id,id`): rendered (3 same-named headers) — a
  bit odd for sorting but not a data bug.
- `header only`: empty table, fine.
- `empty content`: rejected `400`, consistent with `json`.
- `single giant cell` (20 KB): rendered fine.
- `just commas`: empty-named columns, rendered.

So the parsing is robust; the gap is specifically row-width normalization
before the data reaches Grid.js.

## Suggested Fix

In `wrap_csv_viewer`, normalize each data row to `len(columns)` before
serializing — pad short rows with `""`, and for over-long rows either (a)
truncate but surface it, or better (b) widen `columns` to the maximum row
width (auto-naming the extra columns, e.g. `column_4`, `column_5`) so no
cell is ever dropped. Option (b) preserves all data, which matches the
"server owns normalization, never silently lose content" spirit. Whichever
is chosen, the rendered table should never contain fewer values than the
raw sidecar.

## Resolution

_(pending)_