fix(ui): allow c and n in create-order form text fields

[arkanoider]

Summary

Fixes #71

In the Create New Order form, global n (cancel) and c (copy invoice) shortcuts ran before generic character input, so c and n could not be typed in Payment Method and other text fields (e.g. SEPA, Bizum, cash).

• Adds is_creating_order_text_input() in form_input.rs
• Routes c/n through handle_char_input when a text field is focused (Order Type toggle unchanged)
• Refreshes AI docs for the fix and related TUI/DM behavior

Summary by CodeRabbit

• New Features

  • Improved keyboard handling while composing an order so typing won't trigger global cancel/copy shortcuts.

• Documentation

  • Expanded docs covering relay→local order status reconciliation, targeted/background reconciliation modes, DM listener/router behavior, message timeline/stepper logic, TUI form input routing, and startup background task sequencing.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c0655ff3-7618-42bd-aca2-6ed6e8c4f7d5

📥 Commits

Reviewing files that changed from the base of the PR and between a91f043 and b951715.

📒 Files selected for processing (1)

• docs/buy order flow.md

---

Walkthrough

Adds a guard helper and conditional key routing so n/c are typed into create-order text fields, and updates related documentation: TUI form behavior, message timeline stepper, relay→SQLite reconciliation, startup tasks, and DM listener early-return semantics.

Changes

Order Creation Form Input Key Guard and System Documentation

Layer / File(s)	Summary
Form input key guard helper src/ui/key_handler/form_input.rs	Introduced is_creating_order_text_input() that detects when a create-order text-editable field is focused (false only for FormField::OrderType). Added unit tests for text vs toggle focus.
Key handler conditional routing src/ui/key_handler/mod.rs	Re-exported the helper and updated handle_key_event to route n/N and c/C into handle_char_input when a create-order text field is focused; preserves existing cancel/copy behavior otherwise.
TUI form and messages documentation docs/TUI_INTERFACE.md	Documented form-focused character/backspace handling and global shortcut guard for n/N and c/C; clarified Messages tab sidebar label preference, synthetic OrderMessage insertion on early success, My Trades resync, and enumerated order form fields with source pointers.
Timeline stepper step mapping documentation docs/MESSAGE_FLOW_AND_PROTOCOL.md, docs/buy order flow.md, docs/sell order flow.md	Documented message_trade_timeline_step discriminants (repr(u8)), StepPendingOrder = 0 for pending states, six-step mapping for buy/sell flows, status→step resolution (including Status::Success → StepRate), action fallbacks, and synthetic-message handling to avoid replay snapping.
Relay reconciliation and startup integration docs/MESSAGE_FLOW_AND_PROTOCOL.md, docs/DATABASE.md, docs/STARTUP_AND_CONFIG.md	Documented relay→SQLite terminal-status reconciliation (startup bulk + periodic targeted tick), monotonic transition checks, targeted reconciliation scope, and added "Relay order DB reconcile" to startup background tasks with renumbering.
DM listener and reference documentation docs/DM_LISTENER_FLOW.md, docs/README.md, docs/CODING_STANDARDS.md	Documented early returns for Action::CantDo in handle_trade_dm_for_order; updated README architecture bullets with relay reconciliation pointer; added coding-standards example recommending splitting large key handlers and placing guarded arms before generic Char(_) handlers.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• MostroP2P/mostrix#24: Overlaps in UI key-handling and form_input/handle_key_event refactor; changes may conflict or interact with this PR.

Suggested reviewers

• grunch
• Catrya
• mostronatorcoder

Poem

🐰 A rabbit hops past forms so bright,
Where n and c can now take flight!
No more trapped keys in Payment's hold—
Text fields flow free, a tale retold.
With guards in place and docs made clear, joy hops into order creation here.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	Title concisely and accurately summarizes the main fix: allowing 'c' and 'n' characters in create-order form text fields by reordering key-handling precedence.
Linked Issues check	✅ Passed	Changes fully address issue #71 by implementing guard logic to allow 'n'/'c' in text fields and preventing global shortcuts from intercepting them.
Out of Scope Changes check	✅ Passed	Documentation updates provide necessary context for the UI fix; all code and doc changes relate directly to the key-handling precedence fix in scope.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/create-order-form-char-input

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

docs/CODING_STANDARDS.md (1)

76-76: ⚡ Quick win

Break the compound sentence into shorter sentences for clarity.

The example on line 76 is valuable but compresses multiple concepts into a single 85+ word sentence, which reduces readability. Consider breaking it into separate sentences to improve comprehension.

For instance:

• First sentence: general split examples (handle_navigation_keys, handle_form_input)
• Second sentence: location of form typing logic
• Third sentence: the specific pattern (guarded arms before generic Char(_) handler)

Additionally, the term "guarded arms" may benefit from a brief clarification (e.g., "match arms with conditional guards") for readers less familiar with Rust pattern-matching terminology.

📝 Proposed refactor for improved readability

-**Example**: If `handle_key_event` grows too large, split it into `handle_navigation_keys`, `handle_form_input`, etc. Form typing lives in **`src/ui/key_handler/form_input.rs`**; global keys like **`n`** (cancel) and **`c`** (copy) must not swallow characters when **`is_creating_order_text_input`** is true — add guarded arms in `mod.rs` before the generic `Char(_)` handler.
+**Example**: If `handle_key_event` grows too large, split it into `handle_navigation_keys`, `handle_form_input`, etc. Form typing lives in **`src/ui/key_handler/form_input.rs`**. Global keys like **`n`** (cancel) and **`c`** (copy) must not swallow characters when **`is_creating_order_text_input`** is true. To prevent this, add guarded match arms (with conditional guards) in `mod.rs` before the generic `Char(_)` handler.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/CODING_STANDARDS.md` at line 76, Rewrite the long example sentence into
three clear sentences: 1) describe breaking up large handlers (e.g.,
handle_key_event → handle_navigation_keys, handle_form_input), 2) state where
form typing logic lives (src/ui/key_handler/form_input.rs), and 3) explain the
specific pattern to implement in mod.rs (add match arms with conditional guards
before the generic Char(_) handler so global keys like `n` and `c` do not
swallow input when `is_creating_order_text_input` is true); also replace
"guarded arms" with the clearer phrase "match arms with conditional guards
(guarded match arms)".

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/buy` order flow.md:
- Line 110: The sentence claiming "Status::Success does not pick step 6 alone"
conflicts with the updated mapping that maps Status::Success -> StepRate (6);
update the wording so it reflects that a Success status now resolves to StepRate
(6) via listing_step_from_status, and clarify that Action::Rate / RateReceived
still may run before status evaluation so a combined rate+success presentation
can highlight the rate; reference Status::Success, StepRate (6),
listing_step_from_status, Action::Rate, RateReceived,
buy_listing_flow_step_from_action and sell_listing_flow_step_from_action when
making the edit.

---

Nitpick comments:
In `@docs/CODING_STANDARDS.md`:
- Line 76: Rewrite the long example sentence into three clear sentences: 1)
describe breaking up large handlers (e.g., handle_key_event →
handle_navigation_keys, handle_form_input), 2) state where form typing logic
lives (src/ui/key_handler/form_input.rs), and 3) explain the specific pattern to
implement in mod.rs (add match arms with conditional guards before the generic
Char(_) handler so global keys like `n` and `c` do not swallow input when
`is_creating_order_text_input` is true); also replace "guarded arms" with the
clearer phrase "match arms with conditional guards (guarded match arms)".

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 948157bc-7368-4006-b205-1d5ca3934087

📥 Commits

Reviewing files that changed from the base of the PR and between 87ad4f2 and a91f043.

📒 Files selected for processing (11)

• docs/CODING_STANDARDS.md
• docs/DATABASE.md
• docs/DM_LISTENER_FLOW.md
• docs/MESSAGE_FLOW_AND_PROTOCOL.md
• docs/README.md
• docs/STARTUP_AND_CONFIG.md
• docs/TUI_INTERFACE.md
• docs/buy order flow.md
• docs/sell order flow.md
• src/ui/key_handler/form_input.rs
• src/ui/key_handler/mod.rs

[mostronatorcoder]

Reviewed strictly.

This looks good to me.

I checked the key-routing change with the current handler ordering in mind, and the fix is appropriately scoped:

• n / c are now treated as normal character input when a text-editable create-order field is focused
• the OrderType toggle is still excluded, so the fix does not blur the buy/sell selector semantics
• outside that text-input context, the existing global behaviors remain intact

I do not see a blocker in the current version, and the added helper/test make the intent clear enough for future maintenance.