Run Loop on a schedule

Create a weekly estimated-cost report for this project.

Periods:
- Use the automation's seven-day window as the current period.
- Compare it with the immediately preceding seven days.
- State both UTC date ranges in the report.

Cost by user:
- Query project logs separately for each period.
- Group by `span_attributes.created_by_user_id` and sum `metrics.estimated_cost`.
- Keep null creator IDs as `Unattributed`, and never guess a name.

Return only:
1. A Markdown table with columns `User`, `Past 7 days`, `Prior 7 days`, `Change`.
2. One sentence summarizing the total week-over-week change.
3. A short paragraph on which work drove the spend, based on the highest-cost
   traces in the window. Describe the tasks, not the people.

Review factuality in this project's logs for signs of degrading quality.

Compare:
- Use the automation's one-day window and the immediately preceding day.
- State both UTC date ranges. For each period, report the average of
  `scores.factuality` and the number of scored rows. Higher scores are better.
- Exclude missing scores from the average and report how many rows lack scores.
- If either period has no scores, report that the comparison is unavailable.

Investigate:
- If the average falls, inspect up to 10 low-scoring traces from the current
  period and up to 10 scored traces from the previous period.
- Check whether the tasks or traffic mix changed. Distinguish observed score
  changes from possible causes, and do not treat a small sample as proof.
- Use existing scores only. Do not run scorers or create scoring rules.

Return a comparison table, a short summary of the evidence and its limitations,
and up to three representative trace links with suggested follow-up checks.

Summarize recent errors for the production environment in this project.

Scope:
- Use the automation's one-day window and state the UTC date range.
- Select traces matching `metadata.environment = 'production'` and inspect
  their spans for recorded errors. If the field is unavailable, report that
  the scope cannot be applied instead of broadening the search.

Investigate:
- Group similar recorded errors and count distinct affected root traces in
  each group. Do not count repeated errors in one trace as separate incidents.
- Inspect up to three representative traces from each of the five largest
  groups. Check whether the operation recovered later in the trace.
- Distinguish recorded errors from confirmed failures visible to the end user.
  If the outcome is unclear, say so. Do not guess a root cause.

Return a table with each error group, its affected trace count, and a
representative trace link, followed by suggested follow-up checks.
If there are no recorded errors in scope, say so rather than inventing groups.

Analyze recent project traces to find recurring failures within the existing
"Primary failure mode" facet's topic classifications.

Use the facet and its topic classifications only to select candidates. They are
noisy, and are not evidence by themselves.

Workflow:
1. Use the automation window.
2. Collect a sample of 100-200 facet occurrences, spread across the available
   topic classifications rather than only the newest or largest cluster.
3. Cap the sample at two occurrences per root trace, and deduplicate repeated
   facet runs and copies of the same underlying conversation.
4. For each candidate, inspect the compact context around the occurrence: the
   user request, agent actions, tool results, and outcome.
5. Validate every proposed pattern against raw trace evidence. Reject any
   hypothesis explained by explicit user direction, a permission or environment
   block, or intentional fail-fast behavior.

Record a pattern only when it describes a specific recurring behavior, is
supported by at least three independent conversations, has a meaningful impact
and an actionable response, and includes short quotes and relevant span IDs.