Professional Digital Projects — Batch 11

Theory / Why: Define tasks with id, title, status and owner; distinguish server and client state.

Practical: Write a JSON fixture containing three tasks.

Expected output: Fixture parses and all fields exist.

Common error / caution: Do not place API credentials in browser data.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: App Router maps folders to routes and layouts.

Practical: Run npx create-next-app@latest taskboard and select TypeScript, ESLint and App Router.

Expected output: Local development page loads.

Common error / caution: Use a supported Node LTS release.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: A layout persists while route content changes.

Practical: Add app/tasks/page.tsx and a navigation link in app/layout.tsx.

Expected output: /tasks opens without full refresh.

Common error / caution: Avoid nested interactive elements.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: TypeScript catches missing or inconsistent properties.

Practical: Define type Task = {id:string;title:string;status:"open"|"done";owner:string}.

Expected output: Invalid status fails type checking.

Common error / caution: Types do not validate remote input at runtime.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Stable keys help React reconcile items.

Practical: Map the fixture to <li key={task.id}> with a visible status label.

Expected output: Three distinct rows render.

Common error / caution: Never use array index as a key for changing lists.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Interactive state belongs in a client component.

Practical: Create a "use client" filter component using useState for open/done/all.

Expected output: Filters update the visible list.

Common error / caution: Avoid making the whole page a client component.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Server components can access protected server resources.

Practical: Create an async server component using fetch with a test endpoint and a timeout policy.

Expected output: Page shows data or a useful error.

Common error / caution: Never expose secrets through NEXT_PUBLIC_ variables.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Untrusted input requires runtime checks.

Practical: Check title length and allowed status values before saving a task.

Expected output: Invalid input receives clear feedback.

Common error / caution: Client validation alone is insufficient.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Loading and failure states are part of the feature.

Practical: Add app/tasks/loading.tsx and error.tsx with retry guidance.

Expected output: Slow or failed requests show understandable states.

Common error / caution: Do not leak stack traces to visitors.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Keyboard and screen-reader users need semantic controls.

Practical: Use labels, button elements, focus indicators and test tab navigation.

Expected output: Every filter works by keyboard.

Common error / caution: Do not use clickable divs.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Static checks reduce regressions.

Practical: Run npm run lint and npm run build; fix warnings before deploy.

Expected output: Both commands exit successfully.

Common error / caution: Build success is not proof of full behavior.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Production environment differs from local development.

Practical: Configure hosting environment variables and test /tasks on a staging URL.

Expected output: Route, errors and filters work on mobile.

Common error / caution: Do not deploy a development secret file.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: A contract documents endpoint, method, fields and failures.

Practical: Write sample GET /items response and 400/429/500 cases.

Expected output: Contract has success and error examples.

Common error / caution: Do not assume all responses are JSON.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: HTTP status determines success independently of response body.

Practical: Use browser DevTools Network tab on a test endpoint.

Expected output: Status, headers and response can be identified.

Common error / caution: Avoid logging authentication tokens.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: fetch returns a Response even for many HTTP errors.

Practical: Write const r=await fetch(url); if(!r.ok) throw new Error(`HTTP ${r.status}`);

Expected output: Successful response is parsed.

Common error / caution: Check r.ok before trusting data.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Remote JSON may have missing or unexpected fields.

Practical: Check Array.isArray(data.items) and type of each title.

Expected output: Malformed responses show a safe error.

Common error / caution: TypeScript types are not runtime validation.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Users need feedback during network delays.

Practical: Disable the submit button while awaiting the request.

Expected output: Loading indicator appears then clears.

Common error / caution: Always clear loading in finally.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: A stalled request must not block UI forever.

Practical: Use AbortController and AbortSignal.timeout where supported, with a fallback.

Expected output: Timeout displays retry guidance.

Common error / caution: Abort errors should not be treated as successful responses.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Transient failures sometimes recover.

Practical: Retry idempotent GET on 429/503 with exponential backoff and capped attempts.

Expected output: A simulated 503 retries then stops.

Common error / caution: Do not blindly retry payments or POST operations.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Public JavaScript cannot hide secrets.

