# Zyel Labs: The Practical YouTube Tutorial Playbook
Research checked October 25, 2026. Source context: Reddit examples span older directly relevant discussions and a June 2026 learner discussion. They are not a claim of a 2026 consensus or ranking. Official technical and production documentation was checked separately; installed-version behavior still requires testing.

## The Recommendation
Start with a repeatable, screen-first Lab: show a working result, explain the problem, build one solution, prove it works, and leave viewers with one useful exercise. Use OBS for recording, an editor you can operate confidently, clean speech, readable code, the existing Zyel Labs logo unchanged, and an optional one-second branding sting after the result. Make the first pilot before spending money on equipment or elaborate animation.

This is a prioritized synthesis of ten useful practices, not “Reddit's official top ten.” Reddit is anecdotal, self-selected creator/learner feedback, not a controlled study or a reliable ranking of tools. I searched current discussions and included older threads when they directly addressed coding tutorials. Some Reddit pages were accessible only through indexed excerpts. No reported growth or retention numbers are treated as independently verified. Specific durations and production settings below are starting recommendations, not YouTube rules or guarantees.

## 1. Open With The Working Result
Action: In the first 5–12 seconds, demonstrate the exact result promised by the title. For this Lab: change a table's sort and filter, hide a column, reload, and show those choices restored. Then say what the viewer will learn. Do not start with a history of the channel, an installation montage, or a subscription request.
Evidence: A coding-specific Reddit thread recommends a brief preview and short introduction: https://www.reddit.com/r/NewTubers/comments/15ukywh . A 2025 discussion similarly favors matching the opening to the packaging: https://www.reddit.com/r/NewTubers/comments/1id0fj2 . YouTube defines its intro retention measure around the first 30 seconds and recommends checking that the opening matches title/thumbnail expectations: https://support.google.com/youtube/answer/9314415 .
Implementation: Record the finished demo first, even though it appears first only in the edited video. Save two opening takes and choose the clearer one.

## 2. Teach One Viewer, One Problem, One Outcome
Action: Write: “For [audience who already knows X], this video teaches [observable outcome], using [version/tool].” Remove unrelated setup and styling from the core lesson. Put required setup in the starter project or a separate prerequisite video.
Evidence: Learners complain both about unnecessary tangents and unexplained steps in https://www.reddit.com/r/learnprogramming/comments/yihhjf . These competing complaints suggest clearer scope, not simply shorter videos.
Implementation: For the pilot, assume basic HTML/JavaScript and an existing DataTables table. Say that up front. Do not market it as a complete JavaScript course.

## 3. Script The Opening; Outline The Build
Action: Write the first 30 seconds and conclusion word for word. In the middle, use a shot plan with “say / do / expected result.” Record in short sections. If live coding makes narration hesitant, capture the working steps first and record voiceover afterward.
Evidence: A programming-creator workflow discusses recording, editing and then voiceover: https://www.reddit.com/r/NewTubers/comments/o5d15j . This is an option, not a universal best workflow.
Implementation: Keep a verified final version, a starter version, and a clean reset procedure. Never invent a debugging struggle or imply a scripted demonstration is an unrehearsed discovery.

## 4. Prioritize Clear Speech And Readable Code
Action: Before a full session, record a minute and listen on headphones. Turn off irrelevant system audio. Move the microphone closer rather than trying to fix a distant, echoing recording with aggressive processing. Increase editor and terminal text until the smallest important line is readable in a reduced-size player.
Evidence: OBS recommends checking audio devices and making a test recording: https://obsproject.com/kb/quick-start-guide . A 2025 programming-video discussion describes a workable Linux/OBS/Shotcut setup and asks about refinement, illustrating that fancy tooling is not a prerequisite: https://www.reddit.com/r/YouTubeCreators/comments/1nlwr7e .
Implementation: Use one code pane where possible; hide the file tree when unnecessary; keep the cursor still while explaining. A webcam is optional and must not cover the code.

## 5. Explain The Decision, Not Every Keystroke
Action: For each meaningful change, explain what problem it solves, why this approach fits, and how to check the outcome. Cut repetitive typing, but hold on the completed change long enough to read it. Explicitly say when a wait or repetitive section has been shortened.
Evidence: Learners ask for the thought process rather than only finished code in https://www.reddit.com/r/learnprogramming/comments/13qi4dn . Recent discussion also encourages trying a small project instead of only watching: https://www.reddit.com/r/learnprogramming/comments/1uarnpn/stop_doing_tutorials_stop_watching_youtube/ .
Implementation: End each section with a tiny checkpoint. End the video with a variation the viewer can attempt without copying.

