Proposal (docs only): Repeated Word Check UI — Checks tab & Checks panel#305
Proposal (docs only): Repeated Word Check UI — Checks tab & Checks panel#305JEdward7777 wants to merge 2 commits into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR introduces two new proposal documents specifying the Repeated Word Check UI integration. A concise summary document outlines user-facing scope, core design decisions for suppression persistence, and sign-off confirmations. A detailed proposal document expands on the full specification, including web UI decisions, suppression cascade logic, graceful degradation behavior, and a comprehensive testing plan with specific validation cases. ChangesRepeated Word Check UI Integration Proposal
🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Relates to #277, #278 (and fluent-api#172 for the persistence half).
Docs-only proposal PR — no code changes. This is the design-for-review of the Repeated Word Check UI, following the same proposal-PR process as the approved fluent-api proxy design (fluent-api PR #173).
Start here:
docs/proposals/repeated-word-check/checks-ui-integration-summary.md— a condensed reviewer summary (core decisions, out-of-scope list, and the specific items where sign-off/input is sought).Full design:
docs/proposals/repeated-word-check/checks-ui-integration-suggestion.md— decisions W1–W12 covering the tab/panel UI, check trigger, suppression cascade, persistence design (editor-state extension + newuser_settingstable withGET/PUT /users/settings), graceful degradation, rollout, and testing.One proposal covers both repos so the whole design reads in one place; implementation will ship as two PRs (fluent-web + a small fluent-api PR), and either may land first by design (§9.4).
Items needing explicit confirmation are collected in the proposal's §12 sign-off checklist: five product-level mock/card deviations (S1–S5), the no-new-card ruling for suppression persistence (S6), and three engineering confirmations (W2/W7 user-settings store, W4 occurrence identity, W5/W6 cascade & undo).
Summary by CodeRabbit