← A–Z Practice LessonsHome

Professional Digital Projects — Batch 12

Flutter · Firebase FCM · Apps Script · GitHub DevOps · WordPress Plugin · AI Video · Client Projects

7 projects · 112 unique checkpoints · Theory → Action → Result → Verification

Course index / విషయ సూచిక

01. Advanced Flutter — Production Task Manager

Objective: Build an offline-first task manager with validated forms and persistent tasks.

Requirements: Flutter SDK, Android Studio, VS Code, emulator or real device

Learning progression: Starting → Intermediate → Advanced → Expert. Complete each checkpoint in order.

Step 01 — Check toolchain

Theory / Why: Check toolchain is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run flutter doctor -v and resolve Android SDK licenses.

Expected output: Flutter reports no blocking Android toolchain errors.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 02 — Create project

Theory / Why: Create project is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run flutter create astra_tasks and cd astra_tasks.

Expected output: Project folder contains lib/main.dart and pubspec.yaml.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 03 — Inspect structure

Theory / Why: Inspect structure is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Locate main.dart, android/, test/, and pubspec.yaml.

Expected output: You can explain the purpose of each folder.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 04 — Design data model

Theory / Why: Design data model is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Define Task with id, title, completed, and createdAt fields.

Expected output: A task has stable identity and typed fields.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 05 — Create app shell

Theory / Why: Create app shell is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use MaterialApp with a home Scaffold and AppBar.

Expected output: App opens to a task list screen.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 06 — Add task entry

Theory / Why: Add task entry is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use TextEditingController and TextField inside a form.

Expected output: User can type a task title.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 07 — Validate input

Theory / Why: Validate input is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Trim whitespace; reject empty names; show a clear message.

Expected output: Blank tasks cannot be saved.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 08 — Manage state

Theory / Why: Manage state is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use StatefulWidget and setState for this small demo.

Expected output: New tasks immediately appear in the list.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 09 — Render task list

Theory / Why: Render task list is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use ListView.builder with a stable ValueKey per task.

Expected output: Scrolling list displays all tasks.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 10 — Complete tasks

Theory / Why: Complete tasks is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Add CheckboxListTile and update task state by ID.

Expected output: Checkbox updates the correct task.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 11 — Persist locally

Theory / Why: Persist locally is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Add shared_preferences for a demo or SQLite for structured data.

Expected output: Tasks survive app restart.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 12 — Handle storage failure

Theory / Why: Handle storage failure is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Wrap load/save in try/catch; show retry guidance.

Expected output: App does not silently discard failures.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 13 — Add navigation

Theory / Why: Add navigation is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Add a details screen and Navigator push/pop.

Expected output: Back returns to the task list.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 14 — Add tests

Theory / Why: Add tests is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Write a widget test for empty input and adding a task.

Expected output: flutter test passes.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 15 — Run on device

Theory / Why: Run on device is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use flutter devices and flutter run; test portrait and landscape.

Expected output: No overflow on target screens.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 16 — Build release

Theory / Why: Build release is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run flutter build apk --release; inspect signing and output path.

Expected output: Release APK is produced locally when SDK is installed.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Starter code / commands

flutter create astra_tasks
cd astra_tasks
flutter doctor -v
flutter test
flutter build apk --release

Errors & solutions

Independent assignment

Rebuild the project using a new fictional scenario, test at least three failure cases, and prepare a one-page handover note.

Knowledge check

Explain the purpose of the setup, identify one security or privacy risk, and demonstrate the final output without following the guide.

02. Firebase — Push Notifications & Secure Messaging

Objective: Register a test device and deliver opt-in notifications safely.

Requirements: Firebase project, Android package ID, Firebase CLI, FlutterFire CLI

Learning progression: Starting → Intermediate → Advanced → Expert. Complete each checkpoint in order.

Step 01 — Create Firebase project

Theory / Why: Create Firebase project is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create a project in Firebase Console; note project ID.

Expected output: Project is visible in console.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 02 — Register Android app

Theory / Why: Register Android app is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Enter exact applicationId; download google-services.json.

Expected output: Android app appears under project settings.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 03 — Configure FlutterFire

Theory / Why: Configure FlutterFire is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run flutterfire configure for the correct environment.

Expected output: firebase_options.dart is generated.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 04 — Add messaging package

Theory / Why: Add messaging package is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run flutter pub add firebase_messaging.

Expected output: Dependency appears in pubspec.yaml.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 05 — Initialize Firebase

