chore: add .gitattributes and renormalize line endings to LF

16 tracked C++ sources had drifted to CRLF (mostly on Windows edits),
which churned diffs — PR #18 hit exactly this on main.cpp. Add a repo
.gitattributes (`* text=auto eol=lf`) so the working tree is LF on every
platform, protect .bat/.cmd as CRLF (cmd.exe requires it), mark common
binary asset types, then `git add --renormalize .`.

Pure line-ending change: the content diff is empty
(`git diff --ignore-cr-at-eol` shows only .gitattributes). Submodules
(maya, acp-cpp, mcp-cpp, rag-cpp) carry their own attributes and are
untouched. Rebuilt the affected TUs (http/acp/main/composer) clean.

Author: 1ay1

.gitattributes

@@ -0,0 +1,27 @@
+# Normalize line endings across the repo.
+#
+# `text=auto` lets git decide which files are text and stores them with LF
+# in the repository. `eol=lf` forces LF on checkout too, so the working tree
+# stays LF on every platform (including Windows / MSYS2) — this repo builds
+# under MinGW and clang64 where stray CRLF churned diffs before. Submodules
+# (maya, acp-cpp, mcp-cpp, rag-cpp) carry their own attributes and are
+# unaffected.
+* text=auto eol=lf
+
+# Windows batch scripts must keep CRLF or cmd.exe mis-parses them.
+*.bat text eol=crlf
+*.cmd text eol=crlf
+
+# Binary assets: never touch.
+*.png binary
+*.jpg binary
+*.jpeg binary
+*.gif binary
+*.ico binary
+*.woff binary
+*.woff2 binary
+*.ttf binary
+*.otf binary
+*.pdf binary
+*.zip binary
+*.gz binary

include/agentty/acp/server.hpp

