The first version of Cairn’s GitHub onboarding accepted one public repository. It was a small, testable path into repository metadata. It also optimized for the first implementation instead of the likely end state.
The next request was predictable: why connect one repository when GitHub can authorize the whole portfolio?
Routing makes each mile cheaper. A good primitive prevents unnecessary miles.
The prototype tax
The single-repository path proved pieces of authentication and storage, but it could not grow into the experience customers needed. The intake, copy, state model, and onboarding UI all had to be replaced rather than extended.
Cairn recorded that rework honestly. The lesson was not “never prototype.” It was more specific: when the platform-native end state is already understood and the narrow path will be discarded, build toward the durable boundary first.
The hardened path
The replacement uses GitHub’s native App installation flow. A user links their identity, chooses all repositories or an explicit subset in GitHub, and returns to Cairn. Cairn imports repository metadata in one governed write and sets one immutable portfolio-wide before point for the trial.
The permission boundary stayed narrow: repository metadata is read-only. Repository contents and source code are not authorized.
- Repositories imported
- 8
- Hardening checks
- 34 / 34
- Repository permission
- Metadata only
- Production state
- Healthy
Observed in Cairn’s live founder account after the production GitHub App installation. No time-saved or cost-saved figure is claimed because no defensible counterfactual was recorded.
The primitive: End-State First
Cairn now has a candidate primitive to validate across future work:
Before building a narrow integration, ask whether the likely next request will extend it—or replace it.
If replacement is likely, the durable platform path is known, and the permission boundary is understood, Cairn should recommend the end-state architecture before implementation begins. If uncertainty is genuinely high, a disposable experiment can still be the right move—but it should be labeled and bounded as one.
This is what repository memory is for. Not a polished history in which every decision looks inevitable. A useful record of what created rework, what verified the correction, and what the next task should know before spending another token.