Why should accepting a self-repaired element locator, or promoting a drafted case into the regression set, be recorded rather than automatic?

seniornice to knowfreq 26%

answer

Silent changes have no author
Both acts change the suite's claim
Approve a proposal, not a finished change
Record who, when, against which run
A default is a decision nobody made

basics

~20 s

Both acts change what the suite claims, and a silent default means nobody owns the claim. A recorded acceptance gives the change an author, a reason and a reversible history; a default gives it none of those.

solid answer

~50 s

Both are admissions, not housekeeping. Accepting a repair says this different element is still the thing the case was about; promoting a draft says this check now speaks for the product and may stop a release. Each shifts what the suite means, so each needs an author. Make the act explicit: the repair arrives as a proposal a person approves, with the old and new identifier both shown and the case's assertion re-read to confirm the claim is unchanged. Make it recorded: who accepted, when, and against which run — so a case that later proves worthless traces to a decision rather than to drift. Defaults invert this. A suite that silently absorbs repairs and admits drafts accumulates cases nobody chose, and when one turns out to be wrong there is no decision left to revisit.

Both are admissions, not housekeeping. Accepting a repair says *this different element is still the thing the case was about*; promoting a draft says *this check now speaks for the product and may stop a release*. Each shifts what the suite means, so each needs an author. Make the act explicit: the repair arrives as a proposal a person approves, with the old and new identifier both shown and the case's assertion re-read to confirm the claim is unchanged. Make it recorded: who accepted, when, and against which run — so a case that later proves worthless traces to a decision rather than to drift. Defaults invert this. A suite that silently absorbs repairs and admits drafts accumulates cases nobody chose, and when one turns out to be wrong there is no decision left to revisit.

code

yaml · 10 lines

yaml

locator_repair:
  case: checkout_applies_coupon
  step: activate_place_order
  addressed_before: "primary action in the order summary panel"
  addressed_now:    "primary action in the payment panel"
  proposed_by: repair_pass
  evidence_run: run-4821
  claim_protected: "a valid coupon reduces the goods subtotal"
  accepted_by: null      # unset: the suite keeps using the old address
  accepted_at: null

go deeper

for a junior

Know that a case entering the regression set, and an element address quietly rewritten, are both changes to what the suite promises — and changes like that normally carry a person's name.

for a middle

Explain the mechanics of making the act explicit: the repair arrives as a proposal showing the old and new address, the case's assertion is re-read, and the acceptance is stored with an author and a timestamp.

for a senior

Show the failure you have lived through: a suite absorbing repairs silently until a case was passing against the wrong control. Describe how you made acceptance reviewable without stalling the run that discovered the breakage.

for a principal

Own the rule that nothing enters or changes the suite without a named decision, and defend it against the argument that it slows delivery. Say which acts you would let default, and why those cannot change a claim.

Two acts, one principle

Accepting an automatically repaired element locator and promoting a drafted case into the regression set both look like housekeeping. They are not. Each changes what the suite claims.

A repair says: the element this case now addresses is still the thing the case was about. That is a judgement about identity, and it can be wrong. A control with the same role on a redesigned screen may be a different control, with different consequences, sitting in a different flow.
A promotion says: this check now speaks for the product, and its failure may stop a release. That is a judgement about authority — the case is being granted the power to say no.

However the repair was chosen, and however confident the tooling reports itself to be, the act of accepting it is a separate thing from the act of proposing it. Decisions need an author. A default has none.

What a default costs you later

Question you will eventually ask	A silent default answers	A recorded act answers
Who decided this case still tests the same behaviour?	nobody	a named person, at a known time
What did the case address before?	lost, unless buried in history	stored beside the acceptance
Why is this case allowed to block a release?	it appeared one day	someone claimed it
Can we revisit the decision?	there is no decision to revisit	yes, with the reason attached

The last row is the real cost. A silent default does not merely lose an audit trail; it removes the thing an audit trail would point at. When a case is later found to be worthless — passing against the wrong control, or asserting something nobody wanted — a recorded acceptance turns the investigation into a five-minute conversation with the person who remembers why. A default turns it into archaeology, and the usual outcome of archaeology is that the case is kept because nobody dares delete what they cannot explain.

Explicit does not have to mean blocking

The common objection is speed: if every repair needs a person, the run stalls. It does not, because discovery and decision belong at different times.

The run detects that the element a case addressed can no longer be found, reports the case as failed, and emits a proposed repair as data — not as an applied change.
The proposal is read away from the run, showing the old identifier, the new one, and the case's assertion. The question being answered is does this case still make the same claim, and that is answered by reading the assertion, not the identifier.
Acceptance is stored: author, time, the run that produced the evidence, and the before-and-after.
Only then does the suite address the new element.

Promotion works the same way. A drafted case can sit outside the regression set indefinitely at almost no cost. It becomes a member when a person claims it — and the claim, not a passing run, is what confers membership. Passing proves the case is runnable; it says nothing about whether anyone wanted it.

What the record has to carry

Who — a person, not a shared account. If the field can hold a machine identity, it eventually will.
When — so a cluster of forty acceptances in one afternoon is visible for what it is.
Against what evidence — the run, the failure, the before-and-after.
What it replaced — the old identifier, or the fact that no such case previously existed.
What claim it protects — one line, stored in the case, naming the behaviour it defends.

The last item is the one teams skip and the one that pays for the rest. A case with a stated claim can be challenged, refused or deleted on purpose. A case without one can only be re-run.

