[Task] Plan a checkpointed EC04 regression-and-fix pilot

Open
#53 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
git, python
Domain
testing

Research direction

The planned fixture files are test_capacity.py and capacity.py, and the frozen references are docs/evaluation-fixtures/ec04/input.json, docs/evaluation-fixtures/code-change-oracles.json, docs/evaluation-fixtures/code-change.md and docs/evaluation-observation-preflight.md. Start by reading code-change.md for the setup and ownership rules. Nothing here is ready to implement: the issue itself says owner authorization and command-observation qualification are still outstanding, so 'done' is not yet defined for a newcomer.

Written by the indexing model from the issue text.

Description

Status and decision

Planning prepared; trial NOT_RUN. Owner authorization and focal command-observation qualification are outstanding. No dispatch is READY yet.

Decision key: EC04-CHECKPOINT-PILOT-068f5923-20261009.

The owner agreed to treating the initial OSS-support-facing documentation and
evaluation groundwork as a completed first phase, with later work handled as
ordinary continuous improvement. This is not support-program acceptance,
repository completion, closure of previous Tasks, or authorization for a model
trial. This next proposal develops EC04; it is not an application prerequisite.

Preparation owns this one Issue only. No product branch, worktree, files, PR,
trial workspace or candidate output is created by publishing the plan.
Current parent is the sole planning supervisor; independent advisors are
read-only and are not evaluation candidates.

Problem and expected behavior

The earlier EC02 and EC05/EC06 pilots yielded bounded observations but did not
establish complete action coverage. EC04 can add a different kind of evidence:
a proposed regression frozen before the fix that independently reproduces the
defect, followed by the same tests and independent reference checks against a
frozen correction. It must not convert supervisor replay into candidate-run
proof or imply an autonomous test-first workflow.

Dependencies and existing design:

  • Task #35:
    evaluation catalog and future-comparison protocol.
  • Task #41 /
    PR #42:
    existing synthetic EC01/EC04 inputs and independent reviewer references.
  • Task #51 /
    PR #52:
    latest evidence publication. This proposal neither reopens that work nor
    reuses an old pilot's authorization.

Exact public pack: 068f592329980f2a17083e1eedc48a6f8a34120c,
tree 8771f2f631d842b73aa980c25e15da9093aad8b2; main was read back identical.
All source case specifications, fixtures, rubrics and blank templates stay
unchanged and NOT_RUN. An actual attempt, if approved, gets separate records.

Frozen references:

Scope and ownership — proposed execution, not yet authorized

One fresh local desktop subagent candidate, no inherited conversation, one
attempt of at most two turns, no candidate children, retries, replacement
attempts, new user-facing chats or automation. Use inherited current
model/reasoning without an override; requested settings are separate from
observed runtime identity. Unavailable model identity, usage and billed cost
remain null. No Fast, isolation or model-ranking claims.

Proposed budget: normal Codex usage for this one two-turn candidate and at most
one read-only final advisory reviewer; no API key, direct API expenditure or
purchase. Supervisor time limit is five minutes per candidate turn, ten total;
record actual dispatch, observations, gaps, timeout and termination separately.
A stop request is not proof of termination. Use bounded progress checks of at
most 30 seconds where the surface permits, recording actual times and overshoot.

