# 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.

## Workflow

- Use `todo.txt` as the source of truth for staged work.
- Preserve the todo status markers:
  - `-` means open.
  - `+` means implemented, needs testing.
  - `X` means tested and done.
- Work in small batches and update `todo.txt` only for items actually completed
  or tested.
- Before beginning a new phase or section, review all earlier `+` and `X`
  sections in `todo.txt`; confirm their status still matches the code, tests,
  docs, and user-facing surfaces, and downgrade stale `X` markers when evidence
  no longer supports them.
- 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.

## Verification

- 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.

## Accessibility

- 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.