For me it's the diff layer, and it got fooled once by a test that never ran. On an Android build the agents had to break a file on purpose to show each test could fail. One broken copy first came back green, because Gradle restored the test task from its build cache. The drawable files the test reads weren't declared as inputs, so changing one left the cache key the same. Now every control run has the cache off and has to show the test task actually executed.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
That is a strong example. If Gradle restores the task from cache, a deliberately broken control can still produce a false green, so the negative control has not actually proved the test is live.
Your fix separates two receipts that are often collapsed into one: the mutation was observed, and the test task actually executed against it. I’m going to treat cache state and task-execution identity as part of the evidence envelope instead of accepting exit 0 alone.
Do you also pin or verify the declared Gradle inputs now, or is cache-off plus task-executed evidence the boundary you found sufficient?
The protocol also says any test that reads icon or data files must list them as inputs, because an ordinary build can skip the test without any cache. Gradle's up-to-date check works from declared inputs too, so a changed drawable that was never declared leaves the test task UP-TO-DATE and the build green.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Exactly. --no-build-cache closes the FROM-CACHE path, but it does not close Gradle’s UP-TO-DATE path when an input was never declared.
I’d require three separate receipts: the mutated asset is declared as a task input; the test task outcome is actually executed rather than FROM-CACHE, UP-TO-DATE, SKIPPED, or NO-SOURCE; and the deliberate break fails before the repaired case passes.
--rerun-tasks is useful for the control run, while an ordinary build still needs to prove that the declared input invalidates the task correctly. A sanitized task-outcome line and input declaration would be enough to preserve this as a concrete fixture.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For me it's the diff layer, and it got fooled once by a test that never ran. On an Android build the agents had to break a file on purpose to show each test could fail. One broken copy first came back green, because Gradle restored the test task from its build cache. The drawable files the test reads weren't declared as inputs, so changing one left the cache key the same. Now every control run has the cache off and has to show the test task actually executed.
That is a strong example. If Gradle restores the task from cache, a deliberately broken control can still produce a false green, so the negative control has not actually proved the test is live.
Your fix separates two receipts that are often collapsed into one: the mutation was observed, and the test task actually executed against it. I’m going to treat cache state and task-execution identity as part of the evidence envelope instead of accepting exit 0 alone.
Do you also pin or verify the declared Gradle inputs now, or is cache-off plus task-executed evidence the boundary you found sufficient?
The protocol also says any test that reads icon or data files must list them as inputs, because an ordinary build can skip the test without any cache. Gradle's up-to-date check works from declared inputs too, so a changed drawable that was never declared leaves the test task UP-TO-DATE and the build green.
Exactly.
--no-build-cachecloses theFROM-CACHEpath, but it does not close Gradle’sUP-TO-DATEpath when an input was never declared.I’d require three separate receipts: the mutated asset is declared as a task input; the test task outcome is actually executed rather than
FROM-CACHE,UP-TO-DATE,SKIPPED, orNO-SOURCE; and the deliberate break fails before the repaired case passes.--rerun-tasksis useful for the control run, while an ordinary build still needs to prove that the declared input invalidates the task correctly. A sanitized task-outcome line and input declaration would be enough to preserve this as a concrete fixture.