[megyptm]

WU-10 — Consumer Verification Harness & Coexistence

Refs #20. Base main@1e13f0428665b7d18862caa969357ba9befed852 وTree 3a947b7b7f6b44123efa5a8ad18b6b3b88ee7fc2. HEAD d14d09bfc0cb78825d0e41ca0ea4480ad506f35b وTree 95c81dfb02845f52add52fdf87049d548f51888f.

composer test:consumer يختبر التعايش مع maatify/persistence:1.4.0 والمقارنة مع legacy source المثبّت باستخدام Composer roots مستقلة وproduction autoload. كل سيناريو يُشغّل في دورتين نظيفتين على MySQL، بما في ذلك snapshot وsavepoints وdeadlock replay، مع فحوص تنظيف.

MERGED · Technical PASS · RECONCILED. موعد كل دورة يأخذ الحد الأدنى بين موعد التشغيل الأصلي وموعد الدورة، مع حفظ احتياطي التنظيف. عند بقاء أقل من ثانية للعمل، تتوقف الدورة قبل إنشاء workspace. تغطي سبع حالات Regression الحدّين، بما فيهما نفاد الميزانية في الدورة الثانية. Runtime وPublic API وقيود Composer والقرارات ثابتة. تم Squash Merge بتصريح المالك إلى main@375f9aa73dacc4aa789986c6bfae0f22e8bb18d7 بالشجرة المقبولة أعلاه. WU-11 بانتظار تصريح بدء مستقل.

مراجعة F21-04 · مراجعة التغطية السابقة · CI على HEAD الحالية

القبول الفني بعد F21-04 · سجل دورتَي الـHarness

CI بعد الدمج

نجحت 21/21 وظيفة مطلوبة على commit الدمج. سجل المصالحة في Issue #20 · تحديث Architecture Umbrella

[megyptm]

مراجعة مستقلة لـ WU-10 — تصحيحات مطلوبة

راجعت الفرق الكامل على HEAD 84d1a4f1041b95c470ca3b2697a12609d1b7a148 وTree 3c817fb765890da0f194f5f0a44dbfe045cb62d8 مقابل main@1e13f0428665b7d18862caa969357ba9befed852. لم يظهر تغيير في Runtime أو API أو قيود Composer. تركيب الـHarness يستخدم Composer roots منفصلة وproduction autoload ودورة Integration القائمة.

1. P2 — فجوة مقارنة B-12 وB-03. harness/consumer.php يستخدم حد retry الافتراضي صفر في كلا التنفيذين، ويمرر هدف clamp عاديًا دون snapshot قديمة. لذلك CI الحالية تستطيع إثبات سلوك catalog والتعايش لكنها لا تختبر مباشرةً العقدين المنقولين من legacy B. أضف deadlock فعليًا منسقًا دون تأخيرات تخمينية، وأثبت replay محدودًا والتزام معاملة واحدة على الواجهات العامة للطرفين. أضف snapshot قديمة مع كتابة من اتصال ثانٍ لإثبات أن clamp يأتي من القراءة المقفلة.
2. P2 — مرجعية محتوى التشغيل. scripts/consumer-verification.php يأرشف candidate من HEAD ثم يقرأ Composer policy وينسخ fixture من working tree. تعديل محلي يمكنه تغيير workload أو سياسة التحقق بينما تبقى الـSHA المطبوعة كما هي. اقرأ المدخلات من المصدر المثبّت أو افشل صراحةً عند اختلاف مدخلات التحقق.
3. P2 — مسارات lifecycle. scripts/integration-support.php يستدعي callback الخارجي دون تمرير حد PP_SUITE_TIMEOUT_SECONDS المنطبق على suite pass، رغم أن مدخل المستهلك يتحقق من هذا الإعداد. كذلك مسار الإشارة الحالي ينهي العملية مباشرةً، فيتجاوز finally التي تزيل Composer workspace. حافظ على ميزانية وقت حقيقية للـpass، وعالج تنظيف موارد الـHarness عند الإشارات التي يمكن التعامل معها.

تُصحح النتائج في PR #21. يجري التحقق من تشغيل CI الحالي، وتُعاد مراجعة الفرق والأدلة على الـHEAD الناتجة.

Issue #20 · CI على HEAD المراجعة

[megyptm]