Theory / Why: Initialize Firebase is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Call Firebase.initializeApp with generated options.

Expected output: App initializes without configuration errors.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 06 — Request permission

Theory / Why: Request permission is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Ask notification permission at an appropriate user action.

Expected output: User can allow or decline.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 07 — Handle Android channels

Theory / Why: Handle Android channels is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create a notification channel for Android 8+ if showing local notifications.

Expected output: Notification category exists on device.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 08 — Get FCM token

Theory / Why: Get FCM token is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Read token only after initialization; do not publish it in logs.

Expected output: Test token is available privately.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 09 — Store token securely

Theory / Why: Store token securely is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Associate token with signed-in user and use access rules.

Expected output: Other users cannot read tokens.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 10 — Foreground handling

Theory / Why: Foreground handling is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Subscribe to onMessage and show in-app state.

Expected output: Foreground message is visible.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 11 — Background handling

Theory / Why: Background handling is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Register top-level background handler before runApp.

Expected output: Background callback is registered.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 12 — Open notification

Theory / Why: Open notification is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Handle getInitialMessage and onMessageOpenedApp.

Expected output: Tap opens intended screen.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 13 — Send test message

Theory / Why: Send test message is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use Firebase Console test messaging to your own device.

Expected output: Device receives opt-in test notification.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 14 — Enforce authorization

Theory / Why: Enforce authorization is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use trusted server/Cloud Functions to send, not client-held server credentials.

Expected output: No privileged keys are shipped in APK.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 15 — Test failure modes

Theory / Why: Test failure modes is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Test permission denied, token refresh, offline, and duplicate delivery.

Expected output: App fails gracefully.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 16 — Document privacy

Theory / Why: Document privacy is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Explain notification data, opt-out and retention in privacy notice.

Expected output: User can understand and change preferences.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Starter code / commands

flutter pub add firebase_core firebase_messaging
flutterfire configure
# Send only from trusted server-side code

Errors & solutions

Independent assignment

Rebuild the project using a new fictional scenario, test at least three failure cases, and prepare a one-page handover note.

Knowledge check

Explain the purpose of the setup, identify one security or privacy risk, and demonstrate the final output without following the guide.

03. Google Apps Script — Professional Approval Workflow

Objective: Create an auditable approval queue with validation and safe test execution.

Requirements: Google Sheets, Apps Script editor, test spreadsheet

Learning progression: Starting → Intermediate → Advanced → Expert. Complete each checkpoint in order.

Step 01 — Define workflow

Theory / Why: Define workflow is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Document requester, reviewer, approver, and administrator roles.

Expected output: Approval responsibilities are explicit.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 02 — Design columns

Theory / Why: Design columns is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create ID, createdAt, requester, type, status, approver, decisionAt, notes.

Expected output: Sheet schema is consistent.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 03 — Create test sheet

Theory / Why: Create test sheet is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use fictional records, never production payroll or identity data.

Expected output: Safe test data exists.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 04 — Open Apps Script

Theory / Why: Open Apps Script is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use Extensions → Apps Script from the sheet.

Expected output: Bound script editor opens.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 05 — Centralize configuration

Theory / Why: Centralize configuration is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Define spreadsheet ID and allowed statuses as constants.

Expected output: Configuration is easy to audit.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 06 — Read rows

Theory / Why: Read rows is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use SpreadsheetApp.getActive().getSheetByName.

Expected output: Script reads intended tab.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 07 — Validate fields

Theory / Why: Validate fields is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Reject missing type/requester and invalid statuses.

Expected output: Invalid requests fail visibly.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 08 — Generate IDs

Theory / Why: Generate IDs is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use Utilities.getUuid and store createdAt once.

Expected output: Each request has unique ID.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 09 — Add requests

Theory / Why: Add requests is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Append values using fixed schema order.

Expected output: New row appears with Pending status.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 10 — Enforce transition

Theory / Why: Enforce transition is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Allow Pending → Approved/Rejected only with valid reviewer role.

Expected output: No accidental status skipping.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 11 — Add audit record

Theory / Why: Add audit record is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Append change history to separate Audit tab.

Expected output: Changes can be traced.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 12 — Use lock

Theory / Why: Use lock is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use LockService for concurrent updates.

Expected output: Parallel requests do not overwrite each other.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 13 — Handle exceptions

Theory / Why: Handle exceptions is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Return clear error text; do not expose private values.

Expected output: Errors are diagnosable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 14 — Test permissions

