feat(agentic): configure proposer completion budget

[cgfixit]

Summary

Makes the existing real-repo proposer completion budget configurable. Default remains 2048; no new agent framework is introduced.

Invariant / CG-Security Invariant Check (CyClaw)

• Preserves I6 module isolation and the existing default-off real-repo/cloud gates.
• Positive integer validation happens at the agentic config boundary.
• No core RAG, graph routing, telemetry, filesystem authority, or provider eligibility changed.

Verification Steps before commit

• Python 3.12 focused config, plan-handoff, CLI, and real-loop pytest suite passed.
• Ruff passed; invariant guard passed (33/0); doc sync found 0 drift; staged diff check passed.
• Fresh-main throwaway trial merge passed without conflicts or unmerged files.
• Bandit is not installed in this environment; its result is not claimed.

Scope and risks

• planner_max_tokens reaches only real-repo plan/coding calls; it does not alter the separate harness optimizer.
• Raising it can exceed the available Ollama context or the existing timeout; default 2048 preserves current behavior.
• Remote CI remains pending.

[github-actions]

PR template check (advisory, non-blocking)

This PR body doesn't look like it covers everything .github/PULL_REQUEST_TEMPLATE.md expects:

• Risks to monitor (e.g. ## Risks to monitor, ## Risk)

This isn't a required check -- it won't block merge. See the template's own "Notes for contributors" for which sections lighter-path PRs can skip.

[cgfixit]

Nice fix — this closes the "no config knob" gap cleanly. One thing worth flagging before this merges, since the PR body already identifies raising the default as an open tradeoff without resolving it:

The 2048 default itself is very likely too small for real_repo_loop's actual output shape, independent of whether it's configurable. The module's planner protocol is documented whole-file replacement (real_repo_loop.py's own docstring: "the planner protocol is whole-file replacement"), and _parse_file_blocks requires a closing === END FILE === marker (the regex is re.DOTALL anchored on both markers). If a completion gets cut off mid-file at the 2048-token boundary — easy to hit for even one moderately-sized Python file, let alone a multi-file patch — the block regex simply won't match, and the iteration fails with no useful signal that "truncation" was the cause, burning one of max_iterations for free every time it happens.

Both proposer paths share this exposure identically: LocalProposerClient.invoke() (model_adapter.py) and ChatModelProposerClient.invoke() (chat_client.py) both default max_tokens=2048 on the same ProposerClient Protocol, and neither of the two real call sites in real_repo_loop.py overrides it — this PR's own diff confirms that by threading the same 2048 through explicitly rather than changing it.

Not asking for a change in this PR — the config knob standing alone is a legitimate, well-scoped fix. Just flagging that "raise it after measuring" (per your new comment) may be closer to "raise it as a follow-up default-value change" than an edge case, since the failure mode is silent (a rejected iteration, not an error naming truncation as the cause). Happy to pick up a small follow-up PR bumping the default once this lands, if useful — didn't want to submit a competing edit to the same lines while this is still open.

---

Generated by Claude Code

---

Generated by Claude Code