BranchValidation.h header

enum class BranchProblemKind { NoStartNode, StartNodeMissing, Unreachable, DeadEnd, ChoiceWithoutOptions, ConditionWithoutVariable, ConditionVariableMissing, ConditionExpressionInvalid, EffectWithoutVariable, EffectVariableMissing, EffectSourceVariableMissing, EffectTypeMismatch, JumpTargetMissing, JumpSceneMissing, JumpTargetNotAnEntryPoint, LinkEndpointMissing, LinkConditionInvalid, SpeakerMissing, EmptyText }

What is wrong with a branching scene.

std::optional< BranchProblemKind > ew::app::branching::branchProblemKindForRuleId(QStringView ruleId)

The problem kind ruleId names, or std::nullopt when it is not a branching rule id.

How a surface gets back to a compiler-checked switch. A finding carries a rule id, which is a string and therefore cannot be exhaustively matched; going back through the enum means adding a kind still fails to build until every surface has been taught what to say about it.

std::optional< BranchProblemKind > ew::app::branching::branchProblemKindFromToken(QStringView token)

Parses a problem kind from its serialization token; std::nullopt if unrecognized or absent.

QString ew::app::branching::ruleIdFor(BranchProblemKind kind)

The rule id findings of kind carry – "branch/unreachable".

QString ew::app::branching::toToken(BranchProblemKind kind)

Returns a stable, untranslated token for kind, for tests and diagnostics.

Not tr()'d: this library carries no UI, and the desktop translates at its own layer, exactly as it does for every other core- and app-produced string.

std::vector< ew::app::diagnostics::Diagnostic > ew::app::branching::validateScene(const ew::core::branching::BranchScene &scene, const ew::core::project::Project &project)

Everything wrong with scene, in a stable order: scene-level findings first, then per-node findings in the scene's own node order.

Every finding names the SCENE in its subjects – the object a reader would open – and puts the node id in its anchor, so the branching panel can select the exact node while the Conflicts dock, which knows nothing about nodes, can still list it and jump to the scene.

project supplies the variable declarations a condition's variable is checked against; a scene validated without one simply cannot report ConditionVariableMissing.

Reachability is computed forwards from the start node and every declared entry point, following links and a jump's target. Walking forwards is the only definition that matches what a reader experiences: a node with incoming links from other unreachable nodes is still unreachable, which counting incoming links would miss.

The entry points are why the finding survives cross-scene jumps. A node another scene jumps into has nothing leading to it inside its own scene, so a walk from the start node alone would report every cross-scene destination as orphaned prose – and a finding that is usually wrong is one nobody reads. Seeding from the declarations keeps it honest in both directions: a node that is neither reachable nor declared is still reported.