Goal
Make Wright identify high-frequency condition-evaluation hot paths in Ongoing - Global and Ongoing - Each Player rules, including expensive canonical operations and potentially wasteful short-circuit ordering, without turning static cost heuristics into runtime correctness claims.
Context
Workshop ongoing-rule conditions are evaluated every server tick, and conditions are checked sequentially with short-circuit behavior. Wright already detects selected expensive predicates inside explicit loop bodies, but it does not currently analyze the separate cost surface created by ongoing rule conditions themselves.
This matters because an expensive distance, raycast, array, or target-query expression in an ongoing condition can be reevaluated at tick frequency even when the action list rarely runs. The important product distinction is between condition-evaluation frequency and action execution frequency: ongoing actions do not simply rerun every tick while conditions remain true.
Scope
- Identify canonical
Ongoing - Global and Ongoing - Each Player rule conditions as per-tick evaluation paths.
- Surface expensive or scaling-sensitive canonical value operations in those condition trees when there is evidence that they are meaningful static cost indicators.
- Preserve condition order in the analysis and expose when an expensive condition is evaluated before later conditions that could short-circuit it.
- Separate exact structural facts (ongoing scope, condition order, operation presence) from heuristic cost/selectivity judgments.
- Reuse canonical Workshop identities and existing Wright evidence classes rather than introducing source-language-specific pattern matching.
- Keep findings source-provenance aware for raw Workshop and provider-backed source languages where mapping is available.
- Validate useful cases against representative real projects as well as focused positive/negative fixtures.
Non-goals
- Assuming ongoing action blocks execute every tick while their conditions remain true.
- Defining a universal minimum
Wait duration for ongoing rules.
- Claiming exact server CPU/load from static condition structure.
- Automatically reordering conditions; a later condition is not necessarily more selective merely because it is cheaper.
- Flagging every ongoing condition or every array operation as a defect.
- Moving Workshop event or value semantics into Wright.
- Adding OPY/DEL-specific semantic rules solely to recognize these patterns.
Acceptance criteria
- Wright can distinguish ongoing-rule condition evaluation frequency from action execution frequency in its analysis model and documentation.
- Supported ongoing rules report expensive/scaling-sensitive condition operations with stable source provenance and explicit evidence classification.
- Condition-order information is preserved so the result can explain which work is evaluated before which short-circuit gates.
- Any lint finding based on cost/selectivity remains explicitly heuristic or a static indicator unless independent runtime evidence justifies a stronger classification.
- Cheap/necessary ongoing conditions and reordered equivalents have negative fixtures that prevent a blanket "ongoing is bad" rule.
- At least one representative real-project case demonstrates a useful finding or metric not covered by the existing
expensive-loop-check rule.
- Existing loop analyses remain behaviorally unchanged unless a separately evidenced correction is required.
- Raw Workshop and provider-backed analysis consume the same canonical rule logic; unmapped generated evidence is not assigned fabricated source locations.
- Independent implementation ablation removes the ongoing-condition analysis and causes its dedicated regression evidence to fail again.
Dependencies / ownership
Goal
Make Wright identify high-frequency condition-evaluation hot paths in
Ongoing - GlobalandOngoing - Each Playerrules, including expensive canonical operations and potentially wasteful short-circuit ordering, without turning static cost heuristics into runtime correctness claims.Context
Workshop ongoing-rule conditions are evaluated every server tick, and conditions are checked sequentially with short-circuit behavior. Wright already detects selected expensive predicates inside explicit loop bodies, but it does not currently analyze the separate cost surface created by ongoing rule conditions themselves.
This matters because an expensive distance, raycast, array, or target-query expression in an ongoing condition can be reevaluated at tick frequency even when the action list rarely runs. The important product distinction is between condition-evaluation frequency and action execution frequency: ongoing actions do not simply rerun every tick while conditions remain true.
Scope
Ongoing - GlobalandOngoing - Each Playerrule conditions as per-tick evaluation paths.Non-goals
Waitduration for ongoing rules.Acceptance criteria
expensive-loop-checkrule.Dependencies / ownership
workshop-rsowns canonical Workshop event/value identities and exact syntax/semantic facts.