The One Exception

"A ban with a fuzzy exception is not a ban. A ban with one exception, cut to the exact shape of a single need, is a promise."

The Ban That Makes the Family Trust the Hub

Firelink never edits an existing sibling's source. Not to fix a typo, not to bump a config, not while it's 'already in there.' That ban is the reason every sibling can let Firelink observe and operate it without fear — the hub reads your Git state, plans a deploy, restarts your service, but it never reaches into your files. The credibility of the whole hub rests on that promise being absolute.

Why Birth Doesn't Break It

And yet Firelink can create a whole new repository. How is that not a violation? Because Birth creates a shell that did not previously exist. There's no established sibling to edit — the thing being written is brand new, owned by no one yet. Birth is the exception that proves the rule: it's allowed precisely because it isn't the thing the rule forbids. The ban is on editing what exists; Birth is creating what doesn't. Those are genuinely different acts, and the exception is cut exactly along that line.

The Exception Stops Hard

Crucially, the carve-out is narrow and it stops hard. Birth's authority to write a new shell does not extend to filling that shell with product intent, and it never, ever extends to touching an established sibling. Birth may create cwkNewThing and correctly name its architecture and version files — and then it's done. It cannot decide what the product is, and it cannot 'while I'm here' edit a neighbor. One hole, exactly the size and shape of one need, with no slippage past its edges.

This is why Birth feels safe to hand a hub: the authority it grants is 'make a new empty room,' not 'redecorate the house.' The one edit Firelink ever makes to an existing repo is the product-version card — a separate, single-field, audited flow — and even that touches exactly one value. Everything else that exists stays untouchable.

Code

One hole, cut to the exact shape of one need·python

def may_write(target) -> bool:
    # The ban: Firelink never edits an existing sibling's source.
    if target.is_existing_sibling:
        return False                     # no typo fix, no 'while I'm here'

    # The single carve-out: creating a brand-new shell that doesn't exist yet.
    if target.is_new_shell_being_born:
        return True

    return False

# Even inside Birth, the authority is bounded:
#   - may create the shell + name its architecture/version contract
#   - may NOT fill product intent (that's Dad + Pippa work)
#   - may NOT touch any established sibling
# (The lone later edit to an existing repo is the product-version card:
#  a separate, single-field, audited flow -- not Birth.)

Exercise

Find a strict rule in a system you know that has an exception ('read-only, except admins can...', 'immutable, except during migration...'). Ask whether the exception is cut to the exact shape of a real need, or whether it's broad enough to swallow the rule. Sketch a tighter version: name the one categorically-different act that's allowed, and the hard edge where it stops.

Hint

The dangerous exceptions are phrased as a role ('admins can edit') rather than an act ('creating a new record is allowed; editing existing ones is not'). Roles accumulate power; acts stay bounded. Cut the exception to the act, not the actor.

The Ban That Makes the Family Trust the Hub

Why Birth Doesn't Break It

The Exception Stops Hard

Code

External links

Exercise

Progress

Comments 0