# Currency Wars route continuation audit

The captured route 2801 contains these node types after the first boss:

| Chapter | Sections in order |
| --- | --- |
| 2 | CampMonster, Supply, EliteBranch, Monster, Boss |
| 3 | CampMonster, Supply, EliteBranch, Monster, Boss |

These names are joined from `CurrencyWarsCatalog.json` stage routes and
`CurrencyWarsReferenceNodes.json` templates. They describe the template, not
necessarily a run's dynamically substituted node display.

`cwAdvanceRouteNode` now creates a captured empty Supply container and uses
`cwGenerateReferenceEnemyLayer` for other destinations. The enemy factory
accepts Boss, CampMonster and Monster; it still rejects EliteBranch. The
Monster factory uses the explicit replacement-camp policy documented in
`currency-wars-route-factory.md` because the old run's neutral camp is not
present in its saved protocol data.
Consequently a successful 2-1 battle does not establish that 2-2 or later
rooms can be played. Constructing the remaining node layers, pending
actions and rewards needs their corresponding native/reference rules and a
current-Client check; copying the first Supply's randomized inventory would not
prove the later rooms correct.

`cwCapturedSupplyLayer` derives the empty Supply node container from the
revision-bound transition capture and validates that it has no camp or enemy
branches. It neither copies the captured option list nor modifies a run. It is
now connected to route advancement. The generated RoundBegin path creates a
Supply offer from captured role variants and equipment. SupplyBox is not
implemented. Automated offer
generation checks pass; the new route is not yet verified in the Client.

## Updated FFGO Supply evidence

The user-supplied reference binary has SHA-256
`00a75ef82614977d951250705250c6ad478ef7cdde717c761f0c70244a84ed10`.
Its `gfPendingSupplyOf` reads the run rules `SupplyRarity`, `SupplyStar`,
`SupplyEmblems`, and `SupplyBox`. `gfPendingFillSupplyOptions` reads
`GridFight_BaseSupplyRoleNum`, draws roles and selects equipment from `Basic`,
`Craftable`, or `Emblem`, depending on the chapter and rules. These names were
resolved from the reference binary, not inferred from the earlier dump.
`gfFxHProjectRunState` also projects `ExtraSupplyOption` into the additional
option count consumed by `gfPendingFillSupplyOptions`; the generated offer
uses the saved run rule and checks the combined count before drawing.

The updated reference also calls `gfPendingApplySupplyEquipChance`, which
reads `SupplyEquipChance`, `SupplyEquip`, and `SupplyEquipChapter`. When the
conditions match, it can replace equipment in one randomly selected option.
The generated offer uses saved run rules and validates replacement items
against captured equipment. Pool accounting and all run modifiers need more
comparison; later node families still need implementation and Client checks.

When a Supply selection has no captured next-node transition,
`cwSelectSupply` now delegates to the generated route factory on the same
detached transaction and preserves finish/unlock/level/pending notification
order. The existing captured path remains unchanged. This removes the separate
capture-only restriction after a generated Supply choice, but the factory
still rejects unsupported destination families, including the EliteBranch
following 2-2; the selection remains uncommitted until that family is
implemented. No Client run has exercised this fallback.

For a selected Encounter branch, the battle settlement now grants supported
gold, EXP, or item rewards when the reported progress reaches the branch's
threshold, using the selected server-side drop list on the detached snapshot.
Unmapped reward types fail without committing. Perfect-clear monster Orb
generation is not implemented; Client verification is still outstanding.

The native captured Encounter at route 2801 chapter 1 section 4 contains two
branch displays, each with its own penalty, monster wave and `BOAMLLHPNEC`
drop. A read-only check of the saved run at chapter 2 section 1 generated its
next Supply node and four choices on a detached copy; the saved run was not
written and no Client interaction was performed. The latest FFGO's
`gfRouteFillEliteBranch` constructs branch IDs from the node template's first
parameter and option kind, resolves difficulty through
`gfRouteEliteBranchDifficulty`, and builds the reward in
`gfRouteEliteOptionReward`. These are useful evidence, but matching the later
branches to this Client's option, penalty and difficulty data remains open.

After the final node, `cwAdvanceRouteNode` returns `CW route has no next node`.
At zero HP, `finishCurrencyWarsBattle` returns `CW defeat settlement requires
terminal-run handler`. Neither path currently settles the run. FFGO's extracted
descriptor names settlement reasons Quit=1, HpZero=2, and Finish=3; the current
Client's obfuscated enum has matching numeric slots, but only Quit=1 has been
confirmed for the current implementation. The reference `gfSettleSend` builds
and archives a settlement record before sending the settlement notification.
The names and fields of its rank/reward/archive components must be mapped to
the current Client before a completion handler can safely persist rewards and
clear the active run. No saved run has been modified by this audit.