# Episode 3: Verify behavior and state the limits

Production decision, 2026-10-17: English AI-cloned owner narration with English captions and Arabic translated subtitles. The Egyptian Arabic blocks below provide localized translation source text; Arabic audio is deferred. Natural length estimate: 4–6 minutes, including useful demonstrations and exercises. Measure rehearsal; never pad to a minimum. No release day assigned.

## Slide 1: the assistant says done

On screen: `Fixed. All good.` labelled `Illustrative completion message`, beside `Which checks?`.

English:

The assistant says the task is done. That's a useful status message, but we still need evidence for the behavior we requested. In our save example, we'll test overlapping calls and recovery after completion or failure. We'll also identify the parts these tests cannot cover. The goal is to finish with a specific statement: this command ran, these cases passed, and these native behaviors still need checking. That is a result another developer can inspect and repeat.

Egyptian Arabic:

المساعد بيقول إن المهمة خلصت. دي رسالة مفيدة عن حالة الشغل، بس لسه محتاجين دليل على السلوك اللي طلبناه. في مثال الحفظ، هنختبر الاستدعاءات المتداخلة، والرجوع للشغل بعد النجاح أو الفشل. وهنحدد الأجزاء اللي الاختبارات دي ما بتغطيهاش. عايزين نوصل لجملة دقيقة: الأمر ده اتشغّل، والحالات دي نجحت، ولسه سلوكيات في التطبيق محتاجة مراجعة. دي نتيجة مطور تاني يقدر يراجعها ويكررها.


## Slide 2: a request we control

On screen: test excerpt creating a deferred promise, starting the first task, then calling runSave again. Reveal the resolve call last.

English:

The first test keeps a request pending under our control. We start one save, call the same gate again, and count how many task callbacks began before the first request was released. The expected count is one. We then resolve the first request and examine both results. This avoids relying on a guessed delay or network speed. The important observation is whether the second callback ran during the first task, not how quickly the machine happened to complete the test.

Egyptian Arabic:

أول اختبار بيخلي الطلب معلّق وتحت تحكمنا. بنبدأ حفظ، وننادي نفس البوابة تاني، ونعد كام مهمة بدأت قبل ما نسمح للطلب الأول يخلص. المتوقع واحدة. بعدها بنخلّص الطلب الأول ونراجع النتيجتين. كده مش معتمدين على تأخير متخيل أو سرعة الشبكة. المعلومة المهمة هي هل المهمة التانية بدأت والأولى شغالة، مش الجهاز خلص الاختبار بسرعة قد إيه.


## Slide 3: the incomplete version fails

On screen: the recorded result summary `Before: 1 failed, 4 passed` and assertion `2 !== 1`. Do not display runtime durations as performance measurements.

English:

We ran the same suite against the incomplete gate. The overlapping-call check failed because two tasks started where we expected one. The other four checks passed. That's useful: it shows that a partly successful test suite can still expose the exact missing behavior. It also gives us a way to judge the test itself. If our repeated-save test passed on a version that allowed every call through, we'd need to inspect whether the test was actually exercising the requirement.

Egyptian Arabic:

شغّلنا نفس المجموعة على البوابة الناقصة. اختبار التداخل فشل لأن مهمتين بدأوا، وإحنا متوقعين واحدة. الأربع اختبارات التانيين نجحوا. ده مفيد: مجموعة فيها نجاح جزئي لسه ممكن تكشف السلوك الناقص بالضبط. وكمان بيدينا طريقة نراجع بيها الاختبار نفسه. لو اختبار منع التكرار نجح على نسخة بتسمح لكل الاستدعاءات، يبقى محتاجين نشوف هو بيختبر المطلوب فعلًا ولا لأ.


## Slide 4: the corrected gate passes

On screen: `After: 5 passed`. List the actual cases in a plain table: overlap, success release, rejected retry, synchronous throw, independent owners.

English:

The corrected gate passed all five supplied checks. They cover overlapping admission, release after success, retry after rejection, a synchronous throw, and independent gate instances. The rejected task's original error also reaches the caller in the test. These results support our small logic contract. They don't mean we have tested every possible caller. If a screen creates a new gate on each press, this function's tests can stay green while the integration is wrong. That is why we inspect both the helper and its use.

Egyptian Arabic:

