bug(review): deterministic R3-import-path false positive has no dispute transition

[eichhorn-micaela]

Before submitting

• I searched open and closed issues and did not find a report of this problem.
• I reviewed this report and removed credentials, tokens, private paths, hostnames, and other sensitive data.

Problem

A native reliability review reports a deterministic BLOCKER named R3-import-path, but the finding is contradicted by the actual repository layout and a successful typecheck.

The current review reaches correction_required, while the native flow exposes only a correction-plan transition. There is no supported transition to dispute, dismiss, reject, refute, or mark a deterministic finding as a false positive.

Steps to reproduce

1. Use a repository with this public-relative layout:
   • apps/api/src/modules/content-export/http/
   • packages/contracts/src/index.js
2. From the http module directory, resolve:
   ../../../../../../packages/contracts/src/index.js.
3. Observe that six parent-directory traversals resolve to:
   packages/contracts/src/index.js.
4. Resolve the five-traversal alternative:
   ../../../../../packages/contracts/src/index.js.
5. Observe that it resolves to the nonexistent path:
   apps/packages/contracts/src/index.js.
6. Run npm run typecheck; it passes.
7. Run native review and observe:
   state=correction_required
   with deterministic BLOCKER R3-import-path.

Expected and actual behavior

Expected:

• The reviewer validates the actual import resolution before emitting a BLOCKER.
• A demonstrably false deterministic finding can be disputed, dismissed, or refuted through a supported native transition.
• Deterministic findings that do not need a refuter have an explicit safe resolution path.

Actual:

• Native review claims that six traversals are one too many, although six traversals resolve to the repository's packages/contracts/src/index.js.
• The suggested five-traversal path does not exist.
• Typecheck passes.
• The lineage remains in correction_required.
• The only offered transition is a correction plan for R3-import-path; no false-positive dispute or dismissal transition is available.

gentle-pi version

3.5.0

Pi version

0.87.0

Operating system

Linux

Relevant logs or error output (optional)

review state: correction_required
finding: R3-import-path
lens: reliability
severity: BLOCKER
evidence_class: deterministic
causal_disposition: introduced
next transition: correction_plan_required

six traversals:
packages/contracts/src/index.js

five traversals:
no such path: apps/packages/contracts/src/index.js

typecheck:
passed

[DonatoSilva]

Second case of the same class, from a different repository and a different finding id: a deterministic R3 reliability BLOCKER that a local run refutes, with no supported transition to dispute it — and it is the same finding id four times in a row.

Environment

• gentle-pi 3.4.0 / 3.5.0, pi-coding-agent 0.87.0, Linux
• Candidates: single commits of a 33-slice chain in a Next.js 16 repository, reviewed one commit per lineage (committed range, baseRef = parent commit)

The finding

• id R3-test-mock-hoisting-tdz, also emitted as R3-hoisted-mock-tdz
• severity: BLOCKER, evidence_class: deterministic, causal_disposition: introduced
• claim: the vi.mock factories close over module-level const spies (const routerBack = vi.fn()) without vi.hoisted, so TDZ makes "the whole suite fail to load and none of the four tests run"

Refutation, one command

pnpm exec vitest run __tests__/components/contabilidad/conceptos/EditarDetalleModalClient.test.tsx
# Test Files  1 passed (1)   |   Tests  4 passed (4)

and for a later occurrence of the same finding, Tests 6 passed (6). Creating a closure does not read the binding: the spy is dereferenced only when the test invokes it, after the module has finished initializing. The suite loads and every test runs, so the declared evidence — a runtime failure — does not exist.

Occurrences

Four, on four different slices of that chain. In one of them the same pattern in a sibling file had been approved and its receipt burned minutes earlier with only a SUGGESTION from the same lens, so the reviewer was inconsistent between two files identical in shape rather than merely wrong once.

Why this is the same class as the report above

The finding is deterministic, so no refuter is offered; the only transition the flow exposes is a correction plan; and there is no transition to dispute, dismiss, refute or mark a deterministic finding as a false positive. The operator is left with two options, both worse than the third one that does not exist:

1. land the correction inside the reviewed commit, which in that chain would have invalidated 8 already-burned receipts on 43 descendant commits, or
2. abandon the lineage with operator_disposition, leaving the slice without a receipt.

Both were used. The slice whose finding was refuted was abandoned and documented as a gap; the remaining ones were closed by hardening the tests with vi.hoisted — hardening that was never required to make them pass.

Asks (same as this issue)

1. Resolve the claim before promoting it to evidence_class: deterministic. For a class like "this file does not run", running the file is a single command and it eliminates the whole class.
2. Give a demonstrably false deterministic finding a supported dismissal or refutation transition, instead of forcing a choice between rewriting reviewed history and abandoning the lineage.

vi.hoisted is used in 29 files of that repository, so "prefer vi.hoisted" as a SUGGESTION is entirely reasonable advice. A BLOCKER that asserts a runtime failure which does not occur is not.

[spardobo]

A related case on gentle-pi 4.0.0 concerns scope applicability rather than an incorrect technical observation. A frozen review reached correction_required for a CRITICAL finding whose proposed remedy contradicted the approved scope. The only offered continuation was a positive correction plan, with no scope-applicability challenge or disposition.

We observed this with demands for compatibility with an explicitly excluded database engine and for recovery of a withdrawn legacy state. Deterministic evidence can establish the technical observation without establishing that the excluded behavior is an acceptance requirement.

Could this thread cover an audited scope-applicability challenge that preserves the finding and evidence, requires native admission of the disposition, and retains explicit human authorization? It should not automatically bypass genuine critical findings. Audited abandonment succeeded; afterward, inspection offered START for the unchanged target, but no new review ran. A prior case saw a later review cite the excluded engine again. These are workflow/model observations, not a deterministic CLI reproduction or proof of lineage reuse.