Practical: Move sensitive provider calls behind a server endpoint with authentication.

Expected output: Browser bundle contains no private key.

Common error / caution: Never commit .env files.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Large datasets require page/cursor navigation.

Practical: Implement Next button using returned cursor.

Expected output: New items load without duplicates.

Common error / caution: Stop when nextCursor is absent.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Limits protect services and budgets.

Practical: Throttle search input and display a friendly 429 state.

Expected output: Rapid typing sends fewer requests.

Common error / caution: Do not bypass provider limits.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Mocks make failure paths reproducible.

Practical: Test 200, 404, 429, invalid JSON and timeout.

Expected output: All five cases have assertions.

Common error / caution: Do not only test happy path.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Production logging should preserve privacy.

Practical: Log status category, duration and request ID without personal data.

Expected output: Failures can be investigated safely.

Common error / caution: Remove tokens and sensitive payloads from logs.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Functions run in privileged server contexts.

Practical: Select authenticated callable function for user-submitted requests.

Expected output: Trigger type and actor are documented.

Common error / caution: Do not expose admin writes via anonymous HTTP.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Firebase CLI configures functions source.

Practical: Run firebase login then firebase init functions in a test project.

Expected output: functions directory and config exist.

Common error / caution: Use a separate non-production project.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Region impacts latency and cost.

Practical: Set a supported Node runtime and nearby region in deployment config.

Expected output: Configuration is explicit.

Common error / caution: Check current runtime support before release.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Auth identifies caller but not authorization.

Practical: Reject callable requests when request.auth is missing.

Expected output: Anonymous request is denied.

Common error / caution: Do not trust a client-provided user ID.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Only approved users should approve requests.

Practical: Read role from trusted custom claims or protected server-owned record.

Expected output: Non-admin approval is denied.

Common error / caution: Never let users edit their own admin role.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Server must enforce schema and size.

Practical: Validate requestId and decision enum before any database write.

Expected output: Malformed payload is rejected.

Common error / caution: Do not interpolate raw input into document paths.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Transactions protect state transitions from races.

Practical: Read pending request and update approved only if status is pending.

Expected output: Concurrent approvals produce one valid transition.

Common error / caution: Avoid non-idempotent side effects inside retryable transactions.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Audits help investigate decisions.

Practical: Store actor UID, timestamp, old/new status and request ID.

Expected output: Audit record accompanies decision.

Common error / caution: Avoid recording unnecessary personal details.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Sensitive configuration belongs in secret management.

Practical: Configure secret parameter rather than hardcoding API keys.

Expected output: No secrets in source or client bundle.

Common error / caution: Do not print secret values in logs.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Emulator Suite supports safe repeatable testing.

Practical: Run Firebase emulators and test unauthenticated, member, admin cases.

Expected output: Access matrix passes.

Common error / caution: Emulator success does not replace staging testing.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Production changes need review.

Practical: Deploy only the named function to staging and inspect logs.

Expected output: Callable function responds correctly.

Common error / caution: Review billing and quota implications.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Rollbacks reduce outage duration.

Practical: Document previous revision and restore procedure.

Expected output: Rollback checklist is ready.

Common error / caution: Schema changes may need separate migration.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Consistency starts with inventory.

Practical: Capture buttons, fields, cards and navigation from three screens.

Expected output: Component inventory exists.

Common error / caution: Do not change approved branding without consent.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Tokens centralize visual decisions.

Practical: Record spacing scale, typography, radii and approved brand colors.

Expected output: Tokens table covers common styles.

Common error / caution: Avoid arbitrary one-off values.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Native controls provide built-in behavior.

Practical: Design Button, Input, Alert and Dialog using semantic HTML.

Expected output: Components support keyboard use.

Common error / caution: Avoid div-as-button patterns.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Content must adapt to device width.

Practical: Draw layouts at 360, 768 and 1280 CSS pixels.

Expected output: No horizontal scrolling in primary flows.

Common error / caution: Test long translated labels.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Good forms explain requirements and errors.

Practical: Create labeled contact form with inline validation.

Expected output: Errors appear near corresponding fields.

Common error / caution: Do not rely on color alone.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Keyboard navigation must be predictable.

