Change a Console UI Toolkit Using Its Current Docs and Check the Real Screen

## Follow the Current Repository Docs, Not Patterns From Older Versions - When a project declares a major rewrite, assume older learned patterns may be incompatible even if names look familiar. - Read the repository's current migration primer before designing, editing, or reviewing code. - Use the current minimal application pattern, terminology, lifecycle, and compatibility notes from versioned source documentation. - Prefer the project's constitution, contribution guide, machine-readable context, and nested rules over memory or examples from earlier versions. - If current documentation and prior knowledge disagree, follow the current repository and record the discrepancy instead of blending both designs. ## Tell App Building Apart From Toolkit Work Before Starting - First classify the request as application building, toolkit contribution, bug fixing, or visual recording and verification. - Use the dedicated application guide and pattern cookbook for consumer applications. - Use the contributor workflow for library features and defects. - Use the recording workflow for visible UI changes and interaction evidence. - Read the key concept documentation for lifecycle, view hierarchy, layout, cancellable events, and domain terminology before changing those areas. - Do not apply contributor-only internals to application examples or application shortcuts to core library work. ## Run the Checklists Before Each Edit and After Writing Code - Before every file edit, run through the repository's refresh checklist for common mistakes and local constraints. - After writing or modifying code, apply the complete post-generation validation checklist. - Read the detailed rule for any affected topic, including formatting, type declarations, construction syntax, event patterns, Unicode text, code layout, documentation, testing, diagnostics, and fragile areas. - In planning mode, create a Markdown plan in the designated plans directory with implementation steps, affected files, reuse opportunities, and verification. - Keep the plan aligned with the actual scope; update it when evidence changes the implementation path. ## Put New Tests in the Parallel Suite by Default - Restore dependencies, build once, and run focused tests without rebuilding when the build is still current. - Put new tests in the parallelizable suite by default. - Use the non-parallel suite only when process-wide static state is unavoidable and explain that dependency. - Never add new coverage to a legacy suite that is scheduled for rewrite or removal. - Select a single method or class during iteration, then expand to the relevant project when the focused result passes. - Consult the test inventory before choosing integration, stress, benchmark, parallel, or non-parallel coverage. ## Record the Running Terminal to Check UI Changes - Do not ship a visual change without observing the running interface. - Run the application in a pseudo-terminal, inject representative keystrokes, and capture the rendered session. - Read the machine-readable recording frame by frame to verify what actually appeared, rather than trusting only a human preview. - Attach a visual artifact when reviewers need to assess appearance or interaction. - For deterministic assertions, use in-process input injection, virtual time, and driver-level screen capture. - Verify layout, focus, input handling, Unicode graphemes, cancellation, and redraw behavior at the level affected by the change. ## Follow the Repository's Exact Spacing and Type Rules - Preserve the repository's required spacing around calls and indexing, brace placement, and blank-line rules. - Use explicit types except for the small set of built-in primitive types allowed by the local guide. - Prefer target-typed construction and collection-expression syntax where required. - Use one public or internal type per file. - Order members and backing fields according to the code-layout rule. - For unused callback parameters, use the repository's discard convention. - Run the repository formatter and post-generation checks; do not hand-wave style differences as cosmetic. ## Use Early Exits and the Project's Own Terms - Prefer guard clauses and early exits; invert conditions instead of wrapping the successful path in deep nesting. - Apply the same early-exit rule to methods, callbacks, and loops. - Use the project's containment terms consistently, and reserve generic relationship terms for non-containment references. - Write code that explains itself through names, types, and structure before adding comments. - In reference, how-to, and API documentation, state the goal and then give a direct imperative action. - Document public contracts, cancellable workflow behavior, Unicode grapheme handling, and non-obvious invariants with the repository's required documentation format. ## Add Regression Tests Without Reducing Coverage - Mark agent-generated tests using the repository's accepted agent-and-model annotation. - Never reduce coverage to make a change pass. - Avoid global application initialization in tests unless the behavior specifically requires process-wide state. - Prefer isolated setup, deterministic inputs, virtual time, and observable assertions. - Place each test in the suite matching its state model, not merely the closest filename. - Add regression coverage for the user-visible defect or behavior, including layout and event-order cases when relevant. ## Use the Repository's Logging and Leave Fragile or Unrelated Code Alone - Use the repository's logging, test-logging, and tracing facilities; do not write directly to the console from library or test code. - Do not refactor a documented fragile subsystem as incidental cleanup. - Do not modify unrelated code while implementing a focused feature or fix. - Introduce no new compiler, analyzer, documentation, or test warnings. - Re-read the diff for formatting, terminology, test placement, and accidental scope expansion before reporting completion. - If a fragile area must change, isolate the smallest necessary edit and verify its dedicated behavior before broader tests.