Let an attempt change the file it created

A write step's kind is resolved once, when the plan is built, from whether the
file is on disk, and that stops being true the moment the step's own first call
lands. The two write tools then contradicted each other: apply-edit refuses a
second wholesale rewrite and tells the run to send a patch instead, on a step
whose only permitted tool was apply-edit. There was no call the run could make
that would change the file. Ladder rung 9 lost an attempt to it -- the fix for
its one failing test written at 41.9s and refused, rewritten at 50.8s and
refused again, the attempt ending on tests that did not pass.

A creating step now declares both write tools and the tools decide: apply-edit
refuses a rewrite it has already accepted once, and apply-patch has nothing to
match against in a file that is not there. A patch step is not widened, because
there the file exists from the start and a wholesale rewrite is the churn the
patch tool was added to stop.

Separately, the no-op write detection, the staleness flag and the write counter
all asked "== apply-edit", written when that was the only write tool. From the
second attempt onward, when every run switches to patching, none of them saw a
write -- so a suite answered from the last run told a run "the write did not
land" while four patches had applied cleanly and undone each other. It now says
which of those two things happened.

Change-Log: CL-20260803-148
Dev-Log: DL-20260803-158

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: monstercameron

CHANGELOG

@@ -50,9 +50,74 @@ Dev-Log:
 
 Entries
 -------
-Change-ID: CL-20260803-147
+Change-ID: CL-20260803-149
+Commit: pending
+Date: 2026-08-03
+Type: Fix -- a patch could not say which of several identical places it meant,
+  and trailing text became part of the hunk
+Request-or-TODO: Ladder rung 9
+Outcome: A patch names the scope a change is inside in one of two ways: a
+  heading on the "@@" line, or a hunk of nothing but context immediately before
+  the change. Both were discarded -- the heading as envelope, the context block
+  as a hunk that changes nothing -- so a hunk whose context was a closing brace
+  and its indent was searched for across the whole file and matched once per
+  function. Rung 9 sent the same six-line patch six times in a row, told each
+  time to add more context, with the context it needed sitting in the hunk above
+  it. Both forms now travel as a hunk's Anchor: it is never applied and never
+  required to match, and its only effect is to narrow where the hunk is looked
+  for, so a stale scope name costs nothing. Separately, the parser accepts an
+  unprefixed line as context written without its leading space, which is right
+  inside a hunk and wrong after "*** End Patch": a run that finished its patch
+  and wrote a stray "EOF" had that EOF folded into the last hunk, which then
+  asked the file to contain a line no file contains.
+Affected-behavior: apply-patch. Ambiguity refusals fall; a patch followed by
+  trailing text applies.
+Compatibility-or-migration: None. No schema change.
+Verification: Rung 9 passes in 502s after six failing passes. Its patch failures
+  by kind: "does not match anything" fell to 6 of 109 after the end-marker fix,
+  from dominant before it; "matches N places" was 103 of 109 before the anchor
+  fix. Six new tests cover both anchor forms, the line-range control that must
+  not become an anchor, an anchor that resolves to nothing, trailing text after
+  the end marker, and a second envelope whose hunks must not be dropped.
+Dev-Log: DL-20260803-159
+
+Change-ID: CL-20260803-148
 Commit: pending
 Date: 2026-08-03
+Type: Fix -- a step could not use the tool its own first call made necessary,
+  and the suite told a run its writes had not landed when they had
+Request-or-TODO: Ladder rung 9
+Outcome: A write step's kind is resolved once, when the plan is built, from
+  whether the file is on disk. That stops being true the moment the step's first
+  call lands. The two write tools then contradicted each other: apply-edit
+  refuses a second wholesale rewrite and tells the run to send a patch instead,
+  on a step whose only permitted tool was apply-edit. There was no call the run
+  could make that would change the file. Rung 9 lost an attempt to it: the fix
+  for its one failing test was written at 41.9s, refused, rewritten at 50.8s,
+  refused again, and the attempt ended reporting that its tests did not pass. A
+  creating step now declares both write tools and the tools themselves decide --
+  apply-edit refuses a rewrite it has already accepted once, and apply-patch has
+  nothing to match against in a file that is not there. A patch step is not
+  widened, because there the file exists from the start. Separately, the no-op
+  write detection, the staleness flag and the write counter all asked
+  "== apply-edit", written when that was the only write tool, so from the second
+  attempt onward -- when every run switches to patching -- none of them saw a
+  write. A suite answered from the last run therefore told a run "the write did
+  not land" while four patches had applied cleanly and undone each other; it now
+  says which of those two things happened.
+Affected-behavior: A run can revise the file it just created. A suite answered
+  from cache names the real reason it is unchanged.
+Compatibility-or-migration: None. An edit step's plan now declares two
+  completion tools; the loop's contract accepts that pair and no other.
+Verification: Rung 9 reached its integration tests passing for the first time in
+  five passes, and reached path-coverage. New tests cover the pair, the
+  patch-step control, the loop's acceptance of the pair, both notes, and the
+  write-tool set.
+Dev-Log: DL-20260803-158
+
+Change-ID: CL-20260803-147
+Commit: 4237a5d
+Date: 2026-08-03
 Type: Chore -- remove code nothing calls, and satisfy the atom lint the commit
   hook enforces
 Request-or-TODO: Unblocking the commit of CL-20260803-140 through -146