## 6. Make Branding Recognizable And Small
Action: Reuse the existing Zyel Labs logo, site color tokens and typography without redesigning them. Let the result appear before an optional short restrained sting. The existing static logo works just as well for the first pilot.
Evidence: Reddit creators often describe shortening/removing long animations, but their outcomes are anecdotal: https://www.reddit.com/r/NewTubers/comments/1edd82f/do_you_use_intros_or_no_intros_and_why/ .
Implementation: Use the Zyel Labs system below. A one-second recommendation is an editorial choice, not a measured optimum.

## 7. Standardize Recording And Editing
Action: Save an OBS scene collection and an editor project template. Separate microphone and needed system sound when practical, keep original recordings, and label takes by section.
Evidence: OBS documents separate audio tracks and MKV/remux workflows: https://obsproject.com/uk/wiki/advanced-recording-guide-with-multi-track-audio and https://obsproject.com/kb/standard-recording-output-guide .
Implementation: Use folders for source footage, audio, project files, graphics, exports and captions. Keep a clean master project, then duplicate it for each episode.

## 8. Package The Outcome Honestly
Action: Write title candidates before recording so the lesson has a clear promise. Use one focal image and a few readable words, not a collage of code, logos, arrows, faces and screenshots. Put the searchable topic near the beginning; brand/episode labels can go at the end.
Evidence: YouTube recommends accurate, succinct titles and avoiding excessively complex thumbnails: https://support.google.com/youtube/answer/12340300 .
Implementation: Thumbnail for the pilot: one large table crop with the chosen state visible, a simple refresh symbol, “STILL SAVED,” and a small Zyel Labs mark. No fabricated metrics or exaggerated “never lose anything” claim.

## 9. Publish A Complete Learning Package
Action: Include corrected captions, chapters, exact tested versions, starter/final code links, setup instructions, test steps and limitations. Describe what was actually tested, not what AI predicts will work.
Evidence: YouTube allows uploaded/synced/manual captions and recommends reviewing automatic captions: https://support.google.com/youtube/answer/2734796 and https://support.google.com/youtube/answer/6373554 . Chapter instructions: https://support.google.com/youtube/answer/9884579 .
Implementation: Correct “DataTables,” “localStorage,” identifiers and numbers. Keep captions out of the important code area in the edited composition. Never publish credentials, personal browsing data or real customer records.

## 10. Improve One Thing Per Episode
Action: After enough viewing data exists, compare your opening, confusing sections, and viewer questions with similar videos on your own channel. A spike can mean interest or confusion; a drop can mean skipping or leaving. Do not diagnose everything as “the algorithm.”
Evidence: YouTube explains these alternatives and says retention data generally takes 1–2 days to process: https://support.google.com/youtube/answer/9314415 .
Implementation: Keep an episode log: promise, length, opening used, major questions, first-30-second retention when available, and one change for the next episode. Do not use another creator's retention percentage as a universal pass mark.

## The Production Stack: Choose The Simplest One You Can Finish With
Default: OBS + DaVinci Resolve + a reusable vector wordmark.
Pros: flexible recording, separate audio, substantial editing/audio tools and official training. Tradeoffs: initial setup and a larger editing learning curve. Start with cuts, basic audio and titles; ignore advanced effects.
Official Resolve training: https://www.blackmagicdesign.com/products/davinciresolve/training .

Alternative A: OBS + an editor you already know.
Pros: fastest route to the first finished Lab. Tradeoffs: caption, audio, zoom and export features vary; test the complete workflow before committing. Do not switch editors merely because a Reddit comment says another one is “best.”

Alternative B: Live screen narration with minimal editing.
Pros: more natural delivery, less synchronization work. Tradeoffs: tangents and mistakes can slow the lesson. Rehearse, record by chapter, and cut failed takes.

Alternative C: Screen recording followed by voiceover.
Pros: precise narration and easier correction. Tradeoffs: more synchronization, and a script can sound stiff. Read it aloud, shorten sentences, and leave visual breathing room.

Do not buy a microphone, paid editing subscription, stock music or animation package until a test identifies a real limitation. This playbook does not assume a particular operating system or machine specification.

## Step-By-Step: First Episode To Publication

