@fui-org/fui-cli 2.1.4 → 2.2.1

package/skills/{fui-skill → fui}/references/fullstack-workflow.md

@@ -1,313 +1,314 @@
-# Full-Stack Module Workflow
-
-> Owns: **the 6-step UI-first fullstack module workflow (analyze → UI with hard-coded data → lock contract → SP → API wiring → static verification)** and **the Design Review Gate procedure** (SKILL.md §3 holds only the rule "must pass the gate"; the steps live here). tAPI conventions: [tapi-reference.md](tapi-reference.md); multi-module design: [system-design.md](system-design.md).
-
-**UI-first:** build UI (FUI) with hard-coded data, confirm visuals with `fui module simulate --render`, THEN lock the API (tAPI) contract and write SPs. Fixing data shape while it is a literal in `data[]` is far cheaper than after `IN`/`OUT`/`watch` depend on it. No step calls a real API/SP to "test" — verification = read + reason + mock ([verification.md](verification.md)). Read [tapi-reference.md](tapi-reference.md) before step 3.
-
----
-
-## Step 1 — Analyze requirements
-
-**1.1 Business need:** list / search / filter? add / edit / delete? report / statistics? workflow (approve, reject, status)?
-
-**1.2 Data (initial estimate — locked in step 3):** main entity and linked entities; which fields are displayed, which are input.
-
-**1.3 Permissions and auth:**
-
-- Login required? (no → use `AUTH_` in the SP)
-- Rights by `sys_SystemRight`? → handle in the SP body
-
-**Output:** feature list + main entity names (types/column names not yet locked).
-
----
-
-## Step 1b — Design Review Gate (mandatory, before the first line of code)
-
-SKILL.md §3 = the **rule** (every new system/page/function passes); this = the **procedure**, for fullstack and UI-only modules.
-
-1. **Business efficiency** — steps to finish the task, data truly needed, redundant steps.
-2. **Project patterns** — `fui module list` + `fui module get` on similar modules (layout, control naming, action placement, filter/table/dialog). Match existing pages; **never invent a new style when a convention exists**.
-3. **Sketch the UI** in words/rough layout — controls, placement, dialog/form flow.
-4. **Self-review** — friendly? step count? Add/Edit/Delete, filters, pagination where expected? consistent? Issues → **fix the sketch first**, never in code.
-5. Only then write code (step 2+).
-
-**Choose the build approach:**
-
-| Approach                           | When                                                                                                                                                         |
-| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| **A — plain module.json**          | Simple page: data display, single-table CRUD, basic form. Fewer files, easy to maintain.                                                                     |
-| **B — Vue component (`uc-*.vue`)** | Complex UI: multi-area dashboard, custom layout, UI logic reused in many places, or `controls` over ~200 lines ([component-design.md](component-design.md)). |
-
-> Unspecified → **propose** one with a short reason and **wait for confirmation**; never choose silently.
-
-**Component priority**: `f-*` first (`f-button` over `v-btn`, `f-table` over `v-data-table` for EVERY table, `f-echart` for every chart); `v-*` only when no FUI equivalent exists. → [component-quickref.md](component-quickref.md)
-
-**Design System gate** (parallel): decide App-mode vs Web-mode and check `{projectId}/DESIGN.md` **before** sketching — separate aesthetic rules; never mix. → [design-modes.md](design-modes.md)
-
-**Output:** self-reviewed sketch, approach A/B locked (user-confirmed if we proposed it), aesthetic mode decided.
-
----
-
-## Step 2 — Build UI with hard-coded data
-
-Whole UI on **literal** data in `data[]`, no API yet. Structure: [module-json-anatomy.md](module-json-anatomy.md), [controls-patterns.md](controls-patterns.md).
-
-```json
-"data": [
-  { "keyword": "" },
-  { "classId": "" },
-  { "studentList": [
-      { "StudentID": "SV001", "FullName": "Nguyễn Văn A", "ClassID": "C01", "ClassName": "Lớp 10A", "GPA": 8.5 },
-      { "StudentID": "SV002", "FullName": "Trần Thị B", "ClassID": "C02", "ClassName": "Lớp 10B", "GPA": 7.2 }
-  ] },
-  { "form": {} },
-  { "dialogOpen": false }
-]
-```
-
-`f-table`/`v-dialog`/form patterns: [component-table.md](component-table.md), [ui-templates.md](ui-templates.md).
-
-**Visual QA now:** `fui module simulate --render` (vueData override: `fui module simulate --help`). Read screenshot + DOM audit; fix display bugs (horizontal overflow, broken dialog, missing labels...) before moving on.
-
-**Output:** `module.json` with complete layout, running on hard-coded data, clean `--render` QA.
-
----
-
-## Step 3 — Lock data shape + design API endpoints
-
-From the step-2 fields (visually confirmed before becoming an SP contract), lock exact field names + types (→ SQL column types) and the source entity/table of each. Map features to SPs as `spAPI_{Entity}{Action}`; full naming (`spAPI_*` / `spAPI_AUTH_*` / `spAPIFILE_*`, `@url1_`, response contract) is in [tapi-reference.md](tapi-reference.md).
-
-| Feature           | SP name                      | Main params            |
-| ----------------- | ---------------------------- | ---------------------- |
-| List              | `spAPI_{Entity}List`         | Filter params (custom) |
-| Detail            | `spAPI_{Entity}Get`          | `@url1_{EntityID}`     |
-| Insert            | `spAPI_{Entity}Insert`       | Entity fields          |
-| Update            | `spAPI_{Entity}Update`       | ID + fields to update  |
-| Delete            | `spAPI_{Entity}Delete`       | `@url1_{EntityID}`     |
-| Lookup / dropdown | `spAPI_AUTH_{Entity}Options` | No auth, returns list  |
-
-**Example — "Student management"** (matches step-2 fields `StudentID`, `FullName`, `ClassID`, `ClassName`, `GPA`):
-
-```
-spAPI_StudentList       -- danh sách, lọc theo ClassID + Keyword — trả đúng các cột đã hiển thị ở bước 2
-spAPI_StudentGet        -- chi tiết theo url1=StudentID
-spAPI_StudentInsert     -- thêm mới
-spAPI_StudentUpdate     -- cập nhật
-spAPI_StudentDelete     -- xoá theo url1=StudentID
-spAPI_AUTH_ClassOptions -- dropdown danh sách lớp (không cần auth)
-```
-
-**Output:** full SP list; names + params + response shape match the fields used in the UI.
-
----
-
-## Step 4 — Write SQL stored procedures
-
-Per tAPI rules ([tapi-reference.md](tapi-reference.md)) and the step-3 contract.
-
-**SELECT (list):**
-
-```sql
-CREATE PROCEDURE spAPI_StudentList
-    @Keyword    nvarchar(200) = NULL,
-    @ClassID    varchar(20)   = NULL,
-    @sys_UserID varchar(9)
-AS BEGIN
-    SELECT s.StudentID, s.FullName, s.ClassID, c.ClassName, s.GPA
-    FROM tblStudent s
-    JOIN tblClass c ON s.ClassID = c.ClassID
-    WHERE (@Keyword IS NULL OR s.FullName LIKE '%' + @Keyword + '%')
-      AND (@ClassID IS NULL OR s.ClassID = @ClassID)
-    ORDER BY s.FullName
-END
-```
-
-**INSERT:**
-
-```sql
-CREATE PROCEDURE spAPI_StudentInsert
-    @StudentID  varchar(9),
-    @FullName   nvarchar(100),
-    @ClassID    varchar(20),
-    @sys_UserID varchar(9)
-AS BEGIN
-    IF EXISTS (SELECT 1 FROM tblStudent WHERE StudentID = @StudentID)
-    BEGIN
-        RAISERROR(N'Mã sinh viên đã tồn tại', 16, 1)
-        RETURN
-    END
-    INSERT INTO tblStudent (StudentID, FullName, ClassID, CreateUser, CreateTime)
-    VALUES (@StudentID, @FullName, @ClassID, @sys_UserID, GETDATE())
-    SELECT mess = N'Thêm thành công', id = @StudentID
-END
-```
-
-**DELETE:**
-
-```sql
-CREATE PROCEDURE spAPI_StudentDelete
-    @url1_StudentID varchar(9),
-    @sys_UserID     varchar(9)
-AS BEGIN
-    DELETE FROM tblStudent WHERE StudentID = @url1_StudentID
-    SELECT mess = N'Đã xoá', id = @url1_StudentID
-END
-```
-
-**GET (detail, convert_to_object):**
-
-```sql
-CREATE PROCEDURE spAPI_StudentGet
-    @url1_StudentID varchar(9),
-    @sys_UserID     varchar(9)
-AS BEGIN
-    SELECT convert_to_object = '',
-           s.StudentID, s.FullName, s.ClassID, c.ClassName, s.GPA, s.Email
-    FROM tblStudent s
-    JOIN tblClass c ON s.ClassID = c.ClassID
-    WHERE s.StudentID = @url1_StudentID
-END
-```
-
-> `convert_to_object = ''` when the SP returns exactly one record → response is an object instead of `data[0][0]`.
-
-Deploy with `fui sp save` + `fui sp deploy` (never call the endpoint to "try it" — see step 6).
-
-**NEVER put `GRANT EXECUTE` in the .sql file.** A `CREATE PROCEDURE` body runs **to end of batch**; `_sql_execute_NonQuery` sends one batch and **does not support `GO`** (client directive, not T-SQL). A `GRANT` after `END` is **swallowed into the SP body** — runs on every call, never grants at deploy. No error; the endpoint just returns a permission error while the SP looks right.
-
-`fui sp deploy` **auto-grants** new procedures (not FUNCTIONs — functions need no EXECUTE for `[public]`), then **re-checks `sys.database_permissions`** and reports:
-
-- `✓ [public] đã có quyền EXECUTE trên "..."` — done.
-- `❗ [public] CHƯA có quyền EXECUTE ...` — the output prints a runnable command; copy verbatim:
-  `fui exec "GRANT EXECUTE ON [dbo].[spAPI_StudentList] TO [public] AS [dbo]" --db ...`
-- Grant failed but deploy succeeded → **the SP is already on the server**; run the GRANT above, **do not redeploy**.
-
-Deploying via `fui exec` with `CREATE PROCEDURE` → **no auto-grant, no tAPI param-cache clear**; fui warns and names the two commands to run next.
-
-**Output:** all step-3 SPs deployed.
-
----
-
-## Step 5 — Replace hard-coded data with API bindings
-
-Keep the step-2 layout; replace `data[]` literals with named `IN`/`OUT`/`CALLBACK` actions on the deployed SPs.
-
-**5.1 Actions replacing hard-coded data**
-
-```json
-"data": [
-  { "keyword": "" },
-  { "classId": "" },
-  { "studentList": [] },
-
-  {
-    "fetchStudents": {
-      "API": "/{apiName}/StudentList",
-      "IN": { "Keyword": "vueData.keyword", "ClassID": "vueData.classId" },
-      "OUT": "studentList"
-    }
-  },
-  {
-    "saveStudent": {
-      "API": "/{apiName}/StudentInsert",
-      "IN": {
-        "StudentID": "vueData.form.StudentID",
-        "FullName":  "vueData.form.FullName",
-        "ClassID":   "vueData.form.ClassID"
-      },
-      "CALLBACK": [
-        { "CALL": "vueData.fetchStudents" },
-        { "MESS": "Thêm thành công" },
-        { "EXE":  "vueData.dialogOpen = false" }
-      ]
-    }
-  },
-  {
-    "deleteStudent": {
-      "API": "/{apiName}/StudentDelete/`{{vueData.selectedID}}",
-      "CONFIRM": "Bạn có chắc muốn xoá sinh viên này?",
-      "CALLBACK": { "CALL": "vueData.fetchStudents" }
-    }
-  }
-]
-```
-
-**5.2 `watch` to reload when filters change**
-
-```json
-"watch": {
-  "keyword": { "CALL": "vueData.fetchStudents" },
-  "classId":  { "CALL": "vueData.fetchStudents" }
-}
-```
-
-**5.3** Append `{ "CALL": "vueData.fetchStudents" }` at the end of `data[]` to auto-load on open.
-
-**Output:** `module.json` fully wired, layout unchanged from step 2.
-
----
-
-## Step 6 — Static verification and finish
-
-Pre-publish checklist — **no step calls a real API/SP/DML**:
-
-**API/SP** — full checklist (naming, params, security, `GRANT EXECUTE`, deploy workflow): [verification.md](verification.md). Here:
-
-- [ ] `AUTH_` on endpoints that need no login
-- [ ] `fui sp verify` per new SP — reads the real body, infers response shape/error contract, checks params, emits a `--mocks` snippet (no endpoint call)
-- [ ] **Write** APIs: read the body and reason (WHERE, transaction, RAISERROR) — no trial run
-
-**module.json:**
-
-- [ ] Each action's `API` path matches `/{apiName}/{FunctionName}`
-- [ ] `IN` params match SP param names exactly (case-sensitive)
-- [ ] Route params (url1, url2) go via the URL, not `IN`
-- [ ] `OUT` receives the right type (array vs object per SP) — check against the shape inferred by `fui sp verify`
-- [ ] `watch` declared for auto-reload filters
-- [ ] `data[]` declares the initial fetch action and ends with a startup `{ "CALL": ... }`
-
-**Final verification, in order:** `fui module validate` (syntax/rule errors) → `fui module outline` (text review of UI structure) → `fui module simulate --mocks '{...}'` using the `fui sp verify` snippet (action/watch/dialog flow) → if display is still in doubt, a last `fui module simulate --render` with the same `--mocks`. (`fui module check` runs validate + outline + simulate in one step.)
-
-**Output:** module works end-to-end, UI ↔ API connected, zero real calls during verification.
-
----
-
-## Complete output example
-
-### SPs (step 4)
-
-Each SP is **its own file** via `fui sp save` → `fui sp deploy`. No GRANT in the file, no `GO` (step 4); tAPI params **must not have default values** — `fui sp deploy` hard-blocks them.
-
-```sql
--- 1. Danh sách  (file spAPI_StudentList.sql)
-CREATE PROCEDURE spAPI_StudentList @Keyword nvarchar(200), @ClassID varchar(20), @sys_UserID varchar(9)
-AS BEGIN
-    SELECT s.StudentID, s.FullName, s.ClassID, s.GPA
-    FROM tblStudent s WHERE (@Keyword = '' OR s.FullName LIKE '%'+@Keyword+'%') AND (@ClassID = '' OR s.ClassID = @ClassID)
-END
-```
-
-```sql
--- 2. Thêm mới  (file spAPI_StudentInsert.sql)
-CREATE PROCEDURE spAPI_StudentInsert @StudentID varchar(9), @FullName nvarchar(100), @ClassID varchar(20), @sys_UserID varchar(9)
-AS BEGIN
-    INSERT INTO tblStudent(StudentID, FullName, ClassID, CreateUser, CreateTime) VALUES(@StudentID, @FullName, @ClassID, @sys_UserID, GETDATE())
-    SELECT mess = N'Thêm thành công'
-END
-```
-
-### module.json actions (step 5)
-
-```json
-"fetchStudents": { "API": "/me/StudentList", "IN": { "Keyword": "vueData.keyword" }, "OUT": "studentList" },
-"addStudent":    { "API": "/me/StudentInsert", "IN": { "StudentID": "vueData.form.StudentID", "FullName": "vueData.form.FullName", "ClassID": "vueData.form.ClassID" }, "CALLBACK": [ { "CALL": "vueData.fetchStudents" }, { "MESS": "Đã thêm" } ] }
-```
-
----
-
-## Key notes
-
-- **`{apiName}`** in the API path is the app's tAPI apiName (e.g. `me`, `lms`, `hr`). Ask the user if unknown. **A project may use several apiNames** (one database each) — each alias needs its own `fui db add`, and the alias in the path is the `--db` argument of DB commands ([db-workflow.md](db-workflow.md) §4).
-- **Route params** (`@url1_`) go via the URL, not `IN`, using the backtick prefix: `"API": "/me/StudentDelete/\`{{vueData.selectedID}}"`
-- **SP with multiple SELECTs** → `data[0]`, `data[1]`... — declare explicitly in `OUT` or split with `EXE`.
-- **`convert_to_object = ''`** → flat object response: read `vueData.studentDetail.FullName`, not `vueData.studentDetail[0].FullName`.
+# Full-Stack Module Workflow
+
+> Owns: **the 6-step UI-first fullstack module workflow (analyze → UI with hard-coded data → lock contract → SP → API wiring → static verification)** and **the Design Review Gate procedure** (SKILL.md §3 holds only the rule "must pass the gate"; the steps live here). tAPI conventions: [tapi-reference.md](tapi-reference.md); multi-module design: [system-design.md](system-design.md).
+
+**UI-first:** build UI (FUI) with hard-coded data, confirm visuals with `fui module simulate --render`, THEN lock the API (tAPI) contract and write SPs. Fixing data shape while it is a literal in `data[]` is far cheaper than after `IN`/`OUT`/`watch` depend on it. No step calls a real API/SP to "test" — verification = read + reason + mock ([verification.md](verification.md)). Read [tapi-reference.md](tapi-reference.md) before step 3.
+
+---
+
+## Step 1 — Analyze requirements
+
+**1.1 Business need:** list / search / filter? add / edit / delete? report / statistics? workflow (approve, reject, status)?
+
+**1.2 Data (initial estimate — locked in step 3):** main entity and linked entities; which fields are displayed, which are input.
+
+**1.3 Permissions and auth:**
+
+- Login required? (no → use `AUTH_` in the SP)
+- Rights by `sys_SystemRight`? → handle in the SP body
+
+**Output:** feature list + main entity names (types/column names not yet locked).
+
+---
+
+## Step 1b — Design Review Gate (mandatory, before the first line of code)
+
+SKILL.md §3 = the **rule** (every new system/page/function passes); this = the **procedure**, for fullstack and UI-only modules.
+
+1. **Business efficiency** — steps to finish the task, data truly needed, redundant steps.
+2. **Project patterns** — `fui module list` + `fui module get` on similar modules (layout, control naming, action placement, filter/table/dialog). Match existing pages; **never invent a new style when a convention exists**.
+3. **Sketch the UI** in words/rough layout — controls, placement, dialog/form flow.
+4. **Self-review** — friendly? step count? Add/Edit/Delete, filters, pagination where expected? consistent? Issues → **fix the sketch first**, never in code.
+5. Only then write code (step 2+).
+
+**Choose the build approach:**
+
+| Approach                           | When                                                                                                                                                         |
+| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **A — plain module.json**          | Simple page: data display, single-table CRUD, basic form. Fewer files, easy to maintain.                                                                     |
+| **B — Vue component (`uc-*.vue`)** | Complex UI: multi-area dashboard, custom layout, UI logic reused in many places, or `controls` over ~200 lines ([component-design.md](component-design.md)). |
+
+> Unspecified → **propose** one with a short reason and **wait for confirmation**; never choose silently.
+
+**Component priority**: `f-*` first (`f-button` over `v-btn`, `f-table` over `v-data-table` for EVERY table, `f-echart` for every chart); `v-*` only when no FUI equivalent exists. → [component-quickref.md](component-quickref.md)
+
+**Design System gate** (parallel): decide App-mode vs Web-mode and check `{projectId}/DESIGN.md` **before** sketching — separate aesthetic rules; never mix. → [design-modes.md](design-modes.md)
+
+**Output:** self-reviewed sketch, approach A/B locked (user-confirmed if we proposed it), aesthetic mode decided.
+
+---
+
+## Step 2 — Build UI with hard-coded data
+
+Whole UI on **literal** data in `data[]`, no API yet. Structure: [module-json-anatomy.md](module-json-anatomy.md), [controls-patterns.md](controls-patterns.md).
+
+```json
+"data": [
+  { "keyword": "" },
+  { "classId": "" },
+  { "studentList": [
+      { "StudentID": "SV001", "FullName": "Nguyễn Văn A", "ClassID": "C01", "ClassName": "Lớp 10A", "GPA": 8.5 },
+      { "StudentID": "SV002", "FullName": "Trần Thị B", "ClassID": "C02", "ClassName": "Lớp 10B", "GPA": 7.2 }
+  ] },
+  { "form": {} },
+  { "dialogOpen": false }
+]
+```
+
+`f-table`/`v-dialog`/form patterns: [component-table.md](component-table.md), [ui-templates.md](ui-templates.md).
+
+**Visual QA now:** `fui module simulate --render` (vueData override: `fui module simulate --help`). Read screenshot + DOM audit; fix display bugs (horizontal overflow, broken dialog, missing labels...) before moving on.
+
+**Output:** `module.json` with complete layout, running on hard-coded data, clean `--render` QA.
+
+---
+
+## Step 3 — Lock data shape + design API endpoints
+
+From the step-2 fields (visually confirmed before becoming an SP contract), lock exact field names + types (→ SQL column types) and the source entity/table of each. Map features to SPs as `spAPI_{Entity}{Action}`; full naming (`spAPI_*` / `spAPI_AUTH_*` / `spAPIFILE_*`, `@url1_`, response contract) is in [tapi-reference.md](tapi-reference.md).
+
+| Feature           | SP name                      | Main params            |
+| ----------------- | ---------------------------- | ---------------------- |
+| List              | `spAPI_{Entity}List`         | Filter params (custom) |
+| Detail            | `spAPI_{Entity}Get`          | `@url1_{EntityID}`     |
+| Insert            | `spAPI_{Entity}Insert`       | Entity fields          |
+| Update            | `spAPI_{Entity}Update`       | ID + fields to update  |
+| Delete            | `spAPI_{Entity}Delete`       | `@url1_{EntityID}`     |
+| Lookup / dropdown | `spAPI_AUTH_{Entity}Options` | No auth, returns list  |
+
+**Example — "Student management"** (matches step-2 fields `StudentID`, `FullName`, `ClassID`, `ClassName`, `GPA`):
+
+```
+spAPI_StudentList       -- danh sách, lọc theo ClassID + Keyword — trả đúng các cột đã hiển thị ở bước 2
+spAPI_StudentGet        -- chi tiết theo url1=StudentID
+spAPI_StudentInsert     -- thêm mới
+spAPI_StudentUpdate     -- cập nhật
+spAPI_StudentDelete     -- xoá theo url1=StudentID
+spAPI_AUTH_ClassOptions -- dropdown danh sách lớp (không cần auth)
+```
+
+**Output:** full SP list; names + params + response shape match the fields used in the UI.
+
+---
+
+## Step 4 — Write SQL stored procedures
+
+Per tAPI rules ([tapi-reference.md](tapi-reference.md)) and the step-3 contract.
+
+**SELECT (list):**
+
+```sql
+-- No "= NULL" defaults: tAPI passes NULL for a param the client leaves out, and fui sp deploy blocks defaults.
+CREATE PROCEDURE spAPI_StudentList
+    @Keyword    nvarchar(200),
+    @ClassID    varchar(20),
+    @sys_UserID varchar(9)
+AS BEGIN
+    SELECT s.StudentID, s.FullName, s.ClassID, c.ClassName, s.GPA
+    FROM tblStudent s
+    JOIN tblClass c ON s.ClassID = c.ClassID
+    WHERE (@Keyword IS NULL OR s.FullName LIKE '%' + @Keyword + '%')
+      AND (@ClassID IS NULL OR s.ClassID = @ClassID)
+    ORDER BY s.FullName
+END
+```
+
+**INSERT:**
+
+```sql
+CREATE PROCEDURE spAPI_StudentInsert
+    @StudentID  varchar(9),
+    @FullName   nvarchar(100),
+    @ClassID    varchar(20),
+    @sys_UserID varchar(9)
+AS BEGIN
+    IF EXISTS (SELECT 1 FROM tblStudent WHERE StudentID = @StudentID)
+    BEGIN
+        RAISERROR(N'Mã sinh viên đã tồn tại', 16, 1)
+        RETURN
+    END
+    INSERT INTO tblStudent (StudentID, FullName, ClassID, CreateUser, CreateTime)
+    VALUES (@StudentID, @FullName, @ClassID, @sys_UserID, GETDATE())
+    SELECT mess = N'Thêm thành công', id = @StudentID
+END
+```
+
+**DELETE:**
+
+```sql
+CREATE PROCEDURE spAPI_StudentDelete
+    @url1_StudentID varchar(9),
+    @sys_UserID     varchar(9)
+AS BEGIN
+    DELETE FROM tblStudent WHERE StudentID = @url1_StudentID
+    SELECT mess = N'Đã xoá', id = @url1_StudentID
+END
+```
+
+**GET (detail, convert_to_object):**
+
+```sql
+CREATE PROCEDURE spAPI_StudentGet
+    @url1_StudentID varchar(9),
+    @sys_UserID     varchar(9)
+AS BEGIN
+    SELECT convert_to_object = '',
+           s.StudentID, s.FullName, s.ClassID, c.ClassName, s.GPA, s.Email
+    FROM tblStudent s
+    JOIN tblClass c ON s.ClassID = c.ClassID
+    WHERE s.StudentID = @url1_StudentID
+END
+```
+
+> `convert_to_object = ''` when the SP returns exactly one record → response is an object instead of `data[0][0]`.
+
+Deploy with `fui sp save` + `fui sp deploy` (never call the endpoint to "try it" — see step 6).
+
+**NEVER put `GRANT EXECUTE` in the .sql file.** A `CREATE PROCEDURE` body runs **to end of batch**; `_sql_execute_NonQuery` sends one batch and **does not support `GO`** (client directive, not T-SQL). A `GRANT` after `END` is **swallowed into the SP body** — runs on every call, never grants at deploy. No error; the endpoint just returns a permission error while the SP looks right.
+
+`fui sp deploy` **auto-grants** new procedures (not FUNCTIONs — functions need no EXECUTE for `[public]`), then **re-checks `sys.database_permissions`** and reports:
+
+- `GRANT EXECUTE ON [dbo].[...] TO [public]: applied` (new SP) or `[public] has EXECUTE on "..."` — done.
+- `[public] lacks EXECUTE on "..."` or `deploy OK but grant FAILED` — the output prints a runnable command; copy verbatim:
+  `fui exec "GRANT EXECUTE ON [dbo].[spAPI_StudentList] TO [public] AS [dbo]" --db ...`
+- Grant failed but deploy succeeded → **the SP is already on the server**; run the GRANT above, **do not redeploy**.
+
+Deploying via `fui exec` with `CREATE PROCEDURE` → **no auto-grant, no tAPI param-cache clear**; fui warns and names the two commands to run next.
+
+**Output:** all step-3 SPs deployed.
+
+---
+
+## Step 5 — Replace hard-coded data with API bindings
+
+Keep the step-2 layout; replace `data[]` literals with named `IN`/`OUT`/`CALLBACK` actions on the deployed SPs.
+
+**5.1 Actions replacing hard-coded data**
+
+```json
+"data": [
+  { "keyword": "" },
+  { "classId": "" },
+  { "studentList": [] },
+
+  {
+    "fetchStudents": {
+      "API": "/{apiName}/StudentList",
+      "IN": { "Keyword": "vueData.keyword", "ClassID": "vueData.classId" },
+      "OUT": "studentList"
+    }
+  },
+  {
+    "saveStudent": {
+      "API": "/{apiName}/StudentInsert",
+      "IN": {
+        "StudentID": "vueData.form.StudentID",
+        "FullName":  "vueData.form.FullName",
+        "ClassID":   "vueData.form.ClassID"
+      },
+      "CALLBACK": [
+        { "CALL": "vueData.fetchStudents" },
+        { "MESS": "Thêm thành công" },
+        { "EXE":  "vueData.dialogOpen = false" }
+      ]
+    }
+  },
+  {
+    "deleteStudent": {
+      "API": "/{apiName}/StudentDelete/`{{vueData.selectedID}}",
+      "CONFIRM": "Bạn có chắc muốn xoá sinh viên này?",
+      "CALLBACK": { "CALL": "vueData.fetchStudents" }
+    }
+  }
+]
+```
+
+**5.2 `watch` to reload when filters change**
+
+```json
+"watch": {
+  "keyword": { "CALL": "vueData.fetchStudents" },
+  "classId":  { "CALL": "vueData.fetchStudents" }
+}
+```
+
+**5.3** Append `{ "CALL": "vueData.fetchStudents" }` at the end of `data[]` to auto-load on open.
+
+**Output:** `module.json` fully wired, layout unchanged from step 2.
+
+---
+
+## Step 6 — Static verification and finish
+
+Pre-publish checklist — **no step calls a real API/SP/DML**:
+
+**API/SP** — full checklist (naming, params, security, `GRANT EXECUTE`, deploy workflow): [verification.md](verification.md). Here:
+
+- [ ] `AUTH_` on endpoints that need no login
+- [ ] `fui sp verify` per new SP — reads the real body, infers response shape/error contract, checks params, emits a `--mocks` snippet (no endpoint call)
+- [ ] **Write** APIs: read the body and reason (WHERE, transaction, RAISERROR) — no trial run
+
+**module.json:**
+
+- [ ] Each action's `API` path matches `/{apiName}/{FunctionName}`
+- [ ] `IN` params match SP param names exactly (case-sensitive)
+- [ ] Route params (url1, url2) go via the URL, not `IN`
+- [ ] `OUT` receives the right type (array vs object per SP) — check against the shape inferred by `fui sp verify`
+- [ ] `watch` declared for auto-reload filters
+- [ ] `data[]` declares the initial fetch action and ends with a startup `{ "CALL": ... }`
+
+**Final verification, in order:** `fui module validate` (syntax/rule errors) → `fui module outline` (text review of UI structure) → `fui module simulate --mocks '{...}'` using the `fui sp verify` snippet (action/watch/dialog flow) → if display is still in doubt, a last `fui module simulate --render` with the same `--mocks`. (`fui module check` runs validate + outline + simulate in one step.)
+
+**Output:** module works end-to-end, UI ↔ API connected, zero real calls during verification.
+
+---
+
+## Complete output example
+
+### SPs (step 4)
+
+Each SP is **its own file** via `fui sp save` → `fui sp deploy`. No GRANT in the file, no `GO` (step 4); tAPI params **must not have default values** — `fui sp deploy` hard-blocks them.
+
+```sql
+-- 1. Danh sách  (file spAPI_StudentList.sql)
+CREATE PROCEDURE spAPI_StudentList @Keyword nvarchar(200), @ClassID varchar(20), @sys_UserID varchar(9)
+AS BEGIN
+    SELECT s.StudentID, s.FullName, s.ClassID, s.GPA
+    FROM tblStudent s WHERE (@Keyword = '' OR s.FullName LIKE '%'+@Keyword+'%') AND (@ClassID = '' OR s.ClassID = @ClassID)
+END
+```
+
+```sql
+-- 2. Thêm mới  (file spAPI_StudentInsert.sql)
+CREATE PROCEDURE spAPI_StudentInsert @StudentID varchar(9), @FullName nvarchar(100), @ClassID varchar(20), @sys_UserID varchar(9)
+AS BEGIN
+    INSERT INTO tblStudent(StudentID, FullName, ClassID, CreateUser, CreateTime) VALUES(@StudentID, @FullName, @ClassID, @sys_UserID, GETDATE())
+    SELECT mess = N'Thêm thành công'
+END
+```
+
+### module.json actions (step 5)
+
+```json
+"fetchStudents": { "API": "/me/StudentList", "IN": { "Keyword": "vueData.keyword" }, "OUT": "studentList" },
+"addStudent":    { "API": "/me/StudentInsert", "IN": { "StudentID": "vueData.form.StudentID", "FullName": "vueData.form.FullName", "ClassID": "vueData.form.ClassID" }, "CALLBACK": [ { "CALL": "vueData.fetchStudents" }, { "MESS": "Đã thêm" } ] }
+```
+
+---
+
+## Key notes
+
+- **`{apiName}`** in the API path is the app's tAPI apiName (e.g. `me`, `lms`, `hr`). Ask the user if unknown. **A project may use several apiNames** (one database each) — each alias needs its own `fui db add`, and the alias in the path is the `--db` argument of DB commands ([db-workflow.md](db-workflow.md) §4).
+- **Route params** (`@url1_`) go via the URL, not `IN`, using the backtick prefix: `"API": "/me/StudentDelete/\`{{vueData.selectedID}}"`
+- **SP with multiple SELECTs** → `data[0]`, `data[1]`... — declare explicitly in `OUT` or split with `EXE`.
+- **`convert_to_object = ''`** → flat object response: read `vueData.studentDetail.FullName`, not `vueData.studentDetail[0].FullName`.