البوابة بعد التصحيح نجحت في الخمس فحوصات الموجودة. دول بيغطوا التداخل، وفتح البوابة بعد النجاح، وإعادة المحاولة بعد الخطأ، وخطأ بيترمي فورًا، واستقلال البوابات عن بعض. والاختبار بيراجع كمان إن الخطأ الأصلي بيوصل للي استدعى المهمة. النتائج دي بتدعم شروط المنطق الصغير ده. لو شاشة بتعمل بوابة جديدة مع كل ضغطة، اختبارات الدالة ممكن تفضل ناجحة والدمج يبقى غلط. عشان كده بنراجع الدالة واستخدامها.


## Slide 5: the native checks still needed

On screen: `Logic: executed`, `TSX integration: reviewed`, `Native interaction: pending`. Show the busy/error illustration with a clear sample label.

English:

Our sample isn't a complete React Native app. We haven't mounted the supplied screen or tested its touch handling. In a host app, we would check that busy feedback appears, repeated interaction doesn't start extra work through this owner, an error stays understandable, and retry is available. We'd also inspect the localized labels and accessibility behavior. Keep these checks separate from the Node result. Type stripping runs the TypeScript syntax in this test; it isn't a TypeScript typecheck of the native component.

Egyptian Arabic:

المثال ده مش تطبيق React Native كامل. إحنا ما شغّلناش الشاشة الموجودة، وما اختبرناش اللمس عليها. في تطبيق فعلي، هنراجع ظهور التحميل، وإن التفاعل المتكرر ما يبدأش شغل زيادة من نفس المكان، وإن الخطأ مفهوم والمحاولة الجديدة متاحة. وهنراجع النصوص المترجمة وسلوك إمكانية الوصول. الفحوصات دي منفصلة عن نتيجة Node. إزالة الأنواع هنا بتسمح بتشغيل TypeScript في الاختبار، لكنها مش typecheck لمكوّن الشاشة.


## Slide 6: a report you can defend

On screen: exercise claim `The app can never send duplicate saves`. Pause, then replace it with `The retained gate passed the supplied overlap and recovery tests`.

English:

Review this claim: the app can never send duplicate saves. Can our results support it? Pause and decide which part is too broad. The tests cover one retained gate and prepared cases. They don't cover every entry point, a second device, or server-side processing. A supported report is that the retained gate passed the supplied overlap and recovery checks, with native integration still pending. Precise wording makes the review more useful because the next person knows exactly where additional work begins.

Egyptian Arabic:

راجع الادعاء ده: التطبيق مستحيل يبعت حفظ متكرر. هل نتائجنا تثبته؟ وقف وفكر أنهي جزء أوسع من الدليل. الاختبارات بتراجع بوابة موجودة وحالات مجهزة. مش بتغطي كل مكان يبدأ طلب، أو جهاز تاني، أو تنفيذ السيرفر. التقرير اللي نقدر ندعمه هو إن البوابة نجحت في اختبارات التداخل والتعافي الموجودة، ولسه الدمج في التطبيق محتاج مراجعة. الدقة دي بتوضح للي هيكمل أنهي شغل لسه باقي.


## Slide 7: the review is becoming repeatable

On screen: `Trigger / Gate lifetime / Failure path / Test evidence / Limits`. End on `Next: a reusable skill`.

English:

We've now repeated several review questions: what triggers another call, where does the gate live, what happens on rejection, and which checks actually ran? These questions will be useful on other save flows. In the next episode we'll package that procedure into a skill. We'll keep the procedure focused enough to follow, include the evidence we expect in a finding, and make its limits explicit. Then we'll test that skill on examples it hasn't already been shown how to classify.

Egyptian Arabic:

إحنا كررنا دلوقتي شوية أسئلة في المراجعة: إيه اللي بيبدأ استدعاء جديد، والبوابة عايشة فين، وإيه اللي يحصل مع الخطأ، وأنهي فحوصات اتشغلت فعلًا؟ الأسئلة دي هتفيدنا في عمليات حفظ تانية. الدرس الجاي هنحط الطريقة دي في skill. هنخلي خطواتها محددة، ونوضح الدليل المطلوب لكل ملاحظة، ونكتب حدودها. وبعدها هنجرّبها على أمثلة ما شافتش إجابات تصنيفها قبل كده.


## Recording and evidence

Slide cues are not narration. Use the matching task, context, implementation, verification, skill-authoring and evaluation prompts in [prompts.md](../sample/prompts.md). The exercise answers are in the spoken blocks and [evaluation answer key](../sample/review-skill/cases.md). Keep that answer key out of a real blind evaluation. Samples are teaching adaptations; no native app or actual AI evaluation result is claimed. Record slide by slide and time the selected takes.