You are reviewing a single code comment. Decide whether it s...

Prompt

You are reviewing a single code comment. Decide whether it should exist. ## Default Code should be self-explanatory. Comments are a last resort. A comment is justified only when BOTH are true: 1. The fact cannot be expressed safely in the code itself (naming, types, assertions, structure, tests, or a small refactor would not carry it). 2. Omitting it would likely send a developer or coding agent down a costly, incorrect path (data loss, security hole, subtle bug, breaking an external contract, undoing a deliberate workaround, or wasting significant time). Facts that usually qualify: non-obvious invariants that no test can enforce, external-system quirks or bugs being worked around, ordering or timing constraints imposed from outside, legal or compliance constraints, intentional deviations from the obvious approach and the reason for them. Facts that usually do not qualify: what the code does, restating names or types, history or authorship, TODOs without a tracking reference, hedging, commented-out code, section headers that a function boundary would replace. ## Input You receive the comment, the surrounding code, and any available context (tests, callers, docs). ## Verdict Emit exactly one of: - keep — the comment meets both criteria and is accurate, minimal, and placed where it will be read before the mistake is made. - remove — the comment fails criterion 1 or 2, or the code already conveys it. - rewrite-comment — the fact qualifies, but the comment is inaccurate, vague, too long, misplaced, or missing the "why" or the consequence of ignoring it. - rewrite-code — the fact does not need a comment because the code can be changed to carry it (rename, extract, add a type or assertion, add a test, restructure). Decision order: first ask whether the code can carry the fact (→ rewrite-code). Only then ask whether the comment is needed at all (→ remove) and whether it is good enough (→ keep / rewrite-comment). Prefer rewrite-code over keep whenever the code change is small and safe. ## Output format verdict: <keep | remove | rewrite-comment | rewrite-code> reason: <one or two sentences naming which criterion passed or failed> risk_if_omitted: <the concrete wrong path a reader would take, or "none"> proposal: <for rewrite-comment: the new comment text; for rewrite-code: the specific code change; otherwise omit> Rules: - Judge only the comment given. Do not review other code. - Be conservative with keep. If in doubt between keep and rewrite-code, choose rewrite-code. - Do not invent context. If the surrounding code is insufficient to decide, say so in reason and give the verdict that is safest to reverse (keep). --- ```rs impl SearchResultInput { #[must_use] pub const fn relevance_tier(&self) -> u16 { match self { Self::CandidateJob { relevance_tier, .. } | Self::DirectoryProfile { relevance_tier, .. } => *relevance_tier, } } /// Whether the result met the searcher's stated hard constraints. Directory /// results have no such notion, so they are never demoted by this key. #[must_use] pub const fn hard_constraints_satisfied(&self) -> bool { match self { Self::CandidateJob { components, .. } => components.hard_constraints_satisfied, Self::DirectoryProfile { .. } => true, } } #[must_use] pub const fn target_id(&self) -> Uuid { match self { Self::CandidateJob { job_content_version_id, .. } => job_content_version_id.as_uuid(), Self::DirectoryProfile { profile_snapshot_id, .. } => profile_snapshot_id.as_uuid(), } } } ```