Follow up future review note: **Markdown Variants**: Consider supporting other common Markdown variants such as bolded h

[wwind123]

Future follow-up from approved review on PR #79.

Reviewer: Gemini

Follow-up:

• Markdown Variants: Consider supporting other common Markdown variants such as bolded headings (e.g., ### **Future follow-ups**) or headings ending with other punctuation like a period if they are observed in practice. The implementation is surgical and the new test case provides good coverage for the reported bug.

This was mentioned in an approved review as future work and did not block merge readiness.

[wwind123]

Implementation plan for issue #80:

1. Update follow-up heading recognition in protocol.py by replacing the three near-duplicate heading regexes with a small shared helper or shared suffix pattern that accepts:

   • Plain headings: ### Future follow-ups
   • Bolded heading text: ### **Future follow-ups**
   • Existing trailing colon form: ### Future follow-ups:
   • Likely punctuation form from the issue: ### Future follow-ups.
   • The same variants for Same-PR follow-ups and legacy Non-blocking follow-ups

2. Keep matching conservative:

   • Still require Markdown heading markers ## through ######.
   • Still require the exact known section names, allowing only existing hyphen/space flexibility.
   • Allow optional bold markers around the full heading title, not arbitrary inline Markdown.
   • Allow at most one trailing punctuation mark from a small set, probably :, ., optionally ?/! only if reviewers agree.
   • Ensure ANY_HEADING_RE continues to terminate active sections at unrelated headings.

3. Add focused regression coverage in tests/test_agent_loop.py:

   • Extend the existing follow-up parser tests with a parametrized test covering bolded headings for same-PR, future, and legacy sections.
   • Add coverage for headings ending in a period.
   • Preserve the existing colon test so PR Parse approved followup headings with colons #79 behavior remains covered.
   • Include at least one negative/control case if the implementation becomes more permissive, such as ensuring unrelated bold headings still terminate rather than parse.

4. Test strategy:

   • Run python -m pytest tests/test_agent_loop.py -k followups for targeted parser coverage.
   • Run full python -m pytest afterward because follow-up parsing feeds orchestrator behavior and issue creation tests elsewhere in the same test file.

No implementation files were edited during this planning pass.

-- OpenAI Codex

[wwind123]

Plan Review — Issue #80: Markdown Variant Heading Support

Scope and architecture fit: Confirmed correct. Changes are confined to protocol.py (lines 15–17, the three heading regexes) and tests/test_agent_loop.py. No other files are affected.

Current baseline: The three regexes already handle plain headings and trailing colons via :?. The plan extends them to also accept **bold** wrappers and a trailing period — a natural, minimal extension.

Correctness observations:

1. Bold matching placement is well-defined. ### **Future follow-ups** puts ** immediately after the #-space prefix and again after the closing word. A pattern like \*{0,2}...\*{0,2} before and after the name text is straightforward. No ambiguity there.

2. Bold + punctuation ordering. One edge case worth handling explicitly: ### **Future follow-ups**: (punctuation outside the closing **) vs ### **Future follow-ups:** (punctuation inside). LLM output could produce either. The implementation should support both orderings; the test suite should cover at least the outside-bold-closing form since that's the more natural Markdown rendering.

3. ANY_HEADING_RE compatibility. Already correct: r"^\s*#{1,6}\s+\S" matches ** as a non-whitespace character, so bold headings that don't match the known section names will still terminate active sections. No change needed there.

4. Single-asterisk italic (*text*): The plan correctly limits support to ** only, which is the right conservative call. Italic headings are unlikely in practice.

5. Negative test case. The plan calls out covering "unrelated bold headings still terminate rather than parse." This is important — confirm a heading like ### **Summary** does not accidentally activate a follow-up section.

Test strategy: Solid. Parametrizing across all three section types (same-PR, future, legacy) for bold and period variants will provide thorough regression coverage. Preserving the PR #79 colon tests is correct.

No blocking issues. The one implementation detail to nail down (bold+punctuation ordering) is minor enough to resolve during coding without changing the plan's structure.

-- Anthropic Claude

[wwind123]

The implementation plan for issue #80 is well-conceived and addresses the requirements effectively. Supporting Markdown variants like bolding and additional punctuation for follow-up headings will improve the robustness of the parser when interacting with various LLMs or human reviewers.

Review Summary

• Correctness: The plan accurately identifies the necessary changes in src/coding_review_agent_loop/protocol.py. The proposed regex structure (optional bolding, specific section names, optional trailing punctuation) matches the intended behavior.
• Architecture Fit: Refactoring the three similar regexes into a shared helper or using a shared pattern is an excellent cleanup that reduces duplication and makes the parser easier to maintain.
• Edge Cases:
  • The plan correctly prioritizes conservative matching by requiring exact section names and limiting punctuation to a small, safe set (:, .).
  • The suggestion to include ? or ! as optional punctuation is acceptable, though less likely to be seen in practice.
  • I recommend ensuring that both ** and __ are supported for bolding, as both are standard Markdown.
• Test Strategy: The proposed testing approach is thorough. Using parametrized tests in tests/test_agent_loop.py to cover variants while preserving existing colon-based tests ensures both new functionality and regression safety. The inclusion of negative/control cases is particularly valuable for ensuring the parser doesn't become over-permissive.

Recommendation

Proceed with the implementation as planned. When implementing the shared helper for regexes, consider supporting both ** and __ for bolding to be fully compliant with common Markdown variants.

-- Google Gemini

[wwind123]

Planning complete for issue #80.

Outcome: implement

Approved plan:

Implementation plan for issue #80:

1. Update follow-up heading recognition in protocol.py by replacing the three near-duplicate heading regexes with a small shared helper or shared suffix pattern that accepts:

   • Plain headings: ### Future follow-ups
   • Bolded heading text: ### **Future follow-ups**
   • Existing trailing colon form: ### Future follow-ups:
   • Likely punctuation form from the issue: ### Future follow-ups.
   • The same variants for Same-PR follow-ups and legacy Non-blocking follow-ups

2. Keep matching conservative:

   • Still require Markdown heading markers ## through ######.
   • Still require the exact known section names, allowing only existing hyphen/space flexibility.
   • Allow optional bold markers around the full heading title, not arbitrary inline Markdown.
   • Allow at most one trailing punctuation mark from a small set, probably :, ., optionally ?/! only if reviewers agree.
   • Ensure ANY_HEADING_RE continues to terminate active sections at unrelated headings.

3. Add focused regression coverage in tests/test_agent_loop.py:

   • Extend the existing follow-up parser tests with a parametrized test covering bolded headings for same-PR, future, and legacy sections.
   • Add coverage for headings ending in a period.
   • Preserve the existing colon test so PR Parse approved followup headings with colons #79 behavior remains covered.
   • Include at least one negative/control case if the implementation becomes more permissive, such as ensuring unrelated bold headings still terminate rather than parse.

4. Test strategy:

   • Run python -m pytest tests/test_agent_loop.py -k followups for targeted parser coverage.
   • Run full python -m pytest afterward because follow-up parsing feeds orchestrator behavior and issue creation tests elsewhere in the same test file.

No implementation files were edited during this planning pass.

-- OpenAI Codex

-- coding-review-agent-loop