Characters

character is the one file type in this project meant to be played, not just looked up — it's the only type carrying designation: "character", and the only type with reference fields wired into three other types at once. Get a character file right and everything else in the SRD (skills, spells, equipment) shows up on the sheet automatically; get the references wrong and the sheet renders empty cards where lists should be.

The skeleton

A character has five families of field:

• Identity — name, image, concept, culture, species, free-text background, description, personality, notes.
• Characteristics — the seven fixed values (strength, constitution, size, dexterity, intelligence, power, charisma) under characteristics. These match <@Characteristics and Attributes.md> in the Player's Handbook exactly — do not add an eighth Characteristic here without also deciding what it means for every formula downstream (Damage Modifier, Hit Points, Initiative all key off the existing seven).
• Attributes — the derived numbers under attributes (initiative, luckPoints, healingRate, magicPoints, actionPoints, movementRate, damageModifier, experienceModifier) and per-location max Hit Points under hitLocations. These are stored as plain numbers/strings, not computed fields — see the note on computation below.
• References — skills (array of skill slugs), powers (array of spell or power slugs — this field accepts either type), inventory (array of equipment slugs).
• Free text — background, description, personality, notes, each rendered as its own optional section, shown only when non-empty.

Populating the reference fields

skills, powers, and inventory are schema-annotated reference fields, not plain strings — write them as the target file's readable slug (e.g. "athletics", "heal", "longsword"), not an invented ID. Because powers accepts two different target types (spell and power), disambiguate with a qualified slug when a name could belong to either — "spell/heal" or "power/flight" — rather than a bare slug; an unqualified bare slug that matches files in both folders stays a draft reference instead of resolving.

A few practical rules that keep the sheet actually useful:

• Only list skills the character has trained — a Standard skill every human has by default doesn't need to appear unless it's been raised above base value or the table wants it visible for play.
• powers is empty for characters with no magic or superpowers — leave it as an empty array rather than putting "None" in notes; the Spells & Powers card just won't render if it's empty.
• Equip what's carried, not everything owned. inventory drives the Inventory grid on the sheet; a warhorse stabled three towns back doesn't belong there.

Attributes are entered, not derived

Unlike some systems you might expect, attributes and hitLocations on a character are plain typed fields, not expressions computed from characteristics. That's a deliberate simplification for this SRD: Mythras Imperative's derivation tables (Damage Modifier from STR+SIZ, Hit Points from CON+SIZ per location, Initiative from the DEX/INT average) are read straight off the tables in <@Characteristics and Attributes.md> and hand-entered when a character is built or leveled, matching how a player fills in a paper sheet. If you want these fields to auto-recalculate from characteristics instead, that's a schema change — see Extending the System for how computed fields and load() work, and be sure every existing character file still has sane values after you make attributes computed (computed fields are read-only on write, so you'd need to re-derive rather than re-enter them).

Layout notes

The generated layout groups Basics and Attributes side by side, then Characteristics, Max Hit Points, Skills, Spells & Powers, and Inventory as their own cards, with Description/Background/Personality/Notes as collapsible sections that only appear when filled in. If you add a new field to the schema, decide deliberately whether it belongs on an existing card (add it to that card's FieldList/StatGrid items) or needs its own — don't leave a new field invisible by forgetting the layout side entirely. See Extending the System for the general workflow.