Storm Dragon
60 lines
2.7 KiB
Markdown
60 lines
2.7 KiB
Markdown
# 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
|
|
|
|
- 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.
|
|
|
|
## 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.
|