Make marked alternatives selectable and the document editable on the case page #15

New Issue

2026-05-31T23:43:45+02:00

Brummel commented

2026-05-31 23:43:45 +02:00

Request

When the LLM is unsure, it wraps material in [...] and/or ==...==. On the case page these annotations are currently copied verbatim into the clipboard, so the doctor has to clean them up after pasting into the practice software — defeating the purpose of the annotation.

Two improvements are wanted, both on the case page (server/templates/case_page.html):

Pick the desired suggestion in place — e.g. by clicking an alternative, so the chosen text replaces the annotation and only clean text is copied.
Edit the document text directly on the case page.

Current behaviour (verified)

Two annotation conventions coexist:
- ==...== → highlight. server/src/analyze/render.rs (md_to_html / substitute_marks) converts ==text== to <mark>text</mark>; it is the only live HTML injected.
- [...] → not specially rendered. render.rs only handles ==; square brackets pass through as literal text.
The bracket convention is overloaded across the prompts, with no single machine-readable meaning:
- server/prompts/default_system_prompt.md:21 — brackets hold the replaced original text.
- server/prompts/llama_system_prompt.md:8 — ==Originaltext [<Hinweistext>]==: brackets hold an optional hint.
- server/prompts/llama_system_prompt.md:18 — any non-transcript output "MUSS IN "[...]" GESETZT UND MARKIERT WERDEN".
- server/prompts/llama_system_prompt.md:22 — hints tagged as [Hinweis].
The rendered document is read-only: server/templates/case_page.html:622 injects {{ html|safe }} into a static #doc-body div.
Copy reads #doc-body .innerText verbatim (server/templates/case_page.html:630), so brackets, hints and marks all land in the clipboard unchanged. This is the reported friction.

Claim (unverified, based on the route map in server/src/routes/mod.rs): there is no write-back route for document.json today — only close/reopen/analyze/reset/delete exist. Editing therefore needs a new persistence path.

Design considerations / open questions

This is design-heavy and likely warrants a brainstorm spec before implementation. Open points:

A selectable alternative needs a machine-readable encoding. "Click to pick" requires the LLM to emit a defined structure distinguishing a primary suggestion from its alternative(s), and the renderer to turn that into selectable spans. The current [...] is too overloaded (replaced-original vs. hint vs. non-transcript marker) to drive selection unambiguously. The annotation syntax in both prompt files and render.rs would need to be designed together.
Selection semantics. On pick, the chosen text replaces the whole annotation and the ==/[...] decoration is stripped, so a subsequent copy yields clean text.
Editing needs write-back + lifecycle rules. A new save route must persist edits to document.json, and the interaction with re-analysis must be defined (a later analyze/reset regenerates document.json and would otherwise discard manual edits).
Copy then emits the resolved text, not the annotated source — relates to the combined copy action in #14 and the charset normalization in #13.

Acceptance checklist

A marked alternative on the case page can be resolved to a single chosen text by direct interaction, with the annotation decoration removed.
The document text can be edited on the case page and the edit persists across reloads.
After resolving/editing, copying yields clean text containing no ==/[...] artefacts.
The behaviour of a later re-analysis with respect to manual edits is defined and documented.

## Request When the LLM is unsure, it wraps material in `[...]` and/or `==...==`. On the case page these annotations are currently copied verbatim into the clipboard, so the doctor has to clean them up *after* pasting into the practice software — defeating the purpose of the annotation. Two improvements are wanted, both on the case page (`server/templates/case_page.html`): 1. **Pick the desired suggestion in place** — e.g. by clicking an alternative, so the chosen text replaces the annotation and only clean text is copied. 2. **Edit the document text directly** on the case page. ## Current behaviour (verified) - Two annotation conventions coexist: - `==...==` → highlight. `server/src/analyze/render.rs` (`md_to_html` / `substitute_marks`) converts `==text==` to `<mark>text</mark>`; it is the only live HTML injected. - `[...]` → **not** specially rendered. `render.rs` only handles `==`; square brackets pass through as literal text. - The bracket convention is overloaded across the prompts, with no single machine-readable meaning: - `server/prompts/default_system_prompt.md:21` — brackets hold the *replaced original* text. - `server/prompts/llama_system_prompt.md:8` — `==Originaltext [<Hinweistext>]==`: brackets hold an optional *hint*. - `server/prompts/llama_system_prompt.md:18` — any non-transcript output "MUSS IN \"[...]\" GESETZT UND MARKIERT WERDEN". - `server/prompts/llama_system_prompt.md:22` — hints tagged as `[Hinweis]`. - The rendered document is read-only: `server/templates/case_page.html:622` injects `{{ html|safe }}` into a static `#doc-body` div. - Copy reads `#doc-body` `.innerText` verbatim (`server/templates/case_page.html:630`), so brackets, hints and marks all land in the clipboard unchanged. This is the reported friction. Claim (unverified, based on the route map in `server/src/routes/mod.rs`): there is no write-back route for `document.json` today — only close/reopen/analyze/reset/delete exist. Editing therefore needs a new persistence path. ## Design considerations / open questions This is design-heavy and likely warrants a `brainstorm` spec before implementation. Open points: - **A selectable alternative needs a machine-readable encoding.** "Click to pick" requires the LLM to emit a defined structure distinguishing a primary suggestion from its alternative(s), and the renderer to turn that into selectable spans. The current `[...]` is too overloaded (replaced-original vs. hint vs. non-transcript marker) to drive selection unambiguously. The annotation syntax in both prompt files and `render.rs` would need to be designed together. - **Selection semantics.** On pick, the chosen text replaces the whole annotation and the `==`/`[...]` decoration is stripped, so a subsequent copy yields clean text. - **Editing needs write-back + lifecycle rules.** A new save route must persist edits to `document.json`, and the interaction with re-analysis must be defined (a later `analyze`/`reset` regenerates `document.json` and would otherwise discard manual edits). - **Copy then emits the resolved text**, not the annotated source — relates to the combined copy action in `#14` and the charset normalization in `#13`. ## Acceptance checklist - [ ] A marked alternative on the case page can be resolved to a single chosen text by direct interaction, with the annotation decoration removed. - [ ] The document text can be edited on the case page and the edit persists across reloads. - [ ] After resolving/editing, copying yields clean text containing no `==`/`[...]` artefacts. - [ ] The behaviour of a later re-analysis with respect to manual edits is defined and documented.

Brummel added the feature label 2026-05-31 23:43:45 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/doctate#15