Build a Safe Project Validation CLI

1. Argument parsing and usage output

Scenario: you are building a real, local CLI tool a team could run before every commit to catch basic project-structure problems -- entirely on your own machine. Create validate.sh, starting with set -euo pipefail. Accept a project directory as $1, print a clear usage message and exit with a specific code if no argument is given, and print a specific error and exit with a different code if the given path doesn't exist or isn't a directory.

• validate.sh begins with set -euo pipefail
• Running it with no arguments prints a clear usage message to stderr and exits non-zero
• Running it against a nonexistent path prints a clear, specific error and exits with a distinct, documented code

2. Real, non-destructive validation checks

Implement at least 4 distinct checks against the given project directory: for example, a README.md exists, a specific required subdirectory exists, no file larger than a chosen size threshold exists, and no filename contains a space (a common source of downstream scripting bugs). Every check must be read-only -- this script must never create, modify, or delete anything in the directory being validated.

• At least 4 distinct, independent checks are implemented
• Every check is genuinely read-only against the target directory (find, test, grep -- never rm, mv, or > into the target)
• Each check prints a clear PASS or FAIL line naming exactly what it checked

3. Cleanup traps and text-processing checks

Create a temp file with mktemp to accumulate a results summary, and register a trap 'rm -f "$tmpfile"' EXIT immediately after creating it, so it's always removed. Add at least one check using grep, sed, or awk against real file content (for example: no file contains a hardcoded TODO older than a threshold, or a config file has a required key set).

• A temp file is created with mktemp and cleaned up via a trap registered on EXIT, confirmed by checking it doesn't survive an intentionally forced early failure
• At least one check uses grep, sed, or awk against real file content, not just filename/existence checks
• The results summary temp file is genuinely used (written to and read from) during the run, not just created and discarded

4. Distinct exit codes and CI-friendly design

Assign a distinct, documented exit code to each category of failure (for example: 1 = usage error, 2 = missing required file, 3 = a text-content check failed, 4 = a size/naming check failed), with 0 reserved for a fully passing run. Ensure the script never assumes a particular working directory (only ever uses the passed-in path or absolute paths) and never relies on any environment variable being pre-set without an explicit default.

• At least 4 distinct exit codes are used and documented in a comment at the top of the script
• The script produces identical, correct results regardless of the working directory it's invoked from
• set -u is active and the script runs correctly with no pre-set custom environment variables

5. ShellCheck and a CI workflow

Run ShellCheck against validate.sh and resolve every reported issue (or document, with a comment, the specific, deliberate reason a particular warning is a false positive in this case). Add a GitHub Actions workflow that runs validate.sh against the repository itself as a real quality check, uploading the results summary as an artifact.

• shellcheck validate.sh reports zero unaddressed warnings
• A CI workflow file exists that runs validate.sh against a real target directory and reflects its exit code in the job's result
• The results summary is uploaded as a CI artifact on the workflow run