@tdd @tdd_issue @tdd_issue_10878
Feature: Delimiter _parse_file_blocks handles embedded markdown code fences (#10878)
  Bug #10878 caused architecture reviews to be truncated because the old
  backtick delimiter pattern stopped at the first ``` appearing *inside*
  LLM-generated file content. All subsequent sections were lost - for
  example a report with 9 TOC entries produced only 3 before truncation.

  The fix introduces unique sentinel markers:
    <<<<<<< CLEVERAGENTS_FILE_START >>>>>>>   /   <<<<<<< CLEVERAGENTS_FILE_END >>>>>>>

  This regression test proves the new sentinel delimiters do NOT collide
  when file bodies contain triple-backtick markdown code fences.

  Forgejo: #10878


# -------------------------------------------------------------------
  # Main regression - embedded ```python code fences inside FILE blocks
  # -------------------------------------------------------------------

@tdd_issue @tdd_issue_10878
Scenario: New delimiter parses all FILE blocks when each body contains embedded ```python code fences
    Given an LLM response with two FILE blocks, each having ```python sections in the body
    And a mock plan_id "01HQREGTEST"
    When I parse file blocks using the new CLEVERAGENTS_FILE_START / CLEVERAGENTS_FILE_END delimiter pattern
    Then it should return 2 changeset entries


# -------------------------------------------------------------------
  # Real-world architecture-review pattern (the original bug)
  # -------------------------------------------------------------------

@tdd_issue @tdd_issue_10878
Scenario: Full regression - report header + three FILE blocks each with inline markdown code fences
    Given an LLM response mimicking an architecture review with report prose and three FILE blocks each containing markdown code example triple-backticks in their body
    And a mock plan_id "01HQARCHTEST"
    When I parse file blocks using the new CLEVERAGENTS_FILE_START / CLEVERAGENTS_FILE_END delimiter pattern
    Then it should return the full entry count of all embedded blocks


# -------------------------------------------------------------------
  # Edge case - trailing ``` at end of file body before END marker
  # -------------------------------------------------------------------

@tdd_issue @tdd_issue_10878
Scenario: A FILE block whose last line before the END sentinel is exactly ``` parses correctly
    Given an LLM response where a single FILE block body ends on a line that is exactly ``` after code content
    And a mock plan_id "01HQTRAILT"
    When I parse file blocks using the new CLEVERAGENTS_FILE_START / CLEVERAGENTS_FILE_END delimiter pattern
    Then it should return 1 changeset entries


# -------------------------------------------------------------------
  # Edge case - sentinel text mentioned inline without full markers
  # -------------------------------------------------------------------

@tdd_issue @tdd_issue_10878
Scenario: LLM body mentions 'CLEVERAGENTS_FILE_END' in prose but does not use the full sentinel marker
    Given an LLM response where a FILE block body contains the word 'CLEVERAGENTS_FILE_END' referenced in prose within content and another file follows
    And a mock plan_id "01HQSENTINEL"
    When I parse file blocks using the new CLEVERAGENTS_FILE_START / CLEVERAGENTS_FILE_END delimiter pattern
    Then it should return 2 changeset entries (second entry has content in body)


# -------------------------------------------------------------------
  # Edge case - git merge-conflict markers alongside new delimiters
  # -------------------------------------------------------------------

@tdd_issue @tdd_issue_10878
Scenario: FILE block bodies contain git merge-conflict-style markers but only the CLEVERAGENTS sentinels match
    Given an LLM response where FILE block bodies include text like '>>>>>>> some_branch' and '<<<<<<< base' but the actual delimiters are CLEVERAGENTS_FILE_START / CLEVERAGENTS_FILE_END markers
    And a mock plan_id "01HQGITTEST"
    When I parse file blocks using the new CLEVERAGENTS_FILE_START / CLEVERAGENTS_FILE_END delimiter pattern
    Then it should return 2 changeset entries


# -------------------------------------------------------------------
  # Escape support for delimiter markers in file content (#262743)
  # -------------------------------------------------------------------

@tdd_issue @tdd_issue_10878
Scenario: Escaped marker occurrences inside file body are not treated as boundaries
    Given an LLM response with a single FILE block using legacy markers where the body contains a backslash-escaped <<<<<<< CLEVERAGENTS_FILE_START >>>>>>> sequence that should be preserved as literal text
    And a mock plan_id "01HQESCTEST"
    When I parse file blocks using the new delimiter pattern
    Then it should return 1 changeset entries