Skip to content

correct: Handle mixed-case damage explicitly #37

Description

@BenWestgate

correct() and the standalone correct command previously reported no candidate / “No valid correction found” for otherwise repairable mixed-case input, while interactive recovery already applied majority-case interpretation.

Implemented and reviewed in PR #42: apply the same majority-case interpretation to the public correction API and standalone CLI, retry minority-case characters as erasures, preserve the shared deadline/capture ledger, keep explicit --bytes enforcement, preserve the operator's original characters in CorrectionEdit.observed, and never Unicode-case-fold non-ASCII text. The parser itself remains strict: mixed-case codex32 strings are invalid until corrected.

PR #45's distinct correct exit statuses are already merged into #42's branch, so the current #42 head carries both fixes and has green exact-head CI. Keep this issue open until #42 is human-integrated into current reviewability-v1; the branch has ordinary base divergence after #7/#51 rather than a known semantic blocker. Rerun the existing mixed-case/status regressions and frozen differential verifier on the integrated tip.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: cliCommand-line interface behavior.area: correctionCorrection engine and correction UX.bugSomething isn't workinggate: adversarial reviewResolve, merge, or explicitly defer before the next full adversarial review.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions