marcel/familienarchiv
1
0
Fork 0
Code Issues 118 Pull Requests 2 Actions 4 Packages Projects Releases Wiki Activity

fix(test): resolve pre-existing TranscriptionEditView and Richtlinien test failures #423

New Issue
Closed
opened 2026-05-05 15:21:53 +02:00 by marcel · 9 comments
marcel commented 2026-05-05 15:21:53 +02:00
Owner
Copy Link

Context

Two test failures exist on main and were carried into PR #422 (domain restructuring). They are pre-existing and unrelated to the restructuring, but need a tracked home so CI failures can be diagnosed quickly.

Failing tests

1. TranscriptionEditView.svelte.spec.ts

Two tests fail:

  • auto-save debounce — passes the block mentionedPersons array as the 3rd save argument — onSaveBlock is called with an empty [] instead of the expected [{ personId: 'p-aug', displayName: 'Auguste Raddatz' }]. Likely a reactivity issue with how mention state is captured in the debounced save closure (state_referenced_locally Svelte warning is present in the file).
  • flush on blur — flushes pending save immediately on textarea blur before debounce expires — TypeError: Cannot read properties of null (reading 'dispatchEvent'). The textarea element is not found at the time .dispatchEvent is called.

2. src/routes/hilfe/transkription/page.svelte.spec.ts

  • renders Wikipedia external link with security attributes and new-tab annotation — expects link.textContent to contain 'öffnet in neuem Tab', but the component renders that text only in the aria-label attribute, not as visible text content. The component uses aria-label="{m.richtlinien_wiki_link()} — {m.common_opens_new_tab()}" while the visible text is just {m.richtlinien_wiki_link()}. Either the test needs to check aria-label instead of textContent, or the component needs to add a visible (or sr-only) span with the annotation.

Acceptance criteria

  • All three tests are green on main
  • No new Svelte warnings related to state_referenced_locally in TranscriptionEditView

Related

## Context Two test failures exist on `main` and were carried into PR #422 (domain restructuring). They are pre-existing and unrelated to the restructuring, but need a tracked home so CI failures can be diagnosed quickly. ## Failing tests ### 1. `TranscriptionEditView.svelte.spec.ts` Two tests fail: - **`auto-save debounce — passes the block mentionedPersons array as the 3rd save argument`** — `onSaveBlock` is called with an empty `[]` instead of the expected `[{ personId: 'p-aug', displayName: 'Auguste Raddatz' }]`. Likely a reactivity issue with how mention state is captured in the debounced save closure (`state_referenced_locally` Svelte warning is present in the file). - **`flush on blur — flushes pending save immediately on textarea blur before debounce expires`** — `TypeError: Cannot read properties of null (reading 'dispatchEvent')`. The textarea element is not found at the time `.dispatchEvent` is called. ### 2. `src/routes/hilfe/transkription/page.svelte.spec.ts` - **`renders Wikipedia external link with security attributes and new-tab annotation`** — expects `link.textContent` to contain `'öffnet in neuem Tab'`, but the component renders that text only in the `aria-label` attribute, not as visible text content. The component uses `aria-label="{m.richtlinien_wiki_link()} — {m.common_opens_new_tab()}"` while the visible text is just `{m.richtlinien_wiki_link()}`. Either the test needs to check `aria-label` instead of `textContent`, or the component needs to add a visible (or `sr-only`) span with the annotation. ## Acceptance criteria - All three tests are green on `main` - No new Svelte warnings related to `state_referenced_locally` in `TranscriptionEditView` ## Related - PR #422 (domain restructuring) identified and documented these failures - Confirmed pre-existing on `main` before PR #422
marcel added the P3-laterbugtest labels 2026-05-05 15:22:09 +02:00
marcel commented 2026-05-07 17:48:46 +02:00
Author
Owner
Copy Link

👨‍💻 Felix Brandt — Fullstack Developer

Observations

Failure 1 — mentionedPersons capture in debounced save closure (TranscriptionBlock + useBlockAutoSave)

The root cause is subtle. In TranscriptionBlock.svelte, the emitChange() function captures localMentions by reference from the outer $state variable at call time. The useBlockAutoSave.handleTextChange() stores that reference in pendingMentions. However, localMentions is a plain PersonMention[] array replaced on each update (not mutated), so the value stored in pendingMentions at the moment handleTextChange is called is correct — but then the test issues userEvent.type() which fires the onUpdate Tiptap callback and the suggestion command() callback via separate code paths. The Svelte warning state_referenced_locally is the compiler surfacing that localMentions inside the getter lambda () => localMentions of bind:mentionedPersons closes over the local let binding — meaning the setter receives the updated array, but the getter that useBlockAutoSave.handleRetry reads from still sees the closed-over snapshot from binding time if anything intercepts. The practical effect: when userEvent.type inserts characters before the existing @Auguste Raddatz mention node without triggering onUpdate for the mention itself, pendingMentions may be re-set to [] from a prior handleTextChange call that saw empty mentions before the editor finished deserializing. The test then waits 3 s for the debounced save to fire with [{ personId: 'p-aug', displayName: 'Auguste Raddatz' }] but receives [].

The state_referenced_locally warning on bind:mentionedPersons in TranscriptionBlock.svelte (line 164) should be taken seriously — the Svelte compiler is flagging that the getter closes over a local $state variable whose identity changes on reassignment. The fix is to make the getter capture a stable reference or use $derived instead.

Failure 2 — flush on blur test: TypeError: Cannot read properties of null

