Skald Project Instructions

Skald is a hard fork of Galene into an audio-only, hall-based conferencing server.

Direction

Treat Skald as incompatible with Galene unless compatibility is explicitly requested.
Do not add legacy Galene routes, config fallbacks, protocol shims, migration behavior, or compatibility aliases by default.
Replace Galene branding and group/room terminology with Skald and hall terminology everywhere practical.
Apply renames and removals thoroughly. When changing a concept, route, command, UI label, config key, file name, or behavior, search for every related surface and update even small details such as tests, examples, help text, comments, docs, error messages, CSS selectors, and generated/static asset references.
Remove video behavior rather than hiding it.
Reject incoming video intentionally.
Recordings should become single mixed Ogg Opus audio files.

Skald is production software; prefer small, scoped maintenance changes with focused verification.
Use a temporary local plan file only for large or risky batches that need a resumable checklist.
Building the Arch package updates distro-packages/Arch-Linux/skald-git/PKGBUILD with the generated pkgver, so this file is often dirty after package builds.
Keep changes scoped to the current batch. Do not mix in unrelated cleanup.
Before behavior changes, inspect the current code path and tests rather than assuming Galene behavior still applies.

Run the narrowest useful verification for each change.
For Go changes, prefer focused package tests first, then broader go test ./... when the change crosses packages.
For frontend changes, verify renamed assets load and keyboard-accessible controls still work where practical.
For shell script changes, run shellcheck.
If verification is not possible, state that plainly.

The browser UI must be fully screen-reader accessible, not merely visually simplified.
Dynamic conference events must be announced through appropriate live regions so screen readers read important changes automatically. This includes chat messages, participant joins and leaves, raised hands, recording state changes, moderation actions, connection status changes, and errors that require user attention.
Use polite live regions for routine updates and assertive live regions only for urgent or blocking errors.
Avoid duplicate announcements when updating visible text and live-region text.
The browser UI must be audio-only and keyboard accessible.
Preserve labels or accessible names when removing or reworking controls.
Do not rely on visual layout, sound, or color alone to communicate state.