Self-registration extension primitive and completeness mandatory guard test method

Abstract

The application discloses a self-registration extension primitive and completeness mandatory guard test method, and relates to the technical field of computers. The method comprises the following steps: configuring an extension point as a self-contained source file; configuring all self-contained source files of a directory where the extension point is located as binary files through directory-level compilation, and configuring an anti-dead-stripping anchor function for the binary files corresponding to each category of extension points; setting a full-amount registration function family and multiple anti-dead-stripping anchor functions to be triggered at the same entry on different startup paths; taking a live registration table full set of the global registration table as a traversal starting point in the construction period, checking the completeness of predefined mandatory pairs for each entry of the live registration table full set; and if the completeness is missing, determining the test result as a test failure. According to the application, a mandatory integrity guarantee closed loop is constructed, which is not dependent on specific programming languages, discovery mechanisms or guard granularity, and is suitable for various systems requiring continuous security extension primitive closed sets.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a method for testing self-registered extended primitives and completeness mandatory guards. Background Technology

[0002] The underlying primitives of the engine (actions, conditions, components, visual constructors, validation rules, etc.) can form a finite, exhaustive, and fully implemented and tested closed set. The completeness and decidability of load-time validation are built upon this closed set. However, as this closed set is continuously expanded by human engineers and artificial intelligence, each new primitive added can cause its supporting components (parser, executor, semantic validation, behavior probe, documentation, cross-layer bridging copyer, entity reference resolver, etc.) to be silently overlooked, leaving implicit gaps in the closed set that result in runtime inconsistencies.

[0003] Specifically, the necessary components for new primitives are silently omitted, creating runtime gaps that are difficult to detect during the load phase. For example, a new action primitive may be correctly registered with its name and parameter specifications, passing load-phase checks, but it may lack a corresponding behavior probe to verify whether it actually performs its claimed action during execution; a new getter function may be registered but lack the evaluation slots required by its return type; a new component may lack a corresponding scene graph copier. These omissions will not trigger compilation errors or be detected during load-phase checks because the load phase only checks if the name is in the closed set and if the parameter types are correct, not whether the primitive itself has been fully implemented and tested. This gap is only exposed when a configuration using the primitive is generated and the runtime path happens to be reached; however, by then, it has already caused an online crash or a silent error.

[0004] Furthermore, the centralized registry itself becomes a bottleneck and source of conflict for extensions. If all primitives are registered in a central table, this central table must be modified every time a primitive is added, leading to frequent conflicts on this table when multiple extensions are developed in parallel. Moreover, when extending the engine, it is easy to add a new file but forget to register a line in the central table, resulting in the new primitive not being discovered by the engine.

[0005] Furthermore, it's possible for the same primitive family to be registered on two startup paths, but only one path is loaded. A real engine typically has two executable entry points: the command-line validator (CLI binary) and the game runtime service (game server binary). If the registration trigger of a primitive family is only attached to one of the startup paths, then that primitive family will appear as "empty in the registry" on the other startup path; that is, the command-line validation passes, but it cannot be found in the runtime service, or vice versa. This "single-path registration" does not produce any compilation errors and is the most insidious type of defect.

[0006] Furthermore, there's the issue of linker dead code stripping discarding self-registered files that aren't explicitly referenced. The mechanism for self-registered dependent files' scopes of static objects is to append themselves to the global registry when constructed before the main function. However, if a compilation unit has no symbols explicitly referenced externally, the linker's dead code stripping will discard it along with its static constructor, preventing registration from ever occurring.

[0007] The information in the background section is merely intended to illustrate the general background of the invention and should not be construed as an admission or implication in any way that such information constitutes prior art known to those skilled in the art. Summary of the Invention

[0008] To address at least some of the technical problems in the prior art, this invention provides a method for testing self-registered extended primitives and completeness-enforced guards. Specifically, this invention includes the following:

[0009] A first aspect of the present invention provides a method for testing self-registered extended primitives and completeness mandatory guards, comprising: The extension point is configured as a self-contained source file, wherein the self-contained source file is added to the global registry through static initialization of file scope; By compiling at the directory level, all self-contained source files in the directory where the extension point is located are configured as binary files, and a dead-prevention stripping anchor function is configured for the binary file corresponding to each category of extension point. The dead-prevention stripping anchor function is explicitly called on the startup path. Set the full registration function family and various anti-dead stripping anchor point functions to be triggered by the same entry point on different startup paths; During the construction phase, the live registry set of the global registry is used as the starting point for traversal, and the completeness of predefined forced pairs is checked for each entry in the live registry set. If any of the completeness requirements are missing, the test result will be determined as a test failure.

[0010] According to the present invention, the forced pairing is set according to the extension point category, including forced pairing of action verb extension points, forced pairing of value function extension points, forced pairing of ECS system extension points, forced pairing of declarative component extension points, and forced pairing of entity reference fields. The mandatory pairings for action verb extension points include low-level parsing and dispatching fixtures, as well as high-level semantic behavior probes; The mandatory pairing of the getter function class extension point includes fixtures, evaluation slots implied by the return type of the getter function, verification paths reachable from the public call plane via reverse call mapping, and mutual exclusion constraints that the getter function and the engine's set of closure operators do not intersect. The mandatory pairing of ECS system class extension points includes unique and non-empty meta-constraints, acyclic and topologically sortable constraints in the directed graph formed by inter-system dependencies, and constraints on the fixed cross-layer order of the acquisition layer, core layer, and push layer. Forced pairings for declarative component class extension points include scene graph bridge copiers; The mandatory pairing of entity reference field class extension points includes a tag parser.

