docs: fix verified technical errors from deep review

- formatter: read-only _bind paths have no /XX/ segment — correct the
  resolved expression-binding string and the path = abap_true note
  (verified against z2ui5_cl_core_srv_bind=>get_client_name)
- lock: reorder INTO after WHERE in the two inline optimistic-check
  SELECTs (strict ABAP SQL) to match the full source below them
- agent guide: check_on_navigated fires on return from apps called via
  nav_app_call, not from same-app popup_display popups — make both
  comments precise
- how_it_all_works: remove self-referential cross-reference in section
  16 and qualify the "2,300 lines" figure as the original core
  communication layer

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EC2cWJafPETwcMbh3NCsgH

Author: claude

docs/advanced/agent.md

@@ -54,7 +54,7 @@ ENDCLASS.
 ```abap
 IF client->check_on_init( ).            " first call
   " load data + render view
-ELSEIF client->check_on_navigated( ).   " returned from sub-app / popup
+ELSEIF client->check_on_navigated( ).   " returned from a called sub-app (nav_app_call), incl. built-in popup apps
   " refresh state
 ELSEIF client->check_on_event( `POST` ). " user fired event 'POST'
   " handle it
@@ -135,7 +135,7 @@ CLASS zcl_app_xxx DEFINITION PUBLIC.
 
     METHODS on_init.        " first call: load data, render view
     METHODS on_event.       " user triggered an event
-    METHODS on_navigation.  " returned from sub-app or popup
+    METHODS on_navigation.  " returned from a sub-app called via nav_app_call
     METHODS view_display.   " build and render the view
     METHODS data_read.      " SELECT
     METHODS data_update.    " INSERT / UPDATE / DELETE

docs/cookbook/expert_more/lock.md

@@ -297,15 +297,15 @@ On read, remember the record's change timestamp. On save, re-read and reject if
 ```abap
 METHOD data_read.
   SELECT SINGLE aedat, UPD_TMSTMP FROM vbak
-    INTO ( @token_aedat, @token_aezet )
-    WHERE vbeln = @vbeln.
+    WHERE vbeln = @vbeln
+    INTO ( @token_aedat, @token_aezet ).
 ENDMETHOD.
 
 METHOD on_event_save.
 
   SELECT SINGLE aedat, UPD_TMSTMP FROM vbak
-    INTO ( @DATA(now_aedat), @DATA(now_aezet) )
-    WHERE vbeln = @vbeln.
+    WHERE vbeln = @vbeln
+    INTO ( @DATA(now_aedat), @DATA(now_aezet) ).
 
   IF now_aedat <> token_aedat OR now_aezet <> token_aezet.
     client->message_box_display( `Record changed — please reload.` ).

docs/cookbook/model/formatter.md

@@ -13,7 +13,7 @@ UI5 formatter types use a special JSON-based binding syntax with these key eleme
 
 Note on ABAP syntax: inside string templates (`|...|`), escape the curly braces as `\{` and `\}`, because `{ }` normally denotes an embedded ABAP expression.
 
-The `path = abap_true` parameter on `_bind` / `_bind_edit` returns only the raw model path (e.g., `/XX/AMOUNT`) rather than the full binding expression (`{/XX/AMOUNT}`), so you can embed it inside the `parts` array or a single-path `path:` entry.
+The `path = abap_true` parameter on `_bind` / `_bind_edit` returns only the raw model path rather than the full binding expression, so you can embed it inside the `parts` array or a single-path `path:` entry. For `_bind_edit` the path is e.g. `/XX/AMOUNT`; read-only `_bind` paths have no `/XX/` segment (`/AMOUNT`).
 
 For example, this ABAP code:
 ```abap
@@ -93,7 +93,7 @@ ABAP `abap_bool` is `"X"` or `""`. UI5's `CheckBox` expects `true` / `false`. Tw
 ```abap
 )->checkbox( selected = `{= $` && client->_bind( mv_flag ) && ` === 'X' }` )
 ```
-This resolves to `{= ${/XX/MV_FLAG} === 'X' }`. Note that expression bindings cannot write back — checking the box will not flip the ABAP attribute.
+This resolves to `{= ${/MV_FLAG} === 'X' }` — read-only `_bind` paths have no `/XX/` prefix (that segment marks two-way `_bind_edit` bindings). Note that expression bindings cannot write back — checking the box will not flip the ABAP attribute.
 
 **ABAP-side conversion** — keep a parallel `string`-typed attribute (`'true'` / `'false'`) for two-way binding, and translate before/after each event:
 ```abap

