test: InfoVarsLstTest for INFOVARS token (WIP — for review with LK)

[Vest]

Status: draft / WIP — to be analyzed together by @Vest and LegacyKing before this is ready.

Test-only PR adding coverage for the INFOVARS token. No production change: investigation confirmed what is (and isn't) implemented relative to the 2018 spec.

What matches the spec

• INFO:x|y — info name + java.text.MessageFormat. ✅
• The three load-error rules — INFOVARS name with no INFO; INFO needs vars but none provided; var count mismatch (all in InfoLst.process). ✅
• FreeMarker *.info accessor (e.g. pc.race.info.wildness). ✅
• "Global variables only" is enforced at parse time — InfoVarsLst.parseTokenWithSeparator validates each name against the global active scope via isLegalVariableID(getActiveScope(), name).

Spec divergence (the unbuilt feature)

The 2018 spec describes a scoped grammar INFOVARS:x|SCOPE=var (scope optional for default VAR). This is not implemented — INFOVARS parses bare names only; a SCOPE=var token is treated as one illegal name and rejected (verified, including the default VAR=x form). The implementation is a subset: bare global names, no scope prefix. Local-scope support needs a per-instance selector INFOVARS lacks (LK flagged getOther() as the fitting model). Deferred.

Can INFOVARS replace existing Pathfinder LST?

Conceptually yes (INFO/INFOVARS is meant to replace DESC/ASPECT/BENEFIT/SPROP), but almost none is replaceable as-is today:

Token	PF uses	with % substitution
DESC	59,808	9,770
ASPECT	9,024	2,879
BENEFIT	4,131	489

• Static (no %) DESC/ASPECT/SPROP → replaceable by plain INFO: now (no INFOVARS needed); the large majority, low-risk, but doesn't exercise INFOVARS.
• %-substitution tokens (~13k) are the real INFOVARS targets, but their variables are old-system DEFINE: (23,458 in PF) not new-system GLOBAL: (14) — INFOVARS cannot read a DEFINE: var, so these need a DEFINE:→GLOBAL: migration first (the data-team "Phase 2"). Many also embed PRExxx (INFO is unconditional by design) or math, or hit the local-scope wall — needing the deferred features.

Smallest genuine conversion (e.g. ASPECT:Ability Benefit|(%1 ft.)|JetSpeed): declare GLOBAL:NUMBER=JetSpeed, then INFO:AbilityBenefit|({0} ft.) + INFOVARS:AbilityBenefit|JetSpeed. testAspectMigrationPatternToInfoVars demonstrates exactly this end-to-end. (No shipped-data change here — migration is a separate decision.)

Data usage

INFOVARS: appears zero times in shipped data (plain INFO: ~580 in PF core, ~1332 project-wide). The feature is greenfield — no data-regression risk, no existing INFOVARS example to copy.

Tests added

• InfoVarsLstTest (unit): round-robin + invalid-input cases.
• GlobalInfoVarsTest (integration) — INFOVARS against the real formula system:
  • testInfoVarsResolvesGlobalVariable: GLOBAL-declared var referenced by INFO+INFOVARS, loads end-to-end.
  • testInfoVarsRejectsUndeclaredVariable: undeclared var rejected at parse.
  • testInfoVarsScopedFormNotYetSupported: the spec's SCOPE=var form is currently rejected (flip if implemented).
  • testInfoVarsCannotReachLocalHeadScopeVariable: LegacyKing's example — a crit multiplier in the weapon head's local PC.EQUIPMENT.PART scope is still rejected, because INFOVARS resolves against the global scope with no per-instance selector.
  • testAspectMigrationPatternToInfoVars: the ASPECT→INFOVARS conversion (GLOBAL + INFO/INFOVARS) loading end-to-end.

How to use INFOVARS in LST today

# declare a global variable (in a *__variables.lst datacontrol file)
GLOBAL:NUMBER=NumFiles

# reference it (bare name — no scope prefix)
Dodge   INFO:FileCount|There are {0,number,integer} files.   INFOVARS:FileCount|NumFiles

Wiki reference: https://vest.github.io/pcgen-wiki/formula-system/INFO%20and%20INFOVARS.html