Use STIG from Gradle

Model-check context

An element's stigCheckModel discovers all model declarations in its Kotlin module, including nested containers and declarations with incorrect containment. It follows the outgoing model references from that content and loads the complete models of the directly connected modules. Every CREATE viewpoint supplies context, including viewpoints whose checks are disabled. The same loader handles the checked module and its context modules, once each. Context objects supply evidence while the task evaluates the selected module's subjects. References originating only in context modules do not recursively expand the complete-model inventory. Ordinary transitive Kotlin runtime dependencies remain available. Child descriptors declared in a parent's context do not make missing child specifications the parent's module-level responsibility. Child viewpoints or configured element ownership identify the child's module; the full-project check also covers child descriptors without their own module.

Analysis bypass does not change this loading contract. An authored usedIn or propagatesTo link to a grandparent selects the target module as ordinary direct context. Analysis.enabled = false, or an absent parent Analysis, does not itself request any extra module. Rules validate the grandparent target and the permitted single bypass using the loaded relation context; they do not turn context modules into additional rule subjects or discovery roots. Missing links remain missing-link findings. See Bypass one Analysis level.

Incoming coverage is an absence check and requires complete contributor content. A grandchild referenced only by a context module's Design does not get loaded automatically. If the checked module needs that content, supply explicit model context or run the full-project :stigCheckModel; insufficient context remains a loading diagnostic, not a finding that the incoming link is absent.

An element descriptor can be declared in its parent's module while its specifications live in its own module. Gradle's configured element.id supplies the lightweight element-to-module catalog. Source identifiers select conservative compilation candidates before the task graph executes; instantiated references select the actual model context. This preparation reads the checked module's sources, not its parents' Analysis flags, and does not construct a project-wide requirement or failure index. For references computed by arbitrary Kotlin factories, declare any additional compilation context explicitly, without introducing a Kotlin dependency cycle:

stigModelContext prepares complete content for loading; it does not make that module's declarations available to the Kotlin compiler. A source reference to another module's failure declaration still needs an ordinary Kotlin dependency, such as implementation(project(":components:parent")).

IDEA follows the same approach: the inspected file identifies its module, then STIG loads that module and its connected models. Indexed references to viewpoint roots' element arguments locate specification modules whose element descriptors are declared elsewhere. For example, a child requirements file can reference its element while the parent's requirements file contains the allocation to that child. The parent requirements become visible even before any child requirement declares a derivedFrom link. Parent analyses and tests are included in the same way. The shared scope, ownership index, and rule engine live in stig-core; Gradle supplies compiled objects and IDEA supplies objects read from Kotlin PSI.

Automated rules execute in this context, including incoming failure and interface-analysis coverage from Design.children, with one Analysis bypass where applicable. Missing required context fails batch execution; it is not an unassessed rule result. IDEA reports a loading diagnostic for unsupported or incomplete source and continues checks that can run with the available information. Semantic obligations are opt-in review requests, with missing engineering evidence identified in their messages.

stigCheckModel defaults to automatic checks. Select --checks all to include manual review requests or --checks manual to produce only manual review work. Manual modes also write manual-reviews.md next to the canonical reports and print its clickable file URI in the final task summary. The checklist lists selected semantic rules and their outcomes, including reasons when rules are not applicable, followed by review requests grouped by module and rule with subjects, related identities, source locations, and the rule contract. A Requirements.sources link supplies a reference; it does not import requirement text. Requirement-quality rules need actual Requirement objects in the checked module. Loading other modules as context does not select their requirements for review. Record review verdicts, evidence, reviewer, and source revision in an authored review report. STIG does not ingest those verdicts as build approvals; rerunning a checklist does not mean that completed judgments failed.

For automatic findings from every Analysis viewpoint in the project:

The option is plural and accepts repeated selections. A module-scoped task checks that module; it loads children as context where needed but does not select their findings. Use the root task for all modules, or name each selected module task explicitly. A subsequent ordinary stigGenerateHtml regenerates automatic findings after a manual/all run.

The root :stigCheckModel loads the complete project model once, prepares one inventory, and evaluates each module's subjects and connected context using its resolved viewpoint settings and failAt threshold. It writes separate results, preserving each finding's owning project, originating viewpoint, and source location in SARIF as well as JSON:

Each directory contains canonical problems.jsonl, model_check_rules.json, and derived stig-check.sarif. The complete-project check is explicit; ordinary element report generation uses the element's module check. Gradle reuses unchanged compilation outputs. IDEA caches the context and rule results across files of a module and invalidates them when source or module changes can affect content or specification ownership.

Classification-difference information

By default, model checks report INFO when an entity's ASIL or failure severity exceeds the maximum of all its known contributors. The common classification policy defines the relationships, aggregation and reporting locations.

Disable these advisories project-wide in the root build.gradle.kts:

The value inherits independently through defaults → group → element → module. A more specific modelCheck { reportClassificationDifferences = true } enables them again. The setting applies to module and full project checks, generated reports, and live IDEA inspections. IDEA reads literal Boolean assignments from the Gradle Kotlin DSL, including project defaults, groups["name"] selections, element settings, and module settings. Computed Gradle expressions are resolved by Gradle; live inspection uses the default when it cannot read the setting.

The setting suppresses only these advisories. HIGH violations, required-attribute checks, the allocatedAsil equality contract, and other informational findings remain active. Classification INFO uses SARIF informational and cannot fail a build at any failAt threshold.

Persistent project behavior belongs in Kotlin Gradle DSL:

Task-specific command options are useful for one invocation:

When a task exposes both a Gradle property and an option, the command-line option overrides the configured convention. Do not persist project semantics in shell aliases or environment variables.