Theory / Why: Test permissions is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run as authorized account and test unauthorized action.

Expected output: Unauthorized changes are rejected.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 15 — Review triggers

Theory / Why: Review triggers is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Add only necessary installable triggers after manual testing.

Expected output: No unwanted automated emails.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 16 — Deploy carefully

Theory / Why: Deploy carefully is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Limit access; document quotas, backups and rollback.

Expected output: Pilot workflow is ready for review.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Starter code / commands

function addRequest(type, requester) {
  if (!type || !requester) throw new Error('Missing fields');
  const sheet = SpreadsheetApp.getActive().getSheetByName('Requests');
  if (!sheet) throw new Error('Requests sheet missing');
  const id = Utilities.getUuid();
  sheet.appendRow([id, new Date(), requester, type, 'Pending', '', '', '']);
  return id;
}

Errors & solutions

Independent assignment

Rebuild the project using a new fictional scenario, test at least three failure cases, and prepare a one-page handover note.

Knowledge check

Explain the purpose of the setup, identify one security or privacy risk, and demonstrate the final output without following the guide.

04. GitHub DevOps — CI/CD & Safe Rollback

Objective: Validate changes automatically and publish only tested code.

Requirements: GitHub account, sample HTML project, Git installed

Learning progression: Starting → Intermediate → Advanced → Expert. Complete each checkpoint in order.

Step 01 — Initialize repository

Theory / Why: Initialize repository is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create a repository and add README and .gitignore.

Expected output: Repository is versioned.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 02 — Commit baseline

Theory / Why: Commit baseline is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run git add and git commit with descriptive message.

Expected output: Baseline commit exists.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 03 — Create feature branch

Theory / Why: Create feature branch is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use git switch -c feature/site-update.

Expected output: Main branch remains unchanged.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 04 — Add quality checks

Theory / Why: Add quality checks is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create package scripts or static HTML validation checks.

Expected output: Checks run locally.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 05 — Add workflow folder

Theory / Why: Add workflow folder is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create .github/workflows/ci.yml.

Expected output: GitHub recognizes workflow.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 06 — Set trigger

Theory / Why: Set trigger is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run workflow on pull_request and push to main.

Expected output: Checks start on changes.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 07 — Select least privilege

Theory / Why: Select least privilege is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Set permissions: contents: read unless publishing requires more.

Expected output: Token scope is minimal.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 08 — Pin actions

Theory / Why: Pin actions is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use maintained actions and review pinned versions.

Expected output: Supply chain dependencies are visible.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 09 — Run tests

Theory / Why: Run tests is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use npm ci and npm test where package-lock exists.

Expected output: Test result is reported.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 10 — Protect main

Theory / Why: Protect main is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Require review and passing checks in branch protection.

Expected output: Unreviewed changes cannot merge.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 11 — Handle secrets

Theory / Why: Handle secrets is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use GitHub secrets and never echo values.

Expected output: Credentials are not in repository.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 12 — Publish preview

Theory / Why: Publish preview is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Deploy test build to staging first.

Expected output: Preview URL can be inspected.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 13 — Check links

Theory / Why: Check links is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Run local link checker against generated site.

Expected output: Broken internal references are flagged.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 14 — Merge after review

Theory / Why: Merge after review is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Approve PR only after QA checklist.

Expected output: Main contains reviewed code.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 15 — Tag release

Theory / Why: Tag release is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create a version tag and release notes.

Expected output: Known good revision is identifiable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 16 — Rollback

Theory / Why: Rollback is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Redeploy prior tag or revert commit and rerun checks.

Expected output: Site returns to previous known state.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Starter code / commands

