refactor(modal): own table-delete confirmation at interaction boundary

[seonghobae]

Current boundary

Protected main@8dc746920c12988f082e914879d95e13c9693535 already displays the same window.confirm("정말로 이 테이블을 삭제하시겠습니까?") before onDeleteTable() mutates the graph. This branch therefore does not add a new buyer-visible confirmation or newly prevent previously-unconfirmed deletion.

• exact head: e0724a63183e75e97b9b96ddc1294237d5f5a51c
• lifecycle: open / Draft
• source intent: move ownership of the existing destructive-action confirmation from the App callback into the EditTableModal button interaction, and pin confirm/cancel behavior at the component boundary

Valid delta

EditTableModal now invokes the supplied mutation callback only after the same native confirm returns true. Focused component regressions cover confirm→callback and cancel→no callback. App.onDeleteTable() then remains the graph-mutation callback rather than also owning presentation interaction.

This is an ownership/testability refactor. Do not describe it as a before/after UX feature because the protected application already has the confirmation. It also does not by itself establish an accessibility improvement: native browser confirmation behavior is user-agent/platform controlled and current browser/a11y evidence has not been collected on this exact head.

Material-UI acceptance

Before promotion, verify the destructive path in a current browser: button keyboard activation, confirmation acceptance/cancel, focus return to the edit modal after cancel, modal close/focus behavior after confirmed deletion, and unchanged graph/edge cleanup. Confirm normal/error/responsive behavior remains intact. If a product-owned confirmation dialog replaces window.confirm later, it must carry explicit accessible name/description, initial and return focus, Escape/cancel semantics, destructive-action labeling, and responsive behavior rather than being inferred from this refactor.

Keep Draft until one unchanged exact head has terminal frontend/CI/Security/SAST/CodeQL evidence and qualifying current-head independent review. Do not manufacture screenshots/a11y evidence, self-approve, weaken gates, force-push, destructively rebase, or transfer predecessor results.

Delivery Gate: intentionality PASS; functional completeness PARTIAL pending exact-head browser interaction evidence; content fit PASS; resilience PARTIAL pending focus/cancel/responsive verification; evidence FAIL while hosted/current-browser evidence is incomplete; distinctiveness PASS for this bounded existing-product interaction.

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.}