معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۳ — Cost، Pricing، P&L، Entitlement و SLA · 241

Anti-fork Customization

Build an anti-fork customization contract that classifies each request into bounded configuration, entitlement, declarative overlay, extension API, upstream product change, isolated companion service, explicit fork exception or decline; preserve a canonical core; and require compatibility, upgrade, security-patch and support evidence before any divergence is accepted. می‌تواند برای «Anti-fork Customization» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.

Anti-fork Customization — fa-IR

Lesson summary

Build an anti-fork customization contract that classifies each request into bounded configuration, entitlement, declarative overlay, extension API, upstream product change, isolated companion service, explicit fork exception or decline; preserve a canonical core; and require compatibility, upgrade, security-patch and support evidence before any divergence is accepted.

می‌تواند برای «Anti-fork Customization» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.

This lesson produces

می‌تواند برای «Anti-fork Customization» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.

Who it is for

Foundation

Use a field map, one worked scenario and explicit state vocabulary before independent construction.

Repair

Identify the failed evidence dimension, use the smallest mutated fixture and rerun only the affected gate.

Experienced

Compress definitions; require trade-off defense, counterexample analysis and changed-context transfer.

Prerequisites

1) The problem this lesson solves

A customer branch can look fast on day one while quietly splitting upgrade, security-patch, QA, and support paths from the shared product. This lesson governs the variation surface; it does not mutate live infrastructure.

2) Lesson boundary and deliverable

The deliverable is Anti-fork Customization Decision Contract v1. ARC-022 does not own ARC-021 SLA/support outcomes or COM-001 site information architecture, and it performs no live fork, migration, billing, or tenant mutation.

3) Fact: one codebase can have many deploys

The Twelve-Factor App describes one codebase with many deploys. Deploys may run different revisions, but they share the same codebase. This is a boundary pattern, not MAKNOW's commercial fork policy.

4) Fact: keep deploy-varying config separate from code

Twelve-Factor defines config as values likely to vary between deploys and calls for separation of config from code. A deploy-specific value therefore does not automatically require a source patch—but arbitrary config still needs schema, ownership, and test evidence.

5) Fact: Kustomize bases and overlays

Kubernetes Kustomize documents bases and overlays: a base has no knowledge of an overlay and can be reused by multiple overlays. That demonstrates one bounded variation pattern; it does not by itself prove that a commercial customization is supportable or secure.

6) A public extension contract is not an internal hook

A public, versioned extension has an explicit contract. A plugin coupled to an unversioned internal API has hidden upgrade risk. Kubernetes Custom Resources and controllers are examples of declarative API-extension mechanisms, not permission to depend on arbitrary internals.

7) Separate the decision paths

Classify each request as bounded configuration, entitlement, declarative overlay, public extension, upstream product change, companion service, explicit fork exception, or decline/hold. “Customer-specific” is not a sufficient variation type.

8) Preserve the Canonical Core

canonical_core_ref must remain traceable across deployments. Once a customer source patch becomes the operational source of truth, the system has forked even if the branch is still called temporary.

9) Compatibility and upgrade evidence are separate gates

A compatibility_window is not enough by itself; upgrade_test_ref must bind the customization to the target core/extension version. A successful old baseline does not prove the next upgrade.

10) Security patch path is critical

If an urgent fix can ship to the canonical core but the customer divergence cannot receive it cleanly, the customization is not merely inconvenient. The security propagation path is broken and the decision must remain blocked until repaired.

11) Expose support impact and divergence budget

support_owner, support_tier_impact, and divergence_budget make operational cost visible. Customer divergence creates QA, incident, and patch obligations that cannot be hidden under the label of a small customization.

12) Core Evidence Contract

The contract has 24 evidence dimensions, including 16 critical dimensions. The compact table below shows baseline, branch divergence, and recomputed transfer; JSON/CSV files retain the full mapping.

