Web Developer

Send the three-page community learning website from the courses. Include your HTML, CSS and README. Show the page links, form labels, image text and rules for different screen sizes. Write a plan for checking links, keyboard focus and the page at 200% zoom. Explain one change you made to the code. Name any checks you have not carried out. Attach readable code and text files. A link or claimed test result alone is not enough. If important work is missing or unclear, we may ask for more or send it to a school reviewer.

• Source and artifact brief (35%) · essential
  The submitted HTML/CSS artifacts cover all three pages, navigation, labelled form and responsive layout from the authored brief.
• Source and design decisions (30%) · essential
  The source uses appropriate semantics, labels, text alternatives, focus rules and responsive declarations, with a clear rationale.
• Source analysis and check design (25%) · essential
  The proposed link, keyboard, viewport and zoom checks are concrete and traceable to the submitted source; distinguish a planned check from an independently verified result.
• Explanation, attribution and revision (10%)
  Explain a specific source/artifact decision and revision, attribute assistance and state the limits of what the submitted evidence establishes. Unresolved evidence gaps require clarification or optional human review.

Make a small JavaScript program that adds up study time. Send it as solution.mjs. Read exactly one JSON value from stdin: an array/list of at most 200 fictional {topic:string, minutes:integer 1..600, completed:boolean} records. For valid input, write exactly one JSON object to stdout: {totalMinutes:sum of all minutes, completedCount:number of completed sessions, minutesByTopic:object of minute totals keyed by each exact topic string}, then exit with status 0. An empty array/list returns zeros and an empty object. For invalid input, exit with status 2 and no stdout: reject non-arrays/lists, more than 200 entries, malformed entries, non-string or blank/whitespace-only topics, non-integer/out-of-range minutes and non-boolean completed values without coercion. Validate topic.trim() but preserve each original exact topic string as the grouping key. Use no external dependencies, network or file access except reading stdin. Do not print debug messages or a test/pass report. You may organize the script with helper functions; the school assesses actual stdin/stdout behavior in fresh processes, comparing outputs independently on the host. Include a short explanation with your submission. Passing this bounded suite does not establish correctness of the entire capstone.

• Correct summary (35%) · essential
  Write the exact JSON summary for valid stdin input and exit 0; totals include every session, completed counts and original-topic totals.
• Input validation (25%) · essential
  Reject invalid lists, entries and fields with exit status 2 and no stdout, without silently coercing strings, numbers or booleans.
• Trusted test results (25%) · essential
  The isolated trusted suite must actually execute and pass; unavailable execution is not a pass.
• Explanation (15%)
  Explain the function, representative checks and one error corrected.

Send the code for your study planner, including editable tasks, filters and saved local data. Include a text copy of your Git changes, the review comments you acted on and your accessibility notes. Walk through what the code does with a normal task, no tasks and bad input. Point to the relevant code. Explain one change made after review. Attach readable code and text files. A link or claimed test result alone is not enough. If important work is missing or unclear, we may ask for more or send it to a school reviewer.

• Source and artifact brief (35%) · essential
  Source and artifacts implement the intended task, filter and persistence design and include the actual Git/review/accessibility work.
• Source and design decisions (30%) · essential
  The state, storage, validation and accessibility decisions are explicit and internally coherent in the submitted code.
• Source analysis and check design (25%) · essential
  Trace representative input/state changes through specific code locations and propose checks for empty data, persistence and error feedback; label execution claims as unverified.
• Explanation, attribution and revision (10%)
  Explain a specific source/artifact decision and revision, attribute assistance and state the limits of what the submitted evidence establishes. Unresolved evidence gaps require clarification or optional human review.

Send the React learning-goal tracker and your TypeScript changes. Include the routes, goal editing and progress feature. Explain how the code handles missing or bad data. Show a type mistake you corrected. Describe a useful check for the progress feature and point to the code it covers. We read this work; we do not run the app or compiler for this task. Attach readable code and text files. A link or claimed test result alone is not enough. If important work is missing or unclear, we may ask for more or send it to a school reviewer.

• Source and artifact brief (35%) · essential
  The React/TypeScript artifacts address routes, editable goals and the progress interaction in the actual course brief.
• Source and design decisions (30%) · essential
  Component, state and type boundaries are clear, and handling of absent or invalid data is visible in the source.
• Source analysis and check design (25%) · essential
  The explanation traces a progress interaction and type-boundary failure to specific source locations and proposes meaningful checks.
• Explanation, attribution and revision (10%)
  Explain a specific source/artifact decision and revision, attribute assistance and state the limits of what the submitted evidence establishes. Unresolved evidence gaps require clarification or optional human review.

Make your own Frontend Capstone project for a real need, using made-up or permitted data. Send the React and TypeScript code, or enough connected sections to follow a whole feature. Include your HTML and CSS choices, accessibility notes, README, check plans and release and recovery plans. Follow one feature through the screen, changing data, types and saved data. Show a before-and-after change and explain it. Give steps another person could use to run the project. This review does not verify a live site or who wrote every line. Attach readable code and text files. A link or claimed test result alone is not enough. If important work is missing or unclear, we may ask for more or send it to a school reviewer.

• Source and artifact brief (35%) · essential
  The original source portfolio coherently integrates the HTML/CSS, JavaScript, Git, accessibility, React, TypeScript and delivery-study requirements.
• Source and design decisions (30%) · essential
  The submitted source and design explanations support the stated user need, data/state boundaries and accessible interaction choices.
• Source analysis and check design (25%) · essential
  Trace a complete representative workflow and failure path through the source; provide meaningful test and recovery plans and a before/after revision rather than claimed execution proof.
• Explanation, attribution and revision (10%)
  Explain a specific source/artifact decision and revision, attribute assistance and state the limits of what the submitted evidence establishes. Unresolved evidence gaps require clarification or optional human review.