sparkengine-research-frontier-and-methodology

First grep the SparkEngine, SparkEditor, GameModules, and Tests trees to confirm the capability does not already exist. Then write a wiki/research page with a strong, plausible, or considered-and-skipped verdict, an effort estimate, and the exact files where the work would land.

Implement Spark::IBenchmarkScenario and register it with BenchmarkFramework, or run the full-engine load test in Tests/TestEngineLoadTest.cpp. Compare A/B results only on the same machine, build configuration, and commit, and record all three in the write-up.

Work progresses through idea, prototype, candidate, implemented, tested, CI-enforced, and release-ready states. Each promotion requires specific in-repo evidence such as wiring checks, passing ctest entries, or a required CI job, and release-ready is never self-awarded.

Do not use it when actually implementing a subsystem, wiring dependencies into CMake, publishing documentation, or issuing release verdicts. Those tasks route to the domain, build-ci, docs, and change-control sibling skills respectively.

Check for banner comments marking STUB headers, Initialize() returning false, and whether tools/check-wiring.sh sees a real caller. Compiling and linking is not evidence of capability, and stub or experimental labels must not be upgraded in research write-ups.