A. Prepare the lesson
1. Define the viewer, prerequisites, outcome and non-goals in four lines.
2. Build and test the smallest demo using synthetic data. Record exact dependency versions and installation steps.
3. Create starter and finished snapshots. Run the starter instructions from a clean copy.
4. Write the spoken hook, section bullets, test checklist and conclusion.
5. Make the thumbnail concept and working title now. If the promise is hard to explain, narrow the episode.

B. Prepare OBS
1. Obtain OBS from its official project if you need it, then run Tools > Auto-Configuration Wizard for recording.
2. Make a scene named “Lab screen.” Add the relevant window/screen source for your OS and the correct microphone input. Prefer a dedicated demonstration window over your whole private desktop.
3. Start with 1920 x 1080, 30 fps for a mostly static code lesson. These are practical starting settings, not mandatory or optimal for every machine. Increase resolution only if your machine and workflow handle it and the text remains readable; do not rely on resolution to rescue tiny fonts.
4. Use MKV as the recording container for resilience to interrupted recording. Remux to MP4 in OBS if your editor needs it. Preserve the original.
5. If recording application audio, put the microphone on its own track and test that the editor imports it. Disable unused sources to prevent echo or duplicate audio.
6. Turn off notifications. Use demo accounts and synthetic data. Remove secrets from terminals, browser tabs, bookmarks, autofill and recent-file lists.
7. Record a minute containing quiet speech, normal speech, a click sequence, code and the final result. Play it back. Fix unreadable text, clipping, fan noise and wrong capture areas before continuing.

C. Record
1. Record the completed-result opening, then the body in sections, then the conclusion.
2. Pause between sections to make cuts easy. When you misspeak, pause and repeat the complete sentence.
3. Narrate the intent before the action and the outcome after it. Avoid “click here” without naming the control.
4. Leave a clear view of each important code change and its output. Do not race to fill silence.
5. Capture deliberate reload and reset tests. If a test fails, fix it before presenting the result as successful.

D. Edit in five passes
1. Structure: remove tangents and failed takes; keep the prerequisite path intact.
2. Teaching: align narration with the corresponding action; add short labels where the UI is hard to locate.
3. Readability: crop/zoom only to clarify. Avoid constant automatic motion and decorative transitions.
4. Audio: balance speech, reduce distracting noise gently, and inspect edits for cut-off words. Music is optional; no music is a sensible default for coding explanations.
5. Finish: add the short brand sting, corrected captions, a final result recap and a single relevant next step. Play the entire export, not just the editor preview.

Blackmagic's official training covers the editor, audio and delivery workflows; use its current beginner/Edit training rather than trying to master every page before publishing: https://www.blackmagicdesign.com/products/davinciresolve/training .

E. Export and review
Use MP4/H.264 and the recorded frame rate. For a 1080p/30 SDR export, YouTube lists 8 Mbps as a reference video bitrate; 1440p/30 lists 16 Mbps. AAC audio at 48 kHz is a compatible choice. These are upload recommendations, not instructions to record at the same bitrate, and they do not guarantee fine text survives compression. Inspect the export at normal and small player sizes. Official reference: https://support.google.com/youtube/answer/1722171 .

F. Publish deliberately
1. Upload privately first when you are ready to upload; do not treat unlisted as confidential.
2. Enter an accurate title, useful description, thumbnail, language and audience designation based on the actual content. Review any applicable sponsorship/synthetic-content disclosures.
3. Add corrected captions. For manual chapters, begin at 00:00, use at least three ascending timestamps and give each chapter at least ten seconds. Use actual edit timings, not the illustrative script timings below.
4. Check the processed playback, audio, captions and links on desktop and phone. Wait for the intended resolution to finish processing.
5. Publish or schedule only after the review. Keep the project, source recordings and final code snapshot together.
6. Check for viewer-reported bugs and clarify them with a correction when needed. Change teaching or packaging based on evidence, not a single early metric.
YouTube's settings reference: https://support.google.com/youtube/answer/57404 .

## Zyel Labs: A Consistent Logo And Intro System
Preserve the current identity. The existing Zyel Labs logo and site styles were not inspected during this research, so no specific logo geometry, colors, fonts or available variants are asserted here. This is a production recommendation, not a redesign request.

