3.4 KiB
Class Progression Feat Availability Design
Goal
Class progression wiki rows should distinguish automatically granted class feats
from level-gated selectable feats while also exposing bonus feat gains declared
by class bfeat tables in the progression table.
Ownership
The authored wiki page layout stays in sow-module/topdata/wiki/. The toolkit
owns the progression row data assembled from class feat and bonus-feat tables.
The change should stay inside those boundaries:
- module page templates decide how progression row fields are rendered;
- toolkit progression row assembly decides which feats are granted and which level-gated selectable feats become notes.
Behavior
Class feat rows with positive GrantedOnLevel values are not all equivalent.
Rows in class feat tables with List value 3 are automatically granted feats.
Rows with selectable list values such as 0 or 1 become available at the
declared level but are not granted by the progression itself.
For each class progression row:
- keep automatically granted feats in
GrantedFeats; - keep the per-level bonus feat count from the class
bfeattable inBonusFeat; - add level-gated selectable feat availability text to
Notesin the form<feat link> becomes available.; - combine multiple availability notes for the same level deterministically in source table order.
Selectable rows without a positive GrantedOnLevel remain available through
the class feat listing and do not create progression notes.
Rendering
The class progression template can render BonusFeat inline in its existing
Feats cell rather than adding another progression column. It should emit the
separator only when GrantedFeats already rendered content so bonus-only rows
do not start with a comma.
The existing Notes column renders the toolkit-generated Notes text with wiki
links enabled. The lower class feat table remains useful for listing class feat
membership and list metadata; its level label should not be interpreted as an
automatic grant for selectable rows.
Data Flow
The toolkit resolves the class FeatsTable while building progression rows.
Each resolved feat row contributes to exactly one progression-facing bucket:
List == 3and positive level: resolved feat link inGrantedFeats;- positive level and selectable list: resolved availability note for that level;
- non-positive or missing level: no progression-row contribution.
The class BonusFeatsTable lookup continues to populate BonusFeat from the
row whose id matches the progression level.
Errors And Compatibility
The change should preserve current behavior for missing class feat tables,
missing bonus feat tables, unresolved feat references, and classes without
level-gated selectable feats. Existing module templates that only read
GrantedFeats, BonusFeat, and Notes continue to use the same progression
row fields.
Tests
Toolkit coverage should verify:
- automatically granted
List == 3feats remain in progression feat output; - positive-level selectable feats are excluded from
GrantedFeats; - positive-level selectable feats render availability notes with wiki links;
- multiple notes on one level have deterministic order;
- bonus feat counts remain available to the progression template.
Module validation should rebuild the generated wiki output with the local toolkit binary after the toolkit change and inspect a class that has both granted feats and level-gated selectable feats, such as fighter.