CRLF line endings in shell scripts break WSL2/Linux execution

[phil-cc]

Problem

When project-install.sh (and likely other .sh scripts) are checked out on a Windows host and executed inside WSL2, they carry Windows-style CRLF (\r\n) line endings. Bash on Linux treats the \r as a literal character, causing virtually every line to fail:

/home/<user>/agent-os/scripts/project-install.sh: line 2: $'\r': command not found
/home/<user>/agent-os/scripts/project-install.sh: line 4: $'\r': command not found
...

Variable values are also silently corrupted - e.g. VERBOSE='false\r', DEBUG='false\r' - which can break conditional logic downstream even if the script appears to run.

Root Cause

Git defaults core.autocrlf=true on Windows, converting LF to CRLF on checkout. Without a .gitattributes file enforcing eol=lf for shell scripts, any Windows user gets CRLF endings.

Impact

agent-os targets cross-platform use and WSL2 is the primary way Windows users run Linux tooling. This is a first-run blocker for a significant portion of the target audience.

Steps to Reproduce

1. Clone the repo on a Windows host with default Git settings (core.autocrlf=true).
2. Open WSL2.
3. Run ./scripts/project-install.sh --profile php-symfony --verbose --debug.
4. Observe $'\r': command not found on nearly every line.

Suggested Fix

Add a .gitattributes file at the repo root to enforce LF for all shell scripts:

*.sh   text eol=lf
*.bash text eol=lf

Users who have already cloned can fix locally with:

dos2unix scripts/project-install.sh
# or
sed -i 's/\r//' scripts/project-install.sh