Where defaulting is legitimately fine

The rule is not that nothing may ever be automatic. Defaults are correct where the act cannot change the claim:

Formatting, renaming within a case, or moving it between files.
A repair inside a provisional, non-blocking tier whose failures stop nothing and whose cases nobody has claimed yet.
Re-capturing a canned data record whose values were never the subject of any assertion.

Draw the line at authority: if the act can change what a failure means or what a green run entitles you to believe, it needs a name attached. That single test decides every case you will meet, and it is short enough to say in an interview.

## Two acts, one principle Accepting an automatically repaired element locator and promoting a drafted case into the regression set both look like housekeeping. They are not. Each changes what the suite claims. - A **repair** says: *the element this case now addresses is still the thing the case was about.* That is a judgement about identity, and it can be wrong. A control with the same role on a redesigned screen may be a different control, with different consequences, sitting in a different flow. - A **promotion** says: *this check now speaks for the product, and its failure may stop a release.* That is a judgement about authority — the case is being granted the power to say no. However the repair was chosen, and however confident the tooling reports itself to be, the act of accepting it is a separate thing from the act of proposing it. Decisions need an author. A default has none. ## What a default costs you later | Question you will eventually ask | A silent default answers | A recorded act answers | |---|---|---| | Who decided this case still tests the same behaviour? | nobody | a named person, at a known time | | What did the case address before? | lost, unless buried in history | stored beside the acceptance | | Why is this case allowed to block a release? | it appeared one day | someone claimed it | | Can we revisit the decision? | there is no decision to revisit | yes, with the reason attached | The last row is the real cost. A silent default does not merely lose an audit trail; it removes the thing an audit trail would point at. When a case is later found to be worthless — passing against the wrong control, or asserting something nobody wanted — a recorded acceptance turns the investigation into a five-minute conversation with the person who remembers why. A default turns it into archaeology, and the usual outcome of archaeology is that the case is kept because nobody dares delete what they cannot explain. ## Explicit does not have to mean blocking The common objection is speed: if every repair needs a person, the run stalls. It does not, because discovery and decision belong at different times. 1. The run detects that the element a case addressed can no longer be found, reports the case as failed, and emits a **proposed** repair as data — not as an applied change. 2. The proposal is read away from the run, showing the old identifier, the new one, and the case's assertion. The question being answered is *does this case still make the same claim*, and that is answered by reading the assertion, not the identifier. 3. Acceptance is stored: author, time, the run that produced the evidence, and the before-and-after. 4. Only then does the suite address the new element. Promotion works the same way. A drafted case can sit outside the regression set indefinitely at almost no cost. It becomes a member when a person claims it — and the claim, not a passing run, is what confers membership. Passing proves the case is runnable; it says nothing about whether anyone wanted it. ## What the record has to carry - **Who** — a person, not a shared account. If the field can hold a machine identity, it eventually will. - **When** — so a cluster of forty acceptances in one afternoon is visible for what it is. - **Against what evidence** — the run, the failure, the before-and-after. - **What it replaced** — the old identifier, or the fact that no such case previously existed. - **What claim it protects** — one line, stored in the case, naming the behaviour it defends. The last item is the one teams skip and the one that pays for the rest. A case with a stated claim can be challenged, refused or deleted on purpose. A case without one can only be re-run. ## Where defaulting is legitimately fine The rule is not that nothing may ever be automatic. Defaults are correct where the act cannot change the claim: - Formatting, renaming within a case, or moving it between files. - A repair inside a provisional, non-blocking tier whose failures stop nothing and whose cases nobody has claimed yet. - Re-capturing a canned data record whose values were never the subject of any assertion. Draw the line at authority: if the act can change what a failure means or what a green run entitles you to believe, it needs a name attached. That single test decides every case you will meet, and it is short enough to say in an interview.

Your suite already logs every repair it applies. Is that enough?
A log records that something happened; acceptance records that someone decided. If the repair is already in effect by the time the entry appears, the entry is a notification, not an approval, and nothing was ever refusable. The test is whether a person could have said no before the change took effect, and whether the record names the person who did not.
Does requiring a recorded acceptance mean the run that found the breakage has to stall?
No, and it should not. The run reports the case as failed and emits a proposed repair as data; the decision happens afterwards, where it can be read properly. Blocking the run only pressures people into accepting quickly, which is the failure you were avoiding. Separate discovery from decision and you get both a fast run and a real approval.
A drafted case has sat unpromoted for three weeks. What does that tell you?
Either nobody can state the claim it protects, or nobody needs it — and both are answers. An unpromoted draft costs almost nothing while it waits, so read the backlog as a signal about what is being drafted rather than a queue to clear. If most drafts never earn a claim, the drafting is aimed at the wrong behaviours and the fix is upstream.

A parcel left on the doorstep and a parcel signed for both arrive. Only one of them tells you who agreed to take it.

saying these in an interview costs you the question

Lets repairs apply silently and reads the log afterwards
Treats a promoted draft as free because it passes
Cannot name who admitted a case into the suite
Confuses a notification after the fact with an approval
Assumes a repaired locator still tests the same behaviour

Why should accepting a self-repaired element locator, or promoting a drafted case into the regression set, be recorded rather than automatic?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two acts, one principle

What a default costs you later

Explicit does not have to mean blocking

What the record has to carry

Where defaulting is legitimately fine

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

Two acts, one principle

What a default costs you later

Explicit does not have to mean blocking

What the record has to carry

Where defaulting is legitimately fine

answer

go deeper