Summary
Two small ergonomics gaps in the screenplay verifier tool surfaced while validating a single generated .play file. Both are about the "check one generated file" workflow, which becomes common now that Cratis.Arc.Screenplay generates documents.
1. The tool only accepts directories
screenplay <path> requires a directory and globs **/*.play beneath it. Pointing it at a file prints Directory '<path>' does not exist and exits 1:
$ screenplay /Users/me/Ada.play
Directory '/Users/me/Ada.play' does not exist
The natural first invocation everyone tries — verify this file — requires copying the file into a scratch directory first (and pointing it at $HOME instead would scan everything under it). Suggested fix: if the argument is a file with a .play extension, compile just that file; keep the directory behavior otherwise.
2. No way to fail on warnings
The tool exits 0 unless there are Error diagnostics; warnings never affect the exit code. For a generator/CI pipeline ("the generated document must be clean"), an opt-in --warnaserror (or --strict) flag would let warnings gate the build the same way compiler tool conventions do.
Context
Found while compiling a generated 5,348-line document from a real Arc application (result: 0 errors, 1 warning — which exit code 0 then hides from CI).
Summary
Two small ergonomics gaps in the
screenplayverifier tool surfaced while validating a single generated.playfile. Both are about the "check one generated file" workflow, which becomes common now thatCratis.Arc.Screenplaygenerates documents.1. The tool only accepts directories
screenplay <path>requires a directory and globs**/*.playbeneath it. Pointing it at a file printsDirectory '<path>' does not existand exits 1:The natural first invocation everyone tries — verify this file — requires copying the file into a scratch directory first (and pointing it at
$HOMEinstead would scan everything under it). Suggested fix: if the argument is a file with a.playextension, compile just that file; keep the directory behavior otherwise.2. No way to fail on warnings
The tool exits 0 unless there are Error diagnostics; warnings never affect the exit code. For a generator/CI pipeline ("the generated document must be clean"), an opt-in
--warnaserror(or--strict) flag would let warnings gate the build the same way compiler tool conventions do.Context
Found while compiling a generated 5,348-line document from a real Arc application (result: 0 errors, 1 warning — which exit code 0 then hides from CI).