[0011] According to the present invention, after triggering the full registration function family and multiple anti-dead stripping anchor point functions at the same entry point, the method further includes: Enumerate the same registry entries using different startup paths; Determine if the enumerated set of entries is consistent; If there is a discrepancy, the test is considered a failure.

[0012] According to the present invention, before verifying the completeness of predefined mandatory mating parts, the method further includes: Construct examples of mandatory matching parts that are intentionally misclassified or intentionally lack completeness; Determine whether the test result for the completeness of the sample is a test failure; If the completeness test result is not a test failure, then the negative self-test is judged to have failed.

[0013] According to the present invention, if the completeness is missing, the test result is determined to be a test failure, including: The coverage ratio is determined based on the proportion of entries with complete mandatory matching parts to all entries. Set a ratchet floor value that does not decrease; Determine whether the coverage ratio is not lower than the ratchet floor value; The ratchet floor value is adjusted upwards as the coverage ratio increases; If the coverage ratio falls below the ratchet floor value, the test is considered to have failed.

[0014] According to the present invention, when verifying the completeness of predefined mandatory pairings, an exemption set is set, each exemption entry in the exemption set is accompanied by a written reason, and each entry in the exemption set corresponds to an extension point in the directory where the extension point is located.

[0015] According to the present invention, if the actual behavior of the extension point occurs in the bridging system of the rendering backend, the specification description visible in the command line of the extension point carries a convention substring, which indicates that the behavior of the extension point is implemented by the bridging system.

[0016] According to the present invention, the extension point includes multiple in-situ registration blocks within the same source file, and the in-situ registration blocks include the parser registration block, execution function registration block, parameter reduction registration block, semantic verification function registration block, and behavior probe fixture registration block of the extension point.

[0017] According to the present invention, the static initialization of the file scope can be implemented in any of the following ways: static initialization object, compile-time constant expression table, compile-time code generation; The directory-level compilation can be implemented using any of the following methods: directory-level compilation of the build system, compile-time reflection, or build script pattern matching; Verifying the completeness of predefined mandatory pairs includes: verification once per type of registry configuration, verification once per entry configuration, or hierarchical combination verification.

[0018] A second aspect of the present invention provides a self-registering extended primitive and completeness mandatory guard testing system, comprising: The first configuration module is used to configure the extension point as a self-contained source file, wherein the self-contained source file is added to the global registry through static initialization of file scope; The second configuration module is used to configure all self-contained source files in the directory where the extension point is located as binary files through directory-level compilation, and to configure an anti-dead stripping anchor function for the binary file corresponding to each category of extension point. The anti-dead stripping anchor function is explicitly called on the startup path. The configuration module is used to set the full registration function family and various anti-dead stripping anchor point functions to be triggered by the same entry point on different startup paths; The completeness module is used to check the completeness of predefined mandatory pairs for each entry in the global registry full set during the construction phase, starting from the live registry full set. The result module is used to determine the test result as a test failure if the completeness is missing.

[0019] Technical Effects: According to the self-registered extension primitives and completeness mandatory guard testing method of the present invention, the extension point addition mechanism with zero central table editing is realized through static initialization of self-contained source files and file scope, so that adding or deleting primitives is transformed into adding or deleting individual files, avoiding silent omissions; in conjunction with directory-level glob compilation detection, files are automatically included in the build when they are included in the directory, and by configuring anti-deadlock stripping anchor functions for each type of extension point and explicitly referencing them in the startup path, the self-registration remains reliable and effective even under the linking optimization of the release version; the dual startup path invariant ensures full registration of the function family. The anchor family triggers from the same entry point on both the command-line validator and the game runtime service path, and uses consistency guard tests to intercept silent failures caused by single-path omissions. Based on this, it uses the entire live registry as the starting point to check each entry for mandatory matching components layered by category. A lack of completeness results in a hard failure, elevating missing components from a soft review to an insurmountable mechanical gate. Simultaneously, each category's test includes intentionally defective examples for negative self-testing to prove its defect detection capability is truly effective, and a ratchet floor value that only increases and never decreases ensures that the coverage ratio remains monotonically consistent. This allows the primitive closure set to maintain integrity, testability, and completeness during continuous expansion, without relying on specific programming languages, discovery mechanisms, or guard granularity, making it suitable for various systems requiring continuous and secure expansion of primitive closure sets. Attached Figure Description

[0020] Figure 1 A flowchart illustrating a method for testing self-registered extended primitives and completeness mandatory guards according to an embodiment of the present invention is shown. Figure 2 A block diagram of a self-registered extended primitive and completeness mandatory guard testing system according to an embodiment of the present invention is shown. Detailed Implementation

[0021] Various exemplary embodiments of the present invention will now be described in detail. This detailed description should not be considered as a limitation of the present invention, but rather as a more detailed description of certain aspects, features, and embodiments of the present invention.

[0022] It should be understood that the terminology used in this invention is merely for describing particular embodiments and is not intended to limit the invention. Furthermore, with respect to numerical ranges in this invention, it should be understood that the upper and lower limits of the range and each intermediate value between them are specifically disclosed. Any stated value or intermediate value within a stated range, as well as each smaller range between any other stated value or intermediate value within said range, are also included in this invention. The upper and lower limits of these smaller ranges may be independently included or excluded from the range.

