[3mdistal]

Turning comments off hides saved comment text from viewers in notification previews and recording search. The owner retains access through the comment list, player, and screen context, with a read-only discussion panel. Authenticated owners entering through share links are redirected to that player.

Creation, replies, edits, comment reactions, and resolution remain disabled. Authorized deletion retains the approved cleanup exception, subject to the existing author/editor, Trash, and expiry checks.

Stacked on #8059. This implements the clarified comments-off policy separately; it will target main after the base PR merges.

Verification:

• Notification and search regressions failed before production edits; owner and enabled-comment controls passed.
• Owner read regressions failed before the read-only exemption.
• All 306 tests across 17 relevant suites pass, including live reply/edit transitions, owner agent history, rendered owner-panel controls, and existing write restrictions. Clips typecheck and formatting pass.
• Repository guards pass, including dead-settings-keys with GNU grep on PATH. The import guard passes after staging the new helper.
• Independent Codex Sol review found no remaining actionable issues after failing-first verification of both review findings.

No schema or stored-data changes.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes and found 2 potential issues 🟡

Review Details

Review summary

This PR applies the clarified comments-off policy to Clips recording history: saved comments remain readable to owners in player, agent context, screen context, and notification/search paths, while non-owner viewers should not receive comment content. It also adds read-versus-write access semantics and adjusts the recording route to render an owner-only read-only discussion panel. The approach is generally sound: shared visibility logic is used across several surfaces, and tests cover owner/viewer behavior and write restrictions. Risk is high because this is a privacy boundary controlling exposure of saved discussion. Two confirmed medium-severity issues were independently found by 2 of 3 review agents: the owner-facing share-page UI still hides comments returned by the API, and the delete action still permits destructive writes when comments are disabled. No schema or stored-data changes are involved.

Findings

• 🟡 Owner cannot view disabled comments through share links — response data is returned, but the share page still gates the comments UI on enableComments.
• 🟡 Delete action bypasses comments-off write policy — comment authors/editors can still delete saved discussion while the setting is off.

The route/action-level checks and regression tests are otherwise a good foundation for keeping owner reads distinct from viewer reads and preserving write denial. 🧪 Browser testing: Will run after this review (PR touches UI code).

[steve8708]

Thanks for the update and follow-up details. This adds an owner-only read-only discussion panel and changes how disabled comments appear across Clips history, so please get Shomix's Clips-owner review before approval.

[3mdistal]

Alice confirmed the comments-off policy on Oct 22: viewers lose access to saved comments everywhere, while owners retain read access. This PR implements that policy, including the owner read-only panel. It will remain open pending the requested Clips-owner review and your approval.

[steve8708]

Thanks for the update and policy confirmation. I checked the owner share-link redirect and the documented cleanup exception; this still needs Shomix’s Clips-owner review before approval.