Six-dot Braille cells
A dot pattern is data before it becomes a character. Dotbraid helps you work on small encoding functions in a Windows project while keeping accepted positions and rejected inputs visible.
def braille_cell(dots):
if any(type(d) is not int or d < 1 or d > 6 for d in dots):
raise ValueError("dot range")
if len(set(dots)) != len(dots):
raise ValueError("duplicate dot")
return chr(0x2800 + sum(1 << (d - 1) for d in dots))- Project
- Check the empty cell and all six dots, rejecting duplicate positions, dot seven and non-integer input.
- Review before applying
- Compare actual behavior with the expected result. If a check fails, investigate it before applying more changes.
- Connection
- Base URL, credentials and a reachable server.
def braille_cell(dots):
if any(type(d) is not int or d < 1 or d > 6 for d in dots):
raise ValueError("dot range")
if len(set(dots)) != len(dots):
raise ValueError("duplicate dot")
return chr(0x2800 + sum(1 << (d - 1) for d in dots))Make the input contract visible to every caller
A compact encoding helper can hide decisions that matter throughout an application. Dotbraid gives those decisions a Windows AI coding workspace: the project folder, the connected conversation and proposed edits remain part of the same task. Begin by identifying what callers supply, what they expect back and which invalid inputs should be rejected.
Suppose you are developing a helper that converts six-dot cell positions into a Unicode character. Ask the model to inspect validation as well as conversion, with examples of duplicate positions and values outside the supported range. The development task is to make the contract explicit in your code, not simply obtain a character that looks plausible on screen.
Review how that contract reaches the surrounding interface. A rejected position should produce an intentional response rather than an unrelated failure later in rendering. Run your own checks for valid cells, repeated positions and unsupported types, then examine the diff for changes outside the helper and its necessary callers. Keep broader text-processing requirements as separate decisions.
Dotbraid supports model connections through OpenAI-compatible or Anthropic endpoints. You can select an uncensored AI model if your endpoint offers one, while its tools, context and restrictions remain model-dependent. Use the assistant to clarify implementation choices and keep acceptance grounded in the project’s own tests.
Defining a small encoder’s responsibility
Does a dot-to-character helper translate complete text?
No such capability follows from that helper. Treat cell encoding and language-specific translation as different requirements. When requesting a change, specify which layer you are editing and avoid asking the model to assume rules that the project has not defined.
Why reject a repeated dot instead of silently removing it?
Either policy needs an explicit contract. Rejection can expose incorrect upstream data, while deduplication changes what inputs are accepted. Ask the assistant to show affected callers before changing the policy and test the behavior you choose.
What should a useful fixture contain?
Include the input positions, expected code point and expected rejection for invalid cases. A rendered glyph alone can be ambiguous across fonts. Keep exact values in the tests so review does not depend entirely on visual appearance.
How do I keep this change small?
Name the helper and the error path that need attention. Request that unrelated rendering and text conversion remain outside the patch. If a caller needs updating, ask why and review that addition with the original input contract.
Dotbraid · Updated 2026-10-25
