Track upstream AgentHarness v2 and telemetry convergence

[spences10]

Summary

Track upstream Pi's native AgentHarness v2 and telemetry primitives so my-pi can converge deliberately instead of maintaining duplicate abstractions indefinitely.

Upstream development is active:

• AgentHarness v2 implementation plan: https://github.com/earendil-works/pi/blob/main/packages/agent/docs/harness-v2.md
• Native telemetry package: https://github.com/earendil-works/pi/tree/main/packages/telemetry
• Pi v0.84.0 introduced the promoted harness scaffold, durable session APIs, typed telemetry contracts, and reference adapter: https://github.com/earendil-works/pi/releases/tag/v0.84.0

The upstream plan still has major harness execution/integration milestones and runtime telemetry instrumentation outstanding. my-pi should monitor those maturity gates before replacing @spences10/pi-harness, Factory's narrow reviewed-execution path, @spences10/pi-telemetry, or @spences10/pi-observability internals.

Scope

Evaluate each upstream release that materially advances AgentHarness or telemetry and decide whether my-pi should:

• keep its current implementation;
• wrap the upstream primitive;
• migrate incrementally;
• remove duplicated code.

Decision gates

Do not begin a migration until:

• upstream AgentHarness can complete, recover, and observe representative tool-using runs without unfinished-operation errors;
• JSONL/session compatibility and process-loss recovery are documented and tested;
• runtime telemetry instrumentation is wired beyond contracts and the reference adapter;
• upstream extension/SDK surfaces needed by my-pi are released rather than main-only;
• migration preserves my-pi's policy enforcement, deterministic validation, independent review, local SQLite evidence, and operator UX.

Acceptance criteria

• Record the first upstream release satisfying the decision gates.
• Map upstream AgentHarness capabilities against @spences10/pi-harness, @spences10/pi-factory, and Team Mode boundaries.
• Map upstream telemetry schemas/adapters against @spences10/pi-telemetry and @spences10/pi-observability.
• Run representative compatibility spikes without changing default behavior.
• Document keep/wrap/migrate/remove decisions for each overlapping package.
• Create focused implementation issues only for approved migrations.

Related my-pi work

• Epic: replace Factory v1 with evidence-proven reviewed execution #406
• Dogfood reviewed execution on ten representative repository tasks #413
• Evaluate a first-party subagent capability for my-pi #358
• Define a runtime-enforced child-agent policy envelope #359
• Epic: reconcile my-pi packages with upstream Pi SDK changes #287 (closed predecessor SDK reconciliation epic)

[spences10]

Tracking update — 2026-08-20

Reviewed upstream Pi through v0.84.2. my-pi already pins 0.84.2. AgentHarness v2 now has durable session/operation APIs, recovery queries, tools, and typed telemetry schemas, but the upstream changelog still describes it as a compile-complete scaffold whose unfinished operation paths reject with HarnessNotImplemented. The telemetry package remains contracts, schema utilities, no-op/in-memory adapters, and conformance tests; it does not replace my-pi SQLite persistence, queries, or operator UI.

Decision: keep @spences10/pi-harness, @spences10/pi-telemetry, and @spences10/pi-observability unchanged. Recheck after a release completes representative AgentHarness execution/recovery paths and wires runtime telemetry beyond contracts/reference adapters. No focused migration issue is warranted yet.