Reports

A report is a saved, scoped query with a run history. Start from a reviewed definition or a natural-language question, inspect the SQL and preview, then save the server-owned draft. A chain is the only thing that decides when it runs and where the result goes.

The personal digest is not a report. Do not pin it on the Reports page.

Build and inspect

Choose a reviewed definition below, or describe a custom population in natural language.
Review the generated SQL rather than treating it as hidden agent reasoning. Built-in SQL is versioned and reviewed by Warestack; it is not generated again on each run.
Preview rows.
Save the report. Saving commits the authenticated draft revision that produced the preview; the client does not submit SQL or rows as trusted input. Drafts are bound to their owner, space, scope, and revision, and expire after 24 hours.
Use Run now for a fresh result and run history. Warestack revalidates the stored SQL before execution.
Add a scheduled_report chain when the result should be delivered to Slack and/or email.

An empty preview is a valid result and can be saved. A built-in saved against an older definition version must be regenerated before it can run again; Warestack does not silently execute stale built-in SQL.

Optional AI analysis can help interpret a report, but the saved SQL, rows, timestamps, definition version, scope, and delivery history are the evidence.

Weekly space digest

The weekly operating picture — and a sampleable change population: the set an auditor would sample, not a handful of screenshots.

See Digests. Run now completes SQL; Slack announce is the Monday (or your calendar) chain step.

You can add or rewrite reports after you see the first runs. The chain is how they get to Slack or email.

Reviewed report definitions

Use the IDs from /catalog.json. They are API values for report_definition_id, without a report. prefix. Every definition is scoped through the current Warestack space. All except urgent_issues_without_pr can additionally use team or repository scope; that definition is space-wide by design.

Definition ID	Title	Current version
`production_changes`	What shipped to production?	2
`failed_ci_jobs`	Where is CI failing?	1
`changes_requested`	What needs review follow-up?	1
`review_bot_comments`	Unresolved review-bot feedback	1
`urgent_issues_without_pr`	Urgent work without a pull request	1
`stale_pull_requests`	Stale pull requests	1
`rule_violations`	Rule violations by rule	1
`deployments_without_review_record`	Missing deployment-review evidence	2
`deployment_review_decisions`	Deployment approval evidence	2
`repository_protection`	Branch-protection evidence snapshot	2

For a first delivery, add one scheduled_report chain (often Monday local time) to the named Slack channel and/or email recipients. Email recipients do not need a GitHub identity or space membership. Through MCP, schedule_report creates those addresses if they are missing. Choose the definition that matches the control population; rule_violations, deployment_review_decisions, and repository_protection are useful starting points for change-management evidence.

Briefs

A report brief is generated asynchronously from one exact report result snapshot. queued and generating mean work is still in progress; they are not failures. Repeated equivalent requests are coalesced, and regenerating creates version lineage instead of overwriting the earlier brief. A generated brief remains bound to the report rows and evidence it analyzed. A failed generation is persisted as failed so it can be inspected and retried.

Do not

Pin personal_digest on this page.
Treat Run now as Slack announce.

CSV

Scheduled-report notify can attach a summary link, CSV, or both. The Slack card is provenance + title + run time + rows + Open report — not an inline row dump.

See Automation activity for the delivery execution and Events for the underlying change timeline.