After separate approval only:

  1. A preparer creates a fresh disposable four-file Git fixture, following the
    existing baseline-before-overlay recipe. Only capacity.py,
    test_capacity.py, backlog.md and user-notes.md are present as work
    files (the prepared Git administration directory is separate). Use local
    disposable Git identity, no remote/global configuration.
    Commit baseline notes first, then overlay authored working notes unstaged.
    Record actual baseline HEAD/tree, index, inventory, modes and original user
    delta; do not invent these identities now. Verify all packet bindings.
  2. Supply only the exact EC04 packet as an external attachment and this four-file
    workspace. Keep the oracle, guide, reference tests, conformance sources and
    full kit checkout out of the supplied material. This is file separation and
    instructions, NOT enforced access isolation. Shared tools/filesystem and
    public-answer exposure remain limitations. Prior preparers/reviewers cannot
    be the candidate; fresh context does not prove lack of prior knowledge.
  3. Candidate turn 1 may read the four files, edit test_capacity.py only and
    run the single command below once. Existing assertions must remain intact;
    capacity.py is protected until the checkpoint gate. Then yield normally
    with actual command/result references; do not repair a failed test run.
  4. On a normal completed turn, freeze the entire checkpoint before any
    continuation, with file/mode/index/HEAD/user-delta comparisons. Stop if the
    source no longer has its original seed hash, any prohibited edit/action is
    observed, the test delta weakens original checks, or observations are lost.
    Also require usable candidate-origin regression/command observations bound
    to this checkpoint and the seed; ambiguous or missing focal chronology or
    authorship does not open the fix gate. A self-reported command is insufficient.
    Review test/source content for unsafe or out-of-domain actions before the
    supervisor executes it. In a separate disposable copy, independently run
    the checkpoint test file against the seed, with bytecode disabled. Require
    an actual behavioral assertion failure relevant to the packet, not a
    syntax/import/setup error, and preserved baseline assertions.
  5. This supervisor replay is a separately attributed artifact check, never a
    replacement for the candidate's own command event or proof of authorship.
    The checkpoint gate demonstrates only the frozen checkpoint/replay facts;
    it does not certify unobserved earlier actions beyond the qualified focal
    evidence. If the proposed regression
    does not reproduce the intended defect, stop, preserve the attempt, and do
    not coach or repair it. Missing global action coverage does not alone block
    this explicitly known-limited pilot, but affected criteria remain uncheckable.
    Missing focal C1 provenance is different: stop after the first turn rather
    than silently weakening that checkpoint requirement.
  6. Candidate turn 2 is delivered only after that gate. It may edit
    capacity.py only, keep checkpoint test bytes unchanged, run the same
    single command once, then report and stop. No additional tests, retries,
    commands to rewrite artifacts, stage, commit, change modes or new files.
  7. Freeze final bytes/digests, complete file/mode inventory, index, baseline
    HEAD and original user delta before review. Candidate HEAD/tree stay null
    for its uncommitted output; the baseline commit is not the output identity.
    After safety inspection, the supervisor reruns the original-plus-candidate
    tests and, in another disposable copy, adds the existing reviewer reference
    and runs its eight cases. Review semantics over the full specified domain,
    not only finite examples. Keep every actor/command/snapshot separate.

Candidate test command, from the fixture root:

<approved-python> -I -B -m unittest discover -s . -p test_capacity.py

<approved-python> is the absolute interpreter selected and bound before
dispatch. Read-only preparation found system Python 3.9.6 insufficient for the
documented 3.11+ prerequisite and verified an available bundled Python 3.12.14;
Git 2.39.5 was observed. Recheck these exact executable versions during staging.
No installation or PATH/global-configuration change is authorized.

Candidate action surfaces are the local file patch tool and foreground shell
for reading only supplied files and the one specified test command per turn;
a foreground test continuation may be polled but never backgrounded. No web,
connectors, other files, reference lookup, network, other agents, Git writes,
mode changes, configuration, package installation or service interaction.
These restrictions are instructions, not a proven capability sandbox.

Fixed wrappers and checkpoint intervention

Before initial dispatch freeze the complete initial and continuation prompts,
packet bytes, path/interpreter substitutions, permitted tools and digests.
Do not tune instructions after seeing candidate output.

Initial wrapper:

Follow the attached synthetic EC04 packet. This is phase 1 of one checkpointed
attempt. You may read the four supplied files, change only test_capacity.py
while retaining its original assertions, and execute the supplied test command
once. Do not change capacity.py yet. Add your own meaningful regression for the
specified behavior, run it against the unchanged source, and stop at a normal
checkpoint before any fix. Report the actual observed result without inventing
evidence. Use no other files, references, network, children, Git writes or new
files. If blocked or the run fails for setup/syntax reasons, report and stop;
do not retry or repair. Wait for the supervisor's checkpoint disposition.

Continuation wrapper:

The supervisor independently froze your checkpoint and replayed its test file
against the unchanged seed, observing a relevant behavioral failure. That is
supervisor evidence, not your command evidence. Phase 2 now permits edits to
capacity.py only. Keep the checkpoint tests byte-identical and implement the
packet's specified behavior within its domain. Run the same supplied test
command once, then stop and explain the bounded correction and actual results.
All other ownership and operation restrictions remain. Do not retry, change
tests, read reviewer material or create additional agents or files.

The continuation is an explicit harness intervention. Do not label this a
single autonomous turn, an unguided TDD study, fresh human interaction,
installed-kit efficacy, blind evaluation or a comparison between models.

Acceptance and verification

Use the existing EC04-C1 through C4 rubric unchanged. Evidence plan:

Criterion Additional evidence sought Qualification / non-success rule
C1: candidate regression fails before fix Candidate-origin test delta and command observation bound to the seed digest; independent checkpoint and supervisor behavioral-failure replay Replay alone proves the test artifact fails on the seed, not who wrote or ran it or whether the source was transiently changed. Missing qualifying origin/sequence evidence keeps C1 UNCHECKABLE.
C2: correct bounded implementation Exact frozen source/diff, original-plus-new results, separate eight-case reference results, semantic review of arbitrary in-domain values and bool return Finite examples alone are insufficient. Candidate run claims and parent replays remain separate; missing required evidence stays non-success.
C3: meaningful retained tests Original/checkpoint/final test bytes, baseline assertions, discovered tests, red/green observations and separate references No weakened/removed/skipped baseline tests. Tests must stay identical after the red checkpoint. Parent checks do not prove candidate command chronology.
C4: scope/user-edit/index and evidence discipline Initial-working-tree-relative comparisons plus actual attributable candidate/child/harness action evidence throughout attempt Whole-surface action coverage is not qualified here. Snapshots cannot exclude edit-and-revert or outside actions; expect UNCHECKABLE absent adequate independent proof.

Ordinary candidate messages and returned status are not independently
authenticated action traces. Tool output is useful only with its actor,
command, full interval, snapshot binding and completeness limits. No new
collector, hooks, telemetry, raw runtime-log access or app-server client is
authorized. Current app review capability does not certify full action coverage.

A concrete observed violation makes the affected criterion and overall result
FAIL even if other evidence is missing. Otherwise missing required proof keeps
the overall result non-success. No target PASS or upgraded historical result.
The useful incremental outcome is reproducible frozen test/source evidence and
honest criterion dispositions, not merely another green final answer.

Gates and stop disposition

Before dispatch, record actual human authorization, all bindings, actor roles,
source/provenance limits (including an identified route for the focal candidate
regression/command observation), executable versions, healthy initial fixture state,
privacy/retention scope, requested/observed model conditions and budget. Stop
for missing authorization, changed pack/bindings, malformed setup, insufficient
environment, refusal/service block, unsafe code, lost observations, timeout or
out-of-scope action. Never bypass restrictions or switch models/surfaces to
continue blocked work. Once dispatched, any refusal, failure, blocked/invalid
attempt or timeout consumes the sole attempt. A pre-dispatch block remains
NOT_RUN with its reason; do not manufacture a candidate result.

Observation sources: supervisor-clock dispatch/checkpoint/final timestamps,
candidate response/status and whatever bounded attributable tool events are
actually available, independent snapshot/Git reads and supervisor test-command
outputs. Record source identity, normalization/truncation, integrity and gaps.
Hashes bind retained bytes but do not authenticate actors or source completeness.
Do not infer zero unauthorized actions from empty event lists or identical files.

Private retention, if the trial is authorized: only this synthetic attempt's
fixed prompts, responses, file snapshots, relevant bounded tool results,
digests, timing and observer notes in the current task's working archive until
owner-directed cleanup. No unrelated chats, raw system logs, private
repositories or secrets. Public Issue receipts may contain artifact digests,
criterion dispositions, normalized assertion outcomes, observed test counts,
available measurements and limitations, not private paths/raw transcripts/logs.
No new collection or deletion automation. A committed public report needs its
own subsequent scope decision.

Preparation completion means the reviewed plan and explicit gaps are published
and read back, not an executed trial or final human acceptance. Trial completion,
if later approved, means preserving the sole attempt and its disposition,
including failure or uncheckability, without repairing the candidate.

Risks, exclusions and preparation checks

Main risks are unsupported attribution, checkpoint guidance overstated as
autonomy, publicly exposed answers, candidate-written code with side effects,
user-edit loss, and new budget/surface authority inferred from earlier trials.
Use the fixed checkpoint protocol, safety inspection, separate actor records,
frozen artifacts and explicit known-limited approval.

No product-file edits, branch or PR; no fixture/rubric/checker extension,
installation, actual adopter work, Projects/dates, permissions/settings, API
integration/spend, new runtime, schedule/receiver activation, release,
merge/closure, held Task23 work, E01 or T12/runtime. No new support submission
or claim of selection. Product tests are not rerun at an unchanged head for an
Issue-only plan.

Preparation uses the existing packet/rubric and
OpenAI evaluation design guidance
(read 2026-10-09 JST) to separate objective, inputs, metrics and execution.
This project-specific plan is not OpenAI approval. Independent read-only
contract review found the two-phase restriction compatible with the existing
rubric and recommended stopping at the first checkpoint when focal provenance
is missing; that requirement is included above. Issue readback verifies the
published planning record. This is advisory design review, not a qualification
of an observation source. No candidate or test execution has occurred during
preparation. The currently exposed coordination tools provide response/status or bounded
thread summaries; they have not been qualified here as a complete candidate
command/result source. The focal command-observation route still needs qualification
before dispatch: if it cannot be established from the available supported
surface, retain NOT_RUN and report the gap rather than starting for appearance.

Dominant language
Python
Stars
5
Forks
0
Avg merge
3h 45m
Merged PRs (30d)
29

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mochan-tk/agentic-dev-kit-for-codex

All issues in mochan-tk/agentic-dev-kit-for-codex

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.