Source governance
Keeping public and Pro source separate
The reasoning behind Gummy UI’s two-repository boundary and the practical rules for metadata, previews, registry payloads, releases, and credentials.
By Gummy UI · Published
Git history is part of publication
Deleting a paid file from a public working tree does not guarantee that the file has left Git history. Gummy UI therefore uses separate repositories: the public repository for MIT components, registry, website, documentation, and safe metadata; the private repository for paid editable source, templates, design source, releases, and internal QA.
The rule is stronger than placing a private-looking folder inside the public project. Paid source must never enter the public repository, even temporarily. Credentials, customer data, signing material, and protected download locations belong in neither source tree.
Define safe public outputs
The public site may describe catalogue names, categories, counts, purposes, and honest status. It may eventually receive reviewed source-free raster screenshots, but never compiled or minified Pro JavaScript, HTML, CSS, source maps, or design data. Minification does not make paid source public-safe, and those image outputs remain distinct from block TSX, template projects, design-library source, and protected archives.
The current Pro exporter writes boundary-safe metadata inside the private release workspace, and an explicit checked sync copies only that allowlisted contract into the local public surface. Deployment remains a separate founder-approved action. This two-step model prevents a generation command from silently publishing its output.
Keep status with the metadata
The private manifest currently marks all 158 blocks, six templates, and the 300-definition design kit as implemented. That means the documented local source and automated implementation contracts exist; it does not mean manual review, protected releases, entitlement delivery, deployment, or production verification has happened. Public metadata preserves those lower statuses so a catalogue count cannot be read as product availability.
Promotion requires evidence beyond file presence: responsive source, meaningful states, tests, previews, clean consumer checks, release archives, checksums, restore evidence, and entitlement delivery. No script should infer release-ready status from a directory count.
Verify both repositories and artifacts
Boundary checks should inspect current files, Git history, generated registry JSON, client and server bundles, source maps, public metadata, preview artifacts, and release archives. A public manifest path should be constrained to the public source root so an accidental parent-directory reference cannot copy private material.
Secret scanning and ignore rules are supporting controls, not permission to stage sensitive files. The public and private repositories were published only after boundary and secret scans, with paid source kept in the private repository. Deployment still needs a separate inventory of what is reachable from production URLs.