fix(sdl): add createdDate to guardian baseline result entries

[Evgenii (Vaiz)]

🤖 Clawpilot here! Posted automatically by Clawpilot (an AI agent), not by a human. Please verify before acting.

What broke

The publish pipeline has failed on every run against main since 95089c5 ("Introduce cargo-gamma (#93)"). The last green run predates the vendored JS bundle.

The sole failing task is Guardian: Post Analysis; the other failed timeline records are just its ancestor stage, phase and job.

#112 added the repo-root guardian_baselines.gdnbaselines precisely to cover these three findings. The clippy half of that PR worked. The baseline half did not, and #112's own merge commit 8928c0a1 still fails on Guardian alone.

Root cause

Guardian finds and loads the file, then applies none of it:

Baselines: guardian-baseline

##[error]The CreatedDate of the result with signature <76fd7a25...> is empty.
##[error]The CreatedDate of the result with signature <6c2296c1...> is empty.
##[error]The CreatedDate of the result with signature <c4f9dd26...> is empty.

##[error]16. ESLint Error @microsoft/sdl/no-inner-html - crates/cargo-gamma-lib/src/vendor/mutation-test-elements.js. Line: 2.
##[error]17. ESLint Error @microsoft/sdl/no-inner-html - crates/cargo-gamma-lib/src/vendor/mutation-test-elements.js. Line: 4.
##[error]18. ESLint Error @microsoft/sdl/no-inner-html - crates/cargo-gamma-lib/src/vendor/mutation-test-elements.js. Line: 89.

Active results: 3
Skipped results: 16
  Baselined results: 0
  Results below minimum severity: 15
##[error]Guardian detected one or more breaking results.
##[error]Error: Guardian exited with an error exit code: 8

Baselined results: 0 against three entries whose signatures match the three active findings exactly. The three signatures Guardian rejects for an empty CreatedDate are the same three that then break the build.

createdDate is required on each result, not only on the baselines.guardian-baseline object. The file carried it in the latter place only. An existing baseline elsewhere under the same policy has it on every result, between ruleId and justification — it was dropped here because the file was hand-authored rather than emitted by the Guardian CLI.

The fix

Three added lines, one per result entry, in the position a CLI-generated baseline uses, with the same timestamp as the baseline object itself.

Effects

• Guardian: Post Analysis applies the three baseline entries instead of rejecting them, so the publish pipeline can go green on main again.

• The SDL gate becomes a usable signal again rather than permanently red on a known-accepted vendored finding.

• No expirationDate is set. These findings live in a vendored, minified third-party bundle (mutation-testing-elements 3.9.0) that changes only by re-vendoring, so a dated baseline would silently lapse and re-break the build.

  This reasoning was wrong — see fix(sdl): add expirationDate to guardian baseline result entries #126. The SDL policy requires an expiration date for this rule and rejects entries without one, so this PR left the build broken in a second way.

• Nothing outside the SDL gate is touched: no Rust source, no manifest, no pipeline YAML.

Verification

JSON validated after the edit. The defect was confirmed still present on main HEAD 6054135e before branching — the blob is byte-identical (505dc913) to the one merged by #112.

This cannot be verified locally; the Guardian CLI and the .gdn result files only exist on the CI agent. Confirmation is the next publish run reporting Baselined results: 3 and Active results: 0.

/cc Pato Sandaña (@psandana) Martin Taillefer (@geeknoid)

[Copilot]

Pull request overview

Updates the repository’s Guardian baseline file so SDL/Guardian can successfully apply existing baselines for the vendored mutation-test-elements.js ESLint findings and unblock the PublishEachCommit pipeline on main.

Changes:

• Add createdDate to each individual baseline result entry (not just the baseline object), matching Guardian’s required schema.
• Keep the timestamps consistent with the existing baseline metadata (baselines.guardian-baseline.createdDate / lastUpdatedDate).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.7%. Comparing base (6054135) to head (a228104).

❌ Your project status has failed because the head coverage (97.7%) is below the target coverage (100.0%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #124   +/-   ##
=====================================
  Coverage   97.7%   97.7%           
=====================================
  Files        286     286           
  Lines      62460   62460           
=====================================
+ Hits       61030   61031    +1     
+ Misses      1430    1429    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.