Correlate machine state with Chau7 agent runs (read, don't re-store)

[schiste]

Proposal

Let Aetower correlate machine state with agent work, by reading Chau7's
telemetry — without storing a second copy of it.

The distinction that matters

Chau7 already owns the work record: ~/.chau7/telemetry/runs.db holds 775
runs since 2025-06-27, with repo_path, cwd, provider, model,
started_at, ended_at, duration_ms, token counts and cost. Its proxy
store holds 314,090 API calls since 2026-03-08.

Aetower owns the machine record: pressure, memory, wakeups, energy, history,
with retention and stable diagnostics schemas.

Neither can answer the question that sits between them:

This run took 40 minutes and cost three times the usual. What was the machine
doing at the time?

That answer requires both timelines, and producing it is squarely Aetower's
stated purpose — explaining itself and the host.

What this is not

This is not a proposal to ingest and re-store Chau7's data.

A second copy of a fourteen-month history is two truths that drift, and a day
where nobody knows which one to believe. It would also force Aetower to model
a domain it does not own — repositories, agent runs, provider costs.

Read at query time, correlate, do not persist. If a cache is needed for
performance, it should be explicitly derived and disposable, never the
system of record.

Suggested shape

• A read-only adapter over Chau7's telemetry, resolving its path rather than
  hardcoding it, and degrading cleanly when Chau7 is absent — this must remain
  an optional integration, not a dependency.
• Time-window join: given a run's started_at/ended_at, return the machine
  metrics covering it — pressure, memory, thermal, wakeups.
• Surface it through the existing MCP tools rather than inventing a new
  vocabulary. aetower_explain_anomalies already carries the right intent;
  an agent run is a legitimate anomaly subject.
• Make the correlation explainable: which samples were used, at what
  resolution, and how confident the overlap is. A correlation presented
  without its evidence is a guess with a chart.

Caveat worth stating up front

Correlation is not causation, and this feature will be read as if it were.
The output should describe what co-occurred, not assert a cause — and should
say when the sampling window is too coarse to conclude anything.

Dependency

Cost-side conclusions are only as good as Chau7's cost data, which is
currently populated on 16 of 775 runs (Aeptus/chau7#89, #90). Duration and
machine-side correlation do not depend on that and can land first.