Scope Creep and Custom Fork

1. The failure: the product boundary disappears and the fork becomes a second product

Scope creep becomes dangerous when new requirements enter delivery without an explicit decision about baseline, cost, and acceptance criteria. If some changes live only in a customer fork, the team is effectively maintaining two product paths: upstream and the customized variant. A fork is not the failure by itself; the failure is the absence of an owned contract for scope, sync, tests, maintenance, and eventual reintegration or intentional independence.

2. A fork is not inherently technical debt

Git and GitHub support fork-based collaboration as a legitimate distributed workflow. A fork can be temporary, experimental, contractual, or intentionally long-lived. Therefore fork existence, commit count, or a merge conflict is not a diagnosis. Ask what is unique in the fork, why it exists, who owns it, and what condition makes it converge with upstream or remain an explicitly maintained variant.

3. Lock the baseline scope before counting changes

Without an explicit baseline, three additional requests may be uncontrolled scope growth or normal product evolution. The baseline should identify committed capabilities, acceptance criteria, and approval authority. Every delta then receives an explicit state such as APPROVED, REJECTED, DEFERRED, or UNKNOWN. An ambiguous request must not later be rewritten as if it had always been an approved requirement.

4. Re-baselining separates product evolution from scope creep

A new requirement is not scope creep when its cost, acceptance criteria, owner, and new baseline are explicitly approved. If the product now officially contains eight capabilities, update the baseline. Conversely, a request that entered a sprint through conversation or customer pressure is not proven approved merely because its implementation works.

5. Start with ahead/behind divergence, but do not stop there

Ahead and behind counts are useful signals, not complete maintainability metrics. A fork one hundred commits behind with no unique code may collapse to a clean sync. A fork only three commits different can be riskier when those commits patch authorization core and require a separate regression suite. Commit counts must be interpreted together with semantic conflict surface and patch carry.

6. Conflict surface matters more than conflict count

A README conflict is not equivalent to a conflict in authorization, persistence, or a security-sensitive subsystem. The record identifies where upstream change overlaps custom code and whether the conflict is only syntactic or changes behavior. An upstream security patch touching the same customized subsystem activates explicit review and regression evidence even when total divergence is small.

7. Duplicated tests expose hidden maintenance cost

A separate fork test matrix creates two questions on every upstream release: whether upstream tests still cover shared behavior and whether the custom delta has its own regression risk. Duplication is not automatically wrong; a contractual requirement may need dedicated tests. But ownership, execution trigger, and retirement condition must be explicit. An unowned duplicate suite is evidence that the fork is escaping governance.

8. Maintenance ownership requires both authority and obligation

A name in a document is insufficient. The owner is accountable for sync cadence, conflict triage, security-patch intake, regression evidence, and the reintegration or sunset decision. If nobody accepts those obligations, the fork is operationally unowned even if its original author is still on the team. The owner also knows when product or architecture escalation is required.

9. Test configuration and extension points before a permanent fork

When a customer need can be isolated through configuration, a feature flag, a plugin/extension interface, or a policy layer, that path can reduce divergence compared with patching shared core. Moving code behind an extension boundary is not closure by itself: the product baseline and approval must also be updated, and a sync-and-test probe must show that upstream can be consumed without the old private patch.

10. A bounded maintained fork can be the correct decision

A contractual or isolation requirement can make full reintegration inappropriate. In that case a fork may be classified as a BOUNDED_MAINTAINED_FORK: its baseline is explicit, delta is bounded, owner is named, sync cadence exists, dedicated tests are intentional, and a revisit condition is recorded. The lesson is not about deleting every fork; it is about eliminating unbounded and unowned forks.

11. Keep containment, recovery, and closure separate

Freezing new custom work is containment. Creating an extension point or synchronizing upstream is recovery. Closure is stronger: baseline and approved delta are explicit, the fork state is explainable, ownership and test delta are known, and a repeatable sync-and-test closure probe exists. One successful merge does not prove the original cause or guarantee future maintainability.

12. Scope Drift & Fork Divergence Control Record v1

The record keeps at least baseline_scope, approved_delta, acceptance_criteria, unplanned_work, customization_count, upstream_head, fork_head, ahead_count, behind_count, conflict_surface, duplicated_tests, upgrade_cost, maintenance_owner, reintegration_path, sunset_condition, and closure_sync_test. Each claim remains labeled OBSERVED, AUTHORITY, INFERRED, or UNKNOWN.

13. Classification: CONTROLLED, OPEN, CUSTOM_FORK_RISK, or SCOPE_CREEP_AND_CUSTOM_FORK

CONTROLLED_EVOLUTION means the baseline and change governance are explicit and the maintenance path is proportionate. SCOPE_GOVERNANCE_OPEN means baseline or approval evidence is still incomplete. CUSTOM_FORK_RISK means a fork—even with approved scope—has independent risk from conflict surface, duplicated tests, or weak ownership. SCOPE_CREEP_AND_CUSTOM_FORK combines unapproved or ambiguous scope growth with significant divergence and maintenance burden.

14. Lab: eight fixtures and 64 assertions

The lab covers eight cases: long-lived scope creep in a customer fork, approved evolution with no fork, a very-behind fork with no unique code, a three-commit authorization fork, migration to an extension without re-baselining, fully approved product evolution, a bounded contractual fork, and an upstream security patch colliding with a custom subsystem. Each case yields eight deterministic outputs: baseline state, approval state, fork state, divergence state, maintenance state, recovery path, classification, and decision—64 assertions in total.

15. Exit checklist and transfer

Before exit, make the baseline explicit; bind every delta to approval and acceptance criteria; interpret ahead/behind with semantics and conflict surface; record duplicate tests and maintenance ownership; test configuration/extension before a permanent core patch; give necessary forks a sync cadence and revisit/sunset condition; and prove closure with a sync-and-test probe. Then rebuild the transfer fixture from blank evidence: only one customer-specific requirement remains and must be isolated contractually. Decide whether a bounded fork is still necessary or a supported extension can preserve the requirement with less divergence.