Adding a Mechanic

The procedure, in the order that avoids rework.

1 · Write the mechanic. GM Brain/Mechanics/. Deep reference, as long as it needs to be. Nothing will read it whole and that is fine.

2 · Write the card. GM Brain/Cards/, target around six hundred tokens. Thresholds, the procedure in order, the exact schema fields to write. Close with a Deep: footer naming the mechanic.

3 · Declare the state. Whatever the mechanic tracks needs somewhere to live. A declared schema field if it is durable and typed; moduleState if it is free-form. A field written at the top level that the schema does not declare is silently discarded — no error, and it is gone by next session.

4 · Wire the route in. Named by the Ladder, named by a card that already loads, named by a phase file, or fired by a trigger. Pick one and confirm it. This is the step that gets skipped.

5 · Wire the route out. Decide what routinely reads the state you just created. A field nothing consults is dead weight the GM pays for on every write.

6 · Give it an audit hook. Fold one line into an existing check on @Missing file rather than lengthening the list. Mechanics without an audit hook rot quietly, and the list is already long enough that a new entry at the bottom is a new entry nobody reaches.

If your mechanic touches a roll

This is the part that predates most people's mental model of the system, and getting it wrong produces a mechanic that either does nothing or double-counts. @Missing file is the authority; the shape of it is this.

Every table's modifier list is a closed loop. A d100 table's +15 and a d20 table's +2 are not the same unit, so there is no second currency you can introduce to connect them. Do not invent one.

The Collision Line — one outside factor, never more. If exactly one thing outside the table is unusually relevant this roll, classify it Minor, Moderate or Major and apply it at that table's own smallest, middle or largest listed modifier, in the same direction the table's own entries already use. Never invent a number. Never stack two. It caps at one on purpose: a check that has become an accounting exercise has stopped being a check.

It applies to every table in every mechanic. Some tables close with an Outside factor (cap one) line and most do not — that line is a reminder, never a switch. Read its absence as silence, not as exemption.

A standing dependency is a printed row, not an outside factor. This is the distinction most new mechanics get backwards. If a modifier reads another system's live state on every roll of your table, it is part of your table: print it in your own modifier list like any other row. Weather closes a road on every delivery, not on the interesting ones. A standing row spends none of the Collision Line's budget, so a table may print two of them and still close with Outside factor (cap one).

Three rules keep standing rows honest. Read the value, do not re-derive it — name the field and take the level already set, or your table produces a different crowd than the one the player is standing in. Never print a value derived from another value you are also printing, or one storm gets counted twice. Never print a constant — a modifier that always applies is not a modifier, it is the calibration.

Two standing rows is the ceiling. A third is the accounting exercise.

Constraints worth knowing before you start

TRIGGER BODIES   499 characters, tools as well as narrative triggers.
                 One over-length body rejects the entire push batch.
NARRATIVE SLOTS  no documented platform cap. Adding one is a reachability
                 and standing-load argument, not a scarcity one — every
                 body present is evaluated on every turn.
ENUM VALUES      must match the schema exactly. A card telling the GM to
                 write `Standard` into an enum of `standard` is rejected
                 and the data is gone, with no error anywhere.
COMPUTED FIELDS  never write a value into one. It is stripped on the way
                 to the server, and expressions read field names that no
                 validator confirms still exist.

Reuse before you add. Most "new mechanics" are a paragraph in an existing card and a field that already exists.