[0023] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. While only preferred methods and materials have been described herein, any methods and materials similar or equivalent to those described herein may be used in the implementation or testing of this invention. All references to this specification are incorporated by way of citation to disclose and describe methods and / or materials associated with those references. In the event of any conflict with any incorporated reference, the content of this specification shall prevail.

[0024] Figure 1 A flowchart illustrating a method for testing self-registered extended primitives and completeness mandatory guards according to an embodiment of the present invention is shown, the method comprising: Step S1: Configure the extension point as a self-contained source file, wherein the self-contained source file is added to the global registry through static initialization of file scope; Step S2: Configure all self-contained source files in the directory where the extension point is located as binary files through directory-level compilation, and configure an anti-dead stripping anchor function for the binary file corresponding to each type of extension point. The anti-dead stripping anchor function is explicitly called on the startup path. Step S3: Set the full registration function family and various anti-dead stripping anchor point functions to be triggered by the same entry point on different startup paths; Step S4: During the construction phase, the complete set of the live registry of the global registry is used as the starting point for traversal, and the completeness of the predefined forced pairings is checked for each entry in the complete set of the live registry. Step S5: If the completeness is missing, the test result is determined to be a test failure.

[0025] The self-registered extension primitives and integrity-enforced guard testing method according to embodiments of the present invention achieves automatic registration of extension point zero-lists through static initialization of self-contained source files and file scopes. Adding or deleting primitives is transformed into adding or deleting individual files, making it less prone to silent omissions and conflicts. Combined with directory-level compilation and anti-deadlock anchor stripping, it ensures that self-registration remains reliable even under release version link optimization. Dual-start path unified triggering and consistency verification can intercept failures caused by single-path omissions. Using the entire live registry set as the traversal starting point, it reverse-checks each entry to enforce matching components. Missing components confirm test failure, upgrading missing components from soft review to mandatory access control, avoiding silent omissions of components. It constructs a closed loop for enforced integrity protection. Its core architecture does not depend on specific programming languages, discovery mechanisms, or guard granularity, and is applicable to various systems that require a continuously secure closed set of extension primitives.

[0026] According to an embodiment of the present invention, in step S1, the extension points include, but are not limited to, action verbs, conditions, value functions, entity selectors, cross-file validation rules, ECS systems, test step processors, components, and scaffolding templates. The extension points are added to the project as self-contained source files. Self-containment means that the source file completely contains all the registration information and implementation logic of the extension point, without relying on any external centralized registration list or central configuration table editing. Taking action verb extension points as an example, the extension point includes multiple in-situ registration blocks within the same source file. These in-situ registration blocks include the extension point's parser registration block (for both runtime and command line use), execution function registration block, parameter reduction registration block, semantic validation function registration block, and behavior probe fixture registration block. These registration blocks are adjacent to each other and centrally presented within the self-contained source file. The extender only needs to focus on one file to complete the complete registration of the extension point, without needing to jump back and forth between multiple remote files. Adding a new extension point is equivalent to adding a self-contained source file in the corresponding directory, and deleting an extension point is equivalent to deleting the self-contained source file. No modifications are required to any centralized registry, build scripts, or central scheduler throughout the process.

[0027] The self-contained source file is statically initialized through file scope, and its specification information is appended to the corresponding global registry. The static initialization of the file scope can be implemented using any of the following methods: static initialization object, compile-time constant expression table, or compile-time code generation. The global registry is implemented as a series of global data structures categorized by extension point type, such as action tables, condition tables, value function tables, selector tables, validation rule tables, ECS system tables, test step processor tables, component tables, and scaffolding tables. These registry entries collectively constitute the global registry. Each registry entry is a thread-safe global container used to store specification information for the corresponding category of extension points, including but not limited to the extension point's name, parameter definitions, execution function entry pointers, and validation function entry pointers.

[0028] To automatically register extension point specifications in self-contained source files to the corresponding global registry, a family of registration macros is provided during automatic registration, such as action registration macros, value retrieval function registration macros, system registration macros, verification rule registration macros, and test step processor registration macros. The extender calls the corresponding registration macro in the source file. This macro expands into a file-scoped static object definition during the preprocessing stage. The constructor of this object is executed before the main function, and inside the constructor, the specification information of the current extension point (name, execution function pointer, verification function pointer, parameter specification, etc.) is appended to the global action registry. Because this static object has file scope (i.e., it is only visible within the current compilation unit), static objects with the same name defined in different source files will not cause link conflicts. The registration macro can also be further expanded to utilize a compile-time constant expression table implementation, i.e., folding a static table at compile time using macros or templates, resulting in zero construction overhead at runtime; or it can use a compile-time code generation implementation, i.e., scanning the directory before building to generate a registration aggregate source file, moving glob discovery forward to the code generation step.

[0029] Furthermore, when implemented in C++, the static initialization of the file scope utilizes the initialization order of statically stored objects guaranteed by the C++ standard: within the same compilation unit, the static objects of the file scope are constructed before the main function is executed. Therefore, when the program enters the main function, the self-registration of all extension points has been completed, and the global registry already contains all extension point specification information compiled into the binary. This mechanism enables adding an extension point to be transformed into adding a self-contained source file in the corresponding directory, and deleting an extension point to deleting the zero-manifest editing target of that self-contained source file, without requiring manual editing of any central table, centralized switch statement, or centralized registration list. For other implementations in languages ​​such as Rust, Zig, and C, equivalent static registration idioms for each language can be used.

