Why Put the Promise in the Code?

A refactor changes a condition from “valid session” to “valid session and confirmed email.” It is one extra check, but it changes who may enter.

Current Promise	Refactor's Behavior
A valid session may enter before confirmation.	The same session is refused until confirmation.
Confirmation remains owed independently.	Entry has accidentally been made dependent on confirmation.

The error is not the number of lines. The code has made a policy decision that the workshop owner did not make.

The doctrine asks engineers to keep the governing contract readable and connected to permitted behavior. That lets a reviewer locate the decision being changed and lets Rust reject relationships that the contract does not allow.

It also protects freedom to change implementation. Replacing a network library should not require renegotiating entry policy. Replacing a policy should not be disguised as a harmless library cleanup.

Change	Engineering Question
Replace the identity client's HTTP library.	Does it preserve the same verified observations and failure meanings?
Require confirmed email before entry.	Who owns this changed promise, and where must it apply?

Engineering Depth

Compare the two implemented entry rules:

impl EntryRule for CookieValid {
    fn permits(_: bool) -> bool {
        true
    }
}
impl EntryRule for ConfirmedOnly {
    fn permits(confirmed: bool) -> bool {
        confirmed
    }
}

CookieValid ignores the confirmation Boolean. ConfirmedOnly uses it. These are two supported product choices, not a stronger and weaker implementation of the same choice.

// A different product selection:
type WorkshopEntry<P> = ConfirmedWorkshop<P>;

// A machine-level detail could instead change inside the provider P.
// That must preserve P's existing verification contract.

A named type earns its place when its selection affects the actual handler. A decorative name beside an unrelated if statement does not preserve the promise.

Your Reflection

An engineer says, “All existing tests still pass, so adding confirmation to the entry condition is safe.” What question has not been answered?

Worked Discussion

Whether the owner authorized that changed entry policy. Tests may not cover the earlier promise, or may have been changed alongside the implementation. Start with the promised behavior, identify its owner, then use the project's evidence to check the authorized realization.