{"owner":"fluent","repo":"fluent-bit","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Repository Guidelines\n\n## Preferred Commands\n- Configure: `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n- Configure on Windows:\n  `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n- Build: `cmake --build build -j8`\n- Test: `ctest --test-dir build --output-on-failure`\n- Prefer targeted tests with `ctest --test-dir build -R <name> --output-on-failure`\n  when the affected area is known, because the full enabled suite can be slow.\n- Windows supports building and running runtime tests. Prefer focused\n  `flb-rt-*` targets or CTest matches because the full runtime suite can be\n  slow. The GitHub Actions unit-test workflow enables runtime execution only\n  for x64 to control CI running time. Do not apply that CI-only restriction to\n  local agents or AI cloud builds.\n- Run a focused integration test with\n  `ctest --test-dir build -R flb-it-opentelemetry --output-on-failure`\n- Run the in-tree Python integration suite with:\n  `cd tests/integration && ./setup-venv.sh && ./run_tests.py`\n- List available Python integration scenarios with:\n  `cd tests/integration && ./run_tests.py --list`\n- Run locally with `./build/bin/fluent-bit -c conf/fluent-bit.conf`\n\n## Project Structure & Module Organization\nFluent Bit is a C/C++ monorepo built with CMake.\n\n- `src/`: core engine/runtime (`flb_*` components, schedulers, routing, I/O).\n- `include/fluent-bit/`: public/internal headers used by core and plugins.\n- `plugins/`: input/filter/processor/output plugins (`in_*`, `filter_*`, `processor_*`, `out_*`).\n- `lib/`: bundled libraries (e.g., `cprofiles`, `ctraces`, `cmetrics`, `chunkio`).\n- `tests/`: integration/runtime tests and fixtures.\n- `tests/integration/`: in-tree Python integration test suite for end-to-end\n  plugin and protocol validation; introduced from the original\n  `github.com/fluent/fluent-bit-test-suite` project.\n- `conf/`: sample configurations for local validation.\n\nKeep changes scoped: plugin logic in its plugin directory, shared behavior in `src/` or `lib/`.\n\n## Bundled Library Changes\n- Treat `lib/` as bundled third-party or separately maintained code unless the\n  specific path is clearly Fluent Bit-owned.\n- Before editing bundled library code, ask for explicit user confirmation. If\n  the agent environment supports confirmation popups, use one; otherwise ask in\n  chat before writing files.\n- Prefer changes that can be sent upstream as a focused patch. Keep bundled\n  library patches isolated from Fluent Bit glue code, and document the upstream\n  project/path in the close-out.\n- Do not mix bundled library edits with unrelated Fluent Bit core, plugin,\n  documentation, or test changes in the same commit unless the user explicitly\n  asks for that structure.\n\n## Build, Test, and Development Commands\n- `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`:\n  configure runtime and internal tests, including on Windows.\n- `cmake --build build -j8`: compile Fluent Bit and tests.\n- `ctest --test-dir build --output-on-failure`: run enabled tests.\n- `ctest --test-dir build -R flb-it-opentelemetry --output-on-failure`: run a focused integration test.\n- `cd tests/integration && ./setup-venv.sh`: create the local virtualenv for\n  the Python integration suite.\n- `cd tests/integration && ./run_tests.py --list`: list available Python\n  integration scenarios.\n- `cd tests/integration && ./run_tests.py`: run the full Python integration\n  suite against `build/bin/fluent-bit`.\n- `cd tests/integration && FLUENT_BIT_BINARY=/path/to/fluent-bit ./run_tests.py`:\n  run the Python integration suite against a specific binary.\n- `./build/bin/fluent-bit -c conf/fluent-bit.conf`: run locally with a config.\n\n## Coding Style & Naming Conventions\n- Follow Apache-style C conventions used by Fluent Bit.\n- Use 4-space tabs/indentation and target 100 chars per line; 120 chars max.\n- Always use braces for `if/else/while/do` blocks.\n- Put function opening braces on the next line:\n  `int fn(void)\\n{ ... }`\n- Keep short boolean conditions on one line when they fit within 100 chars.\n- Wrap conditions only when needed, and break at logical operators (`&&`, `||`);\n  do not force one operand per line when readability does not improve.\n- Keep short function calls on one line when they fit; avoid splitting each\n  argument into separate lines unless line length or clarity requires it.\n- Declare variables at the start of functions, not mid-block.\n- Prefer descriptive `snake_case` for functions/variables and `flb_*`/`cprof_*` prefixes.\n- Use `/* ... */` comments (single or multiline), with wrapped long comments.\n\n## Testing Guidelines\n- Add or update tests for behavior changes, especially protocol parsing and encoder/decoder paths.\n- Prefer targeted tests close to the changed module (`tests/internal`, plugin runtime tests).\n- Prefer focused `ctest -R ...` runs or specific test binaries when the touched area is known.\n- Windows supports `tests/runtime`, `flb-rt-*` targets, and runtime CTest\n  matches. Configure with `-DFLB_TESTS_RUNTIME=On` and run applicable focused\n  runtime coverage. In `.github/workflows/call-windows-unit-tests.yaml`, keep\n  runtime execution disabled for x86 and ARM64 unless the workflow scope\n  explicitly changes; that exclusion controls GitHub Actions running time only.\n  It does not apply to local agents or AI cloud builds.\n- Use `tests/integration` when validating end-to-end plugin behavior, network\n  protocols, downstream request generation, or local fake-server interactions\n  that are awkward to cover in `ctest` binaries alone.\n- The Python integration suite is not part of the default CMake `ctest` targets;\n  run it explicitly from `tests/integration`.\n- Do not skip focused integration coverage for a touched component when that\n  component has a corresponding `tests/integration` scenario. Agents must run\n  the focused scenario(s) for the touched component before closing the task.\n- For touched components covered by `tests/integration`, agents must run the\n  focused scenario(s) twice:\n  - once normally to verify behavior;\n  - once with the platform memory checker enabled to verify memory-safety\n    behavior: Valgrind on Linux or Leaks on macOS.\n- The default expectation for component verification is:\n  `./tests/integration/setup-venv.sh`\n  `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n  `cmake --build build -j8`\n  `tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n  On Linux, run the memory-safety pass with:\n  `VALGRIND=1 VALGRIND_STRICT=1 tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n  On macOS, run the memory-safety pass with:\n  `LEAKS=1 LEAKS_STRICT=1 tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n- On Windows, use the same `-DFLB_TESTS_RUNTIME=On` configuration and run\n  relevant focused runtime and functional integration cases. Valgrind and\n  macOS Leaks are normally unavailable on Windows; report that exact\n  memory-checker blocker instead of conflating it with test support.\n- Run broader test coverage when changing shared lifecycle, routing, storage, or accounting code.\n- Validate both success and failure paths (invalid payloads, boundary sizes, null/missing fields).\n- You can also run specific binaries from `build/bin` (e.g., `./bin/flb-it-opentelemetry`).\n- When changing code covered by `tests/integration`, agents must verify the\n  affected scenarios are clean under the platform memory checker. On Linux,\n  run `tests/integration/run_tests.py --valgrind --valgrind-strict ...`. On\n  macOS, run `tests/integration/run_tests.py --leaks --leaks-strict ...`. Do\n  not stop at functional pass/fail if memory errors or leaks remain.\n- If a focused integration or platform memory-checker run cannot be executed,\n  agents must not silently skip it. They must report the exact blocker in the\n  final response (for example: missing binary, missing Python environment,\n  unsupported scenario, missing dependency, or infrastructure failure).\n- Final task close-outs must include proof of verification:\n  - the exact focused integration command(s) run;\n  - which platform memory checker was used (Valgrind on Linux or Leaks on\n    macOS), or `not run` with the exact blocker;\n  - pass/fail status;\n  - any concrete blocker if a required run could not be completed.\n- Keep generated integration artifacts out of git. Do not commit\n  `.venv/`, `.pytest_cache/`, `results/`, or `__pycache__/` under\n  `tests/integration`.\n\n## Commit & Pull Request Guidelines\n- Prefix commit subjects with the component/plugin name in lowercase, e.g.:\n  - `engine: fix flush buffer handling`\n  - `in_opentelemetry: profiles: fix ingestion path`\n- Keep subject/body lines <= 80 chars.\n- Keep each commit scoped to one component/prefix; avoid mixed-area commits.\n- Sign commits with DCO: `git commit -s`.\n- PRs should include: problem statement, scope, test evidence (`ctest` output), and compatibility notes.\n- If behavior changes user output/config, include a short before/after example.\n- Target `master` for next major by default; open backport PRs to release branches (`1.x`) when needed.\n\n## Commit Pattern (Branch Practice)\n- Follow observed local history style:\n  - component/plugin: `component: short imperative description`\n  - internal tests: `tests: internal: short imperative description`\n  - integration tests under `tests/integration/`:\n    `tests: integration: short imperative description`\n  - runtime tests/binaries outside `tests/integration/`:\n    `tests: runtime: short imperative description`\n- The repository commit-prefix linter in\n  `.github/scripts/commit_prefix_check.py` is authoritative. When its inferred\n  prefix set is narrower than a hand-written nested subject, follow the linter.\n  Examples from current repo history:\n  - `include/fluent-bit/config_format/flb_cf.h` +\n    `src/config_format/flb_cf_yaml.c` => `config_format:`\n  - `tests/internal/env.c` => `env:` or `tests:`\n  - `tests/internal/fuzzers/config_map_fuzzer.c` => `config_map_fuzzer:` or `tests:`\n  - `tests/internal/config_map.c` => `config_map:` or `tests:`\n- Agents must follow this same style when proposing commit subjects or\n  `git commit` commands; do not invent ad hoc prefixes such as `environment:`\n  when the touched files map to an existing component or test area prefix.\n- When suggesting commit commands, include DCO signing by default with\n  `git commit -s` unless the user explicitly asks otherwise.\n- Keep one interface per commit. If an interface touches both `.c` and `.h`,\n  commit them together in the same commit.\n- Do not bundle different interfaces into one commit just because they support\n  the same feature. Core config-map changes, input/output/filter/custom/\n  processor plumbing, plugin changes, tests, and documentation must be split\n  into separate commits unless they are the same interface.\n- Do not mix unrelated interfaces in one commit.\n- Do not include `AGENTS.md` or other documentation updates in a code commit\n  unless the user explicitly asks for a docs+code combined commit.\n- Prefer concise one-line subjects unless extra context is required.\n- Detect and avoid bad squash commits. Do not place YAML examples, config lines,\n  or multiple subject-like prefix lines in the commit body unless they are\n  fenced code blocks.\n\n## Commit Lint Workflow\n- When the user asks for git commit commands, provide commands that also verify\n  commit-prefix lint before push or PR submission.\n- After creating a commit when the user asked for a commit, agents must run the\n  repo linter before closing the task and fix any bad commit subject\n  immediately.\n- Do not treat a local non-PR linter pass as sufficient before push. Outside\n  GitHub PR context, `.github/scripts/commit_prefix_check.py` validates only\n  `HEAD`, which can miss earlier commits in the branch.\n- Run the same checker used in CI:\n  `python .github/scripts/commit_prefix_check.py`\n- The checker requires `gitpython`. If `python -c 'import git'` fails, install\n  it before running the linter:\n  `python3 -m pip install gitpython`\n- Do not assume a generic `docs:` prefix is acceptable. Check the touched file\n  prefixes from repo history and from `.github/scripts/commit_prefix_check.py`\n  path inference before choosing a commit subject. For example, changes only to\n  `AGENTS.md` must use `agents:`, not `docs:`.\n- For pull-request-style validation, use full history and fetch the base branch\n  first, matching CI behavior. This is required because the checker can fall\n  back to validating only `HEAD` when the base ref is unavailable:\n  `git fetch --all --prune`\n  `git fetch origin <base-branch>:origin/<base-branch>`\n- Before pushing a branch or opening/updating a PR, agents must lint the full\n  PR commit range against the base branch, not just the latest commit. Use the\n  CI-style environment when possible, for example:\n  `GITHUB_EVENT_NAME=pull_request GITHUB_BASE_REF=<base-branch> python .github/scripts/commit_prefix_check.py`\n- If a commit mixes component code and integration tests, do not assume a\n  local `HEAD`-only lint pass proves the earlier code commit is acceptable.\n  Validate the whole branch range before push/PR submission.\n- When giving commit-command sequences to the user, include a final lint step\n  that checks the PR range and mention the `gitpython` install step if it may\n  be missing locally.\n\n## Agent Action Limits\n- Do not open issues, pull requests, or remote branches unless the user explicitly asks.\n- Do not rewrite git history, amend commits, or force-push unless the user explicitly asks.\n- Do not revert user changes outside the requested scope.\n- Do not edit bundled libraries under `lib/` without explicit confirmation.\n- Prefer minimal patches that avoid unrelated formatting or refactoring churn.\n\n## Agent Playbook (Pipeline Architecture Primer)\n\n### Runtime model (mental map)\n- Fluent Bit moves data through: input -> chunk -> router -> task ->\n  filter/processor -> output -> engine result handling.\n- Routing is per output instance; one chunk can fan out to many routes.\n- Route state is independent (success/retry/drop can differ per output).\n\n### Data units and boundaries\n- A **signal** is the high-level type: logs, metrics, traces, profiles, blobs.\n- A **record/event** is the logical payload unit inside a signal.\n- A **chunk** is the persisted/queued container (often MessagePack-backed).\n- A **task** is the engine execution unit for a chunk across routes.\n- Never assume \"one chunk = one route\" or \"one serialized event = one log\n  record\" in shared code.\n\n### Component responsibilities\n- Inputs (`plugins/in_*`) create/append data and trigger ingestion.\n- Input chunk layer (`src/flb_input_chunk.c`) manages lifecycle, routing masks,\n  storage pressure, and drop/release behavior.\n- Router (`src/flb_router*.c`) resolves tag/signal matches to outputs.\n- Task layer (`src/flb_task.c`) tracks per-route state and retries.\n- Filters (`plugins/filter_*`) run on matching streams before output flush.\n- Processors (`plugins/processor_*`) can run in input/output contexts depending\n  on configuration and may mutate/drop payloads.\n- Outputs (`plugins/out_*`) serialize/protocol-encode and return flush result.\n- Engine (`src/flb_engine.c`) applies final retry/drop accounting and task\n  teardown.\n\n### Signal-aware behavior rules\n- Shared paths must branch correctly by `event_type` (logs vs non-logs).\n- Some logic is meaningful only for logs (record-level semantics), while\n  metrics/traces/profiles/blobs may follow different serialization/counting.\n- Group/metadata markers can exist as serialized events; treat them as\n  transport/data-shape artifacts unless the interface explicitly requires them.\n\n### Counting and metrics guidance\n- Separate these concepts when reviewing code:\n  - serialized events in a buffer\n  - logical records after processing\n  - per-route processed/retry/drop counters\n  - byte accounting (chunk bytes vs route-effective bytes)\n- Prefer route-aware values when updating route metrics.\n- Preserve explicit zero values; use clear sentinel values for \"unknown\".\n\n### Retry/drop semantics\n- `FLB_OK`: route succeeded.\n- `FLB_RETRY`: route keeps task/chunk for retry scheduling.\n- `FLB_ERROR`: route failure/drop path.\n- Final chunk release happens only when all active routes are resolved.\n\n### Storage/backlog interaction\n- In-memory and filesystem backlog paths may use different code paths; validate\n  both when touching chunk/task lifecycle.\n- Backlog-loaded chunks must preserve route state and accounting parity with\n  live-ingested chunks.\n\n### Review checklist before patching\n- Trace one full path for affected signals: input -> chunk -> task -> output ->\n  engine completion.\n- Verify fan-out behavior (single chunk, multiple outputs).\n- Verify processing behavior (drop/modify/no-op) in both input and output\n  processor contexts.\n- Verify empty payload behavior (outputs should not crash on zero records).\n- Verify metrics/counters for success, retry, and drop paths.\n\n### Testing strategy\n- Use `tests/internal` for core lifecycle/accounting logic.\n- Use `tests/runtime` for plugin-level behavior and end-to-end semantics,\n  including Windows runtime targets supported by the active toolchain and host.\n- Add regression tests for:\n  - mixed signals\n  - processor drop/modify paths\n  - multi-route fan-out\n  - backlog + live ingestion parity\n"},"files":{"AGENTS.md":"# Repository Guidelines\n\n## Preferred Commands\n- Configure: `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n- Configure on Windows:\n  `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n- Build: `cmake --build build -j8`\n- Test: `ctest --test-dir build --output-on-failure`\n- Prefer targeted tests with `ctest --test-dir build -R <name> --output-on-failure`\n  when the affected area is known, because the full enabled suite can be slow.\n- Windows supports building and running runtime tests. Prefer focused\n  `flb-rt-*` targets or CTest matches because the full runtime suite can be\n  slow. The GitHub Actions unit-test workflow enables runtime execution only\n  for x64 to control CI running time. Do not apply that CI-only restriction to\n  local agents or AI cloud builds.\n- Run a focused integration test with\n  `ctest --test-dir build -R flb-it-opentelemetry --output-on-failure`\n- Run the in-tree Python integration suite with:\n  `cd tests/integration && ./setup-venv.sh && ./run_tests.py`\n- List available Python integration scenarios with:\n  `cd tests/integration && ./run_tests.py --list`\n- Run locally with `./build/bin/fluent-bit -c conf/fluent-bit.conf`\n\n## Project Structure & Module Organization\nFluent Bit is a C/C++ monorepo built with CMake.\n\n- `src/`: core engine/runtime (`flb_*` components, schedulers, routing, I/O).\n- `include/fluent-bit/`: public/internal headers used by core and plugins.\n- `plugins/`: input/filter/processor/output plugins (`in_*`, `filter_*`, `processor_*`, `out_*`).\n- `lib/`: bundled libraries (e.g., `cprofiles`, `ctraces`, `cmetrics`, `chunkio`).\n- `tests/`: integration/runtime tests and fixtures.\n- `tests/integration/`: in-tree Python integration test suite for end-to-end\n  plugin and protocol validation; introduced from the original\n  `github.com/fluent/fluent-bit-test-suite` project.\n- `conf/`: sample configurations for local validation.\n\nKeep changes scoped: plugin logic in its plugin directory, shared behavior in `src/` or `lib/`.\n\n## Bundled Library Changes\n- Treat `lib/` as bundled third-party or separately maintained code unless the\n  specific path is clearly Fluent Bit-owned.\n- Before editing bundled library code, ask for explicit user confirmation. If\n  the agent environment supports confirmation popups, use one; otherwise ask in\n  chat before writing files.\n- Prefer changes that can be sent upstream as a focused patch. Keep bundled\n  library patches isolated from Fluent Bit glue code, and document the upstream\n  project/path in the close-out.\n- Do not mix bundled library edits with unrelated Fluent Bit core, plugin,\n  documentation, or test changes in the same commit unless the user explicitly\n  asks for that structure.\n\n## Build, Test, and Development Commands\n- `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`:\n  configure runtime and internal tests, including on Windows.\n- `cmake --build build -j8`: compile Fluent Bit and tests.\n- `ctest --test-dir build --output-on-failure`: run enabled tests.\n- `ctest --test-dir build -R flb-it-opentelemetry --output-on-failure`: run a focused integration test.\n- `cd tests/integration && ./setup-venv.sh`: create the local virtualenv for\n  the Python integration suite.\n- `cd tests/integration && ./run_tests.py --list`: list available Python\n  integration scenarios.\n- `cd tests/integration && ./run_tests.py`: run the full Python integration\n  suite against `build/bin/fluent-bit`.\n- `cd tests/integration && FLUENT_BIT_BINARY=/path/to/fluent-bit ./run_tests.py`:\n  run the Python integration suite against a specific binary.\n- `./build/bin/fluent-bit -c conf/fluent-bit.conf`: run locally with a config.\n\n## Coding Style & Naming Conventions\n- Follow Apache-style C conventions used by Fluent Bit.\n- Use 4-space tabs/indentation and target 100 chars per line; 120 chars max.\n- Always use braces for `if/else/while/do` blocks.\n- Put function opening braces on the next line:\n  `int fn(void)\\n{ ... }`\n- Keep short boolean conditions on one line when they fit within 100 chars.\n- Wrap conditions only when needed, and break at logical operators (`&&`, `||`);\n  do not force one operand per line when readability does not improve.\n- Keep short function calls on one line when they fit; avoid splitting each\n  argument into separate lines unless line length or clarity requires it.\n- Declare variables at the start of functions, not mid-block.\n- Prefer descriptive `snake_case` for functions/variables and `flb_*`/`cprof_*` prefixes.\n- Use `/* ... */` comments (single or multiline), with wrapped long comments.\n\n## Testing Guidelines\n- Add or update tests for behavior changes, especially protocol parsing and encoder/decoder paths.\n- Prefer targeted tests close to the changed module (`tests/internal`, plugin runtime tests).\n- Prefer focused `ctest -R ...` runs or specific test binaries when the touched area is known.\n- Windows supports `tests/runtime`, `flb-rt-*` targets, and runtime CTest\n  matches. Configure with `-DFLB_TESTS_RUNTIME=On` and run applicable focused\n  runtime coverage. In `.github/workflows/call-windows-unit-tests.yaml`, keep\n  runtime execution disabled for x86 and ARM64 unless the workflow scope\n  explicitly changes; that exclusion controls GitHub Actions running time only.\n  It does not apply to local agents or AI cloud builds.\n- Use `tests/integration` when validating end-to-end plugin behavior, network\n  protocols, downstream request generation, or local fake-server interactions\n  that are awkward to cover in `ctest` binaries alone.\n- The Python integration suite is not part of the default CMake `ctest` targets;\n  run it explicitly from `tests/integration`.\n- Do not skip focused integration coverage for a touched component when that\n  component has a corresponding `tests/integration` scenario. Agents must run\n  the focused scenario(s) for the touched component before closing the task.\n- For touched components covered by `tests/integration`, agents must run the\n  focused scenario(s) twice:\n  - once normally to verify behavior;\n  - once with the platform memory checker enabled to verify memory-safety\n    behavior: Valgrind on Linux or Leaks on macOS.\n- The default expectation for component verification is:\n  `./tests/integration/setup-venv.sh`\n  `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n  `cmake --build build -j8`\n  `tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n  On Linux, run the memory-safety pass with:\n  `VALGRIND=1 VALGRIND_STRICT=1 tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n  On macOS, run the memory-safety pass with:\n  `LEAKS=1 LEAKS_STRICT=1 tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n- On Windows, use the same `-DFLB_TESTS_RUNTIME=On` configuration and run\n  relevant focused runtime and functional integration cases. Valgrind and\n  macOS Leaks are normally unavailable on Windows; report that exact\n  memory-checker blocker instead of conflating it with test support.\n- Run broader test coverage when changing shared lifecycle, routing, storage, or accounting code.\n- Validate both success and failure paths (invalid payloads, boundary sizes, null/missing fields).\n- You can also run specific binaries from `build/bin` (e.g., `./bin/flb-it-opentelemetry`).\n- When changing code covered by `tests/integration`, agents must verify the\n  affected scenarios are clean under the platform memory checker. On Linux,\n  run `tests/integration/run_tests.py --valgrind --valgrind-strict ...`. On\n  macOS, run `tests/integration/run_tests.py --leaks --leaks-strict ...`. Do\n  not stop at functional pass/fail if memory errors or leaks remain.\n- If a focused integration or platform memory-checker run cannot be executed,\n  agents must not silently skip it. They must report the exact blocker in the\n  final response (for example: missing binary, missing Python environment,\n  unsupported scenario, missing dependency, or infrastructure failure).\n- Final task close-outs must include proof of verification:\n  - the exact focused integration command(s) run;\n  - which platform memory checker was used (Valgrind on Linux or Leaks on\n    macOS), or `not run` with the exact blocker;\n  - pass/fail status;\n  - any concrete blocker if a required run could not be completed.\n- Keep generated integration artifacts out of git. Do not commit\n  `.venv/`, `.pytest_cache/`, `results/`, or `__pycache__/` under\n  `tests/integration`.\n\n## Commit & Pull Request Guidelines\n- Prefix commit subjects with the component/plugin name in lowercase, e.g.:\n  - `engine: fix flush buffer handling`\n  - `in_opentelemetry: profiles: fix ingestion path`\n- Keep subject/body lines <= 80 chars.\n- Keep each commit scoped to one component/prefix; avoid mixed-area commits.\n- Sign commits with DCO: `git commit -s`.\n- PRs should include: problem statement, scope, test evidence (`ctest` output), and compatibility notes.\n- If behavior changes user output/config, include a short before/after example.\n- Target `master` for next major by default; open backport PRs to release branches (`1.x`) when needed.\n\n## Commit Pattern (Branch Practice)\n- Follow observed local history style:\n  - component/plugin: `component: short imperative description`\n  - internal tests: `tests: internal: short imperative description`\n  - integration tests under `tests/integration/`:\n    `tests: integration: short imperative description`\n  - runtime tests/binaries outside `tests/integration/`:\n    `tests: runtime: short imperative description`\n- The repository commit-prefix linter in\n  `.github/scripts/commit_prefix_check.py` is authoritative. When its inferred\n  prefix set is narrower than a hand-written nested subject, follow the linter.\n  Examples from current repo history:\n  - `include/fluent-bit/config_format/flb_cf.h` +\n    `src/config_format/flb_cf_yaml.c` => `config_format:`\n  - `tests/internal/env.c` => `env:` or `tests:`\n  - `tests/internal/fuzzers/config_map_fuzzer.c` => `config_map_fuzzer:` or `tests:`\n  - `tests/internal/config_map.c` => `config_map:` or `tests:`\n- Agents must follow this same style when proposing commit subjects or\n  `git commit` commands; do not invent ad hoc prefixes such as `environment:`\n  when the touched files map to an existing component or test area prefix.\n- When suggesting commit commands, include DCO signing by default with\n  `git commit -s` unless the user explicitly asks otherwise.\n- Keep one interface per commit. If an interface touches both `.c` and `.h`,\n  commit them together in the same commit.\n- Do not bundle different interfaces into one commit just because they support\n  the same feature. Core config-map changes, input/output/filter/custom/\n  processor plumbing, plugin changes, tests, and documentation must be split\n  into separate commits unless they are the same interface.\n- Do not mix unrelated interfaces in one commit.\n- Do not include `AGENTS.md` or other documentation updates in a code commit\n  unless the user explicitly asks for a docs+code combined commit.\n- Prefer concise one-line subjects unless extra context is required.\n- Detect and avoid bad squash commits. Do not place YAML examples, config lines,\n  or multiple subject-like prefix lines in the commit body unless they are\n  fenced code blocks.\n\n## Commit Lint Workflow\n- When the user asks for git commit commands, provide commands that also verify\n  commit-prefix lint before push or PR submission.\n- After creating a commit when the user asked for a commit, agents must run the\n  repo linter before closing the task and fix any bad commit subject\n  immediately.\n- Do not treat a local non-PR linter pass as sufficient before push. Outside\n  GitHub PR context, `.github/scripts/commit_prefix_check.py` validates only\n  `HEAD`, which can miss earlier commits in the branch.\n- Run the same checker used in CI:\n  `python .github/scripts/commit_prefix_check.py`\n- The checker requires `gitpython`. If `python -c 'import git'` fails, install\n  it before running the linter:\n  `python3 -m pip install gitpython`\n- Do not assume a generic `docs:` prefix is acceptable. Check the touched file\n  prefixes from repo history and from `.github/scripts/commit_prefix_check.py`\n  path inference before choosing a commit subject. For example, changes only to\n  `AGENTS.md` must use `agents:`, not `docs:`.\n- For pull-request-style validation, use full history and fetch the base branch\n  first, matching CI behavior. This is required because the checker can fall\n  back to validating only `HEAD` when the base ref is unavailable:\n  `git fetch --all --prune`\n  `git fetch origin <base-branch>:origin/<base-branch>`\n- Before pushing a branch or opening/updating a PR, agents must lint the full\n  PR commit range against the base branch, not just the latest commit. Use the\n  CI-style environment when possible, for example:\n  `GITHUB_EVENT_NAME=pull_request GITHUB_BASE_REF=<base-branch> python .github/scripts/commit_prefix_check.py`\n- If a commit mixes component code and integration tests, do not assume a\n  local `HEAD`-only lint pass proves the earlier code commit is acceptable.\n  Validate the whole branch range before push/PR submission.\n- When giving commit-command sequences to the user, include a final lint step\n  that checks the PR range and mention the `gitpython` install step if it may\n  be missing locally.\n\n## Agent Action Limits\n- Do not open issues, pull requests, or remote branches unless the user explicitly asks.\n- Do not rewrite git history, amend commits, or force-push unless the user explicitly asks.\n- Do not revert user changes outside the requested scope.\n- Do not edit bundled libraries under `lib/` without explicit confirmation.\n- Prefer minimal patches that avoid unrelated formatting or refactoring churn.\n\n## Agent Playbook (Pipeline Architecture Primer)\n\n### Runtime model (mental map)\n- Fluent Bit moves data through: input -> chunk -> router -> task ->\n  filter/processor -> output -> engine result handling.\n- Routing is per output instance; one chunk can fan out to many routes.\n- Route state is independent (success/retry/drop can differ per output).\n\n### Data units and boundaries\n- A **signal** is the high-level type: logs, metrics, traces, profiles, blobs.\n- A **record/event** is the logical payload unit inside a signal.\n- A **chunk** is the persisted/queued container (often MessagePack-backed).\n- A **task** is the engine execution unit for a chunk across routes.\n- Never assume \"one chunk = one route\" or \"one serialized event = one log\n  record\" in shared code.\n\n### Component responsibilities\n- Inputs (`plugins/in_*`) create/append data and trigger ingestion.\n- Input chunk layer (`src/flb_input_chunk.c`) manages lifecycle, routing masks,\n  storage pressure, and drop/release behavior.\n- Router (`src/flb_router*.c`) resolves tag/signal matches to outputs.\n- Task layer (`src/flb_task.c`) tracks per-route state and retries.\n- Filters (`plugins/filter_*`) run on matching streams before output flush.\n- Processors (`plugins/processor_*`) can run in input/output contexts depending\n  on configuration and may mutate/drop payloads.\n- Outputs (`plugins/out_*`) serialize/protocol-encode and return flush result.\n- Engine (`src/flb_engine.c`) applies final retry/drop accounting and task\n  teardown.\n\n### Signal-aware behavior rules\n- Shared paths must branch correctly by `event_type` (logs vs non-logs).\n- Some logic is meaningful only for logs (record-level semantics), while\n  metrics/traces/profiles/blobs may follow different serialization/counting.\n- Group/metadata markers can exist as serialized events; treat them as\n  transport/data-shape artifacts unless the interface explicitly requires them.\n\n### Counting and metrics guidance\n- Separate these concepts when reviewing code:\n  - serialized events in a buffer\n  - logical records after processing\n  - per-route processed/retry/drop counters\n  - byte accounting (chunk bytes vs route-effective bytes)\n- Prefer route-aware values when updating route metrics.\n- Preserve explicit zero values; use clear sentinel values for \"unknown\".\n\n### Retry/drop semantics\n- `FLB_OK`: route succeeded.\n- `FLB_RETRY`: route keeps task/chunk for retry scheduling.\n- `FLB_ERROR`: route failure/drop path.\n- Final chunk release happens only when all active routes are resolved.\n\n### Storage/backlog interaction\n- In-memory and filesystem backlog paths may use different code paths; validate\n  both when touching chunk/task lifecycle.\n- Backlog-loaded chunks must preserve route state and accounting parity with\n  live-ingested chunks.\n\n### Review checklist before patching\n- Trace one full path for affected signals: input -> chunk -> task -> output ->\n  engine completion.\n- Verify fan-out behavior (single chunk, multiple outputs).\n- Verify processing behavior (drop/modify/no-op) in both input and output\n  processor contexts.\n- Verify empty payload behavior (outputs should not crash on zero records).\n- Verify metrics/counters for success, retry, and drop paths.\n\n### Testing strategy\n- Use `tests/internal` for core lifecycle/accounting logic.\n- Use `tests/runtime` for plugin-level behavior and end-to-end semantics,\n  including Windows runtime targets supported by the active toolchain and host.\n- Add regression tests for:\n  - mixed signals\n  - processor drop/modify paths\n  - multi-route fan-out\n  - backlog + live ingestion parity\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidelines\n\n## Preferred Commands\n- Configure: `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n- Configure on Windows:\n  `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n- Build: `cmake --build build -j8`\n- Test: `ctest --test-dir build --output-on-failure`\n- Prefer targeted tests with `ctest --test-dir build -R <name> --output-on-failure`\n  when the affected area is known, because the full enabled suite can be slow.\n- Windows supports building and running runtime tests. Prefer focused\n  `flb-rt-*` targets or CTest matches because the full runtime suite can be\n  slow. The GitHub Actions unit-test workflow enables runtime execution only\n  for x64 to control CI running time. Do not apply that CI-only restriction to\n  local agents or AI cloud builds.\n- Run a focused integration test with\n  `ctest --test-dir build -R flb-it-opentelemetry --output-on-failure`\n- Run the in-tree Python integration suite with:\n  `cd tests/integration && ./setup-venv.sh && ./run_tests.py`\n- List available Python integration scenarios with:\n  `cd tests/integration && ./run_tests.py --list`\n- Run locally with `./build/bin/fluent-bit -c conf/fluent-bit.conf`\n\n## Project Structure & Module Organization\nFluent Bit is a C/C++ monorepo built with CMake.\n\n- `src/`: core engine/runtime (`flb_*` components, schedulers, routing, I/O).\n- `include/fluent-bit/`: public/internal headers used by core and plugins.\n- `plugins/`: input/filter/processor/output plugins (`in_*`, `filter_*`, `processor_*`, `out_*`).\n- `lib/`: bundled libraries (e.g., `cprofiles`, `ctraces`, `cmetrics`, `chunkio`).\n- `tests/`: integration/runtime tests and fixtures.\n- `tests/integration/`: in-tree Python integration test suite for end-to-end\n  plugin and protocol validation; introduced from the original\n  `github.com/fluent/fluent-bit-test-suite` project.\n- `conf/`: sample configurations for local validation.\n\nKeep changes scoped: plugin logic in its plugin directory, shared behavior in `src/` or `lib/`.\n\n## Bundled Library Changes\n- Treat `lib/` as bundled third-party or separately maintained code unless the\n  specific path is clearly Fluent Bit-owned.\n- Before editing bundled library code, ask for explicit user confirmation. If\n  the agent environment supports confirmation popups, use one; otherwise ask in\n  chat before writing files.\n- Prefer changes that can be sent upstream as a focused patch. Keep bundled\n  library patches isolated from Fluent Bit glue code, and document the upstream\n  project/path in the close-out.\n- Do not mix bundled library edits with unrelated Fluent Bit core, plugin,\n  documentation, or test changes in the same commit unless the user explicitly\n  asks for that structure.\n\n## Build, Test, and Development Commands\n- `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`:\n  configure runtime and internal tests, including on Windows.\n- `cmake --build build -j8`: compile Fluent Bit and tests.\n- `ctest --test-dir build --output-on-failure`: run enabled tests.\n- `ctest --test-dir build -R flb-it-opentelemetry --output-on-failure`: run a focused integration test.\n- `cd tests/integration && ./setup-venv.sh`: create the local virtualenv for\n  the Python integration suite.\n- `cd tests/integration && ./run_tests.py --list`: list available Python\n  integration scenarios.\n- `cd tests/integration && ./run_tests.py`: run the full Python integration\n  suite against `build/bin/fluent-bit`.\n- `cd tests/integration && FLUENT_BIT_BINARY=/path/to/fluent-bit ./run_tests.py`:\n  run the Python integration suite against a specific binary.\n- `./build/bin/fluent-bit -c conf/fluent-bit.conf`: run locally with a config.\n\n## Coding Style & Naming Conventions\n- Follow Apache-style C conventions used by Fluent Bit.\n- Use 4-space tabs/indentation and target 100 chars per line; 120 chars max.\n- Always use braces for `if/else/while/do` blocks.\n- Put function opening braces on the next line:\n  `int fn(void)\\n{ ... }`\n- Keep short boolean conditions on one line when they fit within 100 chars.\n- Wrap conditions only when needed, and break at logical operators (`&&`, `||`);\n  do not force one operand per line when readability does not improve.\n- Keep short function calls on one line when they fit; avoid splitting each\n  argument into separate lines unless line length or clarity requires it.\n- Declare variables at the start of functions, not mid-block.\n- Prefer descriptive `snake_case` for functions/variables and `flb_*`/`cprof_*` prefixes.\n- Use `/* ... */` comments (single or multiline), with wrapped long comments.\n\n## Testing Guidelines\n- Add or update tests for behavior changes, especially protocol parsing and encoder/decoder paths.\n- Prefer targeted tests close to the changed module (`tests/internal`, plugin runtime tests).\n- Prefer focused `ctest -R ...` runs or specific test binaries when the touched area is known.\n- Windows supports `tests/runtime`, `flb-rt-*` targets, and runtime CTest\n  matches. Configure with `-DFLB_TESTS_RUNTIME=On` and run applicable focused\n  runtime coverage. In `.github/workflows/call-windows-unit-tests.yaml`, keep\n  runtime execution disabled for x86 and ARM64 unless the workflow scope\n  explicitly changes; that exclusion controls GitHub Actions running time only.\n  It does not apply to local agents or AI cloud builds.\n- Use `tests/integration` when validating end-to-end plugin behavior, network\n  protocols, downstream request generation, or local fake-server interactions\n  that are awkward to cover in `ctest` binaries alone.\n- The Python integration suite is not part of the default CMake `ctest` targets;\n  run it explicitly from `tests/integration`.\n- Do not skip focused integration coverage for a touched component when that\n  component has a corresponding `tests/integration` scenario. Agents must run\n  the focused scenario(s) for the touched component before closing the task.\n- For touched components covered by `tests/integration`, agents must run the\n  focused scenario(s) twice:\n  - once normally to verify behavior;\n  - once with the platform memory checker enabled to verify memory-safety\n    behavior: Valgrind on Linux or Leaks on macOS.\n- The default expectation for component verification is:\n  `./tests/integration/setup-venv.sh`\n  `cmake -S . -B build -DFLB_TESTS_RUNTIME=On -DFLB_TESTS_INTERNAL=On`\n  `cmake --build build -j8`\n  `tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n  On Linux, run the memory-safety pass with:\n  `VALGRIND=1 VALGRIND_STRICT=1 tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n  On macOS, run the memory-safety pass with:\n  `LEAKS=1 LEAKS_STRICT=1 tests/integration/.venv/bin/python -m pytest <focused-scenario> -q`\n- On Windows, use the same `-DFLB_TESTS_RUNTIME=On` configuration and run\n  relevant focused runtime and functional integration cases. Valgrind and\n  macOS Leaks are normally unavailable on Windows; report that exact\n  memory-checker blocker instead of conflating it with test support.\n- Run broader test coverage when changing shared lifecycle, routing, storage, or accounting code.\n- Validate both success and failure paths (invalid payloads, boundary sizes, null/missing fields).\n- You can also run specific binaries from `build/bin` (e.g., `./bin/flb-it-opentelemetry`).\n- When changing code covered by `tests/integration`, agents must verify the\n  affected scenarios are clean under the platform memory checker. On Linux,\n  run `tests/integration/run_tests.py --valgrind --valgrind-strict ...`. On\n  macOS, run `tests/integration/run_tests.py --leaks --leaks-strict ...`. Do\n  not stop at functional pass/fail if memory errors or leaks remain.\n- If a focused integration or platform memory-checker run cannot be executed,\n  agents must not silently skip it. They must report the exact blocker in the\n  final response (for example: missing binary, missing Python environment,\n  unsupported scenario, missing dependency, or infrastructure failure).\n- Final task close-outs must include proof of verification:\n  - the exact focused integration command(s) run;\n  - which platform memory checker was used (Valgrind on Linux or Leaks on\n    macOS), or `not run` with the exact blocker;\n  - pass/fail status;\n  - any concrete blocker if a required run could not be completed.\n- Keep generated integration artifacts out of git. Do not commit\n  `.venv/`, `.pytest_cache/`, `results/`, or `__pycache__/` under\n  `tests/integration`.\n\n## Commit & Pull Request Guidelines\n- Prefix commit subjects with the component/plugin name in lowercase, e.g.:\n  - `engine: fix flush buffer handling`\n  - `in_opentelemetry: profiles: fix ingestion path`\n- Keep subject/body lines <= 80 chars.\n- Keep each commit scoped to one component/prefix; avoid mixed-area commits.\n- Sign commits with DCO: `git commit -s`.\n- PRs should include: problem statement, scope, test evidence (`ctest` output), and compatibility notes.\n- If behavior changes user output/config, include a short before/after example.\n- Target `master` for next major by default; open backport PRs to release branches (`1.x`) when needed.\n\n## Commit Pattern (Branch Practice)\n- Follow observed local history style:\n  - component/plugin: `component: short imperative description`\n  - internal tests: `tests: internal: short imperative description`\n  - integration tests under `tests/integration/`:\n    `tests: integration: short imperative description`\n  - runtime tests/binaries outside `tests/integration/`:\n    `tests: runtime: short imperative description`\n- The repository commit-prefix linter in\n  `.github/scripts/commit_prefix_check.py` is authoritative. When its inferred\n  prefix set is narrower than a hand-written nested subject, follow the linter.\n  Examples from current repo history:\n  - `include/fluent-bit/config_format/flb_cf.h` +\n    `src/config_format/flb_cf_yaml.c` => `config_format:`\n  - `tests/internal/env.c` => `env:` or `tests:`\n  - `tests/internal/fuzzers/config_map_fuzzer.c` => `config_map_fuzzer:` or `tests:`\n  - `tests/internal/config_map.c` => `config_map:` or `tests:`\n- Agents must follow this same style when proposing commit subjects or\n  `git commit` commands; do not invent ad hoc prefixes such as `environment:`\n  when the touched files map to an existing component or test area prefix.\n- When suggesting commit commands, include DCO signing by default with\n  `git commit -s` unless the user explicitly asks otherwise.\n- Keep one interface per commit. If an interface touches both `.c` and `.h`,\n  commit them together in the same commit.\n- Do not bundle different interfaces into one commit just because they support\n  the same feature. Core config-map changes, input/output/filter/custom/\n  processor plumbing, plugin changes, tests, and documentation must be split\n  into separate commits unless they are the same interface.\n- Do not mix unrelated interfaces in one commit.\n- Do not include `AGENTS.md` or other documentation updates in a code commit\n  unless the user explicitly asks for a docs+code combined commit.\n- Prefer concise one-line subjects unless extra context is required.\n- Detect and avoid bad squash commits. Do not place YAML examples, config lines,\n  or multiple subject-like prefix lines in the commit body unless they are\n  fenced code blocks.\n\n## Commit Lint Workflow\n- When the user asks for git commit commands, provide commands that also verify\n  commit-prefix lint before push or PR submission.\n- After creating a commit when the user asked for a commit, agents must run the\n  repo linter before closing the task and fix any bad commit subject\n  immediately.\n- Do not treat a local non-PR linter pass as sufficient before push. Outside\n  GitHub PR context, `.github/scripts/commit_prefix_check.py` validates only\n  `HEAD`, which can miss earlier commits in the branch.\n- Run the same checker used in CI:\n  `python .github/scripts/commit_prefix_check.py`\n- The checker requires `gitpython`. If `python -c 'import git'` fails, install\n  it before running the linter:\n  `python3 -m pip install gitpython`\n- Do not assume a generic `docs:` prefix is acceptable. Check the touched file\n  prefixes from repo history and from `.github/scripts/commit_prefix_check.py`\n  path inference before choosing a commit subject. For example, changes only to\n  `AGENTS.md` must use `agents:`, not `docs:`.\n- For pull-request-style validation, use full history and fetch the base branch\n  first, matching CI behavior. This is required because the checker can fall\n  back to validating only `HEAD` when the base ref is unavailable:\n  `git fetch --all --prune`\n  `git fetch origin <base-branch>:origin/<base-branch>`\n- Before pushing a branch or opening/updating a PR, agents must lint the full\n  PR commit range against the base branch, not just the latest commit. Use the\n  CI-style environment when possible, for example:\n  `GITHUB_EVENT_NAME=pull_request GITHUB_BASE_REF=<base-branch> python .github/scripts/commit_prefix_check.py`\n- If a commit mixes component code and integration tests, do not assume a\n  local `HEAD`-only lint pass proves the earlier code commit is acceptable.\n  Validate the whole branch range before push/PR submission.\n- When giving commit-command sequences to the user, include a final lint step\n  that checks the PR range and mention the `gitpython` install step if it may\n  be missing locally.\n\n## Agent Action Limits\n- Do not open issues, pull requests, or remote branches unless the user explicitly asks.\n- Do not rewrite git history, amend commits, or force-push unless the user explicitly asks.\n- Do not revert user changes outside the requested scope.\n- Do not edit bundled libraries under `lib/` without explicit confirmation.\n- Prefer minimal patches that avoid unrelated formatting or refactoring churn.\n\n## Agent Playbook (Pipeline Architecture Primer)\n\n### Runtime model (mental map)\n- Fluent Bit moves data through: input -> chunk -> router -> task ->\n  filter/processor -> output -> engine result handling.\n- Routing is per output instance; one chunk can fan out to many routes.\n- Route state is independent (success/retry/drop can differ per output).\n\n### Data units and boundaries\n- A **signal** is the high-level type: logs, metrics, traces, profiles, blobs.\n- A **record/event** is the logical payload unit inside a signal.\n- A **chunk** is the persisted/queued container (often MessagePack-backed).\n- A **task** is the engine execution unit for a chunk across routes.\n- Never assume \"one chunk = one route\" or \"one serialized event = one log\n  record\" in shared code.\n\n### Component responsibilities\n- Inputs (`plugins/in_*`) create/append data and trigger ingestion.\n- Input chunk layer (`src/flb_input_chunk.c`) manages lifecycle, routing masks,\n  storage pressure, and drop/release behavior.\n- Router (`src/flb_router*.c`) resolves tag/signal matches to outputs.\n- Task layer (`src/flb_task.c`) tracks per-route state and retries.\n- Filters (`plugins/filter_*`) run on matching streams before output flush.\n- Processors (`plugins/processor_*`) can run in input/output contexts depending\n  on configuration and may mutate/drop payloads.\n- Outputs (`plugins/out_*`) serialize/protocol-encode and return flush result.\n- Engine (`src/flb_engine.c`) applies final retry/drop accounting and task\n  teardown.\n\n### Signal-aware behavior rules\n- Shared paths must branch correctly by `event_type` (logs vs non-logs).\n- Some logic is meaningful only for logs (record-level semantics), while\n  metrics/traces/profiles/blobs may follow different serialization/counting.\n- Group/metadata markers can exist as serialized events; treat them as\n  transport/data-shape artifacts unless the interface explicitly requires them.\n\n### Counting and metrics guidance\n- Separate these concepts when reviewing code:\n  - serialized events in a buffer\n  - logical records after processing\n  - per-route processed/retry/drop counters\n  - byte accounting (chunk bytes vs route-effective bytes)\n- Prefer route-aware values when updating route metrics.\n- Preserve explicit zero values; use clear sentinel values for \"unknown\".\n\n### Retry/drop semantics\n- `FLB_OK`: route succeeded.\n- `FLB_RETRY`: route keeps task/chunk for retry scheduling.\n- `FLB_ERROR`: route failure/drop path.\n- Final chunk release happens only when all active routes are resolved.\n\n### Storage/backlog interaction\n- In-memory and filesystem backlog paths may use different code paths; validate\n  both when touching chunk/task lifecycle.\n- Backlog-loaded chunks must preserve route state and accounting parity with\n  live-ingested chunks.\n\n### Review checklist before patching\n- Trace one full path for affected signals: input -> chunk -> task -> output ->\n  engine completion.\n- Verify fan-out behavior (single chunk, multiple outputs).\n- Verify processing behavior (drop/modify/no-op) in both input and output\n  processor contexts.\n- Verify empty payload behavior (outputs should not crash on zero records).\n- Verify metrics/counters for success, retry, and drop paths.\n\n### Testing strategy\n- Use `tests/internal` for core lifecycle/accounting logic.\n- Use `tests/runtime` for plugin-level behavior and end-to-end semantics,\n  including Windows runtime targets supported by the active toolchain and host.\n- Add regression tests for:\n  - mixed signals\n  - processor drop/modify paths\n  - multi-route fan-out\n  - backlog + live ingestion parity\n","category":"root","tokens":4340}]}