[0030] According to an embodiment of the present invention, in step S2, the build system incorporates all self-contained source files in the directory corresponding to each type of extension point into the build process through a directory-level compilation discovery mechanism. The directory-level compilation can be implemented using any of the following methods: directory-level compilation of the build system, compile-time reflection, or build script pattern matching. In the example, directory-level glob matching rules are configured for the directories corresponding to each type of extension point (e.g., actions / , conditions / , values / , systems / , components / , etc.). During the compilation configuration phase, the build system automatically scans all self-contained source files in this directory and adds them one by one to the compiler's input list. After compilation, the corresponding object files (.o or .obj) are generated. Then, the linker merges and links all object files into the final binary executable (i.e., the binary file). Since glob matching is performed at the directory level, the build system does not need to list the filenames of the source files one by one in the script. Therefore, adding the new file to the correct directory constitutes the entire action of incorporating the extension point into the build process, without the need for any build script or registry. For scaffolding extension points existing in the form of disk templates, the build system mirrors the entire template directory to the output directory. At runtime, the directory is parsed and the templates are located according to the agreed order, without the need for source code-level regeneration or centralized manifest editing. The directory-level compiler discovery mechanism can also be replaced by a compile-time reflection method, where the compiler enumerates types with specific annotations during compilation and automatically includes them in the registration system, or by the build script automatically including them in the compilation manifest based on filename pattern matching.

[0031] The self-contained source file appending specification information to the global registry through file-scoped static initialization presents a linker trap: when the linker enables dead code stripping optimization, if any symbol in a compilation unit is not explicitly referenced externally, the linker will classify the entire compilation unit as dead code and discard it completely from the final binary file. Consequently, the constructor of the file-scoped static object within that compilation unit will not be executed, preventing registration from ever occurring. To address this issue, a corresponding anti-dead code stripping anchor function can be configured for each family (i.e., each category) of self-registration extension points. Taking the action verb family as an example, an empty implementation anchor function can be defined in its corresponding registration implementation file. This function body is empty or contains only a return statement and does not need to perform any substantive operation. The key role of this anchor function lies not in its function body, but in the fact that its symbol is explicitly referenced by the startup path. When the linker tracks symbol reference relationships and finds that the anchor function is called externally, it must retain the compilation unit containing the anchor function (and other compilation units of the same family that the compilation unit depends on) in the final binary file. This preserves the static constructors of all self-contained source files in that family, ensuring that static self-registration remains reliable even in releases with linker optimization enabled. Similarly, independent anti-deadlock anchor functions are configured for the value function family, ECS system family, and component family. The call points of these anchor functions are not randomly scattered, but are managed uniformly within a unified entry point of the dual startup paths. That is, the anchor functions of each family are explicitly called in the same way on both the command line verifier startup path and the game runtime service startup path, ensuring that regardless of which path the program starts from, the extension points of all categories are preserved by the linker and the static registration is effective.

[0032] As an alternative to the explicit anchor call mechanism mentioned above, a dedicated link segment can also be used to prevent dead stripping. The compiler places all self-registered entries in a dedicated link segment, and the linker retains this segment after linking is completed. When the program starts, it traverses this segment to complete the registration. This method no longer relies on explicit calls to anchor functions in any startup path to trigger link retention.

[0033] According to an embodiment of the present invention, in step S3, the real engine system has two independent startup paths: the first is the command-line verifier startup path, whose binary program starts from the command-line main function, mainly used to perform specification verification of extension points and parameter validity checks, etc.; the second is the game runtime service startup path, whose binary program starts from the game service process's runtime pipeline registration and ECS world assembly, used to carry the complete game runtime environment. In the example, all full registration function families and all anti-dead stripping anchor point function families must be triggered at the same unified entry point on the above two startup paths. In the example, the full registration function family includes, but is not limited to, batch registration entry points such as the "Register All Actions" function, the "Register All Conditions" function, the "Register All Value Functions" function, the "Register All ECS Systems" function, and the "Register All Components" function. Each full registration function internally traverses the global registry of the corresponding category or calls the registration functions of each entry of that category to ensure that all extension points of that category have been registered. The anti-dead stripping anchor point family includes the set of independent anti-dead stripping anchor point functions configured for the value function family, ECS system family, and component family as described above.

[0034] To ensure that both startup paths invoke the same unified entry point trigger, a unified trigger function can be defined in a unified entry point file. This trigger function sequentially calls all full registration function families and all anti-deadlock anchor point function families. The command-line validator's main function and the game runtime service's pipeline registration both call the same trigger function, instead of maintaining separate trigger lists. Because the two paths share the same unified entry point code, any full registration function or any anti-deadlock anchor point function, once added to the trigger function, takes effect simultaneously in both paths, preventing silent inconsistencies caused by missing game service paths.

[0035] In another example, the full registration entry point can be further converged into a single entry point shared by two startup paths. That is, the two paths no longer call the entry function separately, but instead place the entry function in a shared initialization module and load it together by the two startup paths. Alternatively, the linker can use a dedicated segment collection method to replace the full registration function family, so that registration triggering no longer depends on explicit calls from either path, but is automatically constructed by the linker after linking and traversed uniformly.

[0036] According to an embodiment of the present invention, after triggering the full registration function family and multiple anti-dead stripping anchor point functions at the same entry point, the method further includes: enumerating the same registry through different startup paths; determining whether the enumerated set of entries is consistent; if they are inconsistent, the test is determined to have failed.

[0037] If the invariant that two startup paths call the same set of unified entry points is violated—for example, if the full registration function is called in the main function of the command line, but the same call is forgotten to be added at the corresponding location in the game service pipeline—then the registry content of that family of new systems will be complete in the command line validator binary, and the command line verification will pass. However, the registry of that family will be empty in the game runtime service binary, and these new systems will not be found at runtime, resulting in a silent, inactive defect. To lock this invariant, a path consistency guard test can be configured. This guard test enumerates the global registry of the same category from two different perspectives: the command line validator binary and the game runtime service binary. During the build phase, the same guard test code is linked into the two binary files and executed separately, or registry snapshots are extracted from the two binaries and compared using a build artifact analysis tool. For each family of registry entries, the guard test enumerates the set of entries from the command line perspective and the set of entries from the game service perspective. The equality of the sets is used to determine whether the sets of entries enumerated from the two perspectives are consistent. If any path misses triggering the full registration function or the anti-dead anchor stripping function for a certain family, the enumerated item sets from the two perspectives will differ. The command-line perspective set will contain items for that family, while the game service perspective set will be empty or incomplete. In this case, the guard test will be flagged as red, and the test will fail, thus rigidly preventing the dual-startup path from missing its vulnerability. For Pull / Push type semi-loop extension points that require a rendering backend to operate end-to-end, the game service binary-side verification criteria (recipe verification oracle) will perform end-to-end verification to ensure the correctness of such extension points in a complete rendering environment.

[0038] According to an embodiment of the present invention, in step S4, the completeness mandatory guard test runs during the build or test phase. Its core algorithm uses the complete set of live entries in the global registry (i.e., all extension point entries that have been successfully registered into the binary file and have not been stripped by the linker) as the starting point for traversal. Specifically, the completeness mandatory guard test first obtains a list of all currently live entries in the global registry (e.g., the action registry) corresponding to a type of extension point, and then enumerates each entry in the list one by one. For each enumerated entry, the meta-constraints of the entry itself are first verified, including but not limited to: whether the name is unique (i.e., there is no name conflict), whether the name is not empty, and whether the naming conforms to the naming convention of the type of extension point. After the meta-constraint verification is passed, the guard test then checks whether the mandatory matching parts corresponding to the entry are complete. That is, for the extension point category to which the entry belongs, all its necessary matching parts are checked one by one according to the matching rules of the category to see if they exist, whether they can be called correctly, and whether they meet the type matching conditions. If the entry being checked belongs to the exemption set and the exemption reason is valid, the guard test skips the mandatory pairing check for that entry; if the entry is not in the exemption set, all mandatory pairing requirements must be met. After the guard test performs the above checks on all entries in the registry one by one, it calculates the proportion of entries with complete mandatory pairings to all entries as the coverage ratio, and compares this coverage ratio with the recorded ratchet floor value. If the coverage ratio is not lower than the floor value, the test passes; otherwise, in step S5, it is determined that there is a lack of completeness, and the test fails. The enumeration direction of this test starts from the entire live registry and searches backwards for the pairing set, thus it can report omissions of entries registered in the registry but without a pairing, i.e., falling into the difference set.

[0039] Verifying the completeness of predefined mandatory pairs includes: configuring a check once per registry type, configuring a check once per entry, or performing hierarchical combined checks. For the specific granularity of this test, one can configure a completeness mandatory guard test for each registry type, configure an independent sub-assertion for each entry, or perform hierarchical combined checks. That is, use a unified guard test to traverse all registry families. Alternatively, test failures can be pre-determined during the compilation phase of the build using compile-time static assertions.

[0040] According to embodiments of the present invention, the mandatory pairing is set according to the extension point category, including mandatory pairing for action verb extension points, mandatory pairing for value function extension points, mandatory pairing for ECS system extension points, mandatory pairing for declarative component extension points, and mandatory pairing for entity reference fields. The mandatory pairing for action verb extension points includes a low-level parsing and dispatch fixture, and a high-level semantic behavior probe. The mandatory pairing for value function extension points includes a fixture, an evaluation slot implied by the return type of the value function, a verification path reachable from the public call surface via reverse call mapping, and a mutual exclusion constraint that the value function and the engine's closed operator set do not intersect. The mandatory pairing for ECS system extension points includes a unique and non-empty meta-constraint, a directed graph of inter-system dependencies that is acyclic and topologically sortable, and a constraint on the fixed cross-layer order of the acquisition layer, core layer, and push layer. The mandatory pairing for declarative component extension points includes a scene graph bridging copyer. The mandatory pairing for entity reference field extension points includes a tag parser.

[0041] The mandatory pairings for various extension points are hierarchically configured according to the extension point category, and are executed separately by their respective completeness mandatory guard tests. For action verb extension points, the mandatory pairings include a low-level parsing and dispatch fixture, and a high-level semantic behavior probe. The low-level parsing and dispatch fixture is used to verify that the verb's name is correctly parsed and its parameters are correctly dispatched to the corresponding execution function; the high-level semantic behavior probe is used to launch the real engine world, execute the verb in that world, and assert that its actual side effects are consistent with the semantics claimed by the verb. If either one is missing, the completeness mandatory guard test for that type fails. A few verbs may be included in the exemption set for technical reasons (e.g., pure side effects cannot be asserted in a headless environment), but a written reason must be provided, and the names on the exemption list must be real, registered verbs. In another example, only a single-level fixture may be enforced.

