# H11.0-P11.1-R40 — Power BI PBIX Trust Gate & Desktop Acceptance Contract

## الحقيقة الأساسية
هذه المرحلة **لا تنشئ ملف PBIX** ولا تدعي أن Power BI مكتمل. هدفها إغلاق مشكلة الثقة التي ظهرت في المراحل السابقة: كان فحص `PK` وحده يسمح نظريًا بقبول ZIP عادي تمت إعادة تسميته إلى `.pbix`.

## Base / Target
- Base Candidate: `11.0.11.46 / H11.0-P11.1-R39`
- Target Candidate: `11.0.11.47 / H11.0-P11.1-R40`
- Oracle Writes: `NONE`
- Database Changes: `NONE`
- Calculation Rules Changed: `false`

## ما تم تغييره
1. إضافة `PowerBiReportValidator.php` كمرجع وحيد لحالة PBIX.
2. إلغاء اعتماد الواجهة على مجرد `is_file(...)`.
3. جعل الواجهة والـController وخدمة التصدير تستخدم نفس `reportStatus()`.
4. منع إنشاء User-facing Power BI package عندما لا يكون PBIX مقبولًا.
5. إضافة فحص بنيوي أقوى من توقيع `PK` فقط.
6. إضافة إيصال قبول Power BI Desktop مربوط بـSHA-256 للملف نفسه.
7. إضافة `PBIX_VALIDATION.json` داخل أي حزمة Power BI مقبولة.
8. إضافة QA مستقل لاختبار الحالات السلبية والإيجابية.

## حالات الثقة
### MISSING
لا يوجد PBIX.

### INVALID
يوجد ملف لكنه يفشل الفحص الأساسي أو البنيوي.

### STRUCTURALLY_VALID_PENDING_DESKTOP_ACCEPTANCE
الملف اجتاز الفحص البنيوي، لكن لا يوجد إيصال قبول صحيح ومطابق للـSHA-256.

### ACCEPTED
الملف اجتاز الفحص البنيوي ويوجد إيصال قبول صحيح للبايتات نفسها.

## لماذا لا يكفي الفحص البنيوي؟
الفحص البنيوي Heuristic فقط، ولا يستطيع إثبات أن Power BI Desktop سيفتح الملف أو أن Refresh سينجح أو أن الأرقام تطابق NJCH وMNH. لذلك R40 لا يطلق الزر ولا يسمح بالحزمة النهائية إلا بعد وجود Acceptance Receipt.

## Acceptance Receipt
المسار المتوقع للملف الرئيسي:

`resources/powerbi/Daily_Inpatient_Revenue_Master.pbix`

مسار الإيصال:

`resources/powerbi/Daily_Inpatient_Revenue_Master.pbix.acceptance.json`

Schema الإلزامي:

`DDB_POWERBI_DESKTOP_ACCEPTANCE_V1`

والحقول الملزمة:
- `pbix_sha256` يطابق الملف الحالي حرفيًا.
- `power_bi_desktop_open = PASS`
- `refresh_from_datapack = PASS`
- `njch_reconciliation = PASS`
- `mnh_reconciliation = PASS`
- `accepted_at` تاريخ/وقت صالح.
- `accepted_by` يحدد من اعتمد الاختبار ولا يقبل placeholder.
- `evidence_reference` يشير إلى Evidence حقيقي ولا يقبل placeholder.

أي تعديل على PBIX يغيّر SHA-256 ويلغي صلاحية الإيصال السابق تلقائيًا.

## سلوك الواجهة
زر Power BI يظهر فقط عندما:

`powerBiReportStatus.available === true`

لم تعد الواجهة تفحص مجرد وجود الملف.

## سلوك مسار التصدير
إذا لم تكن الحالة `ACCEPTED`:
- HTTP status = `409`
- لا يتم إنشاء ZIP ناقص تحت اسم Power BI package.
- لا يتم تحميل Oracle data دون داعٍ لهذا الطلب.

إذا كانت الحالة `ACCEPTED`:

```text
<BRANCH>_Daily_Revenue_PowerBI_Package_<YYYY-MM-DD>.zip
│
├── Daily_Inpatient_Revenue_Master.pbix
├── PBIX_VALIDATION.json
└── DataPack/
    ├── summary.csv
    ├── payer_concentration.csv
    ├── care_area_revenue.csv
    ├── patient_level_detail.csv
    ├── power_bi_manifest.json
    └── README.txt
```

## QA المضاف
`tools/test_powerbi_r40_integrity.php`

يغطي على الأقل:
- Missing PBIX لا يعتبر Available.
- ملف نصي معاد تسميته إلى PBIX مرفوض.
- ZIP عادي معاد تسميته إلى PBIX مرفوض.
- PBIX-like structurally admissible لا يعتبر Accepted دون Receipt.
- Receipt به SHA-256 خاطئ مرفوض.
- Receipt مطابق يفعّل الحالة Accepted.
- الواجهة لا تستخدم raw file existence.
- Controller والService يستخدمان نفس trust gate.
- الحزمة النهائية تحتوي PBIX + DataPack + validation manifest فقط عند القبول.
- التصدير النهائي يُحجب دون Desktop acceptance.

## نتيجة الاختبار المحلي عند إنشاء R40
- `13/13 PASS`
- `0 FAIL`
- Real PBIX in candidate: `NOT_PRESENT`
- Power BI Desktop acceptance: `PENDING`

## حدود الادعاء
R40 يصلح بوابة الثقة والتصدير، لكنه **لا يغلق إنشاء تقرير Power BI الحقيقي نفسه**. لا يجوز اعتبار Power BI مكتملًا إلا بعد:
1. وضع PBIX حقيقي محفوظ من Power BI Desktop.
2. فتحه بنجاح.
3. Refresh ناجح من DataPack.
4. مطابقة NJCH.
5. مطابقة MNH.
6. إنشاء Acceptance Receipt مطابق للـSHA-256.
7. Windows Full Test + Live evidence.

## القاعدة الذهبية
**Missing Evidence is not PASS. Structural admission is not Desktop acceptance. Local Candidate is not Official Baseline.**