- Inspect the existing official SVG logo and the site's actual design tokens and typography before producing assets. Reuse those assets and values as the source of truth.
- Preserve the exact SVG geometry, proportions, wordmark lettering and existing colors. Do not redraw a geometric Z, substitute a font in the wordmark, invent a palette, crop away part of the logo or create new brand variants.
- Use existing approved variants if present. If there is no symbol-only or monochrome variant, do not invent one. The full existing mark can appear on a suitable background using its established treatment.
- For video exports, render the existing SVG at the required size without stretching. Check readability at small sizes and placement within a circular avatar before using it there. If it does not fit, use an already-approved avatar asset or leave avatar changes outside this task.
- Reuse the current site typography and color tokens for captions, lower thirds and thumbnail text, while checking readability and contrast in the actual composition. Keep code in a readable monospace font.
- Optional intro storyboard: show the finished demo first; reveal the unchanged existing logo with a restrained opacity fade or simple mask; hold briefly; cut directly back to the tutorial. Keep the mask non-destructive and fully reveal the original mark. Do not morph the paths or add a new symbol.
- A total duration around 1–1.5 seconds is an editorial starting point, not an evidence-backed optimum. A static existing logo or no separate sting is also reasonable. No loud whoosh, long slogan or forced music bed is necessary.
- Spoken bridge: “I'm Chason. Let's build it.” Keep any existing tagline unchanged; do not introduce a new slogan without a separate request.
- Outro: show the working result while suggesting one specific related lesson or exercise. Do not replace useful screen time with a long animated end card.
- Reuse one thumbnail layout with the existing brand assets, but change the focal outcome for each Lab. Branding should support the subject rather than occupy the thumbnail.

## Reusable Episode Script Template
Working title: [searchable problem + concrete outcome]
Audience/prerequisites: [what viewers must already know/have]
Evidence: [tested versions, source links, test results]

0:00 Result: “Here is [outcome]. [Demonstrate proof].”
0:10 Promise: “We'll [specific learning goal], and I'll show you [important limitation/check].”
0:20 Tiny brand sting and brief introduction.
0:25 Setup boundary: “You need [prerequisites]. The starter includes [already prepared pieces].”
Section 1: Problem. Show failure or inconvenience. Explain the desired behavior.
Section 2: First meaningful change. Say why, show it, test it.
Section 3: Second meaningful change. Say why, show it, test it.
Section 4: Failure case/reset. Demonstrate what the solution does not do.
Conclusion: Re-run the promised result. Summarize three decisions. Give one small independent exercise and point to verified resources.

Use approximate timing only to plan. Do not pad the lesson to reach an arbitrary runtime.

## Full Sample Script: DataTables That Remember Your View
Proposed title: “Save DataTables Filters, Sorting and Columns After Refresh”
Alternative: “Make DataTables Remember Your View with stateSave”
Thumbnail: one readable table, refresh symbol, “STILL SAVED.”
Target: roughly 5–7 minutes including demonstrations. Read aloud and adjust pacing.

Production status: This is an original shoot script based on official API documentation, not a claim that your existing Lab has been inspected or that this example has been executed. Before recording, test it against the installed version. The pilot covers sorting, built-in search, column visibility and page length. Column dragging, arbitrary column widths, custom external filters and cross-device preferences are not promised.

0:00–0:15 | SCREEN: Finished demo. Filter synthetic rows, sort, hide the Department column and reload.
SAY: “You filter this table, put the rows in the order you need, and hide a column. Then you refresh. Those choices should still be here. In this Lab, we'll make DataTables remember that view, and add a reset button so users can start over.”

0:15–0:25 | SCREEN: Very short Zyel Labs sting, then editor.
SAY: “I'm Chason. Let's build it.”

0:25–0:55 | SCREEN: Starter table and dependency/version note.
SAY: “I'm starting with a working DataTables table and some fake records. This lesson assumes you're comfortable editing basic HTML and JavaScript. Use the starter project and the exact versions listed with the video. We're focusing on remembering table preferences, not building the whole page from scratch.”

0:55–1:25 | SCREEN: Starter without persistence. Change sort, reload, show the default again.
SAY: “First, here's the problem. I change the order and reload, but the table starts over. The data itself is fine. What's missing is the user's view of it. Before adding our own storage code, let's use the feature the library already provides.”

1:25–2:05 | SCREEN: Add the initialization options below to the existing initialization, not a second initialization.
SAY: “Enable stateSave in the table's configuration. That turns on DataTables' state-saving behavior. I'm also setting stateDuration to zero for this demonstration. Zero means DataTables won't expire the saved state based on its age. A positive number sets a lifetime in seconds, and minus one selects session storage instead. Choose deliberately rather than inheriting a behavior you haven't explained.”