[0042] For value-determining function extension points, mandatory pairings include: fixtures; evaluation slots implied by the return type of the value-determining function (scalar return functions must have scalar evaluation slots, boolean predicate return functions must have predicate evaluation slots, and structured value return functions must have corresponding evaluation slots); verification paths reachable from the public call plane via reverse call mapping to prevent dead primitives that are registered but cannot be called; and mutual exclusion constraints that prevent value-determining functions from intersecting with the engine's closed set of operators to prevent the misregistration of content that should be operators as value-determining functions, or vice versa, causing semantic overlap.

[0043] For ECS system class extension points, mandatory pairing constraints include: unique and non-empty name meta-constraints; a directed graph formed by "before / after" dependencies between systems must be acyclic and topologically sortable; and a fixed cross-layer order constraint, i.e., divided into acquisition layer, core layer, and push layer according to data flow direction, with the global order always being acquisition layer before core layer before push layer. The core layer is further constrained to not reference any rendering backend type to ensure that declarative runtime logic can be unit tested in a non-rendering environment. Violation of any constraint will result in an error during startup or testing.

[0044] For declarative component class extension points, mandatory pairings include requiring each declarative component to have a scene graph bridge copyer to reflect changes in ECS component fields to scene graph nodes; guards enumerate all components, and if the copyer is missing, the class completeness mandatory guard test fails.

[0045] For entity reference field class extension points, mandatory pairing components include tag resolvers. For example, in components, there are fields such as "name a reference field of another entity", "field pointing to a material", "value reference field", "enumeration field", etc. Each such field must register its reference and type in the form of a field declaration, which is then verified by the general field validator at load time. If any structure member of a reference type does not have a corresponding field declaration (tag resolver), the class completeness mandatory guard test will fail.

[0046] The test verifies the uniqueness of the name, the integrity of the registration, and the essential supporting components specific to this category, across file verification rules, test steps, scaffolding, and other extended point categories.

[0047] According to an embodiment of the present invention, when verifying the completeness of predefined mandatory pairings, an exemption set is set, each exemption entry in the exemption set is accompanied by a written reason, and each entry in the exemption set corresponds to an extension point in the directory where the extension point is located.

[0048] When verifying the completeness of predefined mandatory pairs, exemption sets can be configured. If a few extension points genuinely cannot or do not need to be equipped with a certain type of mandatory pair, they can be included in the exemption set to skip the corresponding pairing check. However, each exemption must be accompanied by a written reason explaining why the entry cannot be equipped with the corresponding mandatory pair. The completeness mandatory guard test further verifies whether all the names listed in the exemption set point to actual extension points; that is, it verifies one by one whether each entry name in the exemption set actually exists in the corresponding live registry. This additional verification step is used to prevent attempts to exempt extension points by writing misspelled names or deleted extension point names into the exemption set.

[0049] According to an embodiment of the present invention, if the actual behavior of the extension point occurs in the bridging system of the rendering backend, the specification description visible in the command line of the extension point carries a convention substring, which is used to indicate that the behavior of the extension point is implemented by the bridging system.

[0050] The mandatory constraints for document-oriented code stipulate that the actual behavior of extension points occurs only within the bridging system that exists in the rendering backend. This behavior is not visible at the pure logic layer. For such extension points, the command-line visible specification must include a defined substring to indicate that the behavior is implemented by the backend bridging system. Since AI-oriented documentation only renders the specification, if this substring is omitted, it may be mistakenly assumed that the primitive has no backend behavior, leading to misuse. Therefore, the completeness-mandated guard test verifies the existence of this defined substring.

[0051] According to an embodiment of the present invention, if the completeness is missing, the test result is determined to be a test failure, including: determining the coverage ratio based on the proportion of the currently complete mandatory pairing entries to all entries; setting a ratchet floor value, the ratchet floor value not decreasing; determining whether the coverage ratio is not lower than the ratchet floor value; adjusting the ratchet floor value upwards when the coverage ratio increases; if the coverage ratio falls back below the ratchet floor value, determining that the completeness is missing, and determining that the test has failed.

[0052] To prevent paired coverage from being quietly lowered over long-term evolution, the completeness mandatory guard test employs a ratchet floor mechanism. After enumerating all entries in the registry and verifying the completeness of mandatory paired components, the current actual coverage ratio is calculated using the formula: Coverage Ratio = Number of complete mandatory paired component entries / Total number of registry entries. Simultaneously, the system maintains a recorded ratchet floor value, the initial value of which is set based on the coverage situation at the time of the system's first complete run. After each run, the completeness mandatory guard test asserts that the current actual coverage ratio is not lower than this recorded ratchet floor value. If the current coverage ratio is greater than or equal to the floor value, the test passes; if the current coverage ratio is less than the floor value, the completeness mandatory guard test fails.

[0053] When an extender adds more components, increasing coverage, the ratchet floor mechanism adjusts the ratchet floor value and locks the new coverage ratio. The completeness mandatory guard test compares the current coverage ratio with the updated ratchet floor value at the end of each run: if the current coverage ratio is higher than the floor value, the floor value is automatically updated to the current coverage ratio and persisted. Afterward, any change that causes the coverage ratio to fall below the locked floor value—such as adding an extender without its mandatory pairing, or removing a component due to refactoring—will be considered a test failure. This mechanism ensures the monotonicity of the coverage ratio; it only increases and never decreases (i.e., it only increases or remains constant, never decreases) until it approaches full coverage. The ratchet floor value and item-by-item forced pairing complement each other. Item-by-item pairing verifies the completeness of each item, ensuring that the introduction of new items does not create coverage gaps. The ratchet floor value ensures that the coverage ratio does not decline, preventing the overall coverage level from slowly deteriorating due to the accumulation of new unpaired items. Together, they not only ensure the current state of completeness but also represent an irreversible accumulation in the direction of historical evolution. Furthermore, the ratchet floor mechanism can be applied separately for each expansion point category.

