Skip to content

SP-925: Add PLATFORM_SERVICE validation layer to config validate#381

Open
Kastriot Salihu (ksalihu) wants to merge 3 commits into
mainfrom
ksalihu/SP-925-validate-platform-service-layer
Open

SP-925: Add PLATFORM_SERVICE validation layer to config validate#381
Kastriot Salihu (ksalihu) wants to merge 3 commits into
mainfrom
ksalihu/SP-925-validate-platform-service-layer

Conversation

@ksalihu

@ksalihu Kastriot Salihu (ksalihu) commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Description

Adds PLATFORM_SERVICE (Layer 4: Platform Service Validation, epic SP-866) as an accepted value of the --layers option on config package validate and the deprecated config validate alias.

What changed:

  • CLI help — both validate commands now list PLATFORM_SERVICE in the --layers allowed values and combined example.
  • Rendering — platform-service findings flow through the existing report path unchanged: the text report prints each finding (severity, node key, asset type, message, code) and --json writes the full report. No new branching was needed because the response shape (results[]) is layer-agnostic.
  • Docsdocs/user-guide/config-commands.md gains a PLATFORM_SERVICE row in the layers table, a usage paragraph, updated examples, and the ValidationResult.layer union now includes the new layer.
  • Testsconfig-validate.spec.ts adds coverage for the request body (combined layers), the text report, and the JSON report for PLATFORM_SERVICE. Full suite green (47 suites / 425 tests).

Note: the PLATFORM_SERVICE backend layer is being added to the Pacman validate endpoint under a separate change. The docs and CLI present it as a supported layer; merge this PR once the Pacman change is live so the two land together.

Relevant links

Checklist

  • I have self-reviewed this PR
  • I have tested the change and proved that it works in different scenarios (pending the Pacman endpoint change; unit-tested request body + text + JSON rendering)
  • I have updated docs if needed

Made with Cursor

Add PLATFORM_SERVICE as an accepted value of the --layers option on both
'config package validate' and the deprecated 'config validate', and document
the new layer in the config command guide. Findings flow through the existing
text report and --json output unchanged. Adds spec coverage for the request
body, the text report, and the JSON report for the new layer.

Includes-AI-Code: true
Co-authored-by: Cursor <cursoragent@cursor.com>
@ksalihu Kastriot Salihu (ksalihu) marked this pull request as ready for review June 17, 2026 11:57
Comment thread docs/user-guide/config-commands.md Outdated
| `PLATFORM_SERVICE` | Platform-service-owned validation — each participating platform service checks the assets it owns against its live service (for example Semantic Layer "list-problems" checks), surfacing platform-level problems that only the running service can detect. Which services take part, and how their findings map to severities, is declared by platform-service descriptors. | Owning platform services (e.g. `cloud-semantic-layer`), coordinated by Pacman |

Currently `SCHEMA`, `BUSINESS`, and `PACKAGE_SETTINGS` are the layers accepted by the Pacman API. Other values are rejected with a `400 layers.unsupported` error.
`SCHEMA`, `BUSINESS`, and `PACKAGE_SETTINGS` are accepted by the Pacman API today. `PLATFORM_SERVICE` is the newest layer and is only accepted once platform-service validation is enabled on the validate endpoint. Any value the endpoint does not (yet) support is rejected with a `400 layers.unsupported` error.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if having "newest" is an appropriate phrasing in the documentation.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call — dropped the "newest" framing (and the related "today"/"(yet)"/"until then" wording) and now describe the layer by its capability and backend-enablement gating instead. Applied to both the summary line and the usage paragraph in 3d6ccb8.

Address review feedback on PR #381: describe the layer by its capability and
its backend-enablement gating rather than by relative recency. Removes the
"newest"/"today"/"(yet)"/"until then" wording from the validation-layers
section of config-commands.md.

Includes-AI-Code: true
Co-authored-by: Cursor <cursoragent@cursor.com>
Drop the backend-enablement caveats and present PLATFORM_SERVICE alongside the
other accepted layers, matching how SCHEMA/BUSINESS/PACKAGE_SETTINGS are
documented. The Pacman validate endpoint change lands separately and this PR
is merged once it does.

Includes-AI-Code: true
Co-authored-by: Cursor <cursoragent@cursor.com>
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants