feat(gate): G1 -- computed honesty bit for repin's scan coverage

[2233admin]

What

Gate G1 of the project charter (#139, tracked in #138): the honesty bit is
computed, not asserted.

Adds EvidenceOutcome (crates/code-intel-cli/src/evidence_outcome.rs) — a
completeness claim for one evidence-producing surface, with three states:

• Complete(EvidenceScope) — the surface was fully enumerated. The only
  constructor for this variant takes an EvidenceScope (artifact types
  consumed, paths scanned, excluded prefixes); there is no way to build a
  Complete in Rust without one.
• Partial { reason: PartialReason, scope: EvidenceScope } — reason is
  Truncated, CapHit, or UnreadableInput(paths); scope says what was
  covered despite the gap.
• NotComputed { reason: String } — the surface was never evaluated, and why.

Applied end to end to one real surface: repin's scan-coverage claim.

Why repin, not the risk/context truncation surfaces

I read evidence_query.rs, change_risk/, hospital_diagnosis.rs, and
repin.rs before choosing. The risk/context "callers/co-change/tests-to-run"
truncation pattern described in #138's body doesn't exist as code in this
repo today — I grepped for callers_total, tests_to_run, cochange, etc.
and found no matches; that description characterizes a different product's
existing shape, not something already broken here. change_risk's caps
(FILES_TOUCHED_CAP, LINES_CHANGED_CAP) saturate a score, not a coverage
claim — there's no "clean"-style pass/fail bit being asserted there today.

repin is where the silent-lie failure mode is real and already reported
(#133): repin --write --json printed "clean": true, "filesChanged": 0
while digests it never scanned were stale. Reading repin.rs end to end, I
found and reproduced a second, cheaper instance of the same shape today,
independent of #133's own root cause (which is about digest tracking across
commits, not about scan enumeration — a separate, larger fix):

# exclude the only tracked file out of the scan surface
$ code-intel repin --repo <repo-with-one-file> --exclude only.rs --json
{ "clean": true, "filesChanged": 0, ... }   # exit 0

A scan that covered zero files reported exactly the same clean: true
shape as a scan that covered everything and found it clean — the report
gives a downstream reader no way to tell "checked, and it's fine" from
"never checked." That's the concrete proof-of-need for this surface.

repin.rs was also not the concurrently-edited file (native_code_evidence.rs
chunk-emission work is untouched by this PR — confirmed via git diff --stat
before push).

What changed in repin

RepinReport now stores one EvidenceOutcome, computed once in
scan_coverage() from the exact same scan_targets / skipped data every
other field on the report is built from:

• Empty scan_targets after exclusions → NotComputed (the bug above).
• Any gates_clean skip (too-large / unreadable input) → Partial with
  UnreadableInput and the paths that couldn't be read.
• Otherwise → Complete, with the scope (artifact_types: ["tracked-text-file"],
  the scanned paths, the exclude prefixes).

Both the JSON scanCoverage field and is_clean()/has_unresolved() (which
drives the exit code) read this one stored value — they cannot read
different data, which is the specific anti-pattern the charter calls out
(an interval computed in one structure, a pass/fail decision read from
another, and the two never meeting).

The reverse test — proof it actually fails when forged

forged_complete_claim_without_scope_is_rejected in
crates/code-intel-cli/tests/repin.rs, plus unit tests in
evidence_outcome.rs. Two forgeries, not one:

1. A real not-computed report (from the empty-scan-surface case above),
   status flipped to "complete" with no scope added at all.
2. The realistic one: a real partial report (oversized-input case),
   status flipped to "complete" — leaving its genuine, fully-populated
   scope and its partialReason/paths fields completely untouched. This
   is the shape bug(repin): operationTrace 与 evidenceIds 内嵌 digest 不在扫描面——clean 报告失真 #133's own bug took: one field changed, everything else
   left alone. A bare "does scope exist and have its fields?" check would
   accept this forgery, because the scope really is there and really is
   well-formed (just borrowed from a claim that never achieved completeness).
   from_json catches it with an exact-key-set check per status — a
   Partial's object is a strict superset of a Complete's, so the leftover
   partialReason/detail/paths fields fail the check.

I verified this test is not vacuous by breaking the fix and confirming the
test fails to fail: with the exact-key check temporarily removed,
EvidenceOutcome::from_json on the forged-from-partial JSON returned
Ok(Complete(...)) instead of Err(...), and both the integration test and
the unit test failed as expected. Re-added the check, both pass again.

Same-source requirement (#4)

is_clean() / has_unresolved() and the scanCoverage JSON field both read
RepinReport.outcome — one field, computed once in scan_coverage(). No
second tally exists anywhere in the module.

Surfaces that still lack the honesty bit (explicitly not done here)

• evidence_query.rs's coverage.status ("complete"/"partial" string,
  computed via if/else, no EvidenceScope, no enforced construction rule) —
  the closest existing analog to what this PR builds, and the most obvious
  next candidate to migrate onto EvidenceOutcome.
• change_risk's saturating caps (FILES_TOUCHED_CAP, LINES_CHANGED_CAP,
  BUG_MAGNET_CAP, CHURN_CAP) — silently saturate a score; no coverage
  claim exists to convert yet, but a "did we see the whole diff shape or did
  we cap out" bit would fit this type.
• snapshot.rs's "[truncated]" bounded-preview helper — same
  truncation shape, unconverted.
• G2 (detector registry + gating function) and audit: detector 注册表 + 覆盖矩阵推导 + N-agent 仲裁面——把 prompt 审计换成可复现证据 #138 section C (N-agent
  arbitration / in-flight-change registry) — not started; this PR is scoped
  to G1's type and one proof surface only, per the charter's own layering.
• Did not touch capability_inventory.rs / sentrux_analysis.rs (the other
  bug-magnet hotspots) — out of scope for this change, not examined for
  this pattern.

Testing

• cargo test --workspace --locked: 2958 passed, 0 failed.
• cargo fmt --check: clean.
• code-intel sentrux check .: all rules passed, god-file count unchanged
  (33 -> 33), no degradation against .sentrux/baseline.json.

Refs #139 #138 #133

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[repowise-bot]

🔒 Repowise is not analyzing this repository

The PR bot is free on public repositories. This one is private, which needs a Pro plan.

See plans · Manage this repository

[coderabbitai]

Warning

Review limit reached

@2233admin, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 31 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5b9de710-a27a-4a08-b207-fc094a41e521

📥 Commits

Reviewing files that changed from the base of the PR and between 6a6dd20 and 98fd658.

📒 Files selected for processing (6)

• crates/code-intel-cli/src/evidence_outcome.rs
• crates/code-intel-cli/src/main.rs
• crates/code-intel-cli/src/repin.rs
• crates/code-intel-cli/tests/cli_head_parity.rs
• crates/code-intel-cli/tests/fixtures/cli-head-parity.v2.json
• crates/code-intel-cli/tests/repin.rs

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Code Intel change risk

Score	Percentile	Level
64/100	53th (vs last 49 commits)	🟢 low

Top signals

• Diff shape: 6 file(s), +799/-35 (max file share 0.56)
• Test asymmetry: source changed, tests touched
• Bug-magnet: 7 fix commit(s) in touched files (180d)
• Churn: 35 commit(s) touching these files (90d)

_{revspec: origin/main..HEAD · threshold: percentile >= 90 blocks unless labeled risk-accepted · code-intel change risk}