TenQ.get_item_with_part('Part I', 'Item 4') leaks the trailing "PART II ... OTHER INFORMATION" heading

[warzoo]

Issue Type

• Data Quality Issue (incorrect financial values, missing data)
• XBRL Parsing Issue (statement rendering, concept mapping)
• Filing Access Issue (download failures, attachment problems)
• Performance Issue (slow operations, memory problems)
• Compatibility Issue (platform/dependency conflicts)
• Documentation Issue (unclear instructions, missing examples)

Summary

TenQ.get_item_with_part(part, item) tries the new pattern-based parser
(self.sections) first, returning section.text() directly. That path has no
boundary guard for the Part II title line. The old fallback path
(ChunkedDocument.get_item_with_part → clean_part_line) does try to strip a
trailing "PART ..." line, but only when that line, after str.split("\n"),
starts with PART\s+[IVXLC]+ immediately followed by a word boundary — which
fails when the source HTML renders "PART II" and "OTHER INFORMATION" glued
together with no whitespace, or joined by a mojibake dash byte instead of a
real space/em-dash. Either way, whichever code path actually runs in 5.40.0
for this filing, the heading survives into the returned text.

This is a boundary problem, not data loss: Item 4's real body is fully present
and correct, just over-extended with the next Part's title appended after it.
Same family as bug_8k_signature_block_in_last_item.md (boilerplate section
header leaking into the last item of a part because a title line isn't
recognized as a terminal boundary).

The example is accession 0000320193-20-000052, Apple Inc.'s Form 10-Q filed
2020-05-01 (period 2020-03-28). get_item_with_part('Part I', 'Item 4')
returns 1421 chars ending in a page-footer line ("Apple Inc. | Q2 2020 Form
10-Q | 33" — a separate, pre-existing footer-bleed artifact not covered by this
report) followed by "PART II — OTHER INFORMATION".

This is not an isolated case: every 10-Q filing checked in this project's local
archive (AAPL, multiple years 2016-2021) shows the same trailing artifact on
PartI_Item4, with the separator between "PART II" and "OTHER INFORMATION"
varying across filings (no space at all, real em-dash with spaces, or a
mojibake byte) — consistent with a parser boundary bug rather than a one-off
malformed filing.

Environment

• edgartools version: 5.40.0
• Python: 3.14
• OS: Windows 11

Reproduction

import edgar
edgar.set_identity("you@example.com")

# Apple Inc. 10-Q, filed 2020-05-01, period 2020-03-28.
f = edgar.get_by_accession_number("0000320193-20-000052")
tq = f.obj()

text = tq.get_item_with_part("Part I", "Item 4")
print("Item 4 text length:", len(text))
print(text[-120:])
print("contains 'OTHER INFORMATION':", "OTHER INFORMATION" in text.upper())

Actual

Item 4 text length: 1421
--- last 120 chars ---
Company's internal control over financial reporting.

Apple Inc. | Q2 2020 Form 10-Q | 33

PART II  —  OTHER INFORMATION

contains 'OTHER INFORMATION': True

Expected

Item 4 text length: ~1360   (item body only, ending at "financial reporting.")
contains 'OTHER INFORMATION': False   (Part II's title is not part of Item 4)

Impact

Every 10-Q's Item 4 (Controls and Procedures) text saved for semantic
search / RAG carries an identical trailing "PART II ... OTHER INFORMATION"
line. It is pure noise for retrieval and dilutes the item's embedding — small
but 100% reproducible across every quarterly filing.

Workaround

Strip a trailing Part-heading line, tolerant of missing/mojibake whitespace
between the roman numeral and "OTHER INFORMATION":

import re
_NEXT_PART_HEADING_RE = re.compile(
    r"PART\s+[IVXLC]+\W*OTHER\s+INFORMATION\s*$",
    re.IGNORECASE,
)

def strip_next_part_heading(text: str) -> str:
    return _NEXT_PART_HEADING_RE.sub("", text).rstrip()

Suggested fix

Have the pattern-based section extractor (and/or
ChunkedDocument.clean_part_line's regex/rstrip logic) recognize the next
Part's title line as a terminal boundary even when there is no whitespace (or
a non-ASCII separator) between the roman numeral and the title text, so Item 4
ends before it instead of absorbing it.

Thanks for the great library — this report is intended to help improve 10-Q
item text extraction robustness for the community.

---

This issue will be handled using EdgarTools' systematic issue resolution workflow. A reproduction test will be created to verify the fix.