@@ -78,7 +143,7 @@ Dev-Log: None: this is cleanup carried out to land the entries above, and it is
   nothing.
 
 Change-ID: CL-20260803-146
-Commit: pending
+Commit: 5577f21
 Date: 2026-08-03
 Type: Checkpoint -- unrelated in-flight work swept in at the user's request
 Request-or-TODO: User asked for everything in the working tree to be committed
@@ -101,7 +166,7 @@ Dev-Log: None. This work has no development-log entry because this session did
   not do it.
 
 Change-ID: CL-20260803-145
-Commit: pending
+Commit: 6a5aaa9
 Date: 2026-08-03
 Type: Fix -- the patch tool applied a two-file patch to whichever file was named
   last, and searched every hunk against the whole file
@@ -133,7 +198,7 @@ Verification: Rung 7's patch record across four passes: 4 of 25 landing, then 10
 Dev-Log: DL-20260803-155
 
 Change-ID: CL-20260803-144
-Commit: pending
+Commit: a965e8b
 Date: 2026-08-03
 Type: Fix -- four hard gates were measured only after the loop that was meant to
   inform them, and two of them said things that were not true
@@ -168,7 +233,7 @@ Verification: Rungs 4, 6 and 7 pass, each having failed on the gate the change
 Dev-Log: DL-20260803-153, DL-20260803-154, DL-20260803-155
 
 Change-ID: CL-20260803-143
-Commit: pending
+Commit: 658a746
 Date: 2026-08-03
 Type: Fix -- the attempt budget and the stall tracker disagreed with themselves
 Request-or-TODO: Ladder rungs 5 and 9
@@ -195,7 +260,7 @@ Verification: Rung 5 passes. New tests in
 Dev-Log: DL-20260803-155
 
 Change-ID: CL-20260803-142
-Commit: pending
+Commit: ae366b1
 Date: 2026-08-03
 Type: Fix -- the loop spent whole attempts on mistakes a round could correct
 Request-or-TODO: Ladder rungs 1, 4, 5 and 9
@@ -222,7 +287,7 @@ Verification: Rungs 1, 5, 6, 7 and 8 pass. New tests in internal/agent cover eac
 Dev-Log: DL-20260803-150, DL-20260803-152, DL-20260803-155
 
 Change-ID: CL-20260803-141
-Commit: pending
+Commit: 1fb3d24
 Date: 2026-08-03
 Type: Fix -- the prompt described the run's own files inaccurately
 Request-or-TODO: Ladder rungs 1, 4, 5 and 6
@@ -250,7 +315,7 @@ Verification: Rungs 1 through 8 pass. The patch failure rate for a patch written
 Dev-Log: DL-20260803-151, DL-20260803-152, DL-20260803-153
 
 Change-ID: CL-20260803-140
-Commit: pending
+Commit: 004d2f7
 Date: 2026-08-03
 Type: Fix -- gates that contradicted each other, and a time report that could not
   be read

DEVLOG

@@ -25,6 +25,74 @@ Next-safe-step:
 
 Entries
 -------
