[Task] Plan a checkpointed EC04 regression-and-fix pilot
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 8/100
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:
- EC04 packet:
SHA-256e1af01bfacc850c3bd575534f4dff8d4318a7e95571c12e1dffff86c55877474. - Oracle/rubric and eight artifact bindings:
SHA-25607e9ac8d7e5f3f520d6a7aae32ec2363c5b32b2d6101ff97542c0e97ffdc716c. - Setup and ownership contract.
- Observation preflight.
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:
- A preparer creates a fresh disposable four-file Git fixture, following the
existing baseline-before-overlay recipe. Onlycapacity.py,
test_capacity.py,backlog.mdanduser-notes.mdare 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. - 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. - 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. - 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. - 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. - 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. - 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
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from mochan-tk/agentic-dev-kit-for-codex
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
mochan-tk/agentic-dev-kit-for-codex#48 · 5 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 1/100
mochan-tk/agentic-dev-kit-for-codex#56 · 8 comments ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 15/100
mochan-tk/agentic-dev-kit-for-codex#54 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
mochan-tk/agentic-dev-kit-for-codex#51 · 3 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
mochan-tk/agentic-dev-kit-for-codex#50 · 4 comments ·
Maintainers usually reply within 1 day
All issues in mochan-tk/agentic-dev-kit-for-codex
Similar issues
-
Bug: POWERTOOLS_IDEMPOTENCY_DISABLED set to an empty or non-boolean value crashes every invocationPossibly taken @lechakrawarthy claimed this today. Openbug good first issue help wanted idempotency
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
aws-powertools/powertools-lambda-python#8728 · 2 comments ·
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
emeraldleaf/okl#320 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
mnemosyne-oss/mnemosyne#1309 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
huggingface/diffusers#15163 ·
Maintainers usually reply within 1 day
-
integration: ring
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
home-assistant/core#189787 · 1 comment ·
Maintainers usually reply within 1 day