Skip to content

Crafting — Validators

Folder Overview

This folder contains runtime components that implement ICraftingValidator.

Validators participate in the preflight pipeline and can adjust or reject crafting attempts before a job is accepted.

What Lives Here

  • implementations of ICraftingValidator
  • policy rules applied during preflight evaluation

Purpose

Validators provide a way to:

  • block crafting attempts based on custom rules
  • adjust preflight results
  • override failure reasons for reporting

They operate on CraftCheck and do not perform side effects.

Usage Guidance

Contract

public interface ICraftingValidator
{
    CraftCheck Validate(ref CraftContext ctx, in CraftCheck proposed);
}
  • proposed contains the current preflight result
  • validators may reduce maxCrafts and override the reason
  • results are clamped by the service after evaluation

Execution Behaviour

  • validators run after core preflight checks when not short-circuited
  • collected from owner and parent hierarchy
  • evaluated in a service-defined order

Validators may not run if preflight exits early.

Important Notes

  • validators do not bypass core input, currency, or space checks
  • behaviour depends on service configuration and pipeline rules
  • validators should be allocation-free and side-effect free

Not for Production Use

Validators decide whether a craft may start, not what happens next

This folder does not include:

  • execution logic
  • inventory or currency operations
  • job lifecycle management
  • Crafting Context (data passed to validators)
  • Crafting Contracts (preflight results and failure reasons)

Included Validators

  • CooldownValidator — enforces cooldown between crafts
  • LevelGateValidator — blocks crafting below required level

Those two are the whole shipped set. A third entry here once listed an AllowWithoutSpaceValidator as an "example override"; no such type has ever existed in the package, so it is removed rather than written — a validator cannot grant space the routing stage has already refused.

Design Notes

  • validators are a policy layer
  • operate on data, not systems
  • subject to service short-circuit behaviour

If additional behaviour is required, implement custom validators or use other extension seams.