#Muscle codes

Every muscle in the system has a short uppercase code. The catalogue mirrors Gravn's backend constants exactly - same codes, same names, same support tiers - and a test enforces that, so the two cannot drift apart unnoticed.

#Two tiers, two behaviours

Supported codes have their own geometry. They are filled directly.

Extended codes do not. Each one is aliased onto the drawn region that covers it, so passing PEC lights the chest and passing LAT lights the upper back. Callers never need to know which is which - that is the point of the indirection.

resolveToDrawnRegion("PEC"); // "CHE"
resolveToDrawnRegion("CHE"); // "CHE" - drawn codes resolve to themselves

Aliases resolve in exactly one hop. An alias never points at another alias, and a test enforces that too.

#How collisions merge

When several codes land on the same region, the highest level wins:

resolveIntensities({ UPB: 4, LAT: 9, TER: 2 }, getBodyMap("male", "back"));
// → { regions: { UPB: { left: 9, right: 9 } }, unrenderedCodes: [] }

Not the last write, and not the average. If a session hit the upper back at 4 and the lats at 9, that region was worked hard, and 9 is the honest reading of it. Merge order does not affect the result.

#Why some muscles will never be drawn

Each code carries a resolution that says how it reaches the screen, and - critically - whether it is worth ever drawing.

The deep classification is the one that saves real time. Those five muscles lie beneath other muscles and have no surface projection at all - no body map in existence renders them, because there is nothing to render. They stay aliased permanently. Do not put them on an art backlog.

The splittable codes are the genuine backlog: real, surface-visible muscles currently folded into a larger region. See Artwork for the priority order.

#Visibility

A muscle only exists on the views where the artwork draws it. Quads are front-only; glutes are back-only. Ask the geometry rather than guessing:

getVisibleViews("QUA", "male"); // ["front"]
getVisibleViews("GLU", "male"); // ["back"]
getVisibleViews("DEL", "male"); // ["front", "back"]
getVisibleViews("HEA", "female"); // ["front"]  ← note

That last one is not a bug. The female back artwork genuinely omits the head and ankles, which is what the backend's "Both (Front only for female)" annotation describes. Because getVisibleViews derives its answer from the geometry rather than a hard-coded table, improving the artwork updates it automatically.

Codes that had an intensity but nowhere to render are reported, never silently dropped:

const { unrenderedCodes } = resolveIntensities(
  { QUA: 8 },
  getBodyMap("male", "back"),
);
// unrenderedCodes === ["QUA"]

Log that in development. A value vanishing without trace is how a body map quietly starts lying.

#Coverage by diagram

Which drawn regions appear on each of the four bodies:

#The full catalogue