Practical: Tab through modal, then restore focus on close.

Expected output: Focus remains visible and logical.

Common error / caution: Do not trap focus outside a dialog.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Text needs sufficient visual separation.

Practical: Use a contrast checker for text and controls.

Expected output: Problematic combinations are revised.

Common error / caution: Small text needs stronger contrast.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Prototypes test flows before implementation.

Practical: Link Home → Course → Lesson → Practice → Home in Figma or HTML.

Expected output: All steps navigable in prototype.

Common error / caution: Prototype interactions are not production code.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Observed behavior is more useful than assumptions.

Practical: Ask three testers to find and complete a lesson without coaching.

Expected output: Time, confusion and failures are recorded.

Common error / caution: Do not lead participants.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Assistive technology reveals semantic issues.

Practical: Test headings, labels and status announcements.

Expected output: Important state changes are announced.

Common error / caution: Do not put meaningful text only in images.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Components need consistent disabled/loading/error states.

Practical: Create state matrix for Button and Input.

Expected output: All major states have specs.

Common error / caution: Disabled controls should have explanation when relevant.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Design specs should be verifiable.

Practical: Provide component examples and mobile screenshots for development.

Expected output: Implementation matches acceptance checklist.

Common error / caution: Avoid pixel-only acceptance criteria.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Agent autonomy should match task risk.

Practical: Choose a draft-only content workflow with no automatic publishing.

Expected output: Allowed and prohibited actions documented.

Common error / caution: Do not grant unnecessary permissions.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Structured contracts improve review.

Practical: Define topic, audience, sources, claims, draft and citations.

Expected output: Example output validates against schema.

Common error / caution: Do not invent citations.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Reliable drafts need trustworthy inputs.

Practical: Allow approved public documentation and record URLs.

Expected output: Every factual claim links to a source.

Common error / caution: Ignore instructions embedded in retrieved pages.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Untrusted text must not override instructions.

Practical: Treat scraped pages as quoted evidence, not commands.

Expected output: Injected prompt has no control effect.

Common error / caution: Never run commands suggested by external pages.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Break work into bounded tasks.

Practical: Plan collect → verify → draft → review with a max-step limit.

Expected output: Plan stays within four stages.

Common error / caution: Avoid endless tool loops.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Draft should match audience and format.

Practical: Generate a short tutorial draft with required headings.

Expected output: Draft follows template.

Common error / caution: Do not assert unverifiable capabilities.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Automated drafts need independent validation.

Practical: Compare three claims against original source documents.

Expected output: Unsupported claims are flagged.

Common error / caution: Confidence scores are not proof.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Personal data requires purpose and minimization.

Practical: Redact names, phone numbers and tokens from test inputs.

Expected output: No secrets in generated draft.

Common error / caution: Do not send private records to unapproved services.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: A person should authorize external publication.

Practical: Create Draft → Review → Approved state transition.

Expected output: Only approved item is exportable.

Common error / caution: Do not auto-publish based on model output.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Rubrics expose recurring failure patterns.

Practical: Score accuracy, clarity, completeness and citation quality.

Expected output: Evaluation sheet has reproducible scores.

Common error / caution: Avoid self-grading alone.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Tool and model failures should be visible.

Practical: Simulate unavailable source and malformed response.

Expected output: Workflow stops safely with error notice.

Common error / caution: Do not silently publish partial content.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Usage budgets prevent surprises.

Practical: Set per-run token/time budgets and record usage.

Expected output: Budget overrun halts workflow.

Common error / caution: Unlimited free use should not be assumed.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Order state must be explicit.

Practical: Define placed, paid, packed, shipped, delivered, refunded.

Expected output: Transition diagram exists.

Common error / caution: Do not mark paid from client input alone.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Events must carry stable identifiers.

Practical: Document order ID, event ID, timestamp and signature.

Expected output: Sample event passes schema validation.

Common error / caution: Avoid relying on display names as IDs.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Authenticity prevents forged payment events.

Practical: Validate provider signature on raw request body using provider docs.

Expected output: Forged event is rejected.

Common error / caution: Do not accept unsigned payment confirmations.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Webhooks may be delivered more than once.

