"""Read a final-report's clarification rows, whichever schema wrote them.

A clarification is what a run owes the user — a decision, a file attachment,
a single data point. Each row carries a ``Blocks`` value out of
``{approval, next-phase, none}``. Rows with ``Blocks=approval`` are the
approval gate: they MUST resolve before the user flips the frontmatter
``approved`` field to ``true`` and starts the next ``implementation`` run.
A ``request-revision`` / ``reject`` answer still blocks the report that has
not yet incorporated it. The report that recorded the same id in
``supersessionLedger`` has already absorbed that return and does not block.

The two schemas store those rows in different places, and that is why the
read functions take a report **path**, not its text:

* schema-v1 — the ``## 1. Clarification Items`` markdown table (introduced
  when §4.5.9 / §5.1 / §5.2 collapsed into a single section).
* schema-v2 — ``clarificationItems[]`` in the ``.data.json`` sibling. Its AI
  handoff markdown renders them as one section per row under
  ``## Clarification and User Decisions``, not as a §1 table, so the §1 table
  walk finds nothing there by construction.

Every gate goes through ``scan_approval_gate`` / ``scan_open_user_input`` so
run-prep (``_validate_approved_plan``), the wizard, and the user-response CLI
cannot disagree about what is still open.

Gate semantics are fail-closed: when the rows cannot be read with confidence
(§1 heading missing/drifted, table header unrecognized, a body row whose
metadata cell fails to parse, or a v2 row missing id/blocks/status), the scan
reports an ``unreadable_reason`` and callers must refuse approval instead of
soft-passing. ``parse_clarification_items`` keeps the lenient
None-on-absence contract for the schema-v1 HTML-view renderers, which only
need best-effort row extraction.

구현은 여섯 층으로 나뉜다 — `parsing` · `dispositions` 가 바닥이고,
`rows` · `sidecars` 가 그 위, `scan` · `carry` 가 그 둘을 쓴다. 이 파일은
밖으로 나가는 이름만 모아 둔다.
"""
from __future__ import annotations

from .parsing import (
    ClarificationItem,
    _CELL_ANCHOR_RE,
    _section_1_slice,
    _split_pipe_row,
    parse_clarification_items,
    parse_meta_cell,
    section_1_present_but_unparsed,
)
from .dispositions import (
    APPROVAL_BLOCKS,
    PROCEEDING_DISPOSITIONS,
    USER_INPUT_BLOCKS,
    clarification_disposition,
    incorporated_clarification_ids,
    progress_blocking_ids,
    row_blocks_progress,
)
from .rows import (
    STRUCTURED_REPORT_VERSIONS,
    read_clarification_rows,
)
from .sidecars import (
    attached_user_responses_section,
    sidecar_answers,
    user_response_sidecars,
)
from .scan import (
    scan_approval_gate,
    scan_open_user_input,
)
from .carry import (
    UNRESOLVED_STATUSES,
    carried_clarification_rows,
    clarification_response_with_sidecars,
)

__all__ = [
    "APPROVAL_BLOCKS",
    "ClarificationItem",
    "PROCEEDING_DISPOSITIONS",
    "STRUCTURED_REPORT_VERSIONS",
    "UNRESOLVED_STATUSES",
    "USER_INPUT_BLOCKS",
    "_CELL_ANCHOR_RE",
    "_section_1_slice",
    "_split_pipe_row",
    "attached_user_responses_section",
    "carried_clarification_rows",
    "clarification_disposition",
    "clarification_response_with_sidecars",
    "incorporated_clarification_ids",
    "parse_clarification_items",
    "parse_meta_cell",
    "progress_blocking_ids",
    "read_clarification_rows",
    "row_blocks_progress",
    "scan_approval_gate",
    "scan_open_user_input",
    "section_1_present_but_unparsed",
    "sidecar_answers",
    "user_response_sidecars",
]