You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #846 pins the customer-facing capture-cleanliness contract for `kosli fingerprint`: stdout = fingerprint, stderr = empty on the success path, so that `FP=$(kosli fingerprint ... 2>&1)` works reliably in CI.
@JonJagger flagged in the PR review that *the same fingerprint code path is shared with all the `kosli attest ` commands, which means the contract should logically hold there too. Any future regression that breaks fingerprint capture (a deprecation warning, a logger.Warn, a startup banner) would also break attest capture, but PR #846's tests don't cover the attest surface.
This issue tracks extending the contract coverage to `kosli attest *`.
Why it matters
Customers use `kosli attest` commands programmatically in CI just like `kosli fingerprint`. If a future regression silently puts content on stderr during an attest run, the same class of bugs will hit the same customers — but on a different command. The fix needs to be tested at all the surfaces where the contract applies.
This is a broader contract surface than fingerprint alone:
The existing test infrastructure under `cmd/kosli/attest_*_test.go` already handles all of this via `SetupTest` — but adding capture-cleanliness assertions to those tests will require either extending the existing `cmdTestCase` struct's `goldenStderr` usage or adding a parallel suite focused on the contract.
Suggested approach
Audit which attest commands produce shell-capturable output by design — anything that prints a fingerprint, an attestation ID, a trail name, etc. is a candidate.
Pick one representative attest command (probably `kosli attest generic` since it's the simplest) and add a capture-cleanliness test mirroring the shape of `TestFingerprintFile_CaptureCleanliness` from PR test: pin fingerprint capture cleanliness contract #846.
Extend to other capture-style attest commands once the pattern is proven.
Acceptance criteria
At least one `TestAttestCaptureCleanliness` test in the appropriate `attest*_test.go` file that:
Stubs the version-check via `version.SetCheckForUpdateOverride`
Runs the attest command against the local test server
Asserts capture cleanliness on the success path (exact stdout, empty stderr)
A short note in `cmd/kosli/CLAUDE.md` (or similar) documenting the contract so future contributors know it exists
Background
PR #846 pins the customer-facing capture-cleanliness contract for `kosli fingerprint`: stdout = fingerprint, stderr = empty on the success path, so that `FP=$(kosli fingerprint ... 2>&1)` works reliably in CI.
@JonJagger flagged in the PR review that *the same fingerprint code path is shared with all the `kosli attest ` commands, which means the contract should logically hold there too. Any future regression that breaks fingerprint capture (a deprecation warning, a logger.Warn, a startup banner) would also break attest capture, but PR #846's tests don't cover the attest surface.
This issue tracks extending the contract coverage to `kosli attest *`.
Why it matters
Customers use `kosli attest` commands programmatically in CI just like `kosli fingerprint`. If a future regression silently puts content on stderr during an attest run, the same class of bugs will hit the same customers — but on a different command. The fix needs to be tested at all the surfaces where the contract applies.
This is a broader contract surface than fingerprint alone:
Not all of these necessarily produce shell-capturable raw output, but any that do (or that customers are using in capture patterns) are worth pinning.
Why it's trickier than fingerprint
The attest commands need:
The existing test infrastructure under `cmd/kosli/attest_*_test.go` already handles all of this via `SetupTest` — but adding capture-cleanliness assertions to those tests will require either extending the existing `cmdTestCase` struct's `goldenStderr` usage or adding a parallel suite focused on the contract.
Suggested approach
Acceptance criteria
Context