v1.24.0

frontend-production-engineer v1.24.0

One handoff. references/openapi-schema-and-codegen.md owns the OpenAPI schema
as the one source of the frontend types, and its "What the backend publishes"
table enumerates DRF with drf-spectacular, DRF with drf-yasg, django-ninja, a
schema a person wrote, and no schema at all. Every row assumes one backend
runtime. A Django system that runs a FastAPI service beside it publishes two
documents, and the file had no route for that case. No domain is added, and the
router, the domain roster, and the frontmatter description are unchanged.

Why it matters

The two documents are not in the same dialect, and the difference reaches the
generated types.

• FastAPI 0.141.1 emits "openapi": "3.1.0" and renders an optional string as
  {"anyOf": [{"type": "string"}, {"type": "null"}]}.
• drf-spectacular 0.30.0 emits "openapi": "3.0.3" and renders the same field
  as {"type": "string", "nullable": true}.

A client generated from the DRF document carries nothing for the FastAPI
surface. The nullable-field guidance in
references/boundary-validation-and-api-types.md is written against the 3.0
spelling throughout, so the 3.1 form of that same field arrives in a shape
those rules do not describe.

What changed

references/openapi-schema-and-codegen.md gains one entry in its ## Handoffs
list. A second backend runtime beside Django, and the two OpenAPI documents
that reach one client, now route to fastapi-alongside-django. That skill
reconciles the two dialects. This file keeps what the frontend generates from
each document.

Verification

Both repository workflows pass on the finished tree: 73 reference files, every
link resolving, no orphan, balanced code fences, SKILL.md at 211,569 of the
215,040 bytes allowed, and the frontmatter description at 1013 characters.