mathias eb9e3e69a9 fix(capture): name what escalated the classification in an I1 refusal (#91 part 1) (#95) ...

The tickets array was never broken. Every ticket in the reported batch
targeted a client repo, and the I1 gate refuses a confidential capture
through a us-nexus origin at any length — reproduced live: length 1 and
20 both fine for an internal repo, length 1 refused for a client one.

What made it look like an array bug is that the refusal named neither the
offending target nor that a policy had said no, so with 20 tickets in
flight "the array is broken" was a reasonable conclusion. The refusal now
names the targets carrying the effective classification, and tells a
caller who declared confidential themselves exactly that.

Regression tests at length 1 and 20 pin the path that was already
correct; a third pins per-item partial success.

Closes #91 part 1.

Co-authored-by: Mathias <mthbqv@gmail.com>

2026-08-18 18:13:48 +00:00

..

entities.go

feat(capture): remove summary->ai-sessions write path

2026-07-27 23:17:56 +02:00

ports.go

feat(capture): remove summary->ai-sessions write path

2026-07-27 23:17:56 +02:00

service_test.go

fix(capture): name what escalated the classification in an I1 refusal (#91 part 1) (#95)

2026-08-18 18:13:48 +00:00

service.go

fix(capture): name what escalated the classification in an I1 refusal (#91 part 1) (#95)

2026-08-18 18:13:48 +00:00