chipmates/agoracosmica

What The figure carousel's navigation controls in the Audio Library expose hardcoded English accessible labels ("Previous figure", "Next figure", and the select control). The rest of the component already localizes through our translation hook, so these are the odd ones out. A German user on a screen reader hears English here. Why it matters We target WCAG AA and ship in English and German. All displayed text, including accessible labels, should go through useTranslation. Bonus: the correct German strings already exist in the bundle, they're just not wired up. Where to look client/src/components/AudioLibrary/AudioLibraryModal.tsx. The component already uses the translation hook elsewhere, so the pattern is right there. Before adding new keys, check whether matching ones already live under the audioLibrary namespace. Done when The navigation labels come from the translation system, and a German user gets German announcements. No visual or behavior change. Why this is a good first issue

What Running pnpm lint inside client/ floods the terminal with parsing errors on our .ts and .tsx files (Unexpected token :, The keyword 'interface' is reserved). Every file fails to parse, so the lint script gives no real signal today. Why it matters Lint is one of the checks you reach for before opening a PR, and right now it's just noise. A working pnpm lint makes the project easier to contribute to. (CI runs tests and the build, not lint, so this stayed quiet.) Where to look The setup lives in client/eslint.config.js. It targets .ts/.tsx, so the question is why ESLint can't actually parse them. That's the thread to pull. Done when pnpm lint runs to completion without parser crashes. Scope it to getting the linter parsing our TypeScript. If real warnings surface once it works, leave tightening individual rules for later. Why this is a good first issue Self-contained, reproducible in one command, config only (no app code). It rewards understanding the toolchain over copying a one-lin

What The unsaved-changes confirmation dialog renders a container with role="alertdialog" and aria-modal="true", but it has no accessible name (no aria-label or aria-labelledby). A dialog that has a role but no name is a WCAG 2.2 AA gap (4.1.2 Name, Role, Value) and goes against the WAI-ARIA Authoring Practices for dialogs. The visible title is right there in the component, so the dialog just needs to point at it. Where client/src/components/settings/ChangesAlertDialog.tsx (the role="alertdialog" container and the heading that renders its title). What to do Associate the dialog with its existing visible title so screen readers announce the dialog by name. The heading component used here already forwards an id to the rendered element, so you can wire the two together without adding any new visible text. Read the file and figure out the right two attributes. Done when The dialog's accessible name matches its visible title, verifiable in the devtools accessibility pane or with a screen

What In the Prism audio player, the resume-banner dismiss button has only a × glyph as its content and no text or aria-label. A screen reader announces it as "times" or "multiplication sign," which tells the user nothing about what the button does. That is a WCAG 2.2 AA gap (4.1.2 Name, Role, Value), and we target AA. Where client/src/components/PrismPlayer/PrismPlayer.tsx (the resume-banner dismiss button, class prism-player__resume-dismiss). What to do Give the button a meaningful accessible name. The equivalent dismiss button in StoryPlayer.tsx already does this, so follow that pattern. One thing to improve on while you are there: the app ships in English and German, so prefer a translated label over a hardcoded string. Look at how other strings in this file are localized and reuse that. Done when The button exposes a real accessible name (for example "Dismiss" in English, "Schließen" in German), verifiable in the browser devtools accessibility pane or with a screen reader. No

What thinkingTagStripper.ts strips <think>...</think> reasoning blocks out of model output before it reaches the user or the council parser. Thinking-capable models (Qwen3, DeepSeek-R1 distills, QwQ) emit these blocks, so this module runs on the live chat, council, and summary streams. It has no test coverage today. The streaming filter is a small state machine, and the cases that matter are the ones that only happen mid-stream, so it is worth pinning down. Where client/src/utils/thinkingTagStripper.ts (two exported functions: a whole-string stripper and a streaming filter). New test file under client/tests/unit/. What to do Add a Vitest file that imports the real functions (please do not copy them into the test) and covers their behavior. Read the module first, then think about the cases that matter for a stream: a tag split across two chunks, a block that never closes, more than one block in the same input, and input with no block at all. The two existing tests in client/tests/unit