Composition notes

• Question: what sensitive data are agents touching? The whitespace page — no precedent treats files touched by agents as an inventory class (c19), so the grain is the sensitive category, not the path tree: credential → secret → PII → config → source → other, with the access mix (read / write / edit) as the row's micro-viz.
• Verdict line from filesVerdict(world) (a sharpened verdicts.files, fold-in candidate): files on record, how many sensitive, then the credential read named — agent, person, date, working repo — and the ordinary secret reads as a receipt. Warn when a credential was read; attention in the all-clear state on purpose: two secrets read in the course of work is still a receipt, and a green line would claim nothing was touched. The page says so under the verdict.
• Framing band = three claims as filter buttons (files touched = reset · sensitive · secrets & credentials read, the one attention device, its sub naming the redaction) plus the category mix as a segment bar with a row of claims, each a filter. The band spends one color: the attention block's sub is the credential fragment alone (red when a credential was read, amber for the ordinary-secrets receipt when none was); the full accounting prints once in the footer, and the mix bar is a grey ramp — tone lives in the table badges, where the credential row already carries the page's red. Band numbers cross-foot with the rows.
• Table is the raw UxTableList family so ?id= can pre-open a row. Rows from fileRows(world), pre-ranked; sorters on every column; search rides the Path header. People are person chips (→ User detail) and Agents print the technology marks with the install count as text; Sessions is a column only when a file differs from the rest — when every file has the same count the footer says it once. One attention device per row: the category badge (credential red, secret amber). Sensitivity is a neutral mono meter (●●● high … ○○○ none). The access cell is agent-mini-cards' {read, write, edit} breakdown as a mono triplet over a stacked bar scaled to the table's largest row; writes = new files, edits = existing files modified (the world's definition — events say create / write).
• Repo means the path belongs to one: never for a home-directory path, else the touching session's repo, else a name-prefix match. The session's working repo is context, shown in the access log — so ~/.aws/credentials sits outside any repo while its read happened in qpoint/infra.
• Expand = three UxTableListExpandSection cards: header (path, badge, meter, repo, access / sessions / people / last touch, the honest "view details →" stub — there is no file-detail page in Phase 1, the row is the detail); the access log, one row per session with op-level detail from events where the session has them (the c77 sensitive-file session shows read 16:44:48 · redacted) and "counts only" where it does not — every row drills to Session detail as evidence; actors (installs, people, repo) and the not-captured note.
• Derivation: "redacted" and the finding come from the session's file_access.sensitive / scan_finding events, never from the category; the r/w/e counts on event-bearing sessions equal the events. Nothing hand-typed, nothing fabricated — the world already carries what this page needs.
• Not captured, stated on the page: before/after content ("diff-shaped outcomes") is a standing data ask (c77); secret dwell is a receipt, never a target (c67). Governance (redaction policy, the finding's lifecycle) lives in findings / control-center — linked from Session detail, not designed here.
• Open: the sample is the sensitive files plus a few ordinary rows — a real deployment lists thousands of source files, and the category-first rank plus the sensitive/secrets filters are the bet that keeps the page readable; whether "other" should hide by default is untested. A path-cluster view (by repo, by directory) is the natural second framing once the data is real.