docs/technical/how_it_all_works.md

@@ -214,7 +214,7 @@ SAP GUI (stateful) vs. abap2UI5 (restful)
 
 But use this feature only for interim results; take care when serializing other parts of your app.
 
-We've earned significant flexibility with (9) (10) (11) (16); the next sections focus on how the framework cuts its complexity, starting with the initial request.
+We've earned significant flexibility with (9) (10) (11) and the drafts from this section; the next sections focus on how the framework cuts its complexity, starting with the initial request.
 
 #### 17. Initial Request
 
@@ -307,7 +307,7 @@ And Fiori Elements, with all its floorplans and templates, is simple and will ke
 
 #### 25. System Footprint
 
-We keep the system footprint small — abap2UI5 ships only ABAP classes, with no CDS or RAP artifacts. Most of the code lives in user apps outside the framework (21) (22). Overall, the framework comes to about 2,300 lines of code spread across one HTTP-Handler, two interfaces, and one database table:
+We keep the system footprint small — abap2UI5 ships only ABAP classes, with no CDS or RAP artifacts. Most of the code lives in user apps outside the framework (21) (22). Overall, the core communication layer originally came to about 2,300 lines of code spread across one HTTP handler, two interfaces, and one database table (the framework has grown since — most notably the optional fluent view builder — but the core stays this small):
 
 <img width="600" alt="System footprint of abap2UI5" src="https://github.com/user-attachments/assets/981ab684-d2cf-4f56-b25c-c333db3c6dcc" />
 
@@ -365,7 +365,7 @@ Automated ABAP downporting greatly boosts efficiency. See the abaplint dashboard
 
 In short: inspired by "HTML Over-the-Wire" (1)(2)(3), we combined UI and Data (7) and created a "UI5 Over-the-Wire" approach by sending the XML-View from the server (6). We then used a single generic HTTP-Service for all apps (13), independent of the View and Data Model (12). This gives us great flexibility, so we can create Data Models (10) and Views (11) dynamically at runtime, which greatly cuts the number of backend artifacts.
 
-Next, we explored several ideas for how the framework cuts its complexity by avoiding frontend artifacts (17), removing extra customizing layers (19), and separating the view from the framework (21), along with app-specific JS or HTML (22). The result is a pure source-code approach with only one database table, two interfaces, one class, and about 2,300 lines of code (25). We build it in a single code line (27), making it cloud- and on-premise-ready and downportable to older releases (28). Paired with abapGit, you can build apps that run on nearly every release.
+Next, we explored several ideas for how the framework cuts its complexity by avoiding frontend artifacts (17), removing extra customizing layers (19), and separating the view from the framework (21), along with app-specific JS or HTML (22). The result is a pure source-code approach whose core needs only one database table, two interfaces, one handler class, and roughly 2,300 lines of code (25). We build it in a single code line (27), making it cloud- and on-premise-ready and downportable to older releases (28). Paired with abapGit, you can build apps that run on nearly every release.
 
 Overall, with abap2UI5 you need to set aside some common rules: no separation between View and Model in the HTTP communication (12), HTML and JavaScript live directly in the source code (17) (22), we don't use OData or RAP (7), and there are other tradeoffs to weigh (24). But if you accept all of this, you get a very minimal approach where you only need to write a single method to build standalone UI5 apps (15).