[0054] According to an embodiment of the present invention, before verifying the completeness of a predefined mandatory pair, the method further includes: constructing a sample of a mandatory pair that is intentionally misclassified or intentionally lacks completeness; determining whether the test result of the completeness of the sample is a test failure; and if the test result of the completeness is not a test failure, determining that the negative self-test has failed.

[0055] According to embodiments of the present invention, the completeness enforcement guard test is configured with a negative self-test mechanism to prevent the completeness enforcement guard test from being simplified into an empty shell that always passes tests during long-term maintenance. For example, it might traverse the registry without actually executing any valid assertions, or the guard code might be modified to unconditionally return pass. Specifically, each category of completeness enforcement guard test constructs an intentionally misclassified or intentionally missing component example within its test code. This example is an artificially created defective extension point registration entry. Taking the getter function class as an example, the negative self-test constructs an intentionally misclassified example, for example, a getter function that actually returns a Boolean predicate is incorrectly registered as a getter function that returns a scalar type. This example is registered in a temporary registry dedicated to the test by calling a registration macro or directly injected into the global registry through a simulated registration function within the completeness enforcement guard test. Subsequently, the guard test performs a mandatory completeness check on the sample according to the normal verification process. In the value function example, it checks whether the evaluation slot type of the entry matches the return type according to the evaluation slot rules implicit in the return type. It finds that the Boolean predicate is actually matched to a scalar evaluation slot rather than a predicate evaluation slot. The completeness mandatory guard test asserts that the check result on this sample should be a test failure. If the check result is not a test failure, then the negative self-test fails, and the completeness mandatory guard test has failed.

[0056] The execution logic of the negative self-test is executed as the first assertion within the completeness-enforcement guard test, preceding the normal verification of the actual registry entries. Specifically, before enumerating the actual registry, the guard test first registers intentionally defective test cases in the test environment (e.g., a test fixture or simulated registry container), performs one round of verification, and asserts that the result is a failure (at this point, the completeness-enforcement guard test can be judged to be effective). After confirming the failure, the test case is cleared or bypassed, and normal verification of all entries in the actual registry is performed instead. If the guard test actually returns a pass on the intentionally defective test case, for example, if the guard fails to detect an evaluation slot type mismatch due to a code logic defect, or if the guard is modified to pass unconditionally, then the negative self-test itself is judged to have failed, directly causing the entire build to fail. If the completeness-enforcement guard test correctly judges a failure on the intentionally defective test case, then the negative self-test passes, proving that the guard's completeness testing capability is real and effective, and then the normal enumeration and verification of the actual registry continues.

[0057] The aforementioned negative self-testing mechanism not only verifies the defect detection capability of the guard test but also constitutes a self-defense layer. Any modification that attempts to simplify the completeness-enforced guard test into a formalized shell (such as commenting out assertion statements, replacing red-point branches with skip branches, or changing hard failures to log alerts) will be intercepted by the negative self-testing. Negative self-testing ensures that the completeness-enforced guard test itself is reliable. In another example, negative self-testing can also be implemented through compile-time static assertions, that is, constructing a type mismatch instance during the compilation phase and asserting at compile time that the guard logic can detect the error.

[0058] According to embodiments of the present invention, the self-registered extension primitives and the completeness enforcement guard testing method implement a zero-central-table editing mechanism for adding extension points through static initialization of self-contained source files and file scopes, transforming the addition or deletion of primitives into the addition or deletion of individual files, avoiding silent omissions; in conjunction with directory-level glob compilation detection, files are automatically included in the build process when they are included in the directory, and by configuring anti-deadlock anchor functions for each type of extension point and explicitly referencing them in the startup path, the self-registration remains reliable and effective even under release version linking optimizations; and by using a dual-startup-path invariant, the entire registered function family is fully registered. The anchor family triggers from the same entry point on both the command-line validator and the game runtime service path, and uses consistency guard tests to intercept silent failures caused by single-path omissions. Based on this, it uses the entire live registry as the starting point to check each entry for mandatory matching components layered by category. A lack of completeness results in a hard failure, elevating missing components from a soft review to an insurmountable mechanical gate. Simultaneously, each category's test carries intentionally defective examples for negative self-testing to prove its defect detection capability is truly effective, and a ratchet floor value that only increases and never decreases ensures that the coverage ratio remains monotonically consistent. This allows the primitive closure set to maintain integrity, testability, and completeness during continuous expansion, without relying on specific programming languages, discovery mechanisms, or guard granularity, making it suitable for various systems requiring continuous and secure expansion of primitive closure sets.

[0059] Figure 2 A block diagram of a self-registering extended primitive and completeness-enforced guard testing system according to an embodiment of the present invention is shown, the system comprising: The first configuration module is used to configure the extension point as a self-contained source file, wherein the self-contained source file is added to the global registry through static initialization of file scope; The second configuration module is used to configure all self-contained source files in the directory where the extension point is located as binary files through directory-level compilation, and to configure an anti-dead stripping anchor function for the binary file corresponding to each category of extension point. The anti-dead stripping anchor function is explicitly called on the startup path. The configuration module is used to set the full registration function family and various anti-dead stripping anchor point functions to be triggered by the same entry point on different startup paths; The completeness module is used to check the completeness of predefined mandatory pairs for each entry in the global registry full set during the construction phase, starting from the live registry full set. The result module is used to determine the test result as a test failure if the completeness is missing.

