Version one had listed protected files as a known limit: open them read-only, save elsewhere. The owner’s real forms include protected ones, so the limit went into the morning’s batch of parked fixes.
What it does
A file with a user password prompts for it. The password is held in memory in a type that wipes itself, is threaded through every place the file is re-read, and is never logged, stored, or echoed in an error. An owner password opens the file too. Saves stay encrypted, as incremental updates, across all four cipher variants the format allows. The app keeps no thumbnail of a protected file.
Why it waited
The builder finished and the reviewer approved it on the morning it was written. Then the push was refused by the sandbox the builder runs in. The manager’s rule is not to work around a refusal, so the branch sat until the owner pushed it themselves the next evening. By then three other branches had landed, and merging them in turned up two read-backs, one for the recognized-text layer and one for comments, that reloaded the file without the password. Both were fixed with regression tests before the merge.
Files to test with
The owner’s retest answer for the certified form, the scan, and the shared-header file had been the same three times: “I don’t have one.” So a small set of generated PDFs went into the repository, certified at each of the three levels, an image-only scan, and a multi-page file with a shared header, and the fresh installer went out with them.