SHOWN CODE, adapted to a three-column starter whose table id is labTable:
```javascript
const table = new DataTable('#labTable', {
  stateSave: true,
  stateDuration: 0,
  columns: [
    { name: 'name' },
    { name: 'department' },
    { name: 'status' }
  ]
});
```

SAY: “These column entries match the starter's three columns. Keep the table identifier and column names stable. If your existing initialization already has data, renderers or other options, preserve them and add the new settings there.”

2:05–2:40 | SCREEN: Search, sort and reload. Show before/after without hiding the reload.
SAY: “Now change the search and sort, then reload the same page. Check the actual result, not just whether the code saved successfully. The table should return to that view. If it doesn't, check your installed version, the initialization and whether browser storage is available.”

2:40–3:30 | SCREEN: Add a “Toggle department” button and listener.
SAY: “Let's make a column preference visible too. This button toggles the Department column using DataTables' API. Hiding a cell with CSS would be a different operation. I'm using the named column so the intent is clear. The demo button must already exist in the page before this listener runs.”

SHOWN CODE:
```javascript
document.querySelector('#toggleDepartment').addEventListener('click', () => {
  const department = table.column('department:name');
  department.visible(!department.visible());
});
```

SAY: “Hide the column and refresh again. Check that it stays hidden, then restore it with the same button. This lesson demonstrates visibility. Don't assume that every extension or custom control automatically saves its settings in the same way.”

3:30–4:15 | SCREEN: DevTools storage for the synthetic demo origin only.
SAY: “These are browser-side preferences, not a backup of the table's records and not an account-sync feature. A different browser or device won't automatically inherit them. Also, search terms may contain information people wouldn't want left on a shared computer. Think about what you're saving and how users can clear it.”

4:15–4:55 | SCREEN: Add a “Reset view” button and its listener.
SAY: “Let's give the user a way out. This button clears the saved state and immediately reloads the page. Clearing saved state is separate from changing the view already on screen. Also, a later state save can write it again, so we're not drawing the old view between clearing and reloading.”

SHOWN CODE:
```javascript
document.querySelector('#resetView').addEventListener('click', () => {
  table.state.clear();
  window.location.reload();
});
```

4:55–5:35 | SCREEN: Test checklist with actual runs.
SAY: “Run the whole loop: search, sort, hide the Department column, change the page length, then reload. Check each result. Next, reset and confirm the configured defaults return. Finally, try the page in a separate browser profile. That helps confirm you're testing local preferences rather than accidentally relying on another source of state.”

5:35–6:05 | SCREEN: Finished table and exercise.
SAY: “The important decisions are what to remember, how long to remember it, and how the user resets it. For practice, change the saved-state lifetime and test that behavior. Then try adding another column. Keep the example small enough that you can explain every result. The starter, finished version and documentation belong with the video so you can follow along.”

Producer note: The final sentence assumes you actually provide those resources before publication. Otherwise replace it with a factual statement of what is available. Confirm the exact behavior and version compatibility before filming; do not label untested steps “tested.”

## Provisional Chapter List
These are planning timestamps only. Replace them with the final edit timings before publishing.
00:00 The result after refresh
00:25 Starter project and prerequisites
00:55 What resets without saved state
01:25 Enable state saving
02:05 Verify sorting and filtering
02:40 Remember column visibility
03:30 Storage boundaries and privacy
04:15 Add a reset button
04:55 Test the complete workflow
05:35 Recap and practice

## Technical Sources And Guardrails For The Sample
- stateSave, table identity and version-dependent named-column restoration: https://datatables.net/ref/core/option/stateSave . DataTables documents named-column restoration across certain schema changes from 2.2; test the version used in your Lab rather than presenting it as universal.
- Storage choice, lifetime and default expiration: https://datatables.net/ref/core/option/stateDuration . Browser clearing or restrictions can still remove/prevent saved state; “no age expiry” is not a durable-storage guarantee.
- State structure, including visibility and column search: https://datatables.net/ref/core/type/DataTable.State .
- Column visibility API: https://datatables.net/ref/core/api/column().visible() .
- Clear state and reload: https://datatables.net/ref/core/api/state.clear() .
- Named-column selector syntax is documented here; still test the installed version: https://datatables.net/ref/core/type/DataTable.ColumnSelector .
- Browser storage behavior and restrictions: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage .
- Add the two actual HTML buttons with matching ids in the starter. Avoid undeclared controls, missing imports, unmatched column counts and accidental double initialization. Do not film console errors as a successful result.
- If the real Lab has custom dropdown filters, drag reorder or saved widths, scope a separate verified section. Do not imply the three options above implement those features.