name: site-ci
on: [push, pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: test -f index.html

Errors & solutions

Independent assignment

Rebuild the project using a new fictional scenario, test at least three failure cases, and prepare a one-page handover note.

Knowledge check

Explain the purpose of the setup, identify one security or privacy risk, and demonstrate the final output without following the guide.

05. WordPress — Custom Plugin Development

Objective: Build a minimal shortcode plugin with escaping and safe lifecycle.

Requirements: Local WordPress installation, PHP editor, test site

Learning progression: Starting → Intermediate → Advanced → Expert. Complete each checkpoint in order.

Step 01 — Create local staging

Theory / Why: Create local staging is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Install WordPress locally or on a non-public staging site.

Expected output: Test site works.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 02 — Plan functionality

Theory / Why: Plan functionality is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Specify a reusable call-to-action shortcode and settings.

Expected output: Plugin scope is limited.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 03 — Create plugin directory

Theory / Why: Create plugin directory is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create wp-content/plugins/astra-cta.

Expected output: WordPress plugin path exists.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 04 — Add plugin header

Theory / Why: Add plugin header is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Create astra-cta.php with plugin metadata.

Expected output: Plugin appears in Plugins list.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 05 — Prevent direct access

Theory / Why: Prevent direct access is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Check defined ABSPATH before executing code.

Expected output: Direct PHP access is blocked.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 06 — Register shortcode

Theory / Why: Register shortcode is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use add_shortcode with callback.

Expected output: Shortcode renders on test page.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 07 — Sanitize attributes

Theory / Why: Sanitize attributes is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use shortcode_atts and sanitize_text_field.

Expected output: Unexpected input is normalized.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 08 — Escape output

Theory / Why: Escape output is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use esc_html and esc_url on rendered values.

Expected output: HTML injection is prevented.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 09 — Use nonces for forms

Theory / Why: Use nonces for forms is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: If adding admin forms, verify nonce and capability.

Expected output: Unauthorized submissions are rejected.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 10 — Avoid raw SQL

Theory / Why: Avoid raw SQL is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use WordPress APIs or $wpdb->prepare where needed.

Expected output: Queries use safe patterns.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 11 — Add translations

Theory / Why: Add translations is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Wrap visible strings in localization functions.

Expected output: Strings are translation-ready.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 12 — Test theme compatibility

Theory / Why: Test theme compatibility is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Check shortcode under default and active themes.

Expected output: Layout stays readable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 13 — Test mobile

Theory / Why: Test mobile is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Verify responsive width and accessible contrast.

Expected output: CTA works on phone.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 14 — Review logs

Theory / Why: Review logs is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Enable WP_DEBUG_LOG only on staging and inspect notices.

Expected output: No unexpected warnings.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 15 — Package plugin

Theory / Why: Package plugin is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Zip only plugin folder with documentation.

Expected output: Plugin can be installed on test site.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 16 — Deploy with rollback

Theory / Why: Deploy with rollback is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Back up site; deploy staging-tested plugin and document rollback.

Expected output: Production deployment is controlled.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Starter code / commands

<?php
/** Plugin Name: Astra CTA Demo */
if (!defined('ABSPATH')) exit;
add_shortcode('astra_cta', function($atts) {
  $a = shortcode_atts(['text'=>'Learn more'], $atts);
  return '<div class="astra-cta">'.esc_html($a['text']).'</div>';
});

Errors & solutions

Independent assignment

Rebuild the project using a new fictional scenario, test at least three failure cases, and prepare a one-page handover note.

Knowledge check

Explain the purpose of the setup, identify one security or privacy risk, and demonstrate the final output without following the guide.

06. AI Video Workflow — Script to Subtitled Tutorial

Objective: Produce a clear tutorial video with readable captions and accurate claims.

Requirements: OBS or screen recorder, video editor, original screen footage, consented voice

Learning progression: Starting → Intermediate → Advanced → Expert. Complete each checkpoint in order.

Step 01 — Define audience

Theory / Why: Define audience is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Choose beginner/intermediate and one measurable skill.

Expected output: Learning objective is written.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 02 — Choose project

Theory / Why: Choose project is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Select one small, reproducible example.

Expected output: Demo can be repeated.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 03 — Write outline

Theory / Why: Write outline is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Split into hook, concept, setup, demo, result, recap.

Expected output: Narrative has logical order.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 04 — Write narration

Theory / Why: Write narration is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use short sentences with accurate terminology.

Expected output: Narration can be spoken naturally.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 05 — Check facts

Theory / Why: Check facts is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Verify menus, versions and output against actual software.

Expected output: No unverified feature claims.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 06 — Prepare screen

Theory / Why: Prepare screen is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Hide notifications, personal files, secrets and credentials.

Expected output: Recording area is privacy-safe.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 07 — Record clean demo

Theory / Why: Record clean demo is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Capture 1080p screen and cursor with deliberate pacing.

Expected output: Actions are readable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 08 — Record male narration

Theory / Why: Record male narration is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use natural pacing and consistent microphone distance.

Expected output: Voice is intelligible without long gaps.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 09 — Sync audio

Theory / Why: Sync audio is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Align each explanation to visible action.

Expected output: No confusing mismatch.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 10 — Trim mistakes

Theory / Why: Trim mistakes is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Remove dead air without cutting necessary steps.

Expected output: Pacing remains teachable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 11 — Add captions

Theory / Why: Add captions is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Transcribe actual audio and time each caption.

Expected output: Captions match spoken words.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 12 — Add callouts

Theory / Why: Add callouts is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Highlight clicks without hiding interface controls.

Expected output: Important UI remains visible.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 13 — Show output

Theory / Why: Show output is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Demonstrate result and common failure case.

Expected output: Learner can verify success.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 14 — Export video

Theory / Why: Export video is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use MP4 H.264/AAC, 1080p or suitable mobile preset.

Expected output: File plays on phone.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 15 — Quality check

Theory / Why: Quality check is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Listen fully and inspect captions on mobile.

Expected output: No clipped voice or unreadable text.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 16 — Publish with metadata

Theory / Why: Publish with metadata is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use descriptive title, chapter, language, and version.

Expected output: Learner finds correct tutorial.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Starter code / commands

ffmpeg -i input.mov -c:v libx264 -crf 22 -preset medium -c:a aac -b:a 160k output.mp4

Errors & solutions

Independent assignment

Rebuild the project using a new fictional scenario, test at least three failure cases, and prepare a one-page handover note.

Knowledge check

Explain the purpose of the setup, identify one security or privacy risk, and demonstrate the final output without following the guide.

07. Professional Client Projects — Scope to Handover

Objective: Deliver a web/app project with acceptance criteria, security review, and maintenance plan.

Requirements: Fictional client brief, spreadsheet, Git repository, staging website

Learning progression: Starting → Intermediate → Advanced → Expert. Complete each checkpoint in order.

Step 01 — Discover requirements

Theory / Why: Discover requirements is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Interview stakeholder about users, outcomes and constraints.

Expected output: Written problem statement exists.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 02 — Define scope

Theory / Why: Define scope is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: List in-scope and out-of-scope features.

Expected output: No ambiguous commitments.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 03 — Set acceptance criteria

Theory / Why: Set acceptance criteria is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Write testable conditions for each feature.

Expected output: Client can verify deliverable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 04 — Estimate effort

Theory / Why: Estimate effort is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Break tasks into milestones and contingency.

Expected output: Timeline is realistic.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 05 — Create proposal

Theory / Why: Create proposal is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Document price, deliverables, revisions and payment terms.

Expected output: Client can approve scope.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 06 — Create wireframes

Theory / Why: Create wireframes is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Show primary pages and navigation before coding.

Expected output: Client approves flow.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 07 — Set up repository

Theory / Why: Set up repository is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use version control and private config.

Expected output: Source changes are traceable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 08 — Build incrementally

Theory / Why: Build incrementally is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Deliver small milestones with demos.

Expected output: Progress can be reviewed.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 09 — Run functional tests

Theory / Why: Run functional tests is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Test forms, navigation, links and data flow.

Expected output: Acceptance tests pass.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 10 — Run accessibility review

Theory / Why: Run accessibility review is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Check keyboard, labels, contrast and responsive screens.

Expected output: Core flows are usable.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 11 — Run security review

Theory / Why: Run security review is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Check permissions, secrets, validation and dependency alerts.

Expected output: High-risk issues are addressed.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 12 — Deploy staging

Theory / Why: Deploy staging is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Use separate test URL and sample data.

Expected output: Client sees safe preview.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 13 — Collect feedback

Theory / Why: Collect feedback is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Record each request and its scope impact.

Expected output: Change requests are tracked.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 14 — Obtain acceptance

Theory / Why: Obtain acceptance is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Have client sign off against criteria.

Expected output: Handover is authorized.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 15 — Transfer ownership

Theory / Why: Transfer ownership is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Provide repo, domain, hosting and admin access through secure channels.

Expected output: Client controls their assets.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Step 16 — Document support

Theory / Why: Document support is required to progress toward the project objective; verify this checkpoint before continuing.

Practical action: Deliver maintenance guide, backups, rollback and support period.

Expected output: Project is operable after handover.

Practice check: Repeat this step independently and record the evidence (screenshot, output, or test result).

Starter code / commands

Project: Sample service website
Acceptance: 1) Mobile nav works 2) Contact form validates 3) All links resolve
Deliverables: source, deployment guide, test report, handover checklist

Errors & solutions

Independent assignment

Rebuild the project using a new fictional scenario, test at least three failure cases, and prepare a one-page handover note.

Knowledge check

Explain the purpose of the setup, identify one security or privacy risk, and demonstrate the final output without following the guide.