fix(transcript): a call without a run ID that fails its checks leaves no lock file #443

Outside the plan: Pascal assigned this card on 2026-11-03, through the grooming of Epic 16. Its pull request says that it is outside the plan.

Problem

ncly transcript run opens its run before it checks the output and the key. In extensions/transcript/execute.go, line 34 calls runs.Open, which takes the lock of the run. Lines 59-67 then check the output (resolve) and the key (call.Key("deepgram")). When the caller gives no --run-id, line 32 makes a new ID. So each call that fails these checks leaves one more lock file in the runs folder. nicely never deletes lock files, because deletion of a flock file races with a new lock.

Goal

A call without --run-id that fails the output check or the key check adds no file to the runs folder of transcript.

Acceptance rules

1. When the caller gives no --run-id, transcript checks the output and the key before it opens the run. A new ID has no record, so the restore step of lines 47-57 cannot change the job.
2. When the caller gives --run-id, the order stays the same. The lock comes first, so a busy run answers TEMPORARY before other checks, and a completed run replays.
3. The rule covers only the output and key checks. A refusal after runs.Open, such as in attempt.execute (lines 109-116), can still leave its lock file.
4. A generated ID that collides with an existing run keeps its current answer.
5. No code deletes a lock file.
6. The answers, codes, and exit codes of each refusal do not change.

Examples

• Success: with no Deepgram key granted, ncly transcript run youtube --url <url> answers KEY_NOT_GRANTED (exit 78). The runs folder has the same files before and after the call.
• Failure: the same call adds a .lock file to the runs folder.

Check

Scenarios under testdata/script/ prove these cases:

• A call without --run-id and with no key: the runs folder keeps the same files.
• A call without --run-id and with an output folder that cannot be used: the runs folder keeps the same files.
• A call with a busy --run-id: the answer is still TEMPORARY.
• A call with the --run-id of a completed run: the run still replays.

just check passes.

by Opus-5.5 via Claude Code