sync_* tables have no as-of, only update_time / 为何 BPS sync_* 无 as-of、只有 update_timeEN: The as-of date is renamed down the layers — L1 dataasof (daily snapshot) → L2 asofdate → L3/stage fctrdt → L4 keeps MAX(dataasof) latest. At L5 the main table bpms.sync_loan_foreclosure drops the as-of entirely: it is a current-state table, whole-table DELETE+APPEND overwrite-refreshed (df_db_util.py:691,693), and "days in fcl" is recomputed to the run day via + datediff(dataasof, today_NY) (asset_managment_config.py:597-598). So create_time/update_time are only audit columns (may be NULL). Exception: sync_fcl_stage_info keeps fctrdt history.
中文： as-of 在各层换名：L1 dataasof（每日快照）→ L2 asofdate → L3/阶段 fctrdt → L4 取 MAX(dataasof) 最新。到 L5 主表 bpms.sync_loan_foreclosure 不再保留 as-of：它是当前态表，整表 DELETE+APPEND 覆盖刷新（df_db_util.py:691,693），且在法拍天数用 + datediff(dataasof, 运行日) 实时重算（asset_managment_config.py:597-598）。故 create_time/update_time 只是审计列（可能 NULL）。例外：阶段表 sync_fcl_stage_info 保留 fctrdt 历史。
Real example / 真实数据 (MCP-verified, loan 7727000088): Redshift port.basic_data_loan_foreclosure.dataasof=2026-06-04, stored summary_days_in_fcl=368 → BPS run 2026-06-06 → 368 + datediff(2026-06-04 → 2026-06-06) = 368 + 2 = 370 = bpms.sync_loan_foreclosure.summary_days_in_fcl（无 as-of 列；create_time/update_time NULL）。那 2 天就是 as-of，被吸收进天数。详见 docs/02_etl_pipeline.md §8.1.
数据日期一览（各表快照日期不同，统计须按所属表的 as-of 解读 / per-table as-of）：
port.portmonthbase（delinq 分布）— 最新快照 fctrdt=2025-08-01（该月度基表已冻结于此）；累计口径覆盖 2023-02-01..2025-08-01（31 快照）。port.fcl_stage_info（阶段/分组）— 最新快照 fctrdt=2026-06-07（~41 行）；累计 2025-06-04..2026-06-07（302 快照，~9,587 行）。bpms.sync_fcl_stage_info（L5 阶段）— fctrdt=2026-06-07。newrez.portnewrezfc（fill 率源）— dataasof=2026-06-08。