@@ -1,67 +1,67 @@
-#pragma once
-// Read an image from the system clipboard via platform-native tooling.
-//
-// Bracketed paste delivers UTF-8 text only; binary clipboard content
-// (a PNG that a screenshot tool put on the clipboard) is dropped or
-// mangled by every mainstream terminal. The reliable path is to ASK
-// the platform clipboard for its image content out-of-band, via a
-// small subprocess:
-//
-//   Linux/Wayland → wl-paste --type image/png
-//   Linux/X11     → xclip -selection clipboard -t image/png -o
-//   macOS         → pngpaste -            (brew install pngpaste)
-//   Windows       → powershell System.Windows.Forms.Clipboard.GetImage
-//
-// All capture stdout as raw bytes — `tools::util::Subprocess` runs its
-// captured output through to_valid_utf8(), which would replace every
-// non-UTF-8 byte with U+FFFD and corrupt the image. So this module
-// has its own popen-based capture that doesn't touch the bytes.
-//
-// The reducer arm in update/composer.cpp calls read_clipboard_image()
-// synchronously on Ctrl+V. The subprocesses all exit immediately when
-// no image is available (non-zero status, empty stdout) so the worst
-// case is the shell-spawn cost (~10-50 ms on Linux, ~100-200 ms on
-// macOS via osascript). Acceptable on the UI thread for an explicit
-// user action.
-
-#include <optional>
-#include <string>
-
-namespace agentty {
-
-struct ClipboardImage {
-    /// Raw image bytes — PNG / JPEG / GIF / WEBP. Sniffed from the
-    /// magic prefix of the captured stdout, so format mismatch
-    /// between tool flags and actual content (rare, but possible
-    /// under odd compositor configurations) is surfaced cleanly.
-    std::string bytes;
-    /// MIME type (e.g. "image/png") matching the magic prefix.
-    std::string media_type;
-};
-
-/// Read an image from the system clipboard. On success returns the
-/// raw bytes + sniffed MIME type. On failure (tool missing, clipboard
-/// empty, no image type on clipboard, image too large), returns
-/// nullopt and writes a one-line human-readable diagnostic to
-/// `*error_out` so the caller can surface it as a status toast that
-/// names the actual failure (the previous "no image on clipboard"
-/// blanket message was unhelpful when the real fix was "install
-/// wl-clipboard" or "the clipboard has only text").
-[[nodiscard]] std::optional<ClipboardImage>
-read_clipboard_image(std::string* error_out = nullptr);
-
-/// Read plain UTF-8 text from the system clipboard. Used by the
-/// composer's "smart paste" path: when Ctrl+V / Ctrl+Shift+V arrive
-/// via a trigger that didn't already carry bracketed-paste content
-/// (Windows Terminal swallows Ctrl+V and emits nothing on an
-/// image-only clipboard; the user's Alt+V fallback also goes through
-/// the same path), the composer asks the OS clipboard for whatever
-/// it has — image first, text second — so the same shortcut "just
-/// works" regardless of clipboard contents.
-///
-/// Returns nullopt if the clipboard has no text or the platform tool
-/// is missing; writes a diagnostic to `*error_out` for the toast
-/// path.
+#pragma once
+// Read an image from the system clipboard via platform-native tooling.
+//
+// Bracketed paste delivers UTF-8 text only; binary clipboard content
+// (a PNG that a screenshot tool put on the clipboard) is dropped or
+// mangled by every mainstream terminal. The reliable path is to ASK
+// the platform clipboard for its image content out-of-band, via a
+// small subprocess:
+//
+//   Linux/Wayland → wl-paste --type image/png
+//   Linux/X11     → xclip -selection clipboard -t image/png -o
+//   macOS         → pngpaste -            (brew install pngpaste)
+//   Windows       → powershell System.Windows.Forms.Clipboard.GetImage
+//
+// All capture stdout as raw bytes — `tools::util::Subprocess` runs its
+// captured output through to_valid_utf8(), which would replace every
+// non-UTF-8 byte with U+FFFD and corrupt the image. So this module
+// has its own popen-based capture that doesn't touch the bytes.
+//
+// The reducer arm in update/composer.cpp calls read_clipboard_image()
+// synchronously on Ctrl+V. The subprocesses all exit immediately when
+// no image is available (non-zero status, empty stdout) so the worst
+// case is the shell-spawn cost (~10-50 ms on Linux, ~100-200 ms on
+// macOS via osascript). Acceptable on the UI thread for an explicit
+// user action.
+
+#include <optional>
+#include <string>
+
+namespace agentty {
+
+struct ClipboardImage {
+    /// Raw image bytes — PNG / JPEG / GIF / WEBP. Sniffed from the
+    /// magic prefix of the captured stdout, so format mismatch
+    /// between tool flags and actual content (rare, but possible
+    /// under odd compositor configurations) is surfaced cleanly.
+    std::string bytes;
+    /// MIME type (e.g. "image/png") matching the magic prefix.
+    std::string media_type;
+};
+
+/// Read an image from the system clipboard. On success returns the
+/// raw bytes + sniffed MIME type. On failure (tool missing, clipboard
+/// empty, no image type on clipboard, image too large), returns
+/// nullopt and writes a one-line human-readable diagnostic to
+/// `*error_out` so the caller can surface it as a status toast that
+/// names the actual failure (the previous "no image on clipboard"
+/// blanket message was unhelpful when the real fix was "install
+/// wl-clipboard" or "the clipboard has only text").
+[[nodiscard]] std::optional<ClipboardImage>
+read_clipboard_image(std::string* error_out = nullptr);
+
+/// Read plain UTF-8 text from the system clipboard. Used by the
+/// composer's "smart paste" path: when Ctrl+V / Ctrl+Shift+V arrive
+/// via a trigger that didn't already carry bracketed-paste content
+/// (Windows Terminal swallows Ctrl+V and emits nothing on an
+/// image-only clipboard; the user's Alt+V fallback also goes through
+/// the same path), the composer asks the OS clipboard for whatever
+/// it has — image first, text second — so the same shortcut "just
+/// works" regardless of clipboard contents.
+///
+/// Returns nullopt if the clipboard has no text or the platform tool
+/// is missing; writes a diagnostic to `*error_out` for the toast
+/// path.
 [[nodiscard]] std::optional<std::string>
 read_clipboard_text(std::string* error_out = nullptr);