2.5 KiB
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:
# 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.
# 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.