customization_request_idtenant_or_deploy_scopecanonical_core_refvariation_typeextension_or_config_refcompatibility_windowupgrade_test_refsecurity_patch_pathsupport_ownersupport_tier_impactdivergence_budgetfork_triggerfork_exception_ownersunset_or_rejoin_conditiondecision_stateevidence_ref
CR-101customer-a/prodcore@9.2DECLARATIVE_OVERLAYoverlay:customer-a:v2core>=9,<10test:overlay:9.2:PASScanonical-first + rebuild-overlayplatform-customizationSTANDARD0 source patchessource-divergencepatch-blockedarchitecture-boardN/A_STANDARDACCEPT_STANDARDev:arc022:baseline
CR-202customer-b/prodcore@9.2SOURCE_PATCHbranch:customer-bstale by 2 releasestest:rejoin:FAILmanual cherry-pickcustomer-b-squadESCALATEDexceededsource-divergencearchitecture-boardunprovenBLOCKED_SOURCE_DIVERGENCEev:arc022:fork-drift
CR-303customer-c/prodcore@10.0UPSTREAM_PRODUCT_CHANGEproposal:shared-capability:v1core>=10test:shared-capability:plannedcanonical release traincore-platformSTANDARD_AFTER_UPSTREAM0 source patchesinternal-api-couplingarchitecture-boardN/A_UPSTREAMUPSTREAMev:arc022:transfer

13) Fork Exception requires authority and rejoin/sunset

FORK_EXCEPTION is not a default path. It requires explicit exception authority, a trigger, a time/condition-bound rejoin or sunset plan, patch path, and support impact. A fork with no end condition is a permanent fork with a temporary name.

14) Typed states prevent fake success

HOLD_EVIDENCE_MISSING, HOLD_CONFIG_UNBOUNDED, HOLD_COMPATIBILITY, BLOCKED_SOURCE_DIVERGENCE, and BLOCKED_SECURITY_PATCH are valid outputs. Missing evidence must not be converted into acceptance by guesswork.

15) Lab and transfer

The lab uses eight fixtures and 48 assertions. In transfer, the extension schema changes, an urgent security fix must reach every deployment, and a second request depends on an internal implementation detail. The learner must recompute from changed evidence; the baseline is never the oracle.

Assessment

There is no answer key in this lesson pack; answer it yourself and mark honestly. "Needs review" sends the lesson to your review queue.

ARC-022-S1 retrieval

What does ARC-022 own, and why is a customer-specific source branch not automatically a valid customization surface?

lesson ✗AI ✗notes ✗

ARC-022-S2 application

Build Anti-fork Customization Decision Contract v1 for the baseline synthetic request and justify the decision from visible compatibility, patch, support and divergence evidence.

lesson ✗AI ✗notes ✗

ARC-022-S3 diagnosis

A source patch exists only on one customer branch and the canonical core advances two releases. Which contract fields and states prevent false acceptance?

lesson ✗AI ✗notes ✗

ARC-022-S4 transfer

The extension schema changes, an urgent security fix must reach every deployment, and Customer C asks for another change coupled to an internal detail. Recompute the path without copying the baseline decision.

lesson ✗AI ✗notes ✗
Assessment rubric

A passing artifact preserves a canonical core, classifies the variation surface, binds compatibility and upgrade evidence to explicit versions, proves a security-patch path, names support ownership and divergence budget, and keeps fork triggers plus rejoin/sunset conditions visible. Missing decisive evidence must remain HOLD/BLOCKED rather than acceptance.

References & freshness

The Twelve-Factor App — Codebase
·
The Twelve-Factor App — Config
·
Kubernetes — Declarative Management Using Kustomize
·
Kubernetes — Custom Resources
·

Case studies

baseline

A customer-specific presentation/policy change is implemented as a governed overlay against the canonical core with explicit upgrade and patch evidence.

wrong_approach

A source patch is committed only to one customer branch while the canonical core advances, creating hidden divergence.

transfer

After an extension-schema change and urgent security fix, a second internal-detail request is recomputed as an upstream candidate instead of copied from the baseline.

Lesson visuals

ARC-022-ANTI-FORK-FLOW

Lab files

آزمایش کاملاً آفلاین و synthetic است. fixtures/cases.json را بررسی کنید، python run_checks.py را اجرا کنید و توضیح دهید چرا هر state از شواهد visible مربوط به customization، compatibility، upgrade، security، support و divergence به‌دست می‌آید. هیچ answer key یا credential واقعی وجود ندارد.