Fresh Full Independent Review — Technical PASS

راجعت الفرق المتراكم للملفات العشرة مقابل main@1e13f0428665b7d18862caa969357ba9befed852، بما في ذلك التصحيحات. Accepted HEAD ba01adc0f8caef1383af05c65cd5a6c7d336d078 وTree 61229e6257c11f4477039d99a79a9a9fa42a400a. Checkout الخاص بـCI هو 3d7ea687be6f031af0127dabe94280c3f5bd5ca6، أبواه هما الـbase والـHEAD أعلاه، وشجرته مطابقة.

• تشغيلان نظيفان. سجل MySQL 8.4.13 دورتين Compose مستقلتين. في كل دورة، ثبّت Composer الحزمتين باستخدام production autoload في root مستقل لكل سيناريو. نجح سيناريو التعايش وسيناريو المقارنة في الدورتين. تحقق السجل في كل دورة من صفر جداول ومعاملات متبقية، وصفر containers وvolumes وnetworks بعد teardown.
• التعايش. ثبت maatify/persistence:1.4.0 على fc1459b49fe5af5ead17814eeb3ada7a3fa81791 بجانب candidate. تتداخل savepoints للحزمتين في الاتجاهين على PDO واحدة. يحفظ فشل العملية الداخلية عمل المستدعي والـrunner الخارجي، وتبقى المعاملة بملكية المستدعي.
• المقارنة مع legacy source. استُخدم 1f6a7aafe601090b7e55f60d83794364afdefe67. تحققت من observable catalog results لملكية المعاملات، pagination array/JSON وB-08a عبر اتصال ثانٍ، نطاقات Ordering وB-03 stale clamp وB-04 rollback محلي، وB-12 deadlock فعلي وإعادة callback مرة واحدة وcommit النتيجة الثانية فقط في plain/savepoint لكلا التنفيذين. خريطة الأدلة تحدد الحالات التفصيلية المغطاة باختبارات Integration القائمة والفروق المقصودة بين baseline المنشورة وlegacy source.
• الإغلاق والتحقق. Composer policy والـfixture من الشجرة المثبتة، وميزانية suite timeout تطبق على العمل في كل دورة. اختُبر مسار SIGTERM القابل للمعالجة محليًا على مستوى orchestration. لا يتغير Runtime أو Public API أو قيود Composer أو القرارات. نجح 383 Unit و122 Regression محليًا، مع PHPStan max وPER-CS وSyntax وactionlint.
• CI المطلوبة. نجحت 21/21 وظيفة، بينها 11 Integration و4 Compatibility و2 Examples Smoke ووظيفة Consumer verification and coexistence وStatic وWorkflow lint وCI gate. الخلية الاستكشافية غير المطلوبة تخطاها الـworkflow وفق التصميم.

أُغلقت النتائج الثلاث. القبول الفني يخص الشجرة أعلاه. تبقى PR في Draft حتى قرار المالك.

المراجعة الأولى · نطاق Issue #20 · CI على HEAD المقبولة · سجل الـHarness

[megyptm]

WU-10 — Fresh HEAD Review: P2 Required Fix

راجعت الـdiff المتراكم للملفات العشرة على ba01adc0f8caef1383af05c65cd5a6c7d336d078 مقابل main@1e13f0428665b7d18862caa969357ba9befed852، وقرأت AGENTS.md وقرارات التعايش ومصفوفة الاختبار. تحققت من GitHub Actions run #43279806502: نجحت 21/21 وظيفة مطلوبة، والخلية exploratory مستثناة. سجل الـConsumer يثبت دورتين MySQL 8.4.13، وكل دورة فيها coexistence/differential وdeadlock replay، ثم RESIDUE-CHECK tables=0 openTransactions=0 وTEARDOWN VERIFIED. تطابقت شجرة checkout الخاصة بـPR merge commit 3d7ea687... مع شجرة الـHEAD 61229e6257c11f4477039d99a79a9a9fa42a400a.

F21-04 — P2 / BLOCKER: تجاوز ميزانية الـorchestration الكلية عند تشغيل الـconsumer.

