Annotation reading and writing interaction

[vdvman1]

Question

What does annotating an article actually feel like, and which edge cases does the anchor model have to survive?

Annotations are not being built immediately — the point of this ticket is to make sure the data model can handle the interaction, before the schema is frozen. Rough over polished; throw it away afterwards.

Use /prototype. Build enough to answer:

• Selecting and creating. Select text, choose a kind (correction / link / note), write it, submit. What does the selection affordance look like on desktop and on touch?
• Reading. How do marginal annotations render beside a long article? What happens where several cluster on one paragraph? The article already has a floating table of contents and a floating image competing for the right-hand margin — see src/components/java/patch-notes.tsx.
• Promoted corrections in flow. What does "visible community edit" styling actually look like — strikethrough plus insertion? A badge? It must never read as Mojang's own text.
• Detached annotations. Where does an orphaned annotation live, how does it show its quoted text, and how does the permalink back to its original revision present?
• The write-lock. An article revision changes while someone is mid-annotation. What do they see?

Deliberately hunt the edge cases, because these feed straight back into the anchor model:

• A selection spanning a heading boundary.
• A selection inside a syntax-highlighted code block, where the DOM is generated by shiki, not by Mojang.
• A selection spanning two list items, or partially covering one.
• A zero-width or whitespace-only selection.
• A quote that appears several times in the article.

Deliverable: a linked prototype plus a written list of edge cases with the constraint each one imposes on the anchor model. If any of them break the settled anchor design, say so loudly — that is the point.

Blocked on the anchor model.

[vdvman1]

Constraint from #36 (anchoring prior art). Full write-up: docs/research/annotation-anchoring-prior-art.md

The research recommends a low-confidence "best guess" band between a confident match and an orphan — grounded in Brush et al. (CHI 2001), which found user satisfaction with orphaned annotations actually rises with document modification (median 7.0 for total deletion), while confident-but-wrong placements score at the floor (median 1.0).

That is a UI requirement, not just an algorithm one: this prototype should show three states, not two — confidently anchored, low-confidence/best-guess (visibly hedged), and orphaned. Getting the hedged state's presentation right is squarely this ticket's job, and the research says it matters more to users than raw re-anchoring accuracy does.