chore: bootstrap Atay Makhzan ops repo

docs/FUTURE-GITEA-FORK.md

@@ -0,0 +1,60 @@
+# Future Gitea Fork Strategy
+
+Saad's long-term intent is valid: Atay Makhzan may eventually differ enough from upstream Gitea that we maintain our own source code separately.
+
+But the sequencing matters.
+
+## CTO verdict
+
+Do not fork Gitea just because we can.
+
+Fork only when one of these is true:
+
+1. The required feature cannot be achieved with configuration.
+2. It cannot be achieved cleanly with Gitea Actions, webhooks, external automation, or themes.
+3. The feature is core to Atay Makhzan's identity as a product.
+4. Maintaining the patch is cheaper than working around upstream.
+5. We have time to track upstream security releases and merge conflicts.
+
+## Recommended stages
+
+### Stage 1 — Ops sovereignty
+
+This repository.
+
+Goal: make deployment reproducible, documented, backed up, and safe to upgrade.
+
+### Stage 2 — External extensions
+
+Use webhooks, scripts, bots, custom templates, and integrations around Gitea without touching upstream source.
+
+### Stage 3 — Theming and UX identity
+
+Customize branding, templates, and public surfaces while remaining close to upstream.
+
+### Stage 4 — Source fork
+
+Create a dedicated source repository only when Atay Makhzan needs product behavior that upstream Gitea will not support.
+
+Suggested future repo name:
+
+```text
+ibnezzoubayr/Atay-Makhzan
+```
+
+This ops repo should remain separate:
+
+```text
+ibnezzoubayr/Atay-Makhzan-Ops
+```
+
+## Fork discipline
+
+If we fork:
+
+- Track upstream Gitea releases.
+- Keep a changelog of every divergence.
+- Keep custom patches small and isolated.
+- Add tests for every custom behavior.
+- Maintain an upstream merge schedule.
+- Never delay critical upstream security patches for cosmetic customization.