# Repository Guidelines

## Project Structure & Module Organization
- `src/` holds the shell implementation, with submodules for `builtins/`, `executor/`, `parser/`, and `variables/`.
- `include/` contains public headers used across modules.
- `lib/` is populated at build time with third-party 42 libraries (libft, get_next_line, ft_printf, ft_args).
- `docs/` stores project references and manual test notes (see `docs/tests.md`).
- `build/` is the object output directory generated by `make`.

## Build, Test, and Development Commands
- `make` or `make all`: build `minishell` (auto-clones required libs into `lib/`).
- `make clean`: remove objects in `build/`.
- `make fclean`: remove objects and the `minishell` binary (also cleans libs).
- `make re`: full rebuild.
- `./minishell`: run locally after a build.
- `make DEBUG=lldb` or `make DEBUG=valgrind` or `make DEBUG=address`: rebuild with debug/ASan-friendly flags.

## Coding Style & Naming Conventions
- The codebase follows 42 **Norminette v4** rules. Run `norminette *.c *.h` (or on specific files) before submitting changes.
- Keep file names lowercase with underscores (e.g., `src/builtins/echo/echo.c`).
- Keep headers in `include/` and expose only what modules need.

## Testing Guidelines
- There is no automated test runner. Use manual checks in `docs/tests.md` and basic shell behavior checks (pipes, redirects, builtins).
- When debugging memory issues, run under valgrind and use the suppression file in `valgrind/readline.supp`.

## Commit & Pull Request Guidelines
- Commit messages in this repo use a simple `type: summary` format (examples: `update: ...`, `fix: ...`). Keep summaries short and specific.
- For PRs, include:
  1. What changed and why.
  2. How to test (commands or manual steps).
  3. Notes on any parser/executor/builtin behavior changes.

## Configuration Tips
- The project depends on `readline`; ensure your system has `libreadline-dev` or equivalent before building.