Repository navigation
content_repo 存在 repositories→services 逆向 import(分层既有违例) #113
Description
现状
backend/app/repositories/content_repo.py:870 与 :912 两处函数内 from app.services.scoring_engine import CONFIG as SCORING_CONFIG——repositories 层 import services 层,属 AGENTS.md 2.2 分层表逆向依赖。
机器检查(make layering / check_layering.py)只作用于 app/api/v1/,不覆盖此文件,所以一直静默存在。PR #111 独立 Verifier 复核发现(既有现状,非 #111 引入;#111 未触碰也未恶化)。
修法建议
读 CONFIG 的两个函数(list_for_today_window 一类时间窗查询)本质是「用引擎口径过滤」的查询编排,可选:
- 把 risk_threshold 作为参数由 services 层调用方传入(repo 回到纯 ORM 封装);
- 或将这两个查询的口径过滤上移到 service。
属低优先级清理,建议下次触碰 content_repo 时顺手处理,不必单独开 PR。
Activity
fxbin commentedon Oct 18, 2026
范围更正（取证核实的全量清单）
repositories→services 逆向 import 实际为 5 处、2 个文件，比本 issue 报告的 2 处多：
content_repo.py:870/:912CONFIG["risk_threshold"]app/core/content_repo.py:598normalize_tag_key（纯函数，零依赖）app/core/analysis_repo.py:14-15score_items+get_feedback_scores「低优先级、下次顺手处理」的前提已不成立——人工清单漏了 60% 的违例，这本身就是要上机器门禁的论据。
修复方案（圆桌四席收敛，记录见本地）：
scoring_caliber.py/tag_normalization.py都是零依赖的口径单一事实源模块，从app/services/搬app/core/（core 是各层合法底座，content_repo 已 import core 三处）；check_layering.py新增「repositories 禁止 import app.services」AST 检查；analysis_repo 两处进显式 allowlist（引用 analysis_repo 评分编排上移 services（清空 layering allowlist） #122，棘轮式收缩）；门禁落地后本 issue 关闭；剩余部分由 #122 跟踪。
fix(scoring): 口径常量下沉 core + repositories 逆向依赖门禁 + 前端口径镜像门禁 (#113 #112) (