Challenge 3: Add an Enum to the Schema — Possible Solution
====================================================================

enum PostStatus {
  DRAFT
  PUBLISHED
  ARCHIVED
}

type Post {
  id: ID!
  title: String!
  author: User!
  status: PostStatus!
}

WHY AN ENUM IS A BETTER FIT THAN A PLAIN STRING
---------------------------------------------------
- A plain String field for status would technically accept ANY text
  value at all — "published", "Published", "PUBLISHED", "live",
  "PENDING_REVIEW", or even a typo like "publised" would all be equally
  valid as far as the type system is concerned. Nothing in the schema
  itself would catch an invalid or inconsistent value being stored or
  returned.
- An enum restricts the field to EXACTLY the fixed set of values listed
  (DRAFT, PUBLISHED, ARCHIVED in this case) — any resolver or mutation
  that tries to return or accept a value outside that set gets rejected
  by the GraphQL layer itself, before it ever reaches application logic.
  This moves a whole category of "invalid status string" bugs from
  runtime application code into the schema's own validation, which is
  exactly the kind of guarantee this chapter described the schema
  providing as an explicit, machine-readable contract.
- An enum is also self-documenting in a way a String field never is —
  anyone reading the schema (or using introspection-powered tooling like
  GraphiQL's autocomplete) can see the COMPLETE list of valid status
  values directly from the type definition, with no need to consult
  separate documentation or guess at what strings the API might accept.
- This directly parallels the chapter's broader "schema-first" theme:
  choosing the most specific, restrictive type the data actually
  supports (an enum here, rather than a permissive String) makes the
  schema a stronger, more useful contract for anyone building against
  it — client code can even use the enum's members directly in
  generated types, rather than working with untyped, easily-mistyped
  string literals.