A communityThe lasting work in a fork is keeping a known set of changes compatible with the upstream revisions you intend to use.
Purpose & upstream issue → Named upstream revision → Matched engine artifacts → Repeat regression checks.
Nest’s source separates assembling a fork, building engine variants, publishing the repository and running framework tests. Reading a workflow explains its intended job; it does not prove that its latest run succeeded.
Keep an explicit patch inventory
For each change, record the upstream issue, intended outcome, affected layer and regression check. A patch without an owner or a reproducible purpose becomes harder to evaluate after upstream changes.
Check integration against a named upstream
Record the upstream revision and candidate revision. A clean Git operation establishes a source-level result; it does not establish a working engine or application.
Match artifacts to the target
If engine binaries are needed, retain their identity, target and build provenance. A framework revision alone is not enough to identify a custom native runtime.
Re-run the checks that justify the patch
Repeat the original reproduction and selected regression checks. When upstream fixes the problem, compare whether the extra patch can be retired through the project’s review process.
A small patch register
| Patch | Reason | Evidence required |
|---|---|---|
| Keyboard focus adjustment | One reproducible desktop flow | Case before/after; widget check; target interaction |
| Engine-side change | Native behaviour on a named target | Source revision; binary origin; target build/run |
| CLI adjustment | Reproducible tool invocation | Input, output and failure-path test |
These entries are examples, not claims about patches shipped by Flock. Start with the actual Flock patch repository for a real review. Pair it with the reviewer’s worksheet and the release record.