[braghettos]

Closes #23.

What happened

Nine Repo CRs began failing within 41 seconds of each other:

target commit <sha> not found on branch main while enableUpdate is false

That message describes what the check found, and reads as though each resource had been pinned to a commit that was never there. Nothing was pinned wrong. Their shared target repository was recreated at 12:24:15Z — its entire main history begins one second later — so the recorded commits were discarded along with the history that contained them.

Nine CRs, two distinct SHAs, one repository, one event. The old message sent the reader looking for nine separate mistakes.

The new one names the cause and both remedies. Offering only enableUpdate would push operators toward allowing overwrites they may not want; recreating the resource re-pins to the current history instead.

It is still an error — and that is the interesting part of this PR

My first attempt converted this into a quiet Ready=False with ResourceUpToDate: true. The reasoning looked sound: the branch immediately below already logs-and-continues for the analogous origin-commit case, so the two seemed inconsistent, and Update() already no-ops when enableUpdate is false.

The integration suite rejected it, correctly. TC12-DisableUpdateDetectsTargetDrift does exactly this scenario — deletes and recreates the target repository — and asserts Synced=False/ReconcileError. TC13-AutoHealAfterEnableUpdateFalse covers the heal once the flag is flipped. Together they pin a designed contract: enableUpdate: false surfaces an error until a human chooses.

That contract is right. A real decision is owed here, and reporting it until it is made is the correct behaviour. So this PR changes only the wording.

Worth recording that the test caught a wrong judgement rather than a typo — I had an argument for the change and the argument was wrong.

Not the same as #22, despite the shared function

Both failures are exits of one predicate in Observe (meta.GetExternalName(cr) == ""), which is why they looked related:

#22	the provider refuses on an ambiguity nothing will ever resolve — the resource is stranded with no path back. A deadlock, fixed in the runtime.
#23	a person has a genuine choice to make. Not a deadlock; reporting it is correct.

Same function, two exits, two different defects. Only one of them is a bug in the behaviour.

Detail worth keeping

The "target commit" substring is preserved. TC12 matches on it, and it is how this failure is found across a fleet — nine resources failing for one reason should be greppable as one string. There is a test asserting it stays.

Tests

• message names the cause, the identifiers, and both remedies
• the greppable prefix survives
• full CI-equivalent suite green: go test -race -tags=unit,integration -p 1 -timeout 25m ./... — 9 packages, 0 failures, including TC12 and TC13

🤖 Generated with Claude Code