From 84bbec5ece2a175064d246c20cd2d575a678e570 Mon Sep 17 00:00:00 2001
From: Ohad Livne <libohad-dev@proton.me>
Date: Mon, 23 Feb 2026 22:03:20 +0200
Subject: [PATCH] Track Claude personalization settings

---
 .claude/CLAUDE.md | 61 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 .claude/CLAUDE.md

diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md
new file mode 100644
index 0000000..d49e6d9
--- /dev/null
+++ b/.claude/CLAUDE.md
@@ -0,0 +1,61 @@
+# Project Instructions
+
+## Container Environment (Podman)
+
+This environment runs inside a container with access to a Podman socket shared from the host. There is no `docker` or `podman` CLI available, but you can interact with containers via the Docker-compatible API.
+
+**Socket:** `/var/run/docker.sock` (Podman with Docker-compatible API)
+
+**Environment Variable:** `DOCKER_HOST=unix:///var/run/docker.sock`
+
+**Example API calls using curl:**
+
+```bash
+# Get version info
+curl -s --unix-socket /var/run/docker.sock http://localhost/version
+
+# List images
+curl -s --unix-socket /var/run/docker.sock http://localhost/images/json
+
+# List containers (quote URLs with query params)
+curl -s --unix-socket /var/run/docker.sock "http://localhost/containers/json?all=true"
+```
+
+## Coding Style
+
+**Consistency is paramount.** New code should look like it belongs naturally and blend with its surroundings. This improves readability for people already familiar with the project. Always match the existing style in the file or module you're working in.
+
+Style preferences (when not conflicting with existing patterns):
+- Functional-inspired style with high modularity
+- Dependency injection over direct access to global resources
+- Avoid mutation of inputs
+- Pure functions where practical
+
+**Style changes should be separate from implementation.** If you notice style inconsistencies or want to improve patterns, do so in dedicated refactor commits or branches rather than mixing with feature work.
+
+## Test Coverage
+
+**Maintain full test coverage of the code.** Every new feature, bug fix, or refactor should include corresponding tests that exercise the changed code paths.
+
+Why this matters:
+- 100% coverage is achievable and maintainable
+- Tests serve as living documentation of expected behavior
+- Full coverage catches regressions immediately, before they reach users
+- It enables confident refactoring—if tests pass, the change is safe
+- Gaps in coverage tend to grow; maintaining full coverage prevents technical debt accumulation
+
+When adding or modifying code, verify that tests cover the new logic. If coverage drops, add tests before merging.
+
+## CLI Style
+
+**Prefer long option names over short ones** in command-line applications and examples.
+
+```bash
+# Preferred
+command --verbose --output file.txt
+
+# Avoid
+command -v -o file.txt
+```
+
+Long options are self-documenting and make scripts and examples easier to understand without consulting help text. Short options are acceptable for interactive use but should not appear in committed code, documentation, or examples.