feat(hospital): T2 (4/n) — dot-source 映射表 + 评分 port (#47) - #76
Conversation
T2 step 4 (#47) — the evidence the classification document said had to exist before any PowerShell deletion. It overturns the working assumption for about half the surface. Duplicated, safe to retire: the nine code-evidence symbol extractors (native_code_evidence.rs handles every extension they do plus more, runs as the live evidence.native-code node, and already carries an explicit legacy-parity test), the three sentrux gate metric helpers (sentrux_gate.rs is exercised on every CI run and caught two god-file regressions in this campaign alone), and the hospital state-machine helpers. Not duplicated: hospital scoring. The Rust hospital emits null for triage.overall_score, report_quality.overall_score, diagnostic_score and governance_score, and an empty dimensions array, where the PowerShell producer computes 46 / 46 / 50 / 33 with a populated dimensions list on the same repository at the same commit. hospital_diagnosis.rs:410,425 hardcodes those nulls — not a TODO, not a failure path. Nine of the sixteen PowerShell hospital test cases exist to pin that scoring behaviour, so deleting them would remove the only coverage of logic that lives in exactly one place. A second, smaller candidate gap is flagged with `?` rather than asserted: the Rust ladder ends at post_op and no test names discharge_ready, so "discharge requires affirmative resolved post-op target evidence" may also lack a counterpart. It needs its own check. Whether hospital scoring survives is a product decision the code cannot answer, so it is recorded rather than guessed: porting it is real work, and dropping it means the null fields are the intended contract and docs/hospital-mode.md has to stop listing overall_score and dimensions as reader surface. Refs #47
T2 step 4 outcome (#47). The parity map found that hospital scoring was never duplicated — the Rust hospital hardcodes `null` for every score while the PowerShell launcher computes real values, so the logic lives in exactly one place and that place is the file T2 is retiring. Porting it is a prerequisite for deleting the launcher, not a nice-to-have. `hospital_score.rs` carries the arithmetic: step scores, the banded import resolution score, source coverage, pollution classification and score, rules score, and the governance/diagnostic/overall composition. The parity trap worth naming: `[math]::Round` in .NET is banker's rounding, half to even, and the launcher relies on the default. Rust's `f64::round` rounds half away from zero. Three of five midpoint cases disagree, and midpoints are reachable — these are three- and four-term averages of integers. `round_half_to_even` exists for that reason and is pinned by test. Verified against the original rather than against my own reading of it: the PowerShell functions were dot-sourced out of run-code-intel.ps1 and executed, and every ported value matches. import 100,100,75,75,50,50,30,30 | null=0 coverage 100,100,50,0,0 step 100,0,0,0 | null=0 rounding 2,4,-2,0,2 worked governance=100 diagnostic=0 overall=70 ratio 33.3 / 66.7 Deliberately not wired yet, and `allow(dead_code)` says so with the reason. Roughly half the launcher's score inputs — DSM scope for pollution, CodeNexus context for MRI, runtime CI health for PET — have no Rust producer; they are T5's surface. Feeding the arithmetic inputs the pipeline does not produce would publish confidently wrong scores, which is worse than the nulls it replaces. `0` in this scheme means observed-and-absent, not never-attempted — the same distinction d029b3f drew for structural evidence. cargo test 45 suites 0 failed; cargo fmt --check clean; sentrux gate no degradation (coupling improved 45.79 -> 45.65). Refs #47
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Warning Review limit reached
Next review available in: 40 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds a pure Rust hospital scoring module with banker’s rounding, component and composite scores, comprehensive tests, CLI module wiring, and documentation comparing the implementation with the PowerShell parity contract. ChangesHospital scoring
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
crates/code-intel-cli/src/hospital_score.rs (1)
137-150: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReplace the nine positional score arguments with a typed input struct.
All arguments are
i64, so swapped score dimensions compile silently; Clippy also flags this signature. Use named fields (for example,ScoreInputs) to make composition call sites self-describing.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/code-intel-cli/src/hospital_score.rs` around lines 137 - 150, Replace the positional parameters of compose with a typed input struct such as ScoreInputs containing named i64 fields for all nine score dimensions. Update compose to read those fields when calculating governance, diagnostic, and overall scores, and update every call site to construct the struct with explicit field names.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/ps1-exit/t2-dot-source-parity-map.md`:
- Around line 17-22: Update the parity map’s hospital scoring / measurements row
to reference the Rust hospital scoring module and mark the arithmetic as
implemented, with the remaining gap limited to launcher wiring and unavailable
input producers. Revise the test-coverage claims and open-product-question
section to reflect the Rust scoring and parity tests. Retain `null` only as the
current behavior when the launcher is unwired, not as evidence that Rust lacks
scoring.
---
Nitpick comments:
In `@crates/code-intel-cli/src/hospital_score.rs`:
- Around line 137-150: Replace the positional parameters of compose with a typed
input struct such as ScoreInputs containing named i64 fields for all nine score
dimensions. Update compose to read those fields when calculating governance,
diagnostic, and overall scores, and update every call site to construct the
struct with explicit field names.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 75e6a638-7143-4c04-9e12-fbe398988c00
📒 Files selected for processing (3)
crates/code-intel-cli/src/hospital_score.rscrates/code-intel-cli/src/main.rsdocs/ps1-exit/t2-dot-source-parity-map.md
…hips with CodeRabbit review on #76. The document was written before hospital_score.rs existed and then shipped alongside it, so within one PR the map claimed Rust has "none" for hospital scoring while the branch added exactly that. Left as-is it would drive a duplicate re-port or a wrong deletion decision later. The map now separates translation from integration: the arithmetic is ported and verified value-for-value against the dot-sourced PowerShell originals, while the launcher is unwired and several inputs still have no Rust producer. The pre-port null measurement is kept, relabelled as the evidence that made this a finding rather than as current-state. Adds §3.2, the input availability table behind the wiring block — governance, graph, source coverage and import resolution have Rust producers; pollution (DSM scope), MRI (CodeNexus context), PET (runtime CI) and memory (repowise) do not, and DSM belongs to T5 (#50). §4 stops posing the product question as open: it was escalated and settled — scoring survives and ports, so the null fields are not the intended contract. Records the consequence honestly: run-code-intel.ps1 cannot reach <=50 lines until the wiring lands, while the twelve genuinely duplicated functions are unblocked and can retire first. Refs #47
1 participant
T2 步骤 4：dot-source 映射表 + hospital 评分 port
分类文档里我明确标为「不能当删除依据」的那条假设，验证完了 —— 它对约一半的面是错的。
结论：分裂得很干净
native_code_evidence.rssentrux_gate.rshospital_diagnosis.rs重复的那部分证据：
native_code_evidence.rs覆盖 PS1 那 6 种语言之外还多 7 种扩展名，是活的evidence.native-code节点（本仓自扫产出 2993 个符号），而且已经带一条针对旧生产者的 parity 测试。sentrux_gate.rs每次 CI 都在跑 —— 这个战役里已经抓到我两次 god-file 回归，生产使用比单测更硬。不重复的那部分，同仓同 commit 实测：
triage.overall_scorereport_quality.overall_scorediagnostic_scoregovernance_scoredimensionshospital_diagnosis.rs:410,425是硬编码的 null，不是 TODO 也不是失败路径。PS1 那 16 个 hospital 用例里有 9 个专钉这套评分 —— 删掉不是去重，是删掉唯一一处该行为的覆盖。所以先 port 评分
hospital_score.rs：step 分数、分档的 import resolution、source coverage、pollution 分类与分数、rules 分数、governance/diagnostic/overall 组合。值得单独点名的 parity 陷阱：.NET 的
[math]::Round是银行家舍入（半数取偶），launcher 用的是默认行为。Rust 的f64::round是半数远离零。五个中点用例里三个不一致，而中点是可达的 —— 这里全是整数的三项/四项平均。round_half_to_even就是为此存在，有测试钉死。不是拿我自己的理解验的 —— 把 PS1 原函数从
run-code-intel.ps1里 dot-source 出来实际执行，逐值对拍：全部吻合。
刻意不接线，
allow(dead_code)里写明原因launcher 的评分输入约有一半在 Rust 侧没有生产者：DSM scope（pollution）、CodeNexus context（MRI）、runtime CI health（PET）—— 那些是 T5 的面。
拿流水线不产出的输入去喂这套算术，会发布自信地算错的分数，比它要替换的 null 更糟。这个体系里
0的含义是「观察到且缺失」，不是「从未尝试」—— 和d029b3f为结构化证据划的是同一条界。另一个用
?标记而非断言的疑似缺口Rust 阶梯止于
post_op，没有测试提到discharge_ready，所以 PS1 的「discharge requires affirmative resolved post-op target evidence」可能也没对应。需要单独查证，我没下结论。验证
cargo test45 套 0 失败、cargo fmt --check干净、sentrux gateNo degradation（耦合还降了 45.79 → 45.65）。Refs #47