bug(review): fresh candidate rejected before native START

[Tholir]

Pre-flight Checklist

• I have searched existing issues, including open and closed issues, and this is not a duplicate
• I understand that PRs will be rejected if the linked issue does not have status:approved

📝 Bug Description

On Gentle AI 2.2.4 through the Pi negotiated review integration, read-only STATUS reports a fresh workspace candidate as ready and returns review.start. Executing START is then rejected by the provider integration before native START with candidate-view-invalid.

The same rejection occurs for two distinct immutable candidate identities: first with four intended-untracked paths, then after staging those same four paths. Both failures explicitly report that no lineage was created and no mutation was performed. A valid candidate therefore cannot enter the review lifecycle, and the consumer has no provider-owned recovery transition beyond resolving the native-operation failure.

This report records the observed boundary only; it does not claim a root cause.

🔄 Steps to Reproduce

1. On Linux under WSL2, use Pi with Gentle AI 2.2.4 in a normal Git worktree.
2. Prepare a workspace candidate containing four intended-untracked paths and no other visible changes.
3. Call negotiated review STATUS with contract gentle-ai.review-integration/v2.
4. Observe reason_code: fresh_target_ready, action: start, and an exact provider-owned review.start transition for opaque candidate A (sha256:8ed8f9639ba2bffaaedaa872ecc0234e44670adf960e86ebf83b9f4cd9657f64).
5. Execute START through the Pi integration using ordinary mode.
6. Observe the pre-native candidate-view-invalid failure and confirm lineage_created: false and mutation_performed: false.
7. Stage exactly the same four candidate paths, producing opaque candidate B (sha256:8f4104173083336ca1dc4a2bd230f4f683fae58483c67d30a1feca9e170c5cb8).
8. Call STATUS again and observe another fresh exact START transition for candidate B.
9. Execute START once for candidate B and observe the same pre-native rejection with no lineage or mutation.

✅ Expected Behavior

A candidate accepted by negotiated STATUS as fresh_target_ready should either enter native START successfully or receive a typed provider-owned stop/recovery transition that explains which candidate-view invariant failed.

If provider preflight can reject the candidate view, STATUS and START should apply the same validation so STATUS does not advertise an operation that cannot begin.

❌ Actual Behavior

STATUS advertises review.start for both candidate identities, but START rejects each before native execution:

• status: blocked
• outcome: native-operation-failed
• code: candidate-view-invalid
• message: candidate view rejected before native START
• lineage_created: false
• mutation_performed: false
• mutation_outcome: none
• next_action: resolve-native-operation-failure

The candidate bytes remain unchanged. After the second attempt, exactly four intended paths remain staged; no review lineage, commit, push, or publication was created.

Gentle AI Version

2.2.4

Operating System

Windows (WSL)

AI Agent / Client

Other (Pi 0.83.0)

📋 Affected Area

CLI (commands, flags)

💡 Logs / Error Output

Attempt A:
status reason: fresh_target_ready
projection: workspace
candidate shape: 4 intended-untracked paths
START code: candidate-view-invalid
lineage_created: false
mutation_performed: false
mutation_outcome: none

Attempt B:
status reason: fresh_target_ready
projection: workspace
candidate shape: the same 4 paths staged
START code: candidate-view-invalid
lineage_created: false
mutation_performed: false
mutation_outcome: none

Additional Context

Client: Pi 0.83.0. Shell: bash. Architecture: x86_64. Kernel family: Linux under WSL2.

The operation shape was review.status followed by the exact provider-returned review.start, using contract v2 and workspace projection. No raw command line, repository path, private project name, username, hostname, credentials, environment values, source content, or diff is included.

Related but not duplicates:

• fix(review): classify unsupported START flags as not-started invalid requests #1807 concerned unsupported START flags on 2.1.11 and was closed after invalid requests became typed as not started.
• fix(review): status repeats non-retry-safe start after candidate context failure #1856 concerned a post-commit candidate-context failure with unknown mutation outcome; this occurrence is rejected before native START and explicitly creates no lineage.

[dnlrsls]

Linked to #2237. Shared clause: advertised execute transitions must be command-complete and preflight-valid, with pre-native refusals typed as non-mutating outcomes.

This issue remains open with its own acceptance criteria and regression evidence, and is not being marked as a duplicate.