This task involves the work of creating a proof of concept for the VE Suggestion Mode MVP.

When enabled, the Suggestion Mode MVP will run all available Edit Checks on the contents of the article someone is viewing and present those that are relevant to both the content someone has and has NOT affected during the edit session at-hand.

Story

• As a member of the Growth Team developing the "Improve Tone" Suggested Editing, I'd value seeing how the existing Tone Check would function and appear when scoped to existing content so that I can use this baseline implementation to inform the UX (and technical approach), we are considering for the dedicated UX meant to enable this proactive application of the Tone model.
• As a member of the Editing Team developing the new "VE Suggestion Mode," I'd (similarly) value seeing how existing Checks look and feel when run on published content so that I can use this baseline experience to inform the UX we're designing for Checks when they are presented proactively and related to content people may not have authored/edited themselves (read: suggestions).
• As a member of the Machine Learning and Research Teams, I'd value seeing how the Tone Check model behaves when applied to published content so that I can discover what – if any – facets of the current implementation might need to be reconsidered/evolved to meet the needs of this "Suggestion" use case.

Requirements

• Introduce a new test flag (ecenable=3) that, when appended to a VE edit sessions URL (desktop + mobile) will cause all existing Checks on the entire document.
  • Where "all existing Checks" here refers to both deployed (e.g. Reference Check) and experimental Checks (e.g. Tone Check, convert references, etc.)

Background

This work is prompted by an idea @DLynch shared offline, and began exploring with Editing and ML engineers at the 2025 Hackathon.

Further, this proof of concept will support the work the Growth Team is leading on the "Improve Tone" Suggested Edit in T396162.

Done

• PoC is built that meets the Requirements documented above
• New questions/ideas this implementation brings to mind
  • E.g. how – if at all – might this PoC cause us to reconsider how Suggestions are "computed" in displayed? At present, Checks are shown once all have been "computed."