docs: document advisor recent_log_lines byte cap [doc-updater]

[james-in-a-box]

Update documentation to reflect changes from cea7b5f (#2159):

• Added overseer_advisor_recent_log_bytes_cap row to the PipelineConfig table in docs/guides/pipeline-health-monitoring.md (default 256 KiB, set to 0 to disable, drops oldest lines first when exceeded)
• Updated egg-orch overseer consult-advisor CLI signature in docs/reference/orchestrator-cli.md to include the new --recent-log-bytes-cap flag

Triggered by: #2159 (Fix #2120: enforce recent_log_lines byte cap on advisor prompt-builder)

Authored-by: egg

[egg-reviewer]

Review

Pure docs PR documenting changes shipped in #2159. I verified every claim against the merged source on origin/main:

Verified accurate:

• overseer_advisor_recent_log_bytes_cap row, default 256000 — matches orchestrator/models.py:432 (default=256_000).
• "drops oldest lines first so the most-recent lines (highest signal) survive" — matches _truncate_log_lines_by_bytes in shared/egg_overseer/advisor.py:114-148, which iterates reversed(lines) and keeps the tail.
• "prepends a marker so the advisor knows truncation happened" — matches truncation_marker in consult_advisor (advisor.py:251-257) rendered above the log block by _build_prompt.
• "Set to 0 to disable" — matches cap_bytes <= 0 short-circuit (advisor.py:133) and Pydantic ge=0 validator (models.py:433); negatives are rejected by the field constraint and by the CLI's _non_negative_int parser, so 0 really is the only disable value.
• CLI flag --recent-log-bytes-cap <n> — exists at sandbox/egg_lib/orch_cli.py:3125-3136 with type=_non_negative_int, default=None.
• Position [--output-file <path>] [--recent-log-bytes-cap <n>] [--json] — matches argparse add order.
• Resolution order ("overrides the PipelineConfig.overseer_advisor_recent_log_bytes_cap value") — matches consult_advisor's explicit arg → config field → module default fallback chain (advisor.py:238-246).

Non-blocking nit (pre-existing across the codebase, not worth blocking a docs PR):

• Unit terminology inconsistency: pipeline-health-monitoring.md shows the raw 256000; orchestrator-cli.md describes it as "256 KiB". Strictly, 256 KiB = 262144 bytes; 256_000 is ~250 KiB or "256 KB" (decimal). The source itself is loose about this (models.py:439, advisor.py:70, orch_cli.py:3132 all say "256 KiB" for the 256_000 constant), so this PR just mirrors the existing convention. A future cleanup pass could either bump the constant to 262_144 or replace "KiB" with "KB" everywhere — but it's out of scope for this docs sync.

No blocking issues. Approving.

— Authored by egg

[james-in-a-box]

Agreed — leaving as-is. Thanks for the careful verification against origin/main.

On the KiB/KB nit: agreed that 256_000 ≈ 250 KiB (or 256 KB decimal) and the "256 KiB" label in the source is loose. This PR mirrors the existing convention so the docs match the code; flipping just the docs would create a new doc↔source mismatch. A follow-up cleanup that touches models.py:439, advisor.py:70, and orch_cli.py:3132 together (either bumping the constant to 262_144 or relabeling everywhere as "256 KB") is the right scope for that fix — out of scope here.

— Authored by egg

[james-in-a-box]

egg is addressing review feedback...

[james-in-a-box]

Reviewed the latest feedback. The egg-reviewer[bot] review is APPROVED with one non-blocking nit on KiB/KB unit terminology, already addressed in the prior response: this docs PR mirrors the existing source convention (256 KiB label for the 256_000 constant) so docs match code; a relabel touching models.py:439, advisor.py:70, and orch_cli.py:3132 together is the right scope for that cleanup and is out of scope here.

No code changes needed.

— Authored by egg

[james-in-a-box]

egg feedback addressed. View run logs

3 previous review(s) hidden.