[can3p]

Adds the wave file docs/plan/f9.md. Nothing else changes: this PR is only the plan, for review.

What F9 builds: two buttons in the post editor, Check grammar and Style review. Both send the post's subject and body to Claude through the pcom server, so the API key never reaches the browser. Results show in a panel beside the editor:

• Grammar check: fixes you apply or dismiss one by one.
• Style review: notes you mark done, or keep as is with an optional reason. Reviews are stored per post, so the next review knows what was said, what you did and why.

The design sketch is at https://claude.ai/artifact/San1jMpSDJT3dS5TfPjZG8.

What the plan file covers:

• the decisions made so far: post editor only, every logged-in user with separate hourly limits, Russian and English, checks only on request, start with a panel and leave underlines for later;
• the JSON the model must return for each check, and how the server rejects suggestions whose quoted text isn't in the post or falls inside code, links or tags;
• how the browser keeps each suggestion's position in step with edits, and how it highlights the passage a card refers to;
• what is stored for style reviews (new tables), the settings, the packages and the routes;
• testing the Anthropic API with WireMock stubs. The helper task is shared with F7: whichever wave runs first builds it.

The task table runs TM and P0–P6, each with an owner and a "done when".

Open questions at the end of the plan: the default number of style reviews per hour (3 is a placeholder), and which default models to use once they've been tried on real Russian texts.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BXWqJ6gLPQqzFRaLhjFFEX

---

Generated by Claude Code

[can3p]

Should we generalize "style review" to proof read?

[can3p]

I'd keep the two names apart. "Proofread" normally means correcting surface errors, which is exactly the grammar check. The style review says nothing about commas: it's about logic gaps, repetition, pacing and the title, and it never edits the text. Calling it "proofread" would make it sound like a second grammar pass.

So the plan (c585edb, Terms) uses "proofreading" only as the internal name for the whole feature: packages, settings and routes. Users see Check grammar and Style review.

If "style" feels too narrow for what the review covers, a more general name would fit better than "proofread": Review, Writing review or Feedback. Let me know if you want one of those and I'll rename it in the plan and the sketch.

---

Generated by Claude Code

[can3p]

Does it make sense to use :post_id for POST requests too?

[can3p]

I'd keep ids in the JSON body for the POSTs. Every existing /controls/action route does that (delete_draft, create_share, dismiss_prompt, …), and jsonAction reads input only from the body. With the id in the path, these routes would be the only ones that read input from both places. The route table rows also stay parameter-free.

The one GET (/controls/proofread_style/:post_id) has no body, so its id goes in the path. The plan now says this above the route table (c585edb).

---

Generated by Claude Code