Skip to content

prepare-pr rejects successfully delegated prep-file writes as zero_writes #5289

Open

Description

@Trecek

prepare-pr rejects successfully delegated prep-file writes as zero_writes

Fix target and integration order

Repository: TalonT-Org/AutoSkillit. Fix PR base: develop, baseline f66c21cc689cfe1d2431ea3c270cb69fecb1f2df or descendant (AutoSkillit 0.10.1280). The affected skill, contracts and evidence code match develop in tested feature head 28448805b7c9cfb6ab13fa2f8589ad1b4cc10e88. This is not an unmerged collector-only defect.

Merge the remediation into develop, then integrate into PR #5255 before fresh commissioning. Do not target the feature branch merely because its E2E run exposed the behavior.

Observed defect and scope

Three prepare-pr invocations explicitly assigned an owned writable general-purpose child to create the prep file using Write. Each child successfully created a distinct output under the skill's declared .autoskillit/temp/prepare-pr/ write directory, and the parent returned that path. Each invocation nevertheless exited naturally with success=false, subtype=zero_writes, zero parent write calls and filesystem writes detected.

The current delegated-write contract supports an exact target bound from a pre-existing invocation input. dry-walkthrough opts in through plan_path; prepare-pr generates a new output filename and declares no delegated-write input. Its real child output writes therefore do not satisfy its conditional write obligation. The skill requires delegated work and Write for the prep file, but has no explicit primary-session-only writer requirement. Make the permitted workflow and evidence policy agree; do not classify a proven allowed output write as no observed write.

This ticket concerns write-effect attribution. Other artifact-format, source-pin, invocation or workflow failures must remain enforceable; fixing it does not certify every prep artifact or guarantee the complete pipeline will pass.

Exact live reproduction without another model call

Run 39082347591, attempt 1, implementation scenario on MiniMax-M3 through Claude Code 2.1.280, tested head28448805b:

gh run download 39082347591 --repo TalonT-Org/AutoSkillit --name e2e-implementation-39082347591-1 --dir .autoskillit/temp/investigate/prepare-write-39082347591

Artifact transcript base:

out/transcripts/-workspace-autoskillit-runs-impl-20261018-004807-116140/

Use JSONL record numbers (one-based), not the original runner's /home/autoskillit/.claude/... paths. Canonical second attempt:

  1. Parent 8689b5b8-9a4c-48cf-b0db-3c1a146278e1.jsonl, record37, launches Agent/general-purpose and explicitly delegates the full prep workflow, including creation of the prep file with the required structure. It does not restrict this child to read-only work.
  2. Its owned sidecar 8689b5b8-9a4c-48cf-b0db-3c1a146278e1/subagents/agent-a74437a2bc57aa924.jsonl, record24, calls Write at:
    /workspace/autoskillit-runs/impl-20261018-004807-116140/.autoskillit/temp/prepare-pr/pr_prep_2026-10-18_005822.md.
    Record25 returns File created successfully at: that exact path. The content starts with # PR Prep and includes ## Metadata.
  3. Parent44–46 reads the same file back. The parent hands back its prep_path but makes no direct Write/Edit call.
  4. logs/sessions/8689b5b8-9a4c-48cf-b0db-3c1a146278e1/summary.json records false/zero_writes, exit0/natural_exit, write_call_count=0, file_changes_count=0, delegated_write_count=0, fs_writes_detected=true.
  5. Root transcript out/transcripts/-workspace-sandbox/fd37c73d-a4ca-4116-944d-e40778aba3c0.jsonl, records291–292 and297, retains this attempt's failure and false completion classification.

Two independent invocations in the same run reproduce the effect:

Parent / delegation Successful owned child Write Output / parent confirmation
92baed37-437f-4909-8c11-1f3da49a830f, parent40 agent-a79a4ebb80d50bd8f.jsonl22–23 pr_prep_2026-10-18_005719.md; parent47/49 reads it; root280/285 says zero_writes/false
ced544b4-5a71-4725-a2bd-4579e7b6004f, parent43 agent-a92aaf0329269c591.jsonl20–21 pr_prep_2026-10-18_005921.md; parent50–52 lists the created files; root326/331 says zero_writes/false

Each sidecar is under its corresponding parent session's subagents/ directory. The parent prompts explicitly request the prep Write and structured handback. These are successful fresh output writes, not an already-stamped/no-op rerun, a denied operation or filesystem noise.

Current source mechanism

Links pin develop baseline f66c21c:

  • prepare-pr workflow declares write_paths for the prep directory and delegated work. Step8 requires Write, not Bash heredocs. No primary-only writer clause was found.
  • Skill contract declares file-path output prep_path and conditional write behavior when that token is emitted (lines735–755), but no delegated-write input. The dry-walkthrough declaration at314 is different: an existing input target is available.
  • Target binding only binds from a declared delegated_write_input. Manifest validation requires that name to be a declared file-path input; simply naming the output prep_path would not be a valid fix.
  • Evidence admission requires a successful matching owned child write plus a changed bound target. Without that target it admits no delegated contribution. WriteEvidence intentionally keeps filesystem activity alone insufficient for implementation evidence.
  • Final zero-write adjudication demotes the conditional invocation when its emitted prep token means a write is expected but no admitted implementation evidence exists. Preserve that protection for genuine no-write outcomes.

Required behavior and meaningful regression

Align permitted prep-output delegation and conditional write adjudication. A proven successful output Write by the invocation's authorized owned child, matching the returned declared prep artifact within the skill's write scope, must not be reported as no write. Keep truthful parent-versus-child attribution.

Use the existing child identities, declared outputs/write scope and effect evidence. Do not introduce a generic rollup subsystem, make broad filesystem activity sufficient, count arbitrary unbound children, or simply relabel this skill read-only. Preserve the existing exact-input target rules, root-write positives and worktree temp-only exclusion. Do not infer arbitrary natural-language authorization; the reproduced children have explicit writable assignments and available Write capability.

Add a composition regression through parsing and final adjudication: valid prepare inputs, fresh output path, owned general-purpose child Write/success, parent readback/handback and no direct root writes. Include denied/unowned children, wrong or out-of-scope output paths, unchanged/pre-existing no-op output and filesystem noise. Keep other artifact/metadata validation failures distinct. Run all-files pre-commit and configured task test-local-gate, never direct pytest.

Related issues and limits

Closed #5285, fixed by PR #5288, covers a delegated edit to an input plan file. This new case writes a generated output path; do not reopen the successfully scoped plan-target fix without evidence of regression in that path. Closed #1253 and #1643 concern Bash write detection; these children used Write as instructed. Open #3910 is a no-op revalidation, not this fresh file creation.

Both current commissioning attempts separately fail missing canonical issue links because the root discarded a known issue number after input errors. The second additionally bypasses compose/audit/review with a direct PR-create command. Those are independently observed caller deviations; this ticket does not claim that correcting write evidence alone repairs them or makes either failed attempt acceptable.

Classification: bug, recipe:remediation. Keep #5255 unmerged until fresh complete implementation runs meet its acceptance conditions.

Activity

  1. added
    bugExisting behavior is broken
    recipe:remediationRoute: investigate/decompose before implementation
    on Oct 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugExisting behavior is brokenrecipe:remediationRoute: investigate/decompose before implementation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions