Drydock Review tab: AC24 sandbox verification, small hardening, deferred items

Aperta
#43 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java

Direzione di ricerca

Read docs/superpowers/specs/2026-10-22-intellij-review-tab-design.md and docs/superpowers/plans/2026-10-22-intellij-review-tab.md, then run the listed Gradle runIde command from intellij-plugin and check the AC24 items in the live sandbox. The issue also lists hardening and deferred work in ReviewTabProvider, ReviewTabVisibility, ReviewScopeRegistry, and DiffService; record which checks fail and verify fixes with the relevant project tests. Done means AC24 is verified and the agreed hardening items are addressed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

AI enhancement

Context

P2 ("Drydock Review" tab, branch review-tab-spike) passed its 3-round review loop with merge verdict OK. Seven P1 fixes and one P2 hardening (MismatchMemo) landed during the loop. The items below were deferred by decision, each with its reason — they need either the live sandbox check (AC24), a small hardening batch, or a later phase.

Spec: docs/superpowers/specs/2026-10-22-intellij-review-tab-design.md · Plan: docs/superpowers/plans/2026-10-22-intellij-review-tab.md · Cairn investigation: integrated-review (nodes find-p2-spikes-live-results, find-git-hunk-symmetry-unreliable).

1. AC24 — manual sandbox verification (blocking the PR)

Run cd intellij-plugin && JAVA_HOME=~/.sdkman/candidates/java/25.0.2-tem ./gradlew runIde, open a repo with a branch vs main, and check:

  • Tab appears as "Drydock Review" in the Commit tool window (and resolves its host — never hard-coded)
  • File rows show ◆ n / ✓ / ○ marks with CHANGES/stale/drift tooltips; finding children with :<line>; hidden-findings footer
  • Preview shows the file's diff exactly as git diff renders it (fragments, scroll-to-first-change, read-only)
  • Mark reviewed / Unmark from all three entry points; refusal reasons surface; verdicts persist to annotations.json
  • Changes link opens the tab and reloads; file changes and agent turn-end trigger reload; manual Refresh always reloads
  • The editor-tab host half: if the createRequestPanel fallback drops the request keys (CUSTOM_DIFF_COMPUTER / FORCE_READ_ONLY / SCROLL_TO_LINE), swap hosts per the plan's T10 fallback clause
  • Visibility predicate is actually re-evaluated when sessions change (if not: drop the predicate, rely on the empty state — spec Q8)
  • Split mode / Remote Development (q-split-mode-remote-dev) — unverifiable offline

2. Small hardening batch (fold into the AC24 pass or a quick follow-up PR)

  • P2-B — a reload already in flight can clear the "changed since" notice with a pre-edit result; self-corrects on the next reload. Fix = invalidate in-flight futures on change signals (refresher state machine).
  • P2-C — the app-wide activity subscription hangs on a Disposable with no parent (ReviewTabProvider); released only via disposeContent. Guard with Disposer.register(parent, …).
  • toRealPath on the EDT in ReviewTabVisibility (predates P2; microseconds, but violates the letter of the EDT rule).

3. Deferred to later phases

  • Scope-mint race serialization — the javadoc'd scan-then-mint window in ReviewScopeRegistry can rebind a session's scope in a microsecond race; needs a lock/atomic registration in shared core (app-side blast radius) → P3 material.
  • Quoted-rename pre-image — git C-quotes exotic paths in rename from; those files degrade to the "changed since" state. Proper fix = C-quoted-string unescaping in DiffService.
  • PR scope — deliberately out of P2 (Q12); lands with the PR-submitting phase (P5).
Lingua principale
Java
Stelle
0
Fork
0
Merge medio
50m
PR unite (30g)
81

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.