The patch layer
A fork is only as trustworthy as its diff. Fluorite keeps that diff small, visible and re-earned every cycle.
Two directories, one rule
| Directory | Meaning |
|---|---|
| fluorite/patches/ | The live layer. Every patch here is applied onto each cycle's pristine tree during sync. |
| fluorite/pending/ | The review queue. New changes land here first and graduate to patches/ after review against the current base. |
The rule: nothing reaches a promoted artifact except through patches/, and nothing stays in patches/ that can't survive a fresh application onto the newest upstream stable tag. A patch that no longer applies cleanly is not force-merged — it stops the line and gets consciously rewritten or retired.
Inherited work
This is also where the family inheritance becomes concrete. Fluorite forks Cromite, which itself revived Bromite's hardening work — engine-level ad blocking, disabling platform tracking surfaces — so the patch layer starts from that stack and evolves from here. Changes inherited from the base are kept only while they keep applying cleanly and passing the gates; new ideas queue through this layer rather than hiding in tree drift.
Honest status: as a Cromite fork, Fluorite inherits uazo's patch stack as its starting point — then earns every further change one reviewed diff at a time through this queue. What ships today is documented by the contents of patches/ itself.
Lifecycle of a patch
- ProposeA change lands in
pending/as a standalone diff with a clear rationale. - ProveIt must apply cleanly to the pinned base and pass the build and test gates like any other part of the tree.
- PromoteAccepted patches move to
patches/and join the standard application set for every future cycle. - Re-earnEach new base re-applies everything. Upstream may obsolete a patch — then it's removed with a note, not patched around forever.