The Scope Boundary

"A boundary you can't compute is a boundary you don't have."

One Level Deep, cwk-Prefixed, Support Source Excluded

A hub that manages 'the family' needs an exact, mechanical answer to 'who is in the family?' Firelink's is deliberately narrow: direct child projects of one projects directory whose names begin with cwk, enumerated exactly one level deep. The reserved cwkFamilyAppBirthTemplate support repository is explicitly excluded even though its name matches the prefix. Nested repositories, adjacent non-cwk folders, and 'ancestors' or 'adjacent repos' mentioned only in roster prose do not qualify.

This sounds almost too simple, and that's the point. A membership rule you can run in a loop is a rule that can't drift. The moment 'membership' depends on human judgment — 'well, that one kind of counts' — the census stops being reproducible and the hub starts lying about what it manages.

Prose Never Enrolls a Member

Firelink reads roster and network documents to decorate members with titles, one-liners, and lifecycle status. But those documents can also contain lineage notes, 'ancestors', and 'adjacent repos' sections written for humans. A critical rule: that prose never expands the managed set. A roster entry that sits outside the direct-project scope is reference material — not drift, not a card, not something to reconcile. The project root is the scope boundary; the documents decorate what's inside it and are powerless to enroll what's outside.

Birth Produces a Member; the Template Is Not One

Firelink Birth copies cwkFamilyAppBirthTemplate into a plan-scoped staging area, materializes the new app's identity and contracts, initializes and pushes its private Git repository, and then publishes the resulting shell as a new direct child of the projects directory. The template remains a support source and never appears as a family card. The new app enters the census because its published destination satisfies the membership rule — not because its source template or a document enrolled it.

This is the same instinct as a bounded context in domain design: draw a hard line around what you own, and refuse to let a mention across the line pull new things in. Firelink's line is a filesystem rule you can read in five seconds — which is exactly why it holds under a family that keeps growing.

Code

The eligibility rule is a loop, not a judgment call·python

def eligible_members(projects_dir):
    # ONE level only — a plain listdir, never os.walk()
    for entry in sorted(os.listdir(projects_dir)):
        path = projects_dir / entry
        if not path.is_dir():
            continue
        if not entry.startswith("cwk") or entry.startswith("cwk."):
            continue
        if entry == "cwkFamilyAppBirthTemplate":  # support source, not a member
            continue
        yield entry                                # a managed FamilyMember

# This rule cannot enroll a nested repo, an adjacent non-cwk folder,
# or an ancestor that appears only in roster prose.
# Birth copies cwkFamilyAppBirthTemplate into staging, materializes it,
# and publishes the new shell as a direct child under projects_dir.

Exercise

Take any system that 'manages a set of things' (repos, servers, accounts, devices). Write its membership rule as code you could actually run — no 'and also the important ones' clauses. Then find one place where a human note or a config comment could sneak an extra member in through the side door. That side door is where every 'why is this here?' bug is born.

Hint

If your membership rule contains the word 'usually' or needs a person to adjudicate edge cases, it's not a boundary yet — it's a suggestion. Push it until it's a loop.

One Level Deep, cwk-Prefixed, Support Source Excluded

Prose Never Enrolls a Member

Birth Produces a Member; the Template Is Not One

Code

External links

Exercise

Progress

Comments 0