Challenge 1: Add a createComment Mutation — Possible Solution
====================================================================

// Schema additions

input CreateCommentInput {
  postId: ID!
  text: String!
}

type Mutation {
  createPost(input: CreatePostInput!): CreatePostPayload!
  deletePost(id: ID!): Boolean!
  createComment(input: CreateCommentInput!): Comment!
}

// Resolver addition

Mutation: {
  // ...existing createPost, deletePost...
  createComment: (parent, args, context) => {
    const user = requireAuth(context); // Ch.7/Ch.8 — throws UNAUTHENTICATED if not logged in

    return db.comments.create({
      postId: args.input.postId,
      authorId: user.id,
      text: args.input.text,
    });
  },
},

WHY THIS WORKS
--------------
- CreateCommentInput follows the exact same shape convention as
  CreatePostInput from the capstone's own schema — a dedicated input
  type wrapping the mutation's arguments (Chapter 4), rather than trying
  to pass the Comment type directly as an argument, which Chapter 4
  explained would fail to build.
- createComment returns Comment! directly (not wrapped in a payload
  type like createPost's CreatePostPayload) — this is a legitimate,
  simpler choice for a mutation that doesn't have a validation-heavy
  input needing structured field-level errors the way createPost's
  title-emptiness check did; a comment's only real requirement (text
  presence) is already guaranteed by the schema's String! on
  CreateCommentInput.text, so there's less need for the payload-wrapper
  pattern here.
- requireAuth(context) is called FIRST, before any comment is created —
  reusing the exact same helper from Chapter 8's own examples rather
  than writing new authentication-checking logic. This guarantees an
  unauthenticated caller can never create a comment, mirroring exactly
  how deletePost's resolver in this capstone uses requireOwnerOrAdmin
  before performing its own write.
- authorId: user.id comes directly from the authenticated user
  requireAuth returned — the resolver never trusts a client-supplied
  author ID, which would be a serious authorization gap (letting any
  caller create a comment attributed to someone else). This mirrors
  createPost's own resolver, which similarly derives authorId from the
  authenticated user rather than from args.input.
- Once created, this comment automatically becomes visible through the
  existing Post.comments resolver (Chapter 5's commentsByPostLoader) —
  no changes are needed there, since that resolver already looks up
  comments by postId regardless of when or how they were created.