project-validator
Project Validator
Project-wide lint for a Datex Studio branch. The branch is the source of truth: the validator enumerates the branch's configs via dxs source explore configs and bulk-exports them to a throwaway temp directory with dxs source document build (the CLI's offline-analysis path), then runs five cross-component checks against that temp export — checks that per-file validation cannot see in isolation. Returns a structured, read-only punch-list grouped by check type. Never modifies the branch, and never treats a local src/ checkout as authoritative.
This is the project-level validator. It complements per-file validation: component-validator audits one component file end-to-end against its type-specific rule sheet; this skill audits the whole project (or a scope subset) for issues that only appear when you look across files — broken objectType references, OData queries that don't match the live schema, datasource query options that have drifted away from declared outParams, etc. The two skills are designed to be used together — component-validator after authoring each file, project-validator before merging a batch or shipping a release.
See also:
component-validator— single-file audit against the per-type creator rule sheet. Use it after authoring or modifying any one component. This skill is the project-level counterpart.See also:
component-wiring-check— chases a specific cross-component reference contract. This skill is broader (5 categories across the whole project) but shallower (lint-grade, not deep wiring trace).See also:
post-edit-verification— quick post-write check on a single file. Different scope and lighter touch than this skill.
Dependencies
datex-studio-conventions—defaults.md(description ≤100 chars, mandatory description),file-format.md(configurationTypeIdtable, suffix rules),naming-conventions.md(type-indicator rules). These are the rules the checks below enforce.datex-studio-shared/datex-studio-runtime— branch-setup primitives and platform-runtime globals used when interpreting flow code (e.g. resolving$flow.inParams.<name>and$flow.outParams.<name>references).component-validator— per-file companion. Sibling scope. When the project validator surfaces a file-local violation that a creator skill's rule sheet documents in detail, route the parent tocomponent-validatorfor the deep audit.schema-explorer— invoked for OData pre-flight (check 4). The project validator must not load raw schema documents into the parent context — always delegate the entity / property / navigation lookups toschema-explorer.codebase-research— invoked when a finding needs grounded read-only inspection of supporting context (e.g. confirming an enum's allowed values by fetching the*-customTypeconfig from the branch). Optional, on demand.