## Reusable AI Prompts
Use only code/data you are allowed to share with the selected AI service. Remove secrets and private/customer information. Treat output as a draft until the claims and code are verified.

1. Plan a teachable episode
“Act as a technical tutorial producer. My audience is [audience]. They already know [prerequisites]. The single outcome is [outcome]. Here are the actual tested steps and versions: [evidence]. Create a result-first outline, a prerequisite list, a shot list and three verification checkpoints. Separate verified facts from unknowns. Do not invent API behavior, test results, links or extra features. Suggest what to cut.”

2. Draft a natural script
“Turn this verified outline into a conversational script for Chason at Zyel Labs. Use short sentences and concrete actions. Open with the working result, then the promise, then a one-second branding break. For every section give SAY, SHOW, EXPECTED RESULT and PAUSE. Explain why each important decision matters. Avoid hype, filler, a long greeting and a subscribe request before delivering value. Mark unresolved facts as VERIFY.”

3. Audit the technical claims
“Review this script against the supplied source documents and actual code. List every implementation claim, its evidence, version assumptions and a test that could disprove it. Flag missing setup, undeclared variables, unsafe data handling and differences between built-in behavior and custom code. Do not say you executed anything unless you actually did. Return a concise correction list before rewriting.”

4. Improve pacing without losing instruction
“Review this transcript and shot list. Find repetition, tangents, unexplained jumps and places where the viewer needs time to read. Propose exact cuts and replacement lines. Keep all required setup and verification. Never remove a failure explanation just to make the video faster. Do not invent timestamps; use only those supplied.”

5. Create honest packaging
“Based only on this episode's demonstrated outcome, propose ten accurate YouTube titles: five searchable and five curiosity-led. Put important terms early. For the best three, give a thumbnail concept with ONE focal image, no collage and no more than four short words. Use only the supplied existing Zyel Labs SVG, current site color tokens and current typography. Preserve the exact logo geometry and lettering; do not infer missing brand values or invent new variants. No false superlatives, unsupported time claims or invented results.”

6. Reuse the existing identity in a short intro
“Using the supplied existing Zyel Labs SVG and verified current site tokens and typography, write a production brief for a restrained intro placed after a result demo. Preserve exact SVG geometry, proportions, lettering and colors. Do not redesign, redraw, introduce a geometric Z, invent a palette or substitute a wordmark font. Propose only a non-destructive opacity fade or mask reveal of the unchanged mark. Treat 1–1.5 seconds as an editorial suggestion to test, not a proven rule. If assets or style values are missing, request inspection of the existing site rather than guessing. Use approved existing variants only.”

7. Review captions and publishing text
“Compare these captions against the final narration and displayed code. Correct terminology, identifiers and numbers without changing meaning. Preserve valid timing; flag unreadably long captions and overlaps. Draft a factual description, resource checklist and chapters using only supplied final timestamps and verified URLs. Mark missing resources instead of fabricating links.”

8. Diagnose the next improvement
“Here are this video's retention observations, title, thumbnail, transcript and viewer questions: [data]. Separate observations from hypotheses. Identify at most three likely problems and propose one controlled creative change for the next comparable episode. Do not infer causality from one metric or promise growth. Consider that rewatches may signal confusion.”

## Pre-Publication Gate
The promised result is demonstrated. Prerequisites are explicit. Exact versions are recorded. The starter works from a clean copy. No secrets/private data appear. Audio is intelligible. Code is readable at small size. All major changes are explained. The reset/failure path is shown. Captions and links are checked. Title and thumbnail match the actual lesson. Branding does not delay the lesson. The final processed video has been watched end to end.

## First Three Labs: A Coherent Mini-Series
1. Remember a DataTables view after refresh: built-in state, visibility and reset.
2. Make saved preferences predictable: expiration, stable names, schema changes and a deliberate reset strategy, verified against your chosen version.
3. Persist a custom filter safely: explicit serialization/restoration, UI synchronization and tests, only after the real implementation is inspected and proven.

Finish the first pilot before building a large content calendar. Reuse the production template and improve one weak point each time.