Checkpoint audio-only Skald fork work

AGENTS.md

@@ -0,0 +1,64 @@
+# 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.