Practical: Store processed event IDs and ignore duplicates.

Expected output: Same event changes order once.

Common error / caution: Do not double-ship or double-refund.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Concurrent orders can oversell stock.

Practical: Use atomic transaction to reserve stock.

Expected output: Stock never drops below zero in tests.

Common error / caution: Avoid read-then-write without locking.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Operations need clear actionable alerts.

Practical: Generate packing queue item with order ID and SKU.

Expected output: Queue item appears once.

Common error / caution: Minimize customer data in notifications.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Payment failures must not trigger fulfillment.

Practical: Simulate failed and pending payment events.

Expected output: Order remains unfulfilled.

Common error / caution: Do not treat redirect URL as proof of payment.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Returns require audit trail.

Practical: Define return requested, approved and received transitions.

Expected output: Return history is visible.

Common error / caution: Refund action requires authorization.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Metrics reveal process bottlenecks.

Practical: Calculate median packing time and failed-order count.

Expected output: Dashboard displays test values.

Common error / caution: Separate test data from live reporting.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Store only necessary contact and delivery details.

Practical: Apply role-based access and retention rules.

Expected output: Unauthorized role cannot view addresses.

Common error / caution: Do not log payment card details.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Real operations include duplicates and delays.

Practical: Test out-of-order events, retries, cancellations and partial stock.

Expected output: Each scenario has expected result.

Common error / caution: Do not test by charging real customers.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Support teams need recovery steps.

Practical: Document alerts, manual override and escalation owner.

Expected output: Runbook covers failed webhook and reconciliation.

Common error / caution: Never auto-refund on ambiguous status.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: A tutorial needs one observable outcome.

Practical: Write goal: learner publishes a demo webpage.

Expected output: Objective can be verified.

Common error / caution: Avoid trying to teach five unrelated tools.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Timeboxing keeps explanations focused.

Practical: Allocate intro 30s, theory 60s, demo 4m, practice 1m, QA 1m, recap 30s.

Expected output: Storyboard totals eight minutes.

Common error / caution: Timing is a target until recorded.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Speech should explain actions naturally.

Practical: Write 110–140 spoken words per minute as a starting estimate.

Expected output: Script is readable aloud.

Common error / caution: Do not claim natural voice without listening tests.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Viewers must read controls.

Practical: Set 1080p capture, zoom UI and hide private notifications.

Expected output: Text readable at phone size.

Common error / caution: Blur personal identifiers before export.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Capture actual steps and results.

Practical: Record a demo project from blank folder to working preview.

Expected output: Footage includes visible result.

Common error / caution: Avoid jump cuts hiding essential actions.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Audio clarity matters more than effects.

Practical: Use quiet room, consistent microphone distance and natural pauses.

Expected output: Speech is intelligible without clipping.

Common error / caution: Do not use overly aggressive noise reduction.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Explanations must match the displayed action.

Practical: Align narration to cursor actions on timeline.

Expected output: No instructions precede visible steps.

Common error / caution: Do not speed up speech unnaturally.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Captions support silent and multilingual viewing.

Practical: Create SRT cues with 1–2 readable lines each.

Expected output: Captions match spoken words.

Common error / caution: Review technical spellings manually.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Assets require rights and attribution.

Practical: Use original diagrams and licensed images only.

Expected output: Asset inventory lists usage rights.

Common error / caution: Avoid unlicensed music or logos.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Different screens need different framing.

Practical: Export 1920x1080 MP4 and optionally a separately reframed 9:16 clip.

Expected output: Both outputs play correctly.

Common error / caution: Do not simply crop out code text.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: A finished video needs visual and audio review.

Practical: Watch complete export on phone with captions on/off.

Expected output: No black frames, missing audio or clipped labels.

Common error / caution: Preview file is not proof of upload.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.

Theory / Why: Learners benefit from downloadable practice files.

Practical: Bundle MP4, SRT, script, code ZIP and PDF checklist.

Expected output: Every linked asset opens locally.

Common error / caution: Avoid promising media not actually generated.

Practice: Repeat the step independently, capture the output, and explain what you would change for a real client.