# H11.0-P4.2 — Branch Oracle Connectivity Root Recovery

## سبب الإصلاح

Evidence الخاص بـ H11.0-P4.1 أثبت أن كل الاختبارات السابقة ما زالت PASS،
وأن الفشل الوحيد في GMOV سببه الوصول إلى JCKH:

- direct connection: `ORA-12514`
- hard-coded DB link `rcpmaster_jck`: `ORA-02019`

إذًا المشكلة ليست في SQL الخاص بـ `gmov` ولا في منطق الحساب، بل في افتراض
مسار اتصال واحد غير مثبت.

## الحل الجذري

تم حذف سياسة التخمين الثابت لمسار fallback واستبدالها بـ Shared Oracle
Branch Resolver يعمل هكذا:

1. يجرب آخر مسار سبق إثباته بنجاح من cache محلي لا يحتوي كلمات مرور.
2. يجرب الاتصال المعرّف حاليًا.
3. عند مشكلة SERVICE_NAME يجرب نفس endpoint بصيغة SID والعكس.
4. يقرأ Oracle DB-link catalog ديناميكيًا ويختبر الروابط الموجودة فعليًا.
5. يقرأ TNS الفعلي في Oracle Client.
6. يبحث بصورة محدودة وآمنة في إعدادات نسخة DDB القديمة الموجودة بجوار
   `ddb-new`، بدل افتراض IP أو Service Name.
7. أي endpoint لا يستخدم إلا بعد Oracle identity probe حي.
8. يمنع قبول نفس قاعدة البيانات كأنها فرعان مختلفان.

## ما لا يحدث

- لا توجد Oracle writes.
- لا توجد DDL/DML.
- لا تحفظ كلمات المرور في cache أو Evidence.
- لا يتم قبول endpoint لمجرد أنه يرد؛ يجب أن تتطابق هوية Oracle مع الفرع.
- لا يوجد hard-coded `rcpmaster_jck` كمسار نجاح مفترض.

## Evidence الجديد

`BRANCH_ORACLE_CONNECTIVITY_DIAGNOSTICS.json`

يسجل بصورة منقحة:

- كل طبقة discovery تم تجربتها.
- Oracle error code لكل محاولة فاشلة.
- المسار الذي نجح.
- Oracle identity fingerprint لكل فرع.
- عدم وجود cross-branch identity collision.

## معيار الإغلاق

- NJCH/JCKH/MNH: 3/3 resolved.
- الهويات الثلاث مختلفة.
- Year mode: 36/36 exact checks.
- Date-range mode: 36/36 exact checks.
- إجمالي 72/72.
- `max_difference = 0`.
- `write_operations = NONE`.