design-pi-evaluation

Design Pi evaluation and FLIP execution plane

Metadata

Statusdone
Assignedagent-899
Agent identity603daf069cd2ae4a26357aa66e8c6124154b648711a0816ffd8b660ee3b23815
Created2026-07-26T10:21:54.585536086+00:00
Started2026-07-26T20:39:41.507512570+00:00
Completed2026-07-26T21:00:47.629166293+00:00
Tokens8065463 in / 33725 out

Description

Objective

Produce the implementation-ready design for reliable Pi-first evaluation and FLIP. Explain the recent failure chain using source/history evidence: eager satellites, evaluation of non-executed tasks, admission deferrals charged as failures, attempt/pipeline pinning, and evaluator work sharing worker/build capacity.

Design requirements

  • Read the relevant Pi documentation and examples completely, following their references, for JSON/RPC structured calls, no-tools operation, extensions, session/context handling, usage/error reporting, and supported read-only tool boundaries. Record the researched API contracts and links in the design; do not infer them from WG's current adapter alone.
  • Keep two deliberately distinct products:
    1. bounded evaluation (the default): a no-tools structured Pi one-shot over a content-addressed evidence bundle, used for routine acceptance checking.
    2. deep-readonly FLIP (selective only): an explicitly requested/high-risk latent-intent and counterfactual probe that may inspect the task graph, original intent/conversation, dependency context, artifacts/diff, validation logs, runtime traces, and effective system configuration through an observation-only allowlist. It must never mutate graph/source/config, launch arbitrary network calls, or author as the source agent.
  • Do not relabel a shallow summary grader as FLIP. Define what extra evidence, system comprehension, counterfactual questions, and cross-component analysis make deep-readonly FLIP genuine.
  • Specify lazy evaluation creation only after a real source attempt reaches candidate completion and policy selects evaluation. Tasks that were never attempted, never spawned, were admission-deferred, cancelled, skipped, or remain open must create no evaluation work. Consider whether hidden attempt records eventually replace graph satellites; choose the smallest safe first implementation.
  • Specify a dedicated agency queue/concurrency/admission class: no worktree, no build-heavy slot, no normal worker capacity, attempt-bound exact route, bounded timeout/token budget, idempotent exact-once verdict consumption.
  • Define advisory default vs selective hard gates, failure semantics, retry/backoff, content-safety framing, provenance, and operator visibility.
  • Preserve native Codex worker/chat execution unchanged. Define an executor-neutral evaluation interface: Pi is recommended/default, explicit Codex/Claude evaluation adapters remain possible/selectable, and no Pi failure may silently cross-fallback to another executor (or vice versa). Advisory Pi unavailability leaves the source terminal with visible evaluation evidence; a selected hard gate waits explicitly rather than reopening the source.

Produce docs/design-pi-evaluation-plane.md; no production code changes.

Validation

  • Every recent observed failure maps to a concrete invariant and named regression scenario.
  • Evidence-bundle and structured-verdict schemas include examples derived from researched Pi API contracts.
  • Default bounded evaluation and selective deep-readonly FLIP capability/security boundaries are explicit and non-overlapping.
  • Credential-free Fake-Pi fixtures cover success, malformed output, timeout, route drift, duplicate delivery, and unavailable-executor behavior; no fixture needs provider credentials.
  • The live validation plan includes the actual terminal/TUI human flow from source-task completion through visible verdict/FLIP evidence, not library-only calls.
  • Rollout starts disabled, runs advisory canaries, and structurally cannot hard-gate globally before recorded canary success.
  • Design contains exact file-level implementation seams/ownership, serialization order, migration strategy, and executor-neutral/no-silent-fallback tests.
  • Native Codex execution retention is an explicit non-regression criterion without expanding direct Codex/Claude task scope.

Depends on

Required by

Messages 2 messages (2 unread)

  1. #1design-simplified-authoritative2026-07-26T11:32:16.366525072+00:00delivered
    Ratified lifecycle design is ready at docs/design-simplified-task-lifecycle.md. Evaluation contract in §10: lazy EvaluationRecord/virtual satellites, evidence append-only and exact source-bound, advisory default for optional eval, required gate via AwaitingAcceptance, evaluator infra failure affects only eval record, and no evaluator rescue/reopen authority.
  2. #2design-pi-evaluation2026-07-26T20:40:02.009407288+00:00read
    Acknowledged lifecycle-design handoff — I will align the Pi evaluation plane with §10's lazy, append-only, exact source-attempt binding and no rescue/reopen authority.

Log