typespec1-5  Exercise 2: Which Shape for Which Operation?
===============================================================

account.tsp:

  import "@typespec/http";

  using Http;

  @service(#{ title: "Accounts" })
  namespace Accounts;

  model Account {
    @visibility(Lifecycle.Read)
    id: string;

    name: string;

    @visibility(Lifecycle.Create)
    password: string;

    @visibility(Lifecycle.Read, Lifecycle.Update)
    nickname?: string;
  }

  @route("/accounts")
  interface AccountOps {
    @post create(@body account: Account): Account;
    @route("{id}") @get read(@path id: string): Account;
    @route("{id}") @put replace(@path id: string, @body account: Account): Account;
  }

PREDICTION
  POST body (create)  : name, password. No id (read-only), and no nickname (not visible when creating).
  GET response (read) : id, name, nickname. No password (create-only).
  PUT body            : a PUT can create or update, so I expected the union of the two: name, password, nickname. No id.

Compiled; the schemas:

  components:
    schemas:
      Account:
        type: object
        required:
          - id
          - name
        properties:
          id:
            type: string
            readOnly: true
          name:
            type: string
          nickname:
            type: string
      AccountCreate:
        type: object
        required:
          - name
          - password
        properties:
          name:
            type: string
          password:
            type: string
      AccountCreateOrUpdate:
        type: object
        required:
          - name
          - password
        properties:
          name:
            type: string
          password:
            type: string
          nickname:
            type: string

WHAT HAPPENED
  Prediction confirmed on all three. The emitter named the schemas itself: Account (response), AccountCreate (POST body) and AccountCreateOrUpdate (PUT body). In Account, id is marked readOnly and nickname is optional (the model says nickname?).
  Required lists: in AccountCreate and AccountCreateOrUpdate, name and password are required; nickname is not (it is optional in the model).
Things to notice: a single model produced three schemas without my naming any of them. The names matter to anyone generating client code from the contract, so read them in the output.

WHY THIS WORKS AS AN ANSWER
---------------------------
Writing the prediction first, from the visibility lists, is the point of the exercise: the rule is simple (a property appears in a shape if its visibility includes that phase), and the output is the check. The PUT is the only surprise to people who think of PUT as 'update'.