v0.19.2

Added

• A judge's list items get their record fields from the input, not the
  model (#320). signature_spec.passthrough now takes a per-item form,
  items[].body: prs[number].body: the model writes each item's key
  (number) and what it decides, and code fills body from the input
  record with that key. An item whose key matches no record, several, or
  another item's fails the judge before anything downstream runs. A real
  compile's judge copied pull requests' original bodies into its output and
  the next step appended to that copy and wrote it back, so a model that
  changed a character changed the pull request. It works on every runtime
  and in the compiled skill, and the compiler is offered these pairs and
  told to use them for records a later step writes back.

Fixed

• Workflow step titles are no longer read as fields a person must send
  (#319). A section that mentioned asking the person anywhere made every
  bold list heading in it a required gate key, so a correct compile failed
  on keys like resolve_the_target and verify. A list now counts only
  when what introduces it asks the person for something and ends in a
  colon (ask the duty manager to provide:). Across the example skills
  this drops 30 false keys, including a "What not to do" list, and keeps
  ops-report's three. A procedural list whose own lead-in asks ("Confirm
  with the user before each step:") can still match, so a gate that misses
  the skill's names is now a review gap (repaired once, then a warning),
  never a failed compile.

• A login requests the OAuth scopes you configured, not the server's wider
  list (#316). On a 401 the MCP SDK replaces the requested scopes with the
  challenge's, or with every scope the server's metadata lists as
  supported, and never consults the configured ones. A login configured
  with six read-only Google scopes asked for 26, Gmail send among them,
  while the registry still showed six. rote mcp login now requests
  exactly the scopes set with rote mcp add --scope, plus offline_access
  when the server supports refresh tokens. If the server's challenge
  requires more, the login stops naming the extra scopes before any consent
  page opens. With no scopes configured, the server still decides.
  --no-wait output reports the configured and the requested scopes, read
  from the authorization URL itself.