sensor-processes: build event batching (aggregate start+exit into build-complete)

[aaronsb]

sensor-processes currently fires discrete events for every cargo/rustc/gcc start and exit. In a real build, you get:

• cargo started
• rustc started (child of cargo)
• rustc exited
• cargo exited

Four notifications for what's conceptually one event: a build happened. The user (and the agent reading notifications) would rather see:

• cargo build completed (pass) or cargo build failed

Why it's not trivial

Build tools spawn nested processes. Distinguishing "the build that just started" from "another cargo process" requires some kind of session tracking. Options:

1. Root process tracking. Watch for top-level cargo/make/gcc invocations; consider them done when the root PID exits. Needs PID ancestry.
2. Watch exit codes. Requires process accounting (waitid, wait4) or parsing /proc state.
3. Marker file polling. Users configure a build-status file path; sensor watches for writes.
4. Shell integration. Hook into the shell's command execution events.

Option 1 is probably right for the common case — watch root cargo/npm/make processes, consider the lifecycle bounded by their exit. Option 2 layers on top for exit-code awareness (see #7).

Needs an ADR

This isn't just a refactor — it changes the event model for this sensor from "process lifecycle" to "build lifecycle." Design decisions worth an ADR:

• Does sensor-processes become sensor-builds, or does it grow a second mode?
• What defines a "build" — just the whitelist from existing sensor, or configurable?
• How does aggregation interact with the per-sensor engagement state?
• Is exit-code tracking (Attend CI workflow, signal handler ways, build affordances #7) a separate issue or bundled?

Documentation reference

Called out explicitly in docs/attend-and-monitor/sensors.md under "What it doesn't do" for sensor-processes:

Also doesn't batch multiple events from the same build tool. If cargo starts, then rustc starts as a child, then rustc exits, then cargo exits, that's four events. Smoothing build lifecycles into "build started → build finished" aggregate events is a known todo.

And in issue #2 as a remaining item from the ADR-113/114 work.

Related

• Attend CI workflow, signal handler ways, build affordances #7 — process sensor exit-code awareness (pairs with this)
• attend: remaining work from ADR-113/114 implementation #2 — the larger "remaining attend work" tracker