The test does document.querySelector('[role="textbox"]') and then calls .dispatchEvent(). The element is null at query time. This is a timing issue: TipTap's editor is created in onMount, which runs asynchronously after the initial render frame. vitest-browser-svelte's render() completes synchronously (from the test's perspective), but the editor's editorEl div with role="textbox" is only attached after the async mount lifecycle completes. The test doesn't await anything between textarea.fill() and the dispatchEvent call on the raw DOM element — the [role="textbox"] selector hits before Tiptap's editorProps.attributes are applied. A page.getByRole('textbox').element() (which the other tests use) would wait for the element to exist via Playwright locators; the raw document.querySelector call does not.

Failure 3 — Richtlinien page: textContent vs aria-label

The test (line 29-30) queries document.querySelector('a[href*="wikipedia"]') and then calls link.textContent. The component renders the visible link text as {m.richtlinien_wiki_link()} and puts the new-tab annotation only in aria-label="{m.richtlinien_wiki_link()} — {m.common_opens_new_tab()}". The test comment on line 28 (// icon communicates "opens new tab" visually; aria-label carries the text for a11y) correctly describes the intent — this is actually a well-implemented a11y pattern. The fix is to update the assertion to check aria-label rather than textContent.

Recommendations

  1. Fix the Richtlinien test assertion: Change expect(link.textContent).toContain(...) to expect(link.getAttribute('aria-label')).toContain('öffnet in neuem Tab'). The component's pattern (visible icon + aria-label) is correct; only the assertion is wrong. The existing line 30 already does this correctly — but the issue description says the test checks link.textContent. Check if there is a second assertion earlier in the test that checks textContent; if so, remove it and keep only the aria-label check.

  2. Fix the blur-flush test: Replace document.querySelector('[role="textbox"]') with await page.getByRole('textbox').first().element(). This uses the Playwright locator which waits for the element to be present (after Tiptap's onMount completes), then returns the DOM element for dispatchEvent. The pattern is already established in the delete-block tests.

  3. Fix the mentionedPersons debounce test: The safest structural fix in TranscriptionBlock.svelte is to replace the bind:mentionedPersons getter-setter pair with a two-way binding that avoids the local closure: lift the localMentions tracking into the setter and make emitChange always read the latest value synchronously. Alternatively, rename the setter to avoid capturing the let binding. The state_referenced_locally warning should be silenced by design, not by suppression — fix the reactivity model.

  4. Never suppress state_referenced_locally with a comment without understanding the failure mode. The warning in PersonMentionEditor.test-host.svelte shows the pattern of intentionally suppressing it. The TranscriptionBlock.svelte case is not intentional and needs the underlying reactivity fixed.

## 👨‍💻 Felix Brandt — Fullstack Developer ### Observations **Failure 1 — `mentionedPersons` capture in debounced save closure (`TranscriptionBlock` + `useBlockAutoSave`)** The root cause is subtle. In `TranscriptionBlock.svelte`, the `emitChange()` function captures `localMentions` by reference from the outer `$state` variable at call time. The `useBlockAutoSave.handleTextChange()` stores that reference in `pendingMentions`. However, `localMentions` is a plain `PersonMention[]` array replaced on each update (not mutated), so the value _stored_ in `pendingMentions` at the moment `handleTextChange` is called is correct — but then the test issues `userEvent.type()` which fires the `onUpdate` Tiptap callback _and_ the suggestion `command()` callback via separate code paths. The Svelte warning `state_referenced_locally` is the compiler surfacing that `localMentions` inside the getter lambda `() => localMentions` of `bind:mentionedPersons` closes over the local `let` binding — meaning the _setter_ receives the updated array, but the _getter_ that `useBlockAutoSave.handleRetry` reads from still sees the closed-over snapshot from binding time if anything intercepts. The practical effect: when `userEvent.type` inserts characters before the existing `@Auguste Raddatz` mention node without triggering `onUpdate` for the mention itself, `pendingMentions` may be re-set to `[]` from a prior `handleTextChange` call that saw empty mentions before the editor finished deserializing. The test then waits 3 s for the debounced save to fire with `[{ personId: 'p-aug', displayName: 'Auguste Raddatz' }]` but receives `[]`. The `state_referenced_locally` warning on `bind:mentionedPersons` in `TranscriptionBlock.svelte` (line 164) should be taken seriously — the Svelte compiler is flagging that the getter closes over a local `$state` variable whose identity changes on reassignment. The fix is to make the getter capture a stable reference or use `$derived` instead. **Failure 2 — `flush on blur` test: `TypeError: Cannot read properties of null`** The test does `document.querySelector('[role="textbox"]')` and then calls `.dispatchEvent()`. The element is `null` at query time. This is a timing issue: TipTap's editor is created in `onMount`, which runs asynchronously _after_ the initial render frame. `vitest-browser-svelte`'s `render()` completes synchronously (from the test's perspective), but the editor's `editorEl` div with `role="textbox"` is only attached after the async mount lifecycle completes. The test doesn't `await` anything between `textarea.fill()` and the `dispatchEvent` call on the raw DOM element — the `[role="textbox"]` selector hits _before_ Tiptap's `editorProps.attributes` are applied. A `page.getByRole('textbox').element()` (which the other tests use) would wait for the element to exist via Playwright locators; the raw `document.querySelector` call does not. **Failure 3 — Richtlinien page: `textContent` vs `aria-label`** The test (line 29-30) queries `document.querySelector('a[href*="wikipedia"]')` and then calls `link.textContent`. The component renders the visible link text as `{m.richtlinien_wiki_link()}` and puts the new-tab annotation _only_ in `aria-label="{m.richtlinien_wiki_link()} — {m.common_opens_new_tab()}"`. The test comment on line 28 (`// icon communicates "opens new tab" visually; aria-label carries the text for a11y`) correctly describes the intent — this is actually a well-implemented a11y pattern. The fix is to update the assertion to check `aria-label` rather than `textContent`. ### Recommendations 1. **Fix the Richtlinien test assertion**: Change `expect(link.textContent).toContain(...)` to `expect(link.getAttribute('aria-label')).toContain('öffnet in neuem Tab')`. The component's pattern (visible icon + aria-label) is correct; only the assertion is wrong. The existing line 30 already does this correctly — but the issue description says the test checks `link.textContent`. Check if there is a second assertion earlier in the test that checks `textContent`; if so, remove it and keep only the `aria-label` check. 2. **Fix the blur-flush test**: Replace `document.querySelector('[role="textbox"]')` with `await page.getByRole('textbox').first().element()`. This uses the Playwright locator which waits for the element to be present (after Tiptap's `onMount` completes), then returns the DOM element for `dispatchEvent`. The pattern is already established in the delete-block tests. 3. **Fix the `mentionedPersons` debounce test**: The safest structural fix in `TranscriptionBlock.svelte` is to replace the `bind:mentionedPersons` getter-setter pair with a two-way binding that avoids the local closure: lift the `localMentions` tracking into the setter and make `emitChange` always read the _latest_ value synchronously. Alternatively, rename the setter to avoid capturing the `let` binding. The `state_referenced_locally` warning should be silenced by design, not by suppression — fix the reactivity model. 4. **Never suppress `state_referenced_locally` with a comment without understanding the failure mode.** The warning in `PersonMentionEditor.test-host.svelte` shows the pattern of intentionally suppressing it. The `TranscriptionBlock.svelte` case is not intentional and needs the underlying reactivity fixed.
marcel commented 2026-05-07 17:49:12 +02:00
Author
Owner
Copy Link

🧪 Sara Holt — QA Engineer

Observations

Test quality: these are meaningful tests, not noise. All three failures describe real defects — not flaky timing, not implementation-detail assertions. They should be fixed, not disabled or worked around.

Failure 1 — mentionedPersons auto-save test: The test uses userEvent.type() with vi.waitFor at a 3 s timeout, which is the correct approach for a Tiptap editor where fake timers interfere with CDP keyboard events (as documented in the existing test comments). The test setup is sound. The bug is in production code — the pendingMentions stored by useBlockAutoSave.handleTextChange is not the same array that gets serialized at save time.

Failure 2 — blur test: null element: document.querySelector('[role="textbox"]') without awaiting is a classic vitest-browser anti-pattern. The test comment acknowledges that locator.blur() is not available; the correct substitute is (await page.getByRole('textbox').first().element()).dispatchEvent(...). The existing delete-block tests in this same file already demonstrate this pattern correctly (using await page.getByRole('button'...').element()). The blur test was not updated to follow the same pattern, which is why it's the only one broken in this group.

Failure 3 — Richtlinien link annotation: The test intention is correct (verify the a11y pattern). The implementation of the assertion is slightly behind the component implementation. The test comment on line 28 already states the correct expectation (aria-label carries the text for a11y) — the assertion on line 30 just needs to be the only check, and it already is. Based on the issue description, the failing assertion is somewhere in the test that checks link.textContent. Reading the spec file confirms: link.textContent will return just {m.richtlinien_wiki_link()} (the visible link text), not the aria-label content.

CI impact: Three failing tests on main mean CI is not fully green. While these are labelled P3-later, they create noise that can mask future real failures. Any team that ignores CI failures over time loses trust in the suite.

Test architecture observation: The TranscriptionEditView.svelte.spec.ts file is 373 lines and tests 9 distinct describe blocks — that is well-organized. Factory functions (renderView) and per-describe isolation work correctly. The blur test's raw DOM query is the only structural inconsistency.

Recommendations

  1. Fix the blur test's DOM query by adding await and using the locator API: const el = await page.getByRole('textbox').first().element() as HTMLElement. This makes it consistent with the delete-block test pattern already in the same file. Do not use document.querySelector in vitest-browser tests — use locators.

  2. Add a regression guard for the mentionedPersons bug: Once the production code fix lands, confirm the existing test is actually red before the fix and green after. If it was never truly red, add a console.warn or test comment explaining why it was passing incorrectly so it cannot silently revert.

  3. Keep the Richtlinien test as-is in intent — just fix the assertion. The aria-label check on line 30 is already correct; just confirm there is no earlier textContent assertion hiding the failure. The test title renders Wikipedia external link with security attributes and new-tab annotation accurately describes what should be verified.

  4. Do not add @Disabled or skip markers — these tests are close to passing and can be made green quickly. Disabling them would hide regressions in the exact behaviors they guard.

  5. After fixing, run npm run test locally to confirm all three describe blocks are green. The test suite for this component is otherwise solid and should not require changes beyond the three targeted fixes.

## 🧪 Sara Holt — QA Engineer ### Observations **Test quality: these are meaningful tests, not noise.** All three failures describe real defects — not flaky timing, not implementation-detail assertions. They should be fixed, not disabled or worked around. **Failure 1 — `mentionedPersons` auto-save test**: The test uses `userEvent.type()` with `vi.waitFor` at a 3 s timeout, which is the correct approach for a Tiptap editor where fake timers interfere with CDP keyboard events (as documented in the existing test comments). The test setup is sound. The bug is in production code — the `pendingMentions` stored by `useBlockAutoSave.handleTextChange` is not the same array that gets serialized at save time. **Failure 2 — blur test: `null` element**: `document.querySelector('[role="textbox"]')` without awaiting is a classic vitest-browser anti-pattern. The test comment acknowledges that `locator.blur()` is not available; the correct substitute is `(await page.getByRole('textbox').first().element()).dispatchEvent(...)`. The existing delete-block tests in this same file already demonstrate this pattern correctly (using `await page.getByRole('button'...').element()`). The blur test was not updated to follow the same pattern, which is why it's the only one broken in this group. **Failure 3 — Richtlinien link annotation**: The test intention is correct (verify the a11y pattern). The implementation of the assertion is slightly behind the component implementation. The test comment on line 28 already states the correct expectation (`aria-label carries the text for a11y`) — the assertion on line 30 just needs to be the _only_ check, and it already is. Based on the issue description, the failing assertion is somewhere in the test that checks `link.textContent`. Reading the spec file confirms: `link.textContent` will return just `{m.richtlinien_wiki_link()}` (the visible link text), not the `aria-label` content. **CI impact**: Three failing tests on `main` mean CI is not fully green. While these are labelled `P3-later`, they create noise that can mask future real failures. Any team that ignores CI failures over time loses trust in the suite. **Test architecture observation**: The `TranscriptionEditView.svelte.spec.ts` file is 373 lines and tests 9 distinct describe blocks — that is well-organized. Factory functions (`renderView`) and per-describe isolation work correctly. The blur test's raw DOM query is the only structural inconsistency. ### Recommendations 1. **Fix the blur test's DOM query** by adding `await` and using the locator API: `const el = await page.getByRole('textbox').first().element() as HTMLElement`. This makes it consistent with the delete-block test pattern already in the same file. Do not use `document.querySelector` in `vitest-browser` tests — use locators. 2. **Add a regression guard for the `mentionedPersons` bug**: Once the production code fix lands, confirm the existing test is actually red before the fix and green after. If it was never truly red, add a `console.warn` or test comment explaining _why_ it was passing incorrectly so it cannot silently revert. 3. **Keep the Richtlinien test as-is in intent** — just fix the assertion. The aria-label check on line 30 is already correct; just confirm there is no earlier `textContent` assertion hiding the failure. The test title `renders Wikipedia external link with security attributes and new-tab annotation` accurately describes what should be verified. 4. **Do not add `@Disabled` or skip markers** — these tests are close to passing and can be made green quickly. Disabling them would hide regressions in the exact behaviors they guard. 5. **After fixing, run `npm run test` locally to confirm all three describe blocks are green**. The test suite for this component is otherwise solid and should not require changes beyond the three targeted fixes.
marcel commented 2026-05-07 17:49:36 +02:00
Author
Owner
Copy Link

🏗️ Markus Keller — Application Architect

Observations

Scope is correctly bounded. All three failures are in the frontend/ domain (transcription/ and hilfe/). No cross-domain or backend concerns are implicated. This is a focused fix.

useBlockAutoSave as a separated module is correct design. Extracting the save/debounce logic into useBlockAutoSave.svelte.ts keeps it independently testable and separate from the rendering concern in TranscriptionBlock.svelte. The failure in the mention-capture test points to a subtle reactivity contract violation at the boundary between TranscriptionBlock (which owns the localMentions state) and useBlockAutoSave (which stores a snapshot of mentions at handleTextChange time). The module boundary is correct; the binding contract needs tightening.

The data-block-wrapper + onblur listener pattern: The blur handler is attached to the data-block-wrapper div in TranscriptionEditView.svelte, relying on event bubbling from the TipTap contenteditable. This is architecturally reasonable — TipTap fires native blur events that bubble. The test failure is not an architecture problem; it's a test-side timing issue.

No documentation update required for this fix. This issue touches no backend packages, routes, entities, migrations, or infrastructure. The standard doc-update checklist is not triggered.

state_referenced_locally Svelte compiler warning: The Svelte compiler emits this when a getter in a bind: expression closes over a locally scoped $state variable. The compiler warning is in TranscriptionBlock.svelte on the bind:mentionedPersons binding. This is not a style issue — it is the compiler's signal that the binding contract is fragile. It should be treated as a structural defect, not a warning to suppress.

Recommendations

  1. Resolve the state_referenced_locally warning by design, not suppression. The fix should make the binding's getter always read the current reactive value without capturing a stale closure. One clean approach: extract the getter–setter pair into a $derived or use a stable $state object (instead of reassigning the array reference) so the getter always reflects the current value.

  2. Do not change the useBlockAutoSave module interface. The handleTextChange(blockId, text, mentions) signature is correct — it takes a snapshot at call time. The contract is that TranscriptionBlock must call handleTextChange with the current mentions at the moment of each text change. If the binding is fixed in TranscriptionBlock, the module requires no changes.

  3. The Richtlinien fix requires no architectural review — it is purely a test assertion correction. The component's aria-label pattern (visible text + accessible label with new-tab annotation) is the correct implementation per WCAG 2.1 SC 2.4.4.

  4. Document the intentional client-side fetch exception in PersonMentionEditor.svelte (line 127–139) as an ADR. The inline comment references "Markus #5616: an ADR will formalise this" — this issue is an appropriate reminder that the follow-up ADR is still open.

Open Decisions

  • ADR for client-side fetch in Tiptap suggestion plugin: The inline comment in PersonMentionEditor.svelte already acknowledges this. Should this be formalized before the issue closes, or tracked as a separate work item? The suggestion plugin's items function fires on every keystroke — routing through SSR is impractical, so the exception is justified. The ADR should record this reasoning permanently.
## 🏗️ Markus Keller — Application Architect ### Observations **Scope is correctly bounded.** All three failures are in the `frontend/` domain (`transcription/` and `hilfe/`). No cross-domain or backend concerns are implicated. This is a focused fix. **`useBlockAutoSave` as a separated module is correct design.** Extracting the save/debounce logic into `useBlockAutoSave.svelte.ts` keeps it independently testable and separate from the rendering concern in `TranscriptionBlock.svelte`. The failure in the mention-capture test points to a subtle reactivity contract violation at the boundary between `TranscriptionBlock` (which owns the `localMentions` state) and `useBlockAutoSave` (which stores a snapshot of mentions at `handleTextChange` time). The module boundary is correct; the binding contract needs tightening. **The `data-block-wrapper` + `onblur` listener pattern**: The blur handler is attached to the `data-block-wrapper` div in `TranscriptionEditView.svelte`, relying on event bubbling from the TipTap contenteditable. This is architecturally reasonable — TipTap fires native blur events that bubble. The test failure is not an architecture problem; it's a test-side timing issue. **No documentation update required for this fix.** This issue touches no backend packages, routes, entities, migrations, or infrastructure. The standard doc-update checklist is not triggered. **`state_referenced_locally` Svelte compiler warning**: The Svelte compiler emits this when a getter in a `bind:` expression closes over a locally scoped `$state` variable. The compiler warning is in `TranscriptionBlock.svelte` on the `bind:mentionedPersons` binding. This is not a style issue — it is the compiler's signal that the binding contract is fragile. It should be treated as a structural defect, not a warning to suppress. ### Recommendations 1. **Resolve the `state_referenced_locally` warning by design, not suppression.** The fix should make the binding's getter always read the _current_ reactive value without capturing a stale closure. One clean approach: extract the getter–setter pair into a `$derived` or use a stable `$state` object (instead of reassigning the array reference) so the getter always reflects the current value. 2. **Do not change the `useBlockAutoSave` module interface.** The `handleTextChange(blockId, text, mentions)` signature is correct — it takes a snapshot at call time. The contract is that `TranscriptionBlock` must call `handleTextChange` with the _current_ mentions at the moment of each text change. If the binding is fixed in `TranscriptionBlock`, the module requires no changes. 3. **The Richtlinien fix requires no architectural review** — it is purely a test assertion correction. The component's `aria-label` pattern (visible text + accessible label with new-tab annotation) is the correct implementation per WCAG 2.1 SC 2.4.4. 4. **Document the intentional client-side fetch exception** in `PersonMentionEditor.svelte` (line 127–139) as an ADR. The inline comment references "Markus #5616: an ADR will formalise this" — this issue is an appropriate reminder that the follow-up ADR is still open. ### Open Decisions - **ADR for client-side fetch in Tiptap suggestion plugin**: The inline comment in `PersonMentionEditor.svelte` already acknowledges this. Should this be formalized before the issue closes, or tracked as a separate work item? The suggestion plugin's `items` function fires on every keystroke — routing through SSR is impractical, so the exception is justified. The ADR should record this reasoning permanently.
marcel commented 2026-05-07 17:49:58 +02:00
Author
Owner
Copy Link

🔒 Nora "NullX" Steiner — Security Engineer

Observations

No security vulnerabilities in scope. These are test failures in frontend component tests — no backend endpoint changes, no auth flow changes, no new input surfaces. My scan focused on the code touched by this issue.

PersonMentionEditor.svelte client-side fetch (line 144): fetch('/api/persons?q=...') with encodeURIComponent(query) is correct practice. The query is properly encoded before use in the URL. The response is cast to Person[] after an ok check and sliced to 5 items. No XSS surface — the returned data flows into TipTap's Mention extension renderHTML which serializes to a <span> with data-* attributes, not innerHTML. This is safe.

External link in Richtlinien page (href="https://de.wikipedia.org/wiki/Kurrent"): Has target="_blank" rel="noopener noreferrer" referrerpolicy="no-referrer". All three required attributes are present. The aria-label carrying the "öffnet in neuem Tab" string is also correct (users with screen readers are told the link opens a new tab — preventing surprise). This is a textbook-correct implementation.

flushOnUnload beacon in useBlockAutoSave.svelte.ts (line 119): Uses fetch with keepalive: true to send a PUT request on page unload. The payload is JSON-serialized { text, mentionedPersons }. This does not introduce a security concern — it uses the same endpoint as the normal save path, authenticated via cookie, with the same content-type header. The keepalive flag is the correct choice for unload beacons.

No hardcoded secrets, no logging of user input without sanitization, no JPQL concerns — this is a pure frontend component fix.

The state_referenced_locally warning is not a security issue, but it is worth noting that a stale closure capturing mention state could theoretically cause a different user's mention to be associated with a save payload (if blocks were reused across documents without a component teardown). In this codebase, blocks are unmounted and remounted per document, so the practical risk is zero — but the fix still eliminates the theoretical edge case.

Recommendations

  1. Verify the data-editor-inner selector in the placeholder $effect does not introduce a selector-injection risk. It does not — editorEl.querySelector('[data-editor-inner]') is a static string, not user-controlled. This is clean.

  2. The aria-label pattern on the Wikipedia link is correct and should be preserved exactly as-is. Do not move the new-tab annotation to textContent (a visible sr-only span) as a "fix" — the current aria-label approach is preferable because it avoids redundant announcements for sighted users.

  3. No action required on the security surface of the code changed by this issue. The fix is purely a reactivity and test-assertion correction.

## 🔒 Nora "NullX" Steiner — Security Engineer ### Observations **No security vulnerabilities in scope.** These are test failures in frontend component tests — no backend endpoint changes, no auth flow changes, no new input surfaces. My scan focused on the code touched by this issue. **`PersonMentionEditor.svelte` client-side fetch** (line 144): `fetch('/api/persons?q=...')` with `encodeURIComponent(query)` is correct practice. The query is properly encoded before use in the URL. The response is cast to `Person[]` after an `ok` check and sliced to 5 items. No XSS surface — the returned data flows into TipTap's Mention extension `renderHTML` which serializes to a `<span>` with `data-*` attributes, not `innerHTML`. This is safe. **External link in Richtlinien page** (`href="https://de.wikipedia.org/wiki/Kurrent"`): Has `target="_blank" rel="noopener noreferrer" referrerpolicy="no-referrer"`. All three required attributes are present. The `aria-label` carrying the "öffnet in neuem Tab" string is also correct (users with screen readers are told the link opens a new tab — preventing surprise). This is a textbook-correct implementation. **`flushOnUnload` beacon** in `useBlockAutoSave.svelte.ts` (line 119): Uses `fetch` with `keepalive: true` to send a `PUT` request on page unload. The payload is JSON-serialized `{ text, mentionedPersons }`. This does not introduce a security concern — it uses the same endpoint as the normal save path, authenticated via cookie, with the same content-type header. The `keepalive` flag is the correct choice for unload beacons. **No hardcoded secrets, no logging of user input without sanitization, no JPQL concerns** — this is a pure frontend component fix. **The `state_referenced_locally` warning is not a security issue**, but it is worth noting that a stale closure capturing mention state could theoretically cause a _different_ user's mention to be associated with a save payload (if blocks were reused across documents without a component teardown). In this codebase, blocks are unmounted and remounted per document, so the practical risk is zero — but the fix still eliminates the theoretical edge case. ### Recommendations 1. **Verify the `data-editor-inner` selector in the placeholder `$effect`** does not introduce a selector-injection risk. It does not — `editorEl.querySelector('[data-editor-inner]')` is a static string, not user-controlled. This is clean. 2. **The aria-label pattern on the Wikipedia link is correct** and should be preserved exactly as-is. Do not move the new-tab annotation to `textContent` (a visible `sr-only` span) as a "fix" — the current `aria-label` approach is preferable because it avoids redundant announcements for sighted users. 3. **No action required on the security surface** of the code changed by this issue. The fix is purely a reactivity and test-assertion correction.
marcel commented 2026-05-07 17:50:21 +02:00
Author
Owner
Copy Link

🚀 Tobias Wendt — DevOps & Platform Engineer

Observations

CI impact is the primary concern here. Three failing tests on main mean CI is persistently non-green. Even with a P3-later label, a non-green CI baseline is operationally problematic: new PRs cannot distinguish genuine regressions from pre-existing failures without reading historical context. This erodes confidence in the pipeline and slows diagnosis.

No infrastructure files are changed by this fix. No Docker Compose changes, no CI workflow changes, no image tag updates. My review is scoped to the CI/pipeline implications.

The test runner is vitest-browser with Playwright/Chromium, run via npm run test in the frontend/ project. The failing tests are in the browser-mode project (component tests against real DOM), not the server-mode project. This means they require a Chromium browser in the CI environment. If the Gitea Actions runner does not have Chromium/Playwright pre-installed, these tests may fail for environmental reasons unrelated to the code — worth confirming.

The P3-later label is reasonable for product priority, but from an operational standpoint, a persistent CI failure is P1 for the pipeline. A broken test that's been on main since PR #422 means every CI run for every subsequent PR shows failures that are not caused by that PR's changes. This creates diagnostic noise.

Recommendations

  1. Merge this fix promptly despite the P3-later label — the CI noise cost accumulates with every PR that passes through main. A 30-minute fix now saves hours of context-switching over the next month.

  2. Confirm Playwright/Chromium is installed on the Gitea Actions runner before attributing the blur test failure to code. If the runner environment changed between when these tests were written and when they started failing, the root cause might be environmental. Run npx playwright install chromium --with-deps in the CI setup step if it is missing.

  3. Add a CI step that fails fast on pre-existing test failures after this fix lands — something like a test:browser target that is distinct from the server-mode tests. This makes it immediately obvious when a browser-mode test breaks, rather than discovering it during a PR review weeks later.

  4. No changes to docker-compose.yml are needed for this fix. The modified docker-compose.yml in the working tree (shown in git status) is unrelated to this issue — ensure those changes don't accidentally get bundled into this fix commit.

## 🚀 Tobias Wendt — DevOps & Platform Engineer ### Observations **CI impact is the primary concern here.** Three failing tests on `main` mean CI is persistently non-green. Even with a `P3-later` label, a non-green CI baseline is operationally problematic: new PRs cannot distinguish genuine regressions from pre-existing failures without reading historical context. This erodes confidence in the pipeline and slows diagnosis. **No infrastructure files are changed by this fix.** No Docker Compose changes, no CI workflow changes, no image tag updates. My review is scoped to the CI/pipeline implications. **The test runner is `vitest-browser` with Playwright/Chromium**, run via `npm run test` in the `frontend/` project. The failing tests are in the browser-mode project (component tests against real DOM), not the server-mode project. This means they require a Chromium browser in the CI environment. If the Gitea Actions runner does not have Chromium/Playwright pre-installed, these tests may fail for environmental reasons unrelated to the code — worth confirming. **The `P3-later` label is reasonable** for product priority, but from an operational standpoint, a persistent CI failure is `P1` for the pipeline. A broken test that's been on `main` since PR #422 means every CI run for every subsequent PR shows failures that are not caused by that PR's changes. This creates diagnostic noise. ### Recommendations 1. **Merge this fix promptly** despite the `P3-later` label — the CI noise cost accumulates with every PR that passes through `main`. A 30-minute fix now saves hours of context-switching over the next month. 2. **Confirm Playwright/Chromium is installed on the Gitea Actions runner** before attributing the blur test failure to code. If the runner environment changed between when these tests were written and when they started failing, the root cause might be environmental. Run `npx playwright install chromium --with-deps` in the CI setup step if it is missing. 3. **Add a CI step that fails fast on pre-existing test failures** after this fix lands — something like a `test:browser` target that is distinct from the server-mode tests. This makes it immediately obvious when a browser-mode test breaks, rather than discovering it during a PR review weeks later. 4. **No changes to `docker-compose.yml` are needed** for this fix. The modified `docker-compose.yml` in the working tree (shown in git status) is unrelated to this issue — ensure those changes don't accidentally get bundled into this fix commit.
marcel commented 2026-05-07 17:50:36 +02:00
Author
Owner
Copy Link

📋 Elicit — Requirements Engineer

Observations

The acceptance criteria are precise and testable, which is exactly right for a bug fix issue:

  • "All three tests are green on main" — binary pass/fail, measurable.
  • "No new Svelte warnings related to state_referenced_locally in TranscriptionEditView" — observable via build output.

The issue correctly identifies three distinct failures and attributes each to a specific technical cause. This level of pre-diagnosis in the issue body is excellent — it reduces the implementation ambiguity to near zero.

One implicit acceptance criterion is missing: there is no criterion requiring that the existing passing tests in TranscriptionEditView.svelte.spec.ts continue to pass after the fix. Given that the mentionedPersons fix touches TranscriptionBlock.svelte (which affects the entire {#each} render path), a regression in the other 30+ tests in the spec file is possible. The DoD should explicitly include: "no previously-passing tests in the same spec files become red."

The related PR #422 context is clear. It is sufficient to note that the failures are pre-existing and unrelated to that PR's intent. No additional scoping is needed.

Scope boundary: The issue is scoped to three specific test failures and one Svelte warning. The inline comment in PersonMentionEditor.svelte references an open ADR ("Markus #5616") and a separate issues ("Nora #5618 #3"). These are explicitly out of scope for this issue and should remain tracked separately.

Recommendations

  1. Add one acceptance criterion: "All previously-passing tests in TranscriptionEditView.svelte.spec.ts and page.svelte.spec.ts remain green" — this guards against regressions introduced by the fix.

  2. The issue title is accurate — fix(test): resolve pre-existing TranscriptionEditView and Richtlinien test failures correctly signals that this is a test-fix commit, not a product feature or behavior change. Keep it.

  3. Labels look correct: bug, test, P3-later. The test label correctly signals this is a test-suite fix, not a product behavior change. The P3-later is reasonable for user-facing priority, though as Tobias notes, CI health makes it operationally higher priority.

  4. No new i18n keys, no new error codes, no new routes are implied by this fix. The i18n and error-handling checklists from CLAUDE.md do not apply here.

## 📋 Elicit — Requirements Engineer ### Observations **The acceptance criteria are precise and testable**, which is exactly right for a bug fix issue: - "All three tests are green on `main`" — binary pass/fail, measurable. - "No new Svelte warnings related to `state_referenced_locally` in `TranscriptionEditView`" — observable via build output. **The issue correctly identifies three distinct failures** and attributes each to a specific technical cause. This level of pre-diagnosis in the issue body is excellent — it reduces the implementation ambiguity to near zero. **One implicit acceptance criterion is missing**: there is no criterion requiring that the existing _passing_ tests in `TranscriptionEditView.svelte.spec.ts` continue to pass after the fix. Given that the `mentionedPersons` fix touches `TranscriptionBlock.svelte` (which affects the entire `{#each}` render path), a regression in the other 30+ tests in the spec file is possible. The DoD should explicitly include: "no previously-passing tests in the same spec files become red." **The related PR #422 context is clear.** It is sufficient to note that the failures are pre-existing and unrelated to that PR's intent. No additional scoping is needed. **Scope boundary**: The issue is scoped to three specific test failures and one Svelte warning. The inline comment in `PersonMentionEditor.svelte` references an open ADR ("Markus #5616") and a separate issues ("Nora #5618 #3"). These are explicitly out of scope for this issue and should remain tracked separately. ### Recommendations 1. **Add one acceptance criterion**: "All previously-passing tests in `TranscriptionEditView.svelte.spec.ts` and `page.svelte.spec.ts` remain green" — this guards against regressions introduced by the fix. 2. **The issue title is accurate** — `fix(test): resolve pre-existing TranscriptionEditView and Richtlinien test failures` correctly signals that this is a test-fix commit, not a product feature or behavior change. Keep it. 3. **Labels look correct**: `bug`, `test`, `P3-later`. The `test` label correctly signals this is a test-suite fix, not a product behavior change. The `P3-later` is reasonable for user-facing priority, though as Tobias notes, CI health makes it operationally higher priority. 4. **No new i18n keys, no new error codes, no new routes** are implied by this fix. The i18n and error-handling checklists from `CLAUDE.md` do not apply here.
marcel commented 2026-05-07 17:50:48 +02:00
Author
Owner
Copy Link

🎨 Leonie Voss — UI/UX Designer & Accessibility Strategist

Observations

The Wikipedia link in the Richtlinien page is correctly implemented from an a11y standpoint. The pattern — visible text {m.richtlinien_wiki_link()}, icon aria-hidden="true", and aria-label="{m.richtlinien_wiki_link()} — {m.common_opens_new_tab()}" — is the right approach. Screen reader users hear the full label including the new-tab notification. Sighted users see the external link icon as the visual cue. This is WCAG 2.1 SC 2.4.4 (Link Purpose) compliant.

The failing test is asserting the wrong thing, not the wrong implementation. The component is correct; the assertion should check aria-label, not textContent. Fixing the test preserves the correct a11y pattern without changing the component.

One minor concern in the Richtlinien page: The Wikipedia info card uses border-brand-sand as a border class (line 61 of +page.svelte). Based on the brand token system, border-brand-sand applies a border in the sand palette color. This should be verified against the project's Tailwind v4 token configuration — if border-brand-sand is not a registered utility in layout.css, it would silently produce no border. The canonical card pattern uses border-line. This is a separate cosmetic concern, not part of this issue's scope.

The TranscriptionBlock component's TipTap editor (PersonMentionEditor) correctly uses role="textbox" and aria-multiline="true" on the contenteditable div. The aria-label from m.transcription_editor_aria_label() gives screen reader users context for the field. The blur-flush test failure is a test-side DOM timing issue, not a component accessibility problem.

Touch target compliance: The TranscriptionBlock buttons (delete, review toggle, move up/down) use h-7 w-7 (28px) for the move arrows and similar small sizes for the action buttons. The project standard is 44px minimum. This is a pre-existing issue separate from this bug fix, and should be addressed in a dedicated accessibility issue rather than blocking this fix.

Recommendations

  1. Keep the aria-label pattern on the Wikipedia link exactly as-is. Fix only the test assertion. The component's a11y implementation is correct.

  2. After fixing, manually verify that a screen reader (VoiceOver or NVDA) announces "Wikipedia article on Kurrent — opens in new tab" (or the German equivalent) when the link receives focus. The aria-label overrides the visible text for assistive technology, so the full string including the "öffnet in neuem Tab" annotation should be announced.

  3. Create a follow-up issue for the touch target sizes on the TranscriptionBlock action buttons — they are below the 44px WCAG 2.2 minimum for the mobile (60+) audience this project serves. This is worth a dedicated fix.

Open Decisions

  • sr-only span vs aria-label for new-tab annotation: Both patterns are valid. The current aria-label approach avoids duplicate text (sighted users would hear "Wikipedia Wikipedia — opens in new tab" if a sr-only span were inside the link). The aria-label approach is the right call here — but if the project has a shared ExternalLink component planned, the decision should be standardized in that component's design.
## 🎨 Leonie Voss — UI/UX Designer & Accessibility Strategist ### Observations **The Wikipedia link in the Richtlinien page is correctly implemented from an a11y standpoint.** The pattern — visible text `{m.richtlinien_wiki_link()}`, icon `aria-hidden="true"`, and `aria-label="{m.richtlinien_wiki_link()} — {m.common_opens_new_tab()}"` — is the right approach. Screen reader users hear the full label including the new-tab notification. Sighted users see the external link icon as the visual cue. This is WCAG 2.1 SC 2.4.4 (Link Purpose) compliant. **The failing test is asserting the _wrong thing_**, not the wrong implementation. The component is correct; the assertion should check `aria-label`, not `textContent`. Fixing the test preserves the correct a11y pattern without changing the component. **One minor concern in the Richtlinien page**: The Wikipedia info card uses `border-brand-sand` as a border class (line 61 of `+page.svelte`). Based on the brand token system, `border-brand-sand` applies a border in the sand palette color. This should be verified against the project's Tailwind v4 token configuration — if `border-brand-sand` is not a registered utility in `layout.css`, it would silently produce no border. The canonical card pattern uses `border-line`. This is a separate cosmetic concern, not part of this issue's scope. **The `TranscriptionBlock` component's TipTap editor** (`PersonMentionEditor`) correctly uses `role="textbox"` and `aria-multiline="true"` on the contenteditable div. The `aria-label` from `m.transcription_editor_aria_label()` gives screen reader users context for the field. The blur-flush test failure is a test-side DOM timing issue, not a component accessibility problem. **Touch target compliance**: The `TranscriptionBlock` buttons (delete, review toggle, move up/down) use `h-7 w-7` (28px) for the move arrows and similar small sizes for the action buttons. The project standard is 44px minimum. This is a pre-existing issue separate from this bug fix, and should be addressed in a dedicated accessibility issue rather than blocking this fix. ### Recommendations 1. **Keep the `aria-label` pattern on the Wikipedia link exactly as-is.** Fix only the test assertion. The component's a11y implementation is correct. 2. **After fixing, manually verify** that a screen reader (VoiceOver or NVDA) announces "Wikipedia article on Kurrent — opens in new tab" (or the German equivalent) when the link receives focus. The `aria-label` overrides the visible text for assistive technology, so the full string including the "öffnet in neuem Tab" annotation should be announced. 3. **Create a follow-up issue** for the touch target sizes on the `TranscriptionBlock` action buttons — they are below the 44px WCAG 2.2 minimum for the mobile (60+) audience this project serves. This is worth a dedicated fix. ### Open Decisions - **`sr-only` span vs `aria-label` for new-tab annotation**: Both patterns are valid. The current `aria-label` approach avoids duplicate text (sighted users would hear "Wikipedia Wikipedia — opens in new tab" if a `sr-only` span were inside the link). The `aria-label` approach is the right call here — but if the project has a shared `ExternalLink` component planned, the decision should be standardized in that component's design.
marcel commented 2026-05-07 17:51:10 +02:00
Author
Owner
Copy Link

Decision Queue

Two open decisions surfaced across the persona reviews. Both are out of scope for this fix but need a tracked home.

Theme 1 — ADR: Client-side fetch exception in Tiptap suggestion plugin

Raised by: Markus (architect)

PersonMentionEditor.svelte makes a client-side fetch('/api/persons?q=...') call on every @ keystroke in the suggestion plugin. This is a documented exception to the project's SSR-first rule. The inline comment (line 127–139) already references "Markus #5616: an ADR will formalise this" — but that ADR has not been written.

Decision needed: Should the ADR be created as part of this fix, or tracked as a separate follow-up issue? The exception is justified (routing typeahead queries through SSR would make the dropdown unusable), so the ADR content is already known — this is purely a documentation timing question.

Theme 2 — A11y follow-up: TranscriptionBlock touch target sizes

Raised by: Leonie (UI/UX)

The move-up/move-down arrow buttons in TranscriptionBlock.svelte use h-7 w-7 (28px), and the review toggle and delete buttons are similarly sized. The WCAG 2.2 minimum is 44px, which the project standard also requires. This affects the 60+ transcriber audience on mobile/tablet.

Decision needed: Create a dedicated a11y issue for TranscriptionBlock button sizing, or fold it into the next transcription panel maintenance issue?

Theme 3 — sr-only span vs aria-label for external link new-tab annotation

Raised by: Leonie (UI/UX)

The current pattern on the Wikipedia link (aria-label containing the full text including "öffnet in neuem Tab") is correct. If a shared ExternalLink component is planned, the pattern should be standardized there.

Decision needed: Is a shared ExternalLink component planned? If yes, should this pattern be codified now? If no, the existing per-component aria-label pattern is sufficient and requires no further action.

## Decision Queue Two open decisions surfaced across the persona reviews. Both are **out of scope for this fix** but need a tracked home. --- ### Theme 1 — ADR: Client-side fetch exception in Tiptap suggestion plugin **Raised by**: Markus (architect) `PersonMentionEditor.svelte` makes a client-side `fetch('/api/persons?q=...')` call on every `@` keystroke in the suggestion plugin. This is a documented exception to the project's SSR-first rule. The inline comment (line 127–139) already references "Markus #5616: an ADR will formalise this" — but that ADR has not been written. **Decision needed**: Should the ADR be created as part of this fix, or tracked as a separate follow-up issue? The exception is justified (routing typeahead queries through SSR would make the dropdown unusable), so the ADR content is already known — this is purely a documentation timing question. --- ### Theme 2 — A11y follow-up: `TranscriptionBlock` touch target sizes **Raised by**: Leonie (UI/UX) The move-up/move-down arrow buttons in `TranscriptionBlock.svelte` use `h-7 w-7` (28px), and the review toggle and delete buttons are similarly sized. The WCAG 2.2 minimum is 44px, which the project standard also requires. This affects the 60+ transcriber audience on mobile/tablet. **Decision needed**: Create a dedicated a11y issue for `TranscriptionBlock` button sizing, or fold it into the next transcription panel maintenance issue? --- ### Theme 3 — `sr-only` span vs `aria-label` for external link new-tab annotation **Raised by**: Leonie (UI/UX) The current pattern on the Wikipedia link (`aria-label` containing the full text including "öffnet in neuem Tab") is correct. If a shared `ExternalLink` component is planned, the pattern should be standardized there. **Decision needed**: Is a shared `ExternalLink` component planned? If yes, should this pattern be codified now? If no, the existing per-component `aria-label` pattern is sufficient and requires no further action.
marcel commented 2026-05-09 16:20:40 +02:00
Author
Owner
Copy Link

Resolution

All three failing tests are now green on main. The fixes landed in earlier commits as part of broader test-suite maintenance:

  • flush on blur + mentionedPersons debounce tests — fixed in cdb54c75 (fix(tests): fix 2 more pre-existing vitest-browser spec failures): switched textarea.fill() + fake timers to userEvent.type() + vi.waitFor for the mention test; used page.getByRole('textbox').first() locator instead of raw document.querySelector for the blur dispatch.
  • Richtlinien Wikipedia link test — fixed in 6ab7abb9 (fix(tests): fix 3 pre-existing vitest-browser spec failures): the test already checks link.getAttribute('aria-label') (not textContent), matching the component's correct aria-label pattern.

No new state_referenced_locally warnings were introduced — the two existing warnings in TranscriptionEditView.svelte:77 (for onSaveBlock and documentId passed to createBlockAutoSave) are pre-existing and were not touched by any of these fixes.

Closing as resolved.

## Resolution All three failing tests are now green on `main`. The fixes landed in earlier commits as part of broader test-suite maintenance: - **`flush on blur` + `mentionedPersons` debounce tests** — fixed in `cdb54c75` (`fix(tests): fix 2 more pre-existing vitest-browser spec failures`): switched `textarea.fill()` + fake timers to `userEvent.type()` + `vi.waitFor` for the mention test; used `page.getByRole('textbox').first()` locator instead of raw `document.querySelector` for the blur dispatch. - **Richtlinien Wikipedia link test** — fixed in `6ab7abb9` (`fix(tests): fix 3 pre-existing vitest-browser spec failures`): the test already checks `link.getAttribute('aria-label')` (not `textContent`), matching the component's correct `aria-label` pattern. No new `state_referenced_locally` warnings were introduced — the two existing warnings in `TranscriptionEditView.svelte:77` (for `onSaveBlock` and `documentId` passed to `createBlockAutoSave`) are pre-existing and were not touched by any of these fixes. Closing as resolved.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-critical
Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.
 P1-high
Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.
 P2-medium
Noticeable improvement; doesn't block anything; schedule opportunistically.
 P3-later
Cosmetic or parking-lot work; fine to stay open indefinitely.
 audit
Read-only audit / assessment work; produces a report rather than changing code
 bug
Something isn't working
 cleanup
Removal of dead code, vague comments, naming violations, and scratch artifacts
 collaboration
We want to extend the family archive to have more collaboration tools
 conversation
descoped
We will do that later
 devops
documentation
README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs
 epic
Marker for epic-level issues that group multiple child issues
 feature
file-upload
legibility
Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction
 notification
person
phase-1: security
Security hygiene — must be done first
 phase-2: container-images
Production-ready multi-stage Docker images
 phase-3: prod-compose
Production compose overlay + Caddy reverse proxy
 phase-4: spring-prod-profile
Spring Boot production configuration profile
 phase-5: backups
Database and object storage backup strategy
 phase-6: deployment-docs
.env.example, DEPLOYMENT.md, runbook
 phase-7: monitoring
Prometheus, Loki, Grafana, Alertmanager
 refactor
Code restructuring without behaviour change
 security
test
ui
UI/UX and accessibility issues
 user
No Label P3-later bug test
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#423
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?