+Dev-Log: DL-20260803-159
+Date: 2026-08-03
+Status: Committed as CL-20260803-149
+Change-ID: CL-20260803-149
+Request-or-TODO: Ladder rung 9
+Goal: Stop the patch tool refusing patches that said exactly where they went
+Assumptions: That a hunk of pure context immediately before a change is naming
+  the scope of that change, rather than being decorative. Checked against the
+  patches rung 9 actually sent: every one of them used the two-marker form with
+  the enclosing test function in the first block
+Decisions: An anchor never causes a failure. It narrows the search and nothing
+  else, so an anchor naming something the file no longer has -- a renamed
+  function, a stale copy -- leaves the hunk exactly as findable as it was
+  without one. Refusing on a bad anchor would have converted a class of
+  successful patches into a new class of failures, which is the opposite of the
+  point. A context block AFTER the last change still anchors nothing and is
+  still dropped, which is the case the earlier forgiveness was added for
+Files-or-schemas: internal/executor/patch_tool.go -- PatchHunk gains Anchor;
+  ParsePatch folds context-only hunks and "@@" headings into it; ApplyPatch
+  searches from just past a resolved anchor. No storage schema touched
+Validation: internal/executor passes. Six new tests, each run against the
+  previous implementation first: the context-block anchor records
+  "hunk 2 matches 2 places", the heading anchor records "does not match
+  anything", the trailing-EOF case records a hunk whose Before ends in EOF.
+  Rung 9 passes end to end in 502s
+Failures-or-discarded-approaches: First attempt treated the anchor as an
+  ordinary context-only hunk inside ApplyPatch, which never ran: ParsePatch had
+  already dropped every context-only hunk before ApplyPatch saw the request.
+  Second attempt appended a "@@" heading to the hunk's own context, which made
+  the hunk unmatchable -- the heading and the hunk body are not contiguous in
+  the file. The anchor has to be a separate field for that reason
+Known-limitations: Ambiguity is still possible when neither form is used. The
+  message asking for more context is unchanged for that case
+Next-safe-step: Rung 10
+
+Dev-Log: DL-20260803-158
+Date: 2026-08-03
+Status: Committed as CL-20260803-148
+Change-ID: CL-20260803-148
+Request-or-TODO: Ladder rung 9
+Goal: Let an attempt change the file it created, and stop misreporting why a
+  suite result is unchanged
+Assumptions: None. Both defects are visible in the rung 9 pass 4 trace: the
+  refusal at 41.9s naming a tool the round did not offer, and the "unchanged"
+  answers at 66.9s and 76.1s after four patches had applied
+Decisions: Widened the plan rather than relaxing the refusal. Refusing a second
+  wholesale rewrite is right -- it is the churn the patch tool exists to stop --
+  and the defect was that the alternative it names was not callable. Only the
+  edit kind is widened; a patch step's file exists from the start, so nothing
+  about it changes during the attempt and admitting a rewrite there would
+  reopen the churn
+Files-or-schemas: internal/agent/loop.go -- planStepKindContract gains
+  alsoCompletedBy and a permits method; internal/coordinator/write_step_kind.go
+  -- writeToolsFor; agent_planning.go and agent_narration.go call it;
+  agent_narration.go -- isWriteTool, writesSinceLastTest, and a two-way
+  unchangedTestNote
+Validation: internal/agent passes. New coordinator tests, each run against the
+  previous implementation first: the pair test records "an edit step permits
+  [apply-edit], so the run has no way to revise the file its first call
+  created". Rung 9 reached passing integration tests for the first time
+Failures-or-discarded-approaches: Considered relaxing the rewrite refusal when
+  apply-patch is unavailable. Rejected: on attempt one every write step is an
+  edit step, so that is the common case, and it would have removed the churn
+  control entirely rather than fixing the contradiction
+Known-limitations: The step kind is still resolved once per attempt. Only the
+  tool set is now tolerant of the file moving underneath it
+Next-safe-step: DL-20260803-159
+
 Dev-Log: DL-20260803-157
 Date: 2026-08-03
 Status: Committed as CL-20260803-146

internal/agent/loop.go

@@ -1336,18 +1336,40 @@ func requestArgument(
 }
 
 type planStepKindContract struct {
-	completionTool     executor.ToolName
+	completionTool executor.ToolName
+	// alsoCompletedBy is the one other tool this kind may declare, or empty
+	// when the kind admits exactly one. It exists for the write kinds, where
+	// which tool is right depends on whether the file is there, and that
+	// changes during the attempt rather than between attempts.
+	alsoCompletedBy    executor.ToolName
 	materialEdit       bool
 	validationRequired bool
 }
 
+// permits reports whether a declared completion-tool set is the one this kind
+// allows.
+//
+// The primary tool is required and must come first, because it is the tool the
+// step is named for and the one a run reaches for by default. The alternate is
+// optional: a plan may declare it or not, and both are the same kind of step.
+func (contract planStepKindContract) permits(declared []executor.ToolName) bool {
+	if len(declared) == 0 || declared[0] != contract.completionTool {
+		return false
+	}
+	if len(declared) == 1 {
+		return true
+	}
+	return len(declared) == 2 &&
+		contract.alsoCompletedBy != "" &&
+		declared[1] == contract.alsoCompletedBy
+}
+
 func validatePlanStepContract(step PlanStep) error {
 	contract, ok := planStepContract(step.Kind)
 	if !ok {
 		return fmt.Errorf("%w: step kind is invalid", ErrPlanContract)
 	}
-	if len(step.CompletionTools) != 1 ||
-		step.CompletionTools[0] != contract.completionTool {
+	if !contract.permits(step.CompletionTools) {
 		return fmt.Errorf(
 			"%w: a %s step is completed by %s and this one declares %v",
 			ErrPlanContract, step.Kind, contract.completionTool,
@@ -1425,7 +1447,15 @@ func planStepContract(kind StepKind) (planStepKindContract, bool) {
 	case StepKindEdit:
 		return planStepKindContract{
 			completionTool: executor.ToolApplyEdit,
-			materialEdit:   true, validationRequired: true,
+			// A step is planned as an edit because the file it names does not
+			// exist yet, and it stops being true the moment the step's first
+			// call lands. The rest of the attempt is revising a file that is
+			// now there, which is what apply-patch is for, so an edit step
+			// carries both and the write tools themselves decide which is
+			// right: apply-edit refuses a second wholesale rewrite, and
+			// apply-patch cannot create a file it has no context for.
+			alsoCompletedBy: executor.ToolApplyPatch,
+			materialEdit:    true, validationRequired: true,
 		}, true
 	case StepKindPatch:
 		return planStepKindContract{