docs: analysis on new user input API [compy-toys#77]

Multiple iterations (LLM-assisted, strictly human-directed)
over planned major architectural change.

Result is a (supposedly coherent) set of documents for stakeholders review --
from requirements to design and spec/roadmap.

(plus multiple cross-referenced notes supporting traceability
and formal verification of suggested solution)

Starting point: doc/development/wip/77-new-input-api/README.md

Author: hleb-rubanau

doc/development/wip/77-new-input-api/README.md

@@ -0,0 +1,31 @@
+# Feature #77 — New Input API
+
+**TL;DR:** a callback-based input API for projects, replacing the polling
+functions (`input_text`, `input_code`, `validated_input`, `user_input`). It
+turned out to touch keyboard routing across the whole app, not just the REPL —
+so it got a proper upfront analysis instead of a dive-in. **Complex, but
+solvable**, and pre-planned so building can start on a green light. Old
+functions keep working; nothing existing breaks.
+
+## Start here
+
+Read the **`summaries/`** folder — that's the whole feature at stakeholder
+altitude, ~30 min total. The one that needs your call is
+**`summaries/decisions.md`**.
+
+| # | Summary | What it answers |
+|---|---|---|
+| 1 | `summaries/requirements.md` | What was asked for |
+| 2 | `summaries/assessment.md` | What the code does today |
+| 3 | `summaries/decisions.md` ⭐ | The calls awaiting approve / veto |
+| 4 | `summaries/design.md` | How it works |
+| 5 | `summaries/spec.md` | The API contract |
+| 6 | `summaries/roadmap.md` | Build plan + effort (~35–59 h) |
+
+## If you want to dig
+
+- **Full docs** — same names in this folder (`decisions.md`, `design.md`, …),
+  for when a summary isn't enough.
+- **`input.md`** — your ticket + clarification, verbatim.
+- **`notes/`** — supporting codebase analysis.
+- **`validation/`** — the review rounds and their fixes.