query_archive - ResumeContext

For anything that is arithmetic over the archive: counts, dates, people, machines, sessions, access. Who did what, how much, when, on which machine, the busiest day, per-person breakdowns. Your agent writes a read-only SELECT against project-scoped views:

View	Contains
`turns`	One row per recorded turn, with author, machine, day. `role` is `user` (typed by a person), `assistant`, `tool` (tool output) or `system` (injected by the coding agent itself)
`sessions`	One row per session: author, machine, span, size, and its first and last requests plus a sample of requests across it
`people`	Contributors as seen from recorded history
`members`	Who has access
`requests`	Every message a person typed, verbatim, without tool output
`project`	Project metadata

Why it is safe

The query runs on a connection whose database user owns nothing and can read nothing outside those views. It is not a filter on the SQL text. The agent could write anything and still reach only this project’s rows. The transaction is read-only, with hard row and time limits.

This replaced four hand-written tools (session lists, people lists, per-person breakdowns, project overview). Each existed because someone asked one question shape, and every new shape needed new code. A query surface answers the ones nobody thought of.

What a session was about

There are no generated summaries. To learn what a session covered, your agent reads what people asked for in it: sessions.request_timeline samples the typed requests from start to end, and the requests view has all of them. Both are verbatim, so nothing is paraphrased on the way.