raw_records has session record types the typed views don't surface (pr-link, non-hook attachments, and 9 others)

Context

I was chasing down why Claude Code sometimes shows a PR link for a session and sometimes doesn't. Turns out it writes a pr-link record straight into the session JSONL ({"type":"pr-link","sessionId":...,"prNumber":...,"prUrl":...,"prRepository":...,"timestamp":...}) whenever it recognizes a gh pr/glab mr/raw API call in a Bash command's output.

I went looking for it in cq and it's nowhere in messages, tool_calls, tool_results, or hook_events. Only raw_records has it. That sent me down a rabbit hole of what else falls through that same gap.

Survey

Grouping raw_records by $.type across my whole corpus (1127 files):

SELECT json_extract_string(json,'$.type') AS type, COUNT(*) AS n
FROM raw_records GROUP BY 1 ORDER BY n DESC;

Checking src/views.rs, only two of these get first-class treatment:

• user/assistant → messages (views.rs:109, 138)
• attachment rows where $.attachment.hookEvent is set → hook_events (views.rs:255, 273)

Everything else only exists in raw_records. That includes a chunk of attachment rows too: 15,751 of the 18,019 total have no hookEvent, so hook_events misses them entirely. Sampled a few and they're the per-turn system-reminder injections (deferred tool lists, agent-type lists, MCP server instructions) rather than hook output.

What I'd actually want views for

Not asking for all fourteen of these, most are internal bookkeeping I don't care about. Two seem genuinely worth first-class support:

• pr-link: dead simple, flat schema (sessionId, prNumber, prUrl, prRepository, timestamp). "Which sessions touched which PR" feels like a real query, and it's exactly what I wanted when I went looking.
• ai-title / agent-name: human-readable session labels. Could be useful in cq sessions alongside (or instead of) first_user_message.

The bigger ask

Even short of new views, it'd help to have cq schema (or the skill docs) call out that raw_records holds a bunch of record types the typed views don't cover, with a pointer to SELECT DISTINCT json_extract_string(json,'$.type') FROM raw_records. I assumed the typed views were the whole picture until I went looking for pr-link and came up empty.

Happy to send a PR for a pr_links view if that's wanted, wanted to flag the broader gap first in case there's already a plan here.

Start in src/views.rs, especially the existing user/assistant and attachment-to-hook_events handling, then inspect how cq schema and the skill docs describe raw_records. Use the documented DISTINCT json_extract_string query to verify uncovered record types. Done means an agreed first-class view such as pr_links, or documentation that clearly explains the raw_records gap and discovery query.