Repository navigation
fix(extensiontest): support protecting an unreadable input #497
Description
The problem (CMO)
Agent role: Cook building an image extension from the template
Area: Automated checks
Problem Statement: As an agent working in ncly-image-shrink, I want to prove refusal of an unreadable input while protecting it, so that the generic Unreadable case follows the template's preservation rule.
REF: #494, XT-107-T2
Analogy
The safety check insists on reading a locked file before testing that the command refuses to read it.
- What should happen: The test can observe refusal and prove that the file stays unchanged
- What happened in this session: The test kit failed before the command started because it could not hash the protected mode-000 file
What we saw
On non-root Linux with Nicely v0.27.0, just scenario acceptance exited 1 at refuses, before invoking the extension:
> chmod 000 unreadable.png
> protect missing.png empty.png broken.png unreadable.png
> refuses IMAGE_SHRINK_INPUT ncly image shrink missing.png
open $WORK/unreadable.png: permission denied
The protected file caused the failure even though this first call concerned another input. Selecting only the unreadable file still reaches the same unconditional os.Open before command execution. The case cannot reach its refusal assertion with the input protected as the template requires.
What exists today
generic-cases.md requires an unreadable-input case. The template's replace-a-file.md requires protecting the input before a refusal. sdk/extensiontest/protected.go, snapshotFiles, hashes every regular file through fileDigest, which opens the path. paired.go, refuses, takes that snapshot before the dry run.
Start, Stop, Continue (FMO)
- Start: Document or provide a preservation proof for unreadable files, with a before-permission-change digest and a checked restoration or equivalent observation
- Stop: Requiring an immediate read of a protected file whose unreadability is the test stimulus
- Continue: Compare bytes and permissions for readable files and observe links without following them
How we'll know it works
- Today: On a non-root host, protect a mode-000 regular file before
refuses. The helper fails before command execution - After the change: Both dry run and run reach the declared refusal, and the test detects a handler that changes the input bytes or permissions
- Nothing else changes: Existing readable-file and symbolic-link preservation cases still pass
👨🏻🍳 For the agent
👨🏻🍳 Details
The exact observed command was just scenario acceptance, exit 1. The failed scenario line was the refuses call quoted above. This was a generated local PNG, with no user data, root privilege, mount, network or key.
Fixed sources: Nicely v0.27.0, sdk/extensiontest/protected.go, snapshotFiles and fileDigest, and sdk/extensiontest/paired.go, refuses. The unconditional regular-file digest explains the observed permission error. The failure occurs before either command invocation.
A possible explicit accommodation is to protect the absent output, retain a readable reference, make the input unreadable, run the paired refusal, verify its permission bits still equal 000, restore read permission, and compare every input byte with the reference. This preserves the behavior proof but needs an exception to the template's instruction to use protect on that input. No such exception or Nicely edit has been applied.
The fix belongs to the kit or its contract. Do not silently drop the unreadable case or its input-preservation assertion.
by GPT-6.1-Sol via Codex
Activity