Files
Integration-kit/template/server/swagger/doc.js
wtclaude 7875848ee7 feat(kit): the two shapes Teams added, taught and built
MODULE_API 1.6.0 expands the contract this book teaches against, so the book
owes two shapes and one correction. Chapter 2 gains both and the template grows
a working version of each, because a reader following a snippet has no way to
find out whether it runs.

ONE SENTENCE WAS WRONG. Chapter 2 said, of extension slots, "Only core may
declare a slot; a module may only fill one". 1.6.0 inverted exactly that: a
module declares a place on its OWN page and core fills it. That is not a stale
detail - a new game's module cannot implement Teams at all without the inverted
direction, so it is the shape the reader needs and did not have.

THE TWO SHAPES

- The inverted slot. A new "Slots go the other way too" section: why the
  direction has to invert (core owns the Team, not the word for one), the
  namespace rule, one slot per PLACE, the optional { core } naming which of
  core's three contributions goes there, and why asking for one core does not
  offer throws when almost everything else in that registry fails open.

- registerTeamProvider, in "Becoming the source of Teams". The first
  registration where core calls YOU and waits, which is where every rule in it
  comes from: the envelope, the ten-second budget, refusing as a normal answer,
  and the one mistake worth naming - answering with an empty list because the
  game is unreachable, which core reads as authoritative and acts on.
  projectRoster gets its own treatment because it is the exception that fails
  CLOSED. pageUrlTemplate is a footnote beside it, as intended.

WHAT THE TEMPLATE GREW

model/clans/ - the provider over two tables, with the guards that matter: an
unreachable game refuses rather than reporting no clans, an empty roster is
refused unless the game says the clan is empty (which is why the schema keeps a
member count the rows cannot supply), and the audience rule lives in one file
that both projectRoster and the module's own page consult, because a second copy
drifts in the direction that publishes what core is withholding.

Its own /clans routes, deliberately not /teams - core mounts that itself, and
the loader would refuse the collision. A clan list page and a clan page that
declares three slots for core.

12 provider tests and three registration tests, 47 server and 20 client in
total. The purge test finally proves something: two of the three tables are now
a parent and its child.

WHAT IT DOES NOT DO. Enumerate the contract. The kit teaches one path end to end
and links out; it has never mentioned three pre-Teams registrations and that is
the design, not a gap.

FOUND WHILE WRITING IT: core filled three literal uo.guild.* slot names, so the
inverted direction reached exactly one module and every other game's page came
up empty with nothing logged. Fixed in website#160 / Module-uo#15 / docs#165
before this chapter could teach it - which is what this phase is for.

The ci/core-ref.json pin moves in a later commit on this branch: checkCoreApi is
an equality against a core on main, and 1.6.0 does not reach main until the
cutover.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-19 01:21:55 -05:00

106 lines
4.6 KiB
JavaScript
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

// ── The OpenAPI fragment: the shared half ─────────────────────────────────
//
// The tags and component schemas your `#swagger.*` annotations refer to.
// `scripts/swaggerFragment.js` feeds this to swagger-autogen; the per-endpoint
// detail lives beside each route, exactly as it does in core.
//
// **Two rules about names, and both belong to the MERGED document rather than to
// this file** (MODULE_API.md §6.1a). Core merges every started module's fragment
// over its own spec and serves the result at `/api/docs.json`, and core wins any
// key collision:
//
// • **Namespace what you DEFINE.** `ExamplegameWorldStatus`, not `WorldStatus`.
// A second game's module describing the same idea under the same bare name
// would silently clobber yours or be clobbered by it. The prefix is what
// makes two modules able to coexist.
// • **Reference what CORE defines by core's name.** `#/components/schemas/Error`
// and `ValidationError` are core's; point at them and do not redefine them.
// They resolve in the merged document, where core's definitions are. Shipping
// your own copy is a collision core drops — which is the right outcome, and
// an expensive way to learn it.
//
// A tag is how the docs UI groups operations. Name yours after your module so an
// operator reading `/api/docs` can see which operations arrived with it.
//
// **swagger-autogen renders `components.schemas` from an EXAMPLE object, not from
// raw OpenAPI.** `{ type: 'object' }` comes back as a meta-description of itself.
// That is uniform across core's committed spec and is the house shape — match it,
// do not fight it.
module.exports = {
tags: [
{
name: 'Public · Example Game',
description: 'Live world data and the games clans, as last reported by the game server',
},
],
components: {
schemas: {
ExamplegameWorldStatus: {
type: 'object',
description: 'The game worlds status (GET /public/world/status).',
properties: {
online: { type: 'boolean', example: true },
players: { type: 'integer', example: 12 },
worldName: { type: 'string', nullable: true, example: 'Example World' },
updatedAt: { type: 'string', format: 'date-time', nullable: true },
stale: {
type: 'boolean',
description: 'Has nothing reported in longer than the freshness window? A stale row is reported offline.',
example: false,
},
},
},
ExamplegameClanList: {
type: 'object',
description: 'Every clan the game has reported (GET /public/clans).',
properties: {
stale: { type: 'boolean', example: false },
clans: {
type: 'array',
items: { $ref: '#/components/schemas/ExamplegameClanSummary' },
},
},
},
ExamplegameClanSummary: {
type: 'object',
properties: {
externalId: { type: 'string', example: 'clan-1' },
name: { type: 'string', example: 'The Gilded Company' },
abbr: { type: 'string', nullable: true, example: 'GC' },
memberCount: { type: 'integer', example: 3 },
},
},
ExamplegameClan: {
type: 'object',
description: 'One clan and the roster this viewer may see (GET /public/clans/{externalId}).',
properties: {
externalId: { type: 'string', example: 'clan-1' },
name: { type: 'string', example: 'The Gilded Company' },
abbr: { type: 'string', nullable: true, example: 'GC' },
memberCount: { type: 'integer', example: 3 },
projected: {
type: 'boolean',
description: 'Was the audience rule answered? False means the roster was withheld because the question could not be resolved — which is a different thing from a clan with no members.',
example: true,
},
members: {
type: 'array',
description: 'Deliberately carries no member key and no linked account id. Both exist and both go to core on the Team providers envelope; neither belongs on a public page.',
items: { $ref: '#/components/schemas/ExamplegameClanMember' },
},
},
},
ExamplegameClanMember: {
type: 'object',
properties: {
displayName: { type: 'string', nullable: true, example: 'Aldric' },
rankLabel: { type: 'string', nullable: true, example: 'Warlord' },
leader: { type: 'boolean', example: true },
online: { type: 'boolean', example: true },
},
},
},
},
}