22 Revise the plan without losing the goal

Implementation is an encounter with facts the plan could not fully contain. The resource has an auxiliary file nobody mentioned. A filesystem operation behaves differently under the supported deployment. A consumer needs metadata before it can open otherwise valid bytes. Finding one of these conditions is not itself a planning failure. The failure is to conceal the discovery, or to treat every discovery as permission to redefine the outcome.

The plan should be revisable because the goal matters. Its current form is a means of preserving decisions while work proceeds. Once an assumption becomes false, faithful execution can become a way of building the wrong thing more efficiently.

Classify the new fact before changing the work

Suppose the acquisition adapter now obtains both the main resource and an auxiliary file. The existing progress calculation uses the known size of the main resource as its total, while received bytes include both files. There are several possible questions here, and they should not be bundled into one vague request to “fix progress.”

The known total may be a false measurement assumption. The meaning of completion may be an inadequate contract. The presentation of unknown progress may be an unresolved product choice. A proposal to substitute a different resource is a change of scope. Each belongs to a different decision, even if one test first exposes all of them.

For our illustrative application, assume the main requirement remains: a valid selected replacement becomes usable, while the old version survives a preparation failure before publication. Discovering an auxiliary file does not automatically change that goal. It changes what acquisition must include and what can truthfully be reported during preparation.

A revision record could say:

Observation: The selected resource includes a required auxiliary file whose size is unavailable before transfer.

Invalidated assumption: The known main-file size represents total acquisition size.

Preserved decisions: Selection identity remains fixed. Publication waits for all required checking. The active version survives failure before publication. An uncertain publication result requires reconciliation, not an assumed rollback.

Changed contract: Total size and estimated remaining time may be unknown. Availability continues to depend on publication, independent of any displayed fraction.

Affected work: Acquisition accounting, status serialization, interface presentation, and tests that assume a known denominator.

Decision needed: Select how the interface communicates ongoing work when the total is unknown. The measurement must remain unknown regardless of the presentation choice.

This record makes it possible to keep valid implementation. It also prevents a convenient percentage from becoming permission to invent a total.

Propagate consequences, not just text

Updating the plan is the beginning of a revision. Each affected worker needs to know which assumption changed and whether its current proposal remains valid. Tests may need a new fixture. An API example may need to represent absence. A previously reviewed diff may now require another look at the changed contract.

The integration owner should classify work rather than resetting everything. An adapter that already carries an optional total may remain usable. A presentation that divides by the total without checking absence does not. A publication test can remain valid if it never depended on progress arithmetic. This selective approach reduces rework without pretending the change has no consequences.

Keep the history of the previous decision intelligible. A future maintainer should be able to tell that a number was removed because its evidence was inadequate, not because somebody forgot to calculate it. The current plan should contain the current rule; a short dated record can preserve why it changed. Two competing active versions create uncertainty rather than traceability.

Sometimes the rule is what needs repair

It is tempting to respond to every failure by adding a stricter gate. A gate can also be based on the wrong ownership model. Passeur's October 1 record describes a Muse task whose native work produced a commit but was classified as interrupted because ordinary SDK startup lacked a protected-launcher stop proof. The repair made successful SDK close the ordinary requirement and demanded additional proof only when that launcher owned it. Recorded focused checks passed, while broader failures remained unqualified. This was a correction to an evidence contract, not permission to assume shutdown. Operational report, adapter repair.

The important question is whether a requirement protects a real obligation at the correct owner. “More checks” does not answer it. A rule can reject valid work, obscure responsibility, or make the system impossible to operate without improving the outcome it was meant to protect.

Steve Yegge's September 2026 Wheelhouse account offers a larger, explicitly personal example: he describes accumulated constraints stopping progress and a substantial reduction in refusal sites. The account also discusses spending and task-sizing pressures. These are operator reports rather than controlled findings, but they challenge the assumption that adding orchestration rules is a one-way improvement. Seats and Sunsets.

Removing an unnecessary rule still requires understanding its purpose. Deleting a failing acceptance test solely to obtain a green run erases the question the test was asking. Revising a test because it encoded a disproved assumption can be correct, provided the intended outcome is checked by a better observation.

Decide when to involve the requester

An implementer can often correct an internal assumption within the granted scope. A change to the promised behavior, supported audience, cost, privacy, or release commitment belongs with the person authorized to decide it. The useful escalation explains the consequence and offers a bounded choice. It does not ask the requester to resolve an implementation detail that the developer already understands.

If the requester cannot decide immediately, preserve the working version and continue independent work. Do not use silence as acceptance of a broadened objective. Equally, do not freeze unrelated tasks whose inputs remain valid.

Rehearse an amendment

Take the plan from chapter 17 and add the unknown-size auxiliary file. Identify every assumption that changes, then mark each pending task as unaffected, needing adjustment, or blocked on a decision. Rewrite one acceptance example before changing implementation.

The exercise succeeds when another reader can explain both what changed and what still governs the work. They should also be able to identify who decides the unresolved presentation choice. A revised plan that merely matches the current code has not yet demonstrated that it preserves the goal.