Greetings 

I am  working on an entry for this jam and would love some help from this community, since the whole point of the project is to actually get this right rather than guess at it.

What it is: Veiled Dominion: Duet is a scoped-down, 2-player variant of a larger 4-player chess-variant project. It's standard chess plus two extra mechanics:

• Radius of Ruin — one player's piece emits a danger zone; anything that ends its turn nearby gets temporarily weakened ("Veiled").
• Sanctuary — a second piece creates a safe zone nearby that cancels the danger effect.

Everything else from the bigger project (four players, hidden pieces/fog of war, card/dice layers) is deliberately cut for this entry — full information, one board, one ruleset, so it's actually finishable as a fully non-visual game within the jam window rather than a tech demo of one cue.

What I'm looking to build for accessibility, specifically:

• Move input via typed/spoken algebraic notation, plus a "query square" command to read back board state on demand — no pointing or dragging required.
• Turn changes, checks, and captures announced via TTS.
• The Radius of Ruin communicated through a continuous proximity-to-pitch/volume audio mapping (not a static beep) — soft attack/decay, no sudden startling spikes.
• Sanctuary represented as ambient sound dampening near the safe piece, on its own independent volume channel from music/SFX.

What I'm looking for:

1. Blind or low-vision playtesters — willing to play a rough build partway through the jam and tell me honestly where the audio cues are unclear, annoying, too subtle, too startling, or just don't map the way you'd expect. Early feedback (not just at the end) is what actually shapes this, so even a short session mid-jam is genuinely useful.
2. Anyone who's built accessible chess/board-game input before — if you've solved move-input-via-notation or screen-reader board narration and have advice, patterns, or pitfalls to share, I'd rather learn from you than reinvent it badly.
3. Feedback on the audio design itself — even without playing, if you have thoughts on proximity-mapping conventions (pitch vs. volume vs. panning, what's felt too subtle or too sharp in other games) I'd love to hear it.

## Duet build update: architecture alignment pass

Duet (the 2-player, screen-reader-first jam variant) is still its own standalone HTML/JS build — 

it doesn't share code with the main C#/.NET/Unity engine, and that's staying true. But I wanted its internal structure to at least follow the same *shape* as the real engine's documented architecture, so anyone moving between the two codebases later isn't relearning a totally different mental model.

**What changed:**

- Replaced the single flat move-handling function with the same Ordered Engine Sequence the main engine's ARCHITECTURE_OVERVIEW.md defines: PlayerIntent → OnValidateIntent → OnApplyMove   → OnResolveCapture → OnResolveSystems → OnCheckEndState → Snapshot → UI Refresh. Each stage is  its own function now, instead of one function doing everything at once.

- Added an actual Snapshot layer — the UI (board render, audio cue) now only ever reads from a cloned snapshot of state, never touches live game state directly. Matches the engine doc's "consumers should react to snapshots" rule.

- Named the Radius of Ruin / Veiled logic as explicit systems (RadiusOfRuinSystem, VeiledStateSystem) instead of inline loops.

**Bug fix this surfaced:** the original build only set a piece's Veiled status on *first* entry into the Radius of Ruin. If a piece was already Veiled and re-entered the aura, nothing happened 

— the timer just kept counting down on its original schedule. The engine doc is explicit that re-entry should *refresh* the duration, not get ignored or stack. Fixed to match spec, and checked it with a small headless test (tick down to 1 turn remaining, re-trigger, confirm it resets to full duration).

**What didn't change:** the rules, the board, the accessibility architecture (ARIA live regions driving your own screen reader), the audio cue, or the fact that this is plain HTML/JS/Web Audio 

— no build step, no engine dependency, no GenAI anywhere in it.

Same game. Cleaner internals, and one real correctness fix. Full build's up on the itch page now.

The accessible path (typed notation + screen reader narration) isn't changing — that's the actual point of this build, and it already works the way established tools like Lichess's Blind Mode do. What I'm adding is a second, purely additive way in: click-to-select on the visual board for sighted players, plus a visible legend so the notation isn't a hidden secret. Neither of those touches or slows down the screen-reader path — they're just a faster on-ramp for people who don't need it.