[0060] Although the invention has been described with reference to exemplary embodiments, it should be understood that the invention is not limited to the disclosed exemplary embodiments. Various adjustments or changes may be made to the exemplary embodiments described in this specification without departing from the scope or spirit of the invention. The scope of the claims should be interpreted in the broadest possible sense to cover all modifications and equivalent structures and functions.

Claims

1. A method for testing self-registered extended primitives and completeness-enforced guards, characterized in that, include: The extension point is configured as a self-contained source file, wherein the self-contained source file is added to the global registry through static initialization of file scope; The directory-level compilation configures all self-contained source files in the directory where the extension point is located as binary files, and configures a dead-prevention stripping anchor function for the binary file corresponding to each category of extension point. The dead-prevention stripping anchor function is explicitly called on the startup path. Set the full registration function family and various anti-dead stripping anchor point functions to be triggered by the same entry point on different startup paths; During the construction phase, the live registry set of the global registry is used as the starting point for traversal, and the completeness of predefined forced pairs is checked for each entry in the live registry set. If any of the completeness requirements are missing, the test result will be determined as a test failure.

2. The method according to claim 1, characterized in that, The mandatory pairings are set according to the extension point category, including mandatory pairings for action verb extension points, mandatory pairings for value retrieval function extension points, mandatory pairings for ECS system extension points, mandatory pairings for declarative component extension points, and mandatory pairings for entity reference fields. The mandatory pairings for action verb extension points include low-level parsing and dispatching fixtures, as well as high-level semantic behavior probes; The mandatory pairing of the getter function class extension point includes fixtures, evaluation slots implied by the return type of the getter function, verification paths reachable from the public call plane via the reverse call mapping, and mutual exclusion constraints that the getter function and the engine's set of closure operators do not intersect. The mandatory pairing of ECS system class extension points includes unique and non-empty meta-constraints, acyclic and topologically sortable constraints in the directed graph formed by inter-system dependencies, and constraints on the fixed cross-layer order of the acquisition layer, core layer, and push layer. Forced pairings for declarative component class extension points include scene graph bridge copiers; The mandatory pairing of entity reference field class extension points includes a tag parser.

3. The method according to claim 1, characterized in that, After triggering the full registration function family and multiple anti-dead-out anchor point functions at the same entry point, the method further includes: Enumerate the same registry entries using different startup paths; Determine if the enumerated set of entries is consistent; If there is a discrepancy, the test is considered a failure.

4. The method according to claim 1, characterized in that, Before verifying the completeness of predefined mandatory mating parts, the method further includes: Construct examples of mandatory matching parts that are intentionally misclassified or intentionally lack completeness; Determine whether the test result for the completeness of the sample is a test failure; If the completeness test result is not a test failure, then the negative self-test is judged to have failed.

5. The method according to claim 1, characterized in that, If any of the completeness requirements are missing, the test result will be determined as a test failure, including: The coverage ratio is determined based on the proportion of entries with complete mandatory matching parts to all entries. Set a ratchet floor value that does not decrease; Determine whether the coverage ratio is not lower than the ratchet floor value; The ratchet floor value is adjusted upwards as the coverage ratio increases; If the coverage ratio falls below the ratchet floor value, completeness is determined to be lacking, and the test is judged to have failed.

6. The method according to claim 1, characterized in that, When verifying the completeness of predefined mandatory pairings, an exemption set is set up, each exemption entry in the exemption set is accompanied by a written reason, and each entry in the exemption set corresponds to an extension point in the directory where the extension point is located.

7. The method according to claim 1, characterized in that, If the actual behavior of the extension point occurs in the bridging system of the rendering backend, the specification description visible in the command line of the extension point carries a convention substring, which indicates that the behavior of the extension point is implemented by the bridging system.

8. The method according to claim 1, characterized in that, The extension point includes multiple in-place registration blocks within the same source file. The in-place registration blocks include the parser registration block, execution function registration block, parameter reduction registration block, semantic verification function registration block, and behavior probe fixture registration block of the extension point.

9. The method according to claim 1, characterized in that, The static initialization of the file scope can be implemented in any of the following ways: static initialization object, compile-time constant expression table, or compile-time code generation; The directory-level compilation can be implemented using any of the following methods: directory-level compilation of the build system, compile-time reflection, or build script pattern matching; Verifying the completeness of predefined mandatory pairs includes: verification once per type of registry configuration, verification once per entry configuration, or hierarchical combination verification.

10. A self-registering extended primitive and completeness-enforced guard testing system, used to execute the method as described in any one of claims 1-9, characterized in that, include: The first configuration module is used to configure the extension point as a self-contained source file, wherein the self-contained source file is added to the global registry through static initialization of file scope; The second configuration module is used to configure all self-contained source files in the directory where the extension point is located as binary files through directory-level compilation, and to configure an anti-dead stripping anchor function for the binary file corresponding to each category of extension point. The anti-dead stripping anchor function is explicitly called on the startup path. The configuration module is used to set the full registration function family and various anti-dead stripping anchor point functions to be triggered by the same entry point on different startup paths; The completeness module is used to check the completeness of predefined mandatory pairs for each entry in the global registry full set during the construction phase, starting from the live registry full set. The result module is used to determine the test result as a test failure if the completeness is missing.

Images