Comment by mitander

Yeah, I think this is the real danger with this kind of approach: mistaking a useful pipeline for a universal mechanic language.

I’m not trying to build a PoE solver or make every future mechanic fit a clean algebra. The compiler analogy is smaller: authored content emits facts, rows keep provenance, caches are rebuilt in a known phase, and combat consumes the resulting runtime data.

The part I want to avoid is common mechanics becoming direct skill/support/item/status branches inside every skill implementation.

But I agree the weird cases need escape hatches. Some rules should probably be explicit hooks, and some unique mechanics may just deserve custom resolution code.

The interesting design question to me is where to draw that line: what belongs in the boring fact pipeline, and what should stay as hand-written mechanic code?