Full Stack Developer

Send the resource-directory server code, database tables, migrations and queries. Use made-up records. Explain how the records connect and show the planned replies for valid and bad requests. Follow one of each through the input checks and SQL. Describe useful checks and explain one database choice. A written claim that the service ran is not proof that it did. 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 source and schema address the authored resource-directory entities, API routes and relational queries.
• Source and design decisions (30%) · essential
  Relationships, validated boundaries, parameter handling and response/error design are explicit and coherent in the submitted artifacts.
• Source analysis and check design (25%) · essential
  Trace representative requests and queries through the source and state expected results and failure cases without representing them as verified execution.
• 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 private-notes server code and access rules. Use two made-up accounts. Make a table showing what each account may read or change. Point to the code that checks identity and ownership. Follow a request from the wrong account and explain where it is refused. Include signed-out and bad-input cases. This is a review of your code and reasoning, not a security test of a running service. 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 API and rule artifacts cover the actual private-notes brief and both fictional account roles.
• Source and design decisions (30%) · essential
  Identity, ownership, validation and denial paths are visible at the server/data boundary rather than only in UI controls; explain any remaining uncertainty.
• Source analysis and check design (25%) · essential
  Use a source-linked access matrix and negative test designs to reason about signed-out, other-account and malformed requests; do not treat supplied pass claims as verification.
• 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 private learning journal code, database plan and sign-in and ownership rules. Follow an entry from the screen to the server and database, then back to the reader. Explain which code runs in the browser and which runs on the server. Compare the owner, another account and a signed-out visitor. Include error states. We review the code and design; we do not check a live sign-in session. 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 source portfolio addresses the actual authenticated-entry and journal workflow brief.
• Source and design decisions (30%) · essential
  The server/client, identity, ownership and data-handling boundaries are explicit and consistent across the supplied artifacts.
• Source analysis and check design (25%) · essential
  Trace allowed, signed-out and other-account cases with source locations and expected decisions; identify what requires future independent execution.
• 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 your Full Stack Capstone project for a private learning or community app. Use made-up accounts. Include the user brief, screen, server and database code, migrations, access table, input checks and check plans. Add a release and restore plan and handover notes. Follow one whole feature and one refused cross-account request through the code. Show a small change and explain its effect. This review does not prove that a live app is secure or correctly deployed. 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 integrated artifacts connect Node/API, relational data, access-rule, Next.js and full stack capstone study around one original application brief.
• Source and design decisions (30%) · essential
  Identity, authorization, validation and server/client design are explicit and coherent across the submitted source and schema.
• Source analysis and check design (25%) · essential
  Source-linked workflow/denial traces, negative test designs, migration/recovery plan and a documented revision provide reviewable reasoning without unsupported runtime claims.
• 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.