leak-guardlisted

<!-- leak-guard-version: 4 --> # Leak guard A repository governed by forge-kit is usually about to become public, and nothing in the ordinary workflow stops the developer's own machine arriving with it. This is the guard for that. The mechanism is boring, which is why it keeps working. Real names arrive as sample data, because the fastest way to write a realistic project list is to list the projects you have, and the result looks like sample data forever afterwards. Absolute paths arrive inside pasted output: a traceback, a `ps` line, a test failure. Each carries a working directory, and under a home directory that path is not neutral. The username identifies a person, and **the segments above the project are worse**, because a path can name an employer, a client, a filing scheme, or a category its owner considers private. The project name at the end is the only part anyone meant to publish. ## Two halves, split by whether the check needs a secret **A denylist of the private names cannot live in the repository it protects.** A public file enumerating the names you have been hiding tells a reader exactly what to search the history for. It converts a guard into an index. That single constraint forces the whole design. | | Public half | Private half | |---|---|---| | Asset | `check-public-leaks.sh` | `check-private-leaks.sh` | | Catches | path shapes, unlisted `~/` roots, addresses | private project and folder NAMES | | Needs a secret | no | yes, a list of the names | | Wh