• scripts/integration-support.php: startBudget() يثبت OrchestrationBudget::$deadline على now + PP_TOTAL_BUDGET_SECONDS، وremainingWorkSeconds() يحجز مهلة الـteardown من نفس الحد. تعليق الدالة يصرّح أنها ميزانية التشغيل الكامل.
• scripts/consumer-verification.php داخل verifyConsumer(): السطر OrchestrationBudget::$deadline = microtime(true) + boxed($suiteTimeout) + reserveSeconds(); يستبدل المهلة الكلية بمهلة جديدة، بدل تقاطعها مع الحد السابق. تعاد المهلة الأصلية فقط بعد انتهاء الـworkload والتنظيف.
• مثال ثابت من المنطق: إذا PP_TOTAL_BUDGET_SECONDS=240 وPP_SUITE_TIMEOUT_SECONDS=900، يمكن لـverifyConsumer() تمديد العمل إلى ما يقارب 900 ثانية رغم أن ميزانية التشغيل الكلية 240. وحتى بالإعدادات الافتراضية (1500/900) يمكن للدورة الثانية أن تمدد العمل بعد استهلاك جزء من الإجمالي في الأولى. بذلك تصبح ضمانات bounded orchestration ونافذة cleanup أمام timeout وظيفة CI غير ثابتة؛ نجاح التشغيل السريع الحالي لا يغطي هذا المسار.

المطلوب: الإبقاء على الـoverall deadline كحد أعلى لا يمكن تمديده، ووضع حد pass محلي بأخذ min(existingOverallDeadline, now + suiteTimeout + reserve) أو تصميم مكافئ مع الحفاظ على teardown reserve. أضف regression سلبية تُثبت عدم تمديد الميزانية عندما تكون الـsuite أطول من الـtotal أو عندما تكون الدورة الثانية قريبة من نهاية الميزانية، وفشلًا آمنًا مع teardown. ثم إعادة Full Applicable CI على exact HEAD الجديدة.

Notes: الفجوات الثلاث في المراجعة الأولى تظهر معالجة في الـpatch الحالي والـCI، ولا أعتبرها blocker مفتوحة من الأدلة التي راجعتها. لا يوجد تغيير في Runtime/Public API/Composer dependencies أو مخالفة ظاهرة لـDEC-005/008/013. لم أشغّل اختبارات محلية؛ حكم CI مبني على logs فعلية. الـPR تظل Draft؛ لا موافقة نهائية على الدمج قبل معالجة F21-04 وإعادة مراجعة النتيجة.

[megyptm]

Fresh Full Independent Re-Review — Technical PASS

أُغلقت F21-04 على d14d09bfc0cb78825d0e41ca0ea4480ad506f35b، Tree 95c81dfb02845f52add52fdf87049d548f51888f، مقابل main@1e13f0428665b7d18862caa969357ba9befed852.

كان boxed() يمنح حدًا أدنى مقداره ثانية حتى عندما تبقى أجزاء من الثانية أو ينفد وقت العمل. كان استخدامه لإعادة بناء الموعد المطلق قادرًا على تمديد الموعد الأصلي. يحسب التصحيح min(original, now + suite timeout + teardown reserve)، ويرفض بدء العمل إذا بقي أقل من ثانية قبل احتياطي التنظيف. يُستعاد الموعد الأصلي في finally. لذلك لا تعيد الدورة الثانية ضبط الميزانية العامة. تغطي سبع حالات Regression الحد العام الأضيق، حد الدورة الأضيق، التساوي، غياب الحد العام في helper، ثانية كاملة، وبقاء أجزاء من الثانية أو نفادها في الدورة الثانية.

راجعت التصحيح والفرق المتراكم وراجعت بقاء أدلة النتائج السابقة. Runtime وPublic API وقيود Composer والقرارات المثبّتة بلا تغييرات. نجحت اختبارات Unit وRegression والتحليل الساكن والتنسيق وSyntax. نجحت وظائف CI المطلوبة 21/21 على الـHEAD الجديدة، وشجرة checkout مطابقة. في كل من دورتَي MySQL نجح التعايش مع legacy v1.4.0 والمقارنة مع legacy main المثبّت، بما في ذلك deadlock replay لكلا نوعَي الـrunner، وتحقق صفر جداول ومعاملات وموارد Compose بعد التنظيف.

القبول الفني يخص الـHEAD أعلاه. تظل PR في Draft بانتظار قرار المالك.

F21-04 · المراجعة السابقة · CI على HEAD المقبولة