# Repository Guidelines
use Chinese to response.
## Project Structure & Module Organization
- `src/` contains the core pipeline engine, config parsing, and node implementations (sources, transforms, sinks).
- `tests/` holds integration tests; unit tests live alongside code in `src/`.
- `examples/` provides runnable pipeline configs (YAML) for the CLI.
- `docs/` includes design notes and deeper architecture details.
- `Cargo.toml` defines feature flags (e.g., `http-client`, `file`, `database`).
## Build, Test, and Development Commands
- `cargo build` builds the default feature set; add `--all-features` or `--no-default-features` as needed.
- `cargo run -- run examples/http_to_console.yaml` runs a pipeline from an example config.
- `make build` / `make release` build debug or optimized binaries.
- `make fmt` runs `rustfmt`; `make lint` runs `clippy` (and Markdown lint if installed).
- `make test` runs unit tests; `make test-integration` runs integration tests; `make test-all` runs the full suite.
## Coding Style & Naming Conventions
- Rust code follows `rustfmt` defaults (4-space indentation, trailing commas).
- Use `snake_case` for functions/modules, `CamelCase` for types, `SCREAMING_SNAKE_CASE` for consts.
- Prefer feature-gated modules for optional sources/sinks (`cfg(feature = "...")`).
## Testing Guidelines
- Use `cargo test --all-features` for coverage across feature flags.
- Integration tests live in `tests/` and should be named `*_test.rs`.
- New nodes should include unit tests and at least one integration test covering config + runtime behavior.
## Commit & Pull Request Guidelines
- Commit messages follow a short prefix style (e.g., `feat: ...`, `refactor: ...`).
- PRs should include a clear description, linked issue (if any), and the tests run.
- If behavior changes, update `README.md` or `docs/` and include example configs when relevant.
## Configuration Tips
- Pipeline configs are YAML; validation happens during engine build.
- When adding new config fields, update schema validation and examples.