Skip to content

docs(#1820): document test attestation input contract in AGENTS.md #1821

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
fullsend-ai-coder wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs(#1820): document test attestation input contract in AGENTS.md #1821

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,6 +63,18 @@ These files have `effective_on` dates — rules with future dates are warnings,
architectural constraints that aren't derivable from the code. Check there before reverse-engineering
a subsystem.

**Test attestation input contract:** Konflux test-result attestations (evaluated by

@fullsend-ai-review fullsend-ai-review Bot Aug 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

[low] paragraph length / information density

The new 'Test attestation input contract' paragraph is approximately 10 lines, roughly 2x longer than the longest existing paragraph in the Architecture section (Collections at 5 lines). The surrounding paragraphs each convey a single concise architectural fact, while this one mixes the input contract description with deduplication behavior, threat-model rationale, and a reference to a separate enforcement story.

Suggested fix: Consider splitting into two paragraphs: one describing the input contract and deduplication behavior, and a second shorter note on severity calibration and the enforcement safety net.

`policy/release/test_attestation/test_attestation.rego`) always include
`predicate.configuration[0].name` (the test name) and `predicate.timestamp` (RFC 3339 with
nanosecond precision). The `test_attestation` package relies on these fields for deduplication:
attestations are grouped by name and only the latest timestamp per group is evaluated. Attestations
without a valid (non-empty string) `timestamp` are excluded from evaluation by design — this is
intentional deduplication behavior, not a fail-open path. Missing-timestamp or missing-name edge
cases in this package are low-severity theoretical concerns, not high-severity vulnerabilities,
because the Konflux attestation producers guarantee these fields. A separate enforcement story
exists to require certain test attestations, providing a safety net if the attestation format
changes.

## Rego Evaluation Model (for AI reviewers)

Rego is a declarative policy language (Datalog-inspired), not imperative code:
Expand Down
Loading