Professional Digital Skills — Batch 15

Theory / why: Define requester, reviewer, approver, status, and handover.

Practical step: Draw a request lifecycle: Submitted → Under Review → Approved/Rejected → Closed.

Expected output / verification: A decision map with named owners.

Common error / caution: Do not let the requester approve their own request.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A stable ID prevents accidental cross-record updates.

Practical step: Add columns RequestID, CreatedAt, Type, Requester, Amount, Status, Approver, DecisionAt, Notes.

Expected output / verification: A header row with nine fields.

Common error / caution: Avoid using row numbers as permanent IDs.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Form validation reduces malformed submissions.

Practical step: Create Google Form fields for type, requester email, description, amount; connect responses to a Sheet.

Expected output / verification: A test response appears in the response sheet.

Common error / caution: Keep sensitive data out of public forms.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Bound Apps Script runs with the connected spreadsheet.

Practical step: In Sheets open Extensions → Apps Script; create a function called onFormSubmit(e).

Expected output / verification: Script editor opens and saves.

Common error / caution: An installable trigger is needed for authorized services.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Time plus random data reduces collision risk.

Practical step: Use Utilities.getUuid() to generate a new RequestID and write it to the matching response row.

Expected output / verification: A unique UUID appears for each submission.

Common error / caution: Do not generate a new ID on every edit.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Triggers run automatically after form submissions.

Practical step: In Apps Script Triggers add On form submit for the spreadsheet and authorize required scopes.

Expected output / verification: A new submission creates a request ID.

Common error / caution: Test under the intended owner account.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Controlled statuses make reporting consistent.

Practical step: Apply data validation to Status: Submitted, Under Review, Approved, Rejected, Closed.

Expected output / verification: Invalid status values are rejected or flagged.

Common error / caution: Avoid arbitrary status spellings.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Business rules must be checked before changing records.

Practical step: Build an approveRequest(id,actor) function that verifies approver identity and current status.

Expected output / verification: Only authorized transitions are accepted.

Common error / caution: Sheet UI hiding is not access control.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Audit entries explain who changed what and when.

Practical step: Append RequestID, actor, old status, new status, timestamp to a separate Audit sheet.

Expected output / verification: Each decision creates a traceable entry.

Common error / caution: Never silently overwrite audit history.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Two approvers may act at the same time.

Practical step: Use LockService.getDocumentLock() before validating and writing a decision.

Expected output / verification: Simultaneous test requests do not overwrite each other.

Common error / caution: Always release locks in finally.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A dashboard makes pending work visible.

Practical step: Use QUERY or pivot tables for pending counts by type and approver.

Expected output / verification: Dashboard totals match underlying records.

Common error / caution: Do not include private applicant details in shared charts.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A workflow is complete only when failures are exercised.

Practical step: Test duplicate submit, invalid email, unauthorized approval, two simultaneous updates, and a rejected request.

Expected output / verification: Test log records pass/fail and next action.

Common error / caution: Do not enable notifications without consent.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A visual is useful only if it communicates a clear message.

Practical step: Write a one-sentence audience, platform, and call to action for a sample tutorial.

Expected output / verification: A concise creative brief.

Common error / caution: Do not design before identifying the audience.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Brand systems prevent inconsistent outputs.

Practical step: Choose two brand colors, heading/body fonts, logo clearance, and minimum contrast.

Expected output / verification: A one-page mini style guide.

Common error / caution: Do not use tiny low-contrast captions.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Avoid copying recognizable copyrighted artwork.

Practical step: Sketch three logo directions using simple shapes and original wordmarks.

Expected output / verification: Three distinct concept thumbnails.

Common error / caution: Avoid claiming ownership of copied marks.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Specific prompts improve consistency.

Practical step: Specify subject, composition, typography, palette, aspect ratio, and exclusions.

Expected output / verification: A reusable prompt document.

Common error / caution: Generated text may need manual correction.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A thumbnail must read on a small phone.

Practical step: Create a 16:9 draft with one focal subject and a short headline.

Expected output / verification: A readable thumbnail draft.

Common error / caution: Avoid too many small elements.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Poster layout differs from video thumbnails.

Practical step: Rebuild the composition for a vertical social poster; preserve margins and hierarchy.

Expected output / verification: A vertical poster variant.

Common error / caution: Do not simply stretch the 16:9 image.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Typography affects comprehension and accessibility.

Practical step: Correct text manually; test title size at phone preview scale.

Expected output / verification: Error-free readable title.

Common error / caution: AI image tools can misspell words.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Transparency and export settings affect reuse.

Practical step: Export logo as SVG or high-resolution transparent PNG; export thumbnail as PNG/JPEG.

Expected output / verification: Reusable master and delivery files.

Common error / caution: Keep editable source separately.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Automated generation needs editorial oversight.

Practical step: Check text, visual artifacts, copyright risk, brand consistency, and platform policies.

Expected output / verification: Completed review checklist.

Common error / caution: Never publish unreviewed claims.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Consistent names speed production.

Practical step: Name assets course-topic-language-format-version, e.g. github-intro-en-16x9-v01.png.

Expected output / verification: Predictable asset folder.

Common error / caution: Avoid spaces and duplicate ambiguous names.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Testing should compare one meaningful change.

Practical step: Make two thumbnails with only the headline changed; document hypothesis.

Expected output / verification: Two controlled variants.

Common error / caution: Do not infer a winner from tiny sample sizes.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Clients need both publishable and editable assets.

Practical step: Deliver exports, editable source, font/license notes, size guide and revision log.

Expected output / verification: A complete handover ZIP.

Common error / caution: Do not bundle fonts without distribution rights.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Start with a legitimate user-initiated conversation.

Practical step: Choose appointment inquiries and map inquiry → qualification → response → close.

Expected output / verification: A service flow chart.

Common error / caution: Do not send unsolicited bulk messages.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Clear business identity improves trust.

Practical step: Complete profile, hours, description, and official website in WhatsApp Business.

Expected output / verification: Accurate profile preview.

Common error / caution: Do not impersonate another business.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Users should understand what they agree to.

Practical step: Write an explicit opt-in sentence describing message type and opt-out method.

Expected output / verification: Saved consent template.

Common error / caution: Do not treat purchased phone lists as consent.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Labels keep requests organized.

Practical step: Create New, Awaiting Details, In Progress, Resolved labels.

Expected output / verification: A sample inquiry moves through labels.

Common error / caution: Labels are not a secure customer database.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Reusable replies reduce typing without sounding robotic.

Practical step: Create replies for pricing, operating hours, document requirements and human handoff.

Expected output / verification: Four editable quick replies.

Common error / caution: Avoid promising unverified delivery times.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A clear service-level target improves reliability.

Practical step: Document response hours, escalation owners, and what happens outside business hours.

Expected output / verification: An internal response policy.

Common error / caution: Do not imply 24/7 human availability.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Catalog items should describe genuine offerings.

Practical step: Add a real service with description, price or quote policy, and a relevant image.

Expected output / verification: One accurate service listing.

Common error / caution: Avoid unsupported guarantees.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Minimize data collection to necessary fields.

Practical step: Track InquiryID, consent, request type, owner, status, last reply, next action.

Expected output / verification: A sample tracker with fictional entries.

Common error / caution: Do not store passwords or sensitive documents in Sheets.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Cloud API automation is not the same as the mobile app.

Practical step: Document Meta business setup, approved sender, template requirements and webhook endpoint needs.

Expected output / verification: An architecture checklist.

Common error / caution: Do not assume unofficial browser automation is supported.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Webhook endpoints must verify legitimate requests.

Practical step: Plan signature verification, idempotency keys, retries, and secret storage.

Expected output / verification: A secure webhook sequence diagram.

Common error / caution: Never hardcode access tokens in client-side JavaScript.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A user must be able to stop nonessential messaging.

Practical step: Simulate STOP or unsubscribe request and mark the contact as opted out.

Expected output / verification: A recorded suppression test.

Common error / caution: Do not send follow-ups after opt-out.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Operational metrics should improve support, not spam.

Practical step: Review first-response time, resolution rate, and opt-out rate on fictional data.

Expected output / verification: A small monthly service dashboard.

Common error / caution: Do not optimize only for message volume.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Clicks are not the same as customers.

Practical step: Write one measurable lead goal and a realistic cost-per-lead ceiling.

Expected output / verification: A campaign objective sheet.

Common error / caution: Do not promise guaranteed earnings.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Audience selection should reflect genuine product fit.

Practical step: List target location, language, intent, exclusions and customer problem.

Expected output / verification: An audience brief.

Common error / caution: Avoid sensitive-attribute targeting.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Ad claims must match the destination.

Practical step: Sketch a landing page with offer, proof, privacy link and one clear form.

Expected output / verification: A landing-page wireframe.

Common error / caution: Avoid misleading scarcity or fake reviews.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: UTM tags help attribute visits.

Practical step: Create utm_source, utm_medium, utm_campaign and utm_content naming rules.

Expected output / verification: A sample tagged URL.

Common error / caution: Never place personal data in URLs.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Measure actions that reflect business value.

Practical step: Specify form_submit or qualified_lead events and test with a staging page.

Expected output / verification: A conversion event specification.

Common error / caution: Do not count page views as qualified leads.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Search ads respond to explicit user intent.

Practical step: Group keywords by intent; write relevant headlines and negatives.

Expected output / verification: A draft search campaign.

Common error / caution: Review policy and billing before activation.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Creative and audience context differ from search.

Practical step: Draft two creative concepts and a lead-form question set.

Expected output / verification: A Meta campaign draft.

Common error / caution: Avoid collecting unnecessary personal information.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Controlled experiments limit financial risk.

Practical step: Use a hypothetical ₹3,000 test budget with a daily cap and stop rule.

Expected output / verification: A budget and stop-rule table.

Common error / caution: Do not launch without account owner approval.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Metrics must use consistent denominators.

Practical step: For 1,000 impressions, 40 clicks, 4 leads, calculate CTR 4% and click-to-lead 10%.

Expected output / verification: A checked metrics worksheet.

Common error / caution: Do not confuse CTR with conversion rate.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Browser privacy and consent affect reporting.

Practical step: Compare platform conversions with consented analytics and CRM lead counts.

Expected output / verification: A reconciliation table.

Common error / caution: Do not assume exact one-to-one matching.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Controlled changes are easier to interpret.

Practical step: Test one headline or creative while holding budget and audience constant.

Expected output / verification: A documented experiment plan.

Common error / caution: Avoid editing every setting simultaneously.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Reports should state results and uncertainty.

Practical step: Create a report with spend, leads, cost/lead, limitations, and next actions.

Expected output / verification: A client-ready monthly report.

Common error / caution: Separate observed outcomes from projections.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Core actions should work without a network.

Practical step: Specify add, edit, complete and search tasks while offline.

Expected output / verification: A testable requirements list.

Common error / caution: Do not make network availability a hidden prerequisite.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Separation of concerns reduces maintenance cost.

Practical step: Organize lib/features/tasks, data, domain and presentation folders.

Expected output / verification: A clear Flutter folder tree.

Common error / caution: Avoid putting all logic in main.dart.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Stable IDs enable safe edits and future sync.

Practical step: Define Task(id,title,completed,updatedAt,version).

Expected output / verification: A serializable model.

Common error / caution: Do not use list index as permanent task ID.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Controls must be usable on small phones.

Practical step: Create task list, add form, edit dialog and visible empty state.

Expected output / verification: A responsive screen.

Common error / caution: Avoid tiny tap targets.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Validation prevents empty or invalid records.

Practical step: Reject blank titles; trim whitespace; show inline errors.

Expected output / verification: A failed and successful validation test.

Common error / caution: Do not rely only on server validation.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Local databases preserve data between launches.

Practical step: Compare SQLite/Drift and shared_preferences; select a database for structured tasks.

Expected output / verification: A storage decision note.

Common error / caution: Do not store large relational records in preferences.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A repository abstracts persistence from widgets.

Practical step: Define createTask, listTasks, updateTask, deleteTask operations.

Expected output / verification: Testable repository interface.

Common error / caution: Avoid database calls directly in every widget.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Predictable state updates simplify UI.

Practical step: Choose Provider or Riverpod and bind loading/error/success states.

Expected output / verification: UI updates after a task edit.

Common error / caution: Do not silently swallow exceptions.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Offline writes require conflict handling.

Practical step: Draft an outbox queue and last-write conflict policy with version checks.

Expected output / verification: A sync flow diagram.

Common error / caution: Do not overwrite remote changes without a policy.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Mobile apps may be paused or killed.

Practical step: Test background/foreground, process restart, rotation and no-network state.

Expected output / verification: A lifecycle test log.

Common error / caution: Do not assume memory state survives process death.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Tests protect behavior during future changes.

Practical step: Write unit tests for validation and repository plus widget test for add task.

Expected output / verification: Passing test report.

Common error / caution: Do not equate a successful build with functional correctness.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Production builds require signing and checks.

Practical step: Review app ID, version, permissions, privacy policy, signing and AAB build.

Expected output / verification: A release checklist.

Common error / caution: Never commit signing secrets to Git.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Client input must never be treated as authorization.

Practical step: Draw client → Auth → callable function → Firestore.

Expected output / verification: A trust-boundary diagram.

Common error / caution: Never grant admin rights based on client-supplied role.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A predictable schema simplifies security rules.

Practical step: Define requests/{id} with ownerId, status, createdAt, updatedAt.

Expected output / verification: A documented schema.

Common error / caution: Avoid exposing private fields in public collections.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Use supported runtime and CLI versions.

Practical step: Create a Firebase project, install Firebase CLI, and initialize Functions and emulators.

Expected output / verification: A working local project.

Common error / caution: Check runtime support before selecting Node version.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: A callable function should reject unauthenticated requests.

Practical step: Read verified request.auth and return unauthenticated when absent.

Expected output / verification: Unauthorized test fails as expected.

Common error / caution: Never trust a UID supplied in request.data.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Schema validation protects backend logic.

Practical step: Check allowed status values and maximum note length before any write.

Expected output / verification: Malformed payloads are rejected.

Common error / caution: Do not pass arbitrary objects directly to Firestore.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Role checks belong on the server.

Practical step: Look up approver role from trusted claims or server-managed documents.

Expected output / verification: Unauthorized role test fails.

Common error / caution: Do not accept an isAdmin boolean from the app.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Transactions prevent stale state changes.

Practical step: Read current status and update it inside a Firestore transaction.

Expected output / verification: Concurrent decisions yield one valid transition.

Common error / caution: Avoid read-then-write outside a transaction.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Retries must not duplicate actions.

Practical step: Store operationId and reject or replay duplicate operation IDs.

Expected output / verification: Repeated call produces one decision.

Common error / caution: Do not assume functions run exactly once.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Audit trails support accountability.

Practical step: Write actor, requestId, oldStatus, newStatus and timestamp in the same transaction.

Expected output / verification: One audit record per accepted decision.

Common error / caution: Do not permit clients to edit audit entries.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: App Check helps reduce abuse but is not authorization.

Practical step: Plan App Check enforcement after validating supported clients and debug setup.

Expected output / verification: A staged enforcement checklist.

Common error / caution: Do not treat App Check as a replacement for Auth.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Local tests catch rules and function regressions.

Practical step: Test owner, approver, stranger, malformed data and retry in emulator suite.

Expected output / verification: A pass/fail test report.

Common error / caution: Do not test destructive operations on production data.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Release safety requires monitoring and recovery.

Practical step: Deploy to staging, check logs, define rollback and verify production rules.

Expected output / verification: A signed-off deployment checklist.

Common error / caution: Never expose secrets in logs.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Security tests must be performed only on owned or authorized systems.

Practical step: Document domain, allowed endpoints, test window and backup plan.

Expected output / verification: A written scope.

Common error / caution: Do not scan unrelated third-party sites.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Old packages may contain known vulnerabilities.

Practical step: List frontend/backend dependencies and update policy.

Expected output / verification: A dependency inventory.

Common error / caution: Do not upgrade production without a staging test.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Transport security and browser headers reduce risk.

Practical step: Check TLS, redirects, HSTS and content security policy on staging.

Expected output / verification: A header review checklist.

Common error / caution: Do not copy an overly restrictive CSP without testing.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Login must protect session and account recovery.

Practical step: Review rate limiting, reset links, session expiry and MFA availability.

Expected output / verification: An authentication test matrix.

Common error / caution: Never log passwords or tokens.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Users must not access others’ records.

Practical step: Test fictional user A cannot read or edit user B records in staging.

Expected output / verification: A pass/fail access-control test.

Common error / caution: Hidden buttons are not authorization.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Server-side validation reduces injection and logic flaws.

Practical step: Test safe malformed values and confirm output encoding on staging.

Expected output / verification: A validation report.

Common error / caution: Avoid destructive payloads against live systems.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Oversized media slows mobile loading.

Practical step: Convert suitable images to WebP/AVIF and add responsive sizes.

Expected output / verification: Before/after transfer size comparison.

Common error / caution: Keep accessible alt text.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Field and lab data reveal different bottlenecks.

Practical step: Run Lighthouse and inspect LCP, INP, CLS plus waterfall.

Expected output / verification: A baseline performance report.

Common error / caution: Do not claim field scores from lab-only runs.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Excessive JS delays interaction.

Practical step: Defer noncritical scripts and remove unused bundles after testing.

Expected output / verification: Lower main-thread work in a rerun.

Common error / caution: Avoid breaking event handlers.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Cache strategy depends on asset mutability.

Practical step: Set versioned immutable assets and shorter HTML cache policy.

Expected output / verification: Correct response headers.

Common error / caution: Do not cache authenticated private responses publicly.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Desktop-only QA misses real user failures.

Practical step: Test 360px viewport, slow network, keyboard navigation, and offline error state.

Expected output / verification: A mobile QA checklist.

Common error / caution: Avoid fixed-width overflow.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.

Theory / why: Improvements must be measurable and reversible.

Practical step: Document baseline, changes, regression tests, and rollback steps.

Expected output / verification: A client-ready audit report.

Common error / caution: Never promise a perfect security score.

Your exercise: Repeat this step with a second fictional example; record your result and explain what changed.