biz-a-cli 2.3.80-15419 → 2.3.80

package/engine/cc/guides/V2-SCREEN-AUTHORING.md

@@ -1,531 +1,512 @@
-# Writing version 2 screens — authoring guide
-
-**Applies to:** Biz-A platform as of 2026-10-09 (Doc 2 steps 1–3, Doc 8 M2) · **Status:** reference, v1.17
-**Audience:** anyone writing Layer 3 domain config — implementors, and the AI in Doc 1, which reads this as context.
-**Source of truth:** Doc 2 (`Doc 2 Biza_ai_ready.md`) and its implementation plan (`DOC2-IMPLEMENTATION-PLAN-2026-09-25.md`).
-**Where it lives:** `cli/engine/cc/guides/V2-SCREEN-AUTHORING.md` — Control Center hands it to the AI that writes
-configuration (Phase B), and checks the rules below on every AI write. `docs/V2-SCREEN-AUTHORING.md` is an
-identical copy; a test keeps the two equal, so edit the one under `cli` and copy it.
-Every rule below is enforced by the platform or pinned by a test; where a rule is only a convention, it says so.
-
-A version 2 screen is **configuration only**: no load code, no save code, no deleted-row tracking, no handlers.
-The platform loads the record with its details, keeps the form and its data in step, and saves the whole
-graph in one transaction. If a v2 screen seems to need a handler, first check whether an effect below already
-does the job.
-
----
-
-## 1. The rules (read these first)
-
-1. **Every screen you write is `version: 2`.** Never produce new v1 config. `version` sits on the **entryPoint**
-   (per screen), not on `metadata` — `metadata.version` is the package's semver and means something else.
-2. **An entryPoint names its `entity`.** The entity's table is what the screen loads and saves.
-3. **Collections are keyed by the detail TABLE name** — a repeat by its `key`, a grid by its `props.detailKey` —
-   and only a declared `one-to-many` relationship makes a repeat or grid a collection. Anything else is UI-only and is neither loaded nor saved — with no error.
-4. **Every collection a v2 screen edits declares `orderBy`** on its relationship, and the order column is a
-   `number` attribute. The platform numbers rows from their screen position on save. Save **refuses** a screen
-   that edits an unordered collection.
-5. **Never show the order column on a v2 screen** — the platform owns it and overwrites whatever is typed.
-6. **Owned details declare `ownership: 'parent'`.** Delete cascades through exactly these; `shared` and
-   `independent` relationships are never followed.
-7. **Bindings declare `effects`, not a `handler`.** A binding may have one or the other, never both.
-8. **A collection you save must be complete.** Deletion is inferred from absence: a row missing from the save
-   is deleted. Never paginate, filter or lazy-load an edited collection — or, if a component must, mark it
-   incomplete (§6.4) so the save is refused instead.
-9. **Give list columns a `title`** when the attribute has no `label`, or the header shows the raw column name.
-10. **Keep config comments free of apostrophes and quote marks** — the admin App Config parser counts them.
-11. **A form tells the user what happened, and goes back to where it was opened.** Its `SAVE` carries
-    `onSuccess` (a success `NOTIF`, then `NAVIGATE` with `back: true`) and `onInvalid` (a `NOTIF` saying what to
-    complete) — without `onInvalid` an incomplete form does nothing at all. A `DELETE` goes back the same way.
-    Give `back` a `route` (the entity's list) for a form opened directly, from a bookmark or a refresh.
-12. **Every required attribute can be filled.** It is a field the user edits, or the item carries a
-    `defaultValue`, or the attribute has one. A field the form only **shows** — a `label` item, or a `statusBadge`
-    or `readonly` attribute — gets the item's `defaultValue` when it is required (a workflow state: its initial
-    state), or the form is never valid.
-13. **The CRUD baseline — every entity a user maintains gets all of it.**
-    - **Form:** its fields, **Simpan** (rule 11) and **Batal** — a button bound to `NAVIGATE` with `back: true`
-      (the entity's list as `route`), which leaves without saving.
-    - **List:** **Tambah** (§7) and, on every row, **Ubah** and **Hapus** — one row button column
-      `{ type: 'button', buttons: [{ icon: 'edit', caption: 'Ubah' }, { icon: 'delete', caption: 'Hapus' }] }`,
-      bound by icon: `edit` → `NAVIGATE ['form', <form>, { $ref: 'event.id' }]`, `delete` →
-      `DELETE { id: { $ref: 'event.id' }, confirm: '<question>' }`. The platform shows a row's actions when the row
-      is hovered (always, on a touch screen), so no row needs a click to open. A **review list** — one with a fixed
-      `filter`, like the records waiting for an approval (§3.3) — only opens its records: **Lihat** for a document
-      with a workflow, Ubah otherwise; no Tambah or Hapus — those belong to the entity's main list.
-    - **A lookup's master data:** a required lookup picks from an entity some screen maintains — that entity's own
-      list with Tambah, its form and a menu item, in this domain or another. Without one nothing can be picked and
-      the record can never be saved.
-    - **A document with a workflow** is moved through its states in **view mode**: **Lihat** opens its form
-      read-only, with a button per transition the user may take — clicking one moves the record to that
-      transition's next state — and **Tutup**; Simpan and Batal show only while editing (§3.3).
-
----
-
-## 2. A complete example
-
-The Add-Info template screens in Supertail (`supertail/src/config/setupConfig.js`) are the reference: a list,
-and a master → detail → subdetail form, with no handler code at all. (Supertail's own screens also name Supertail's
-own styles — `styleRef: 'screenShell'`, `'inlineRow'` …; they are left out here. A domain names only the styles its
-own `ui.styles` declares.)
-
-### 2.1 Model — what the screens depend on
-
-```js
-entities: {
-  st_item_add_info_template:     { table: 'st_item_add_info_template', attributes: { template_code: {...}, template_name: {...}, active: {...} } },
-  st_item_add_info_template_det: { table: 'st_item_add_info_template_det', attributes: { field_label: {...}, sequence_no: { type: 'number', ... }, ... } },
-  st_item_add_info_options:      { table: 'st_item_add_info_options', attributes: { value: {...}, label: {...}, sequence_no: { type: 'number', uiIntent: 'number' } } },
-},
-relationships: {
-  rel_item_add_info_template_det: {
-    type: 'one-to-many', from: 'st_item_add_info_template', to: 'st_item_add_info_template_det',
-    foreignKey: 'st_item_add_info_template_id', ownership: 'parent',
-    orderBy: 'sequence_no',                       // rule 4
-  },
-  rel_item_add_info_options: {
-    type: 'one-to-many', from: 'st_item_add_info_template_det', to: 'st_item_add_info_options',
-    foreignKey: 'st_add_info_tmpl_det_id',        // declared: the <parent>_id convention is too long for Firebird
-    ownership: 'parent', orderBy: 'sequence_no',
-  },
-},
-```
-
-### 2.2 The form
-
-```js
-entryPoints: {
-  stItemAddInfoTemplateV2: {
-    entity: 'st_item_add_info_template',
-    structureRef: 'stItemAddInfoTemplateV2Structure',
-    version: 2,
-    eventBindings: [
-      { emitter: 'Simpan Add-Info Template V2', trigger: 'onClick',                  // the button label, exactly
-        effects: [{ type: 'SAVE',
-                    onSuccess: [{ type: 'NOTIF', level: 'success', message: 'Add-Info Template tersimpan.' },
-                                { type: 'NAVIGATE', back: true, route: ['list', 'supertail-stItemAddInfoTemplateListV2'] }],
-                    onInvalid: [{ type: 'NOTIF', level: 'warning', message: 'Lengkapi isian yang wajib.' }] }] },   // rule 11
-      { emitter: 'Hapus Add-Info Template V2', trigger: 'onClick',
-        effects: [{ type: 'DELETE', confirm: 'Hapus template ini beserta semua field dan opsinya?',
-                    confirmText: 'Hapus', cancelText: 'Batal',
-                    onSuccess: [{ type: 'NOTIF', level: 'success', message: 'Add-Info Template dihapus.' },
-                                { type: 'NAVIGATE', back: true, route: ['list', 'supertail-stItemAddInfoTemplateListV2'] }] }] },
-      { emitter: 'Batal', trigger: 'onClick',                                         // rule 13: leave without saving
-        effects: [{ type: 'NAVIGATE', back: true, route: ['list', 'supertail-stItemAddInfoTemplateListV2'] }] },
-    ],
-  },
-},
-structures: {
-  stItemAddInfoTemplateV2Structure: {
-    type: 'form',
-    items: [
-      { className: 'row g-2', items: [                        // a row of fields (§3.4): no key, no type
-        { className: 'col-12 col-md', items: [{ key: 'template_code', type: 'input', props: { label: 'Kode', required: true } }] },
-        { className: 'col-12 col-md', items: [{ key: 'template_name', type: 'input', props: { label: 'Nama', required: true } }] },
-        { className: 'col-12 col-md-auto', items: [{ key: 'active', type: 'bool', defaultValue: 1, props: { label: 'Aktif', showAsCheckBox: true } }] },
-      ] },
-      { type: 'repeat', key: 'st_item_add_info_template_det',  // the DETAIL TABLE (rule 3)
-        props: { label: 'Field', addBtn: { text: 'Tambah Field', icon: 'add' }, deleteBtn: { text: 'Hapus Field', icon: 'delete' } },
-        items: [
-          { key: 'field_label', ... },
-          { type: 'repeat', key: 'st_item_add_info_options', props: {...}, items: [ { key: 'value', ... }, ... ] },
-        ] },
-      { type: 'button', icon: 'save',   label: 'Simpan Add-Info Template V2' },
-      { type: 'button', icon: 'delete', label: 'Hapus Add-Info Template V2' },
-      { type: 'button', icon: 'close',  label: 'Batal' },
-    ],
-  },
-},
-```
-
-### 2.3 The list
-
-```js
-entryPoints: {
-  stItemAddInfoTemplateListV2: {
-    entity: 'st_item_add_info_template',
-    structureRef: 'stItemAddInfoTemplateListV2Structure',
-    version: 2,
-    eventBindings: [
-      { emitter: 'add', trigger: 'onClick',
-        effects: [{ type: 'NAVIGATE', route: ['form', 'supertail-stItemAddInfoTemplateV2', 'null'] }] },
-      { emitter: 'edit', trigger: 'onClick',                                          // rule 13: row actions
-        effects: [{ type: 'NAVIGATE', route: ['form', 'supertail-stItemAddInfoTemplateV2', { $ref: 'event.id' }] }] },
-      { emitter: 'delete', trigger: 'onClick',
-        effects: [{ type: 'DELETE', id: { $ref: 'event.id' }, confirm: 'Hapus template ini beserta semua field dan opsinya?' }] },
-    ],
-  },
-},
-structures: {
-  stItemAddInfoTemplateListV2Structure: {
-    type: 'list', caption: 'Add-Info Template',
-    items: [ { key: 'template_code', title: 'Kode' }, { key: 'template_name', title: 'Nama' }, { key: 'active', title: 'Aktif' },
-             { type: 'button', buttons: [{ icon: 'edit', caption: 'Ubah' }, { icon: 'delete', caption: 'Hapus' }] } ],
-    buttons: [{ icon: 'add', caption: 'Tambah' }],
-  },
-},
-```
-
-Routes are `form/<app>-<entryPoint>/<id>` and `list/<app>-<entryPoint>`; `null` as the id opens a new record.
-Publishing generates each screen's template — nothing else needs to exist.
-
----
-
-## 3. Form screens
-
-### 3.1 Items
-
-| Item | Shape | Notes |
-|---|---|---|
-| Field | `{ key, type?, props?, defaultValue?, styleRef? }` | `key` is an attribute of the entity that owns this level. Without `type`, the attribute's `uiIntent` decides the control. Explicit `props` win over the attribute. `defaultValue` fills a new record (rule 12). A column class goes on a group around the field, never on the field (§3.4). |
-| Layout row / group | `{ className, items }` or `{ styleRef, items }` — **no `key`, no `type`** | Groups fields of the **same** entity. `className` takes Bootstrap's grid classes — rows and columns (§3.4). A `styleRef` names a style of this domain's own `ui.styles`; nothing else resolves. |
-| Repeat (a collection) | `{ type: 'repeat', key: <detail table>, props, items }` | Its fields resolve against the **detail** entity (labels, validation). Nests for subdetail. Buttons: `props.addBtn` / `props.deleteBtn` as `{ text, icon }` — `addText` alone renders an unlabeled button. |
-| Grid (a one-level collection) | `{ type: 'detail-grid', key: 'grid_<detail table>', props: { detailKey: <detail table>, columns, addBtn, deleteBtn } }` | The grid's own `key` names the grid — no attribute, never the detail table: the form holds a plain field under that key, and with the table's name the grid could add no row. Columns are `{ key, label, type?, default? }`. `default` initialises rows the user adds, never loaded rows. A hidden `id` column is added automatically. A grid hides its add and delete unless declared: a grid the user edits carries `addBtn: { show: true, label: 'Tambah <row>' }` and `deleteBtn: { show: true, icon: 'delete', key: '__hapus_<detail table>', label: ' ' }` (the delete column's own key, no attribute). Optional (Doc 8 M5a): `iconOnly: true` on either shows the icon alone, its word becoming the tooltip and spoken name (`label` for add, `text` for delete); `deleteBtn.confirm: true` or a question asks before a row goes; `addBtn.requireKeys: ['<column>']` keeps the add button disabled, saying why (`blockedText`), while a row has no value in those columns. An empty money / number cell shows blank, 0 still shows 0. Money and number cells are shown and typed in the company number format (Number format setting: ID 1.500,50 / US 1,500.50) and keep a number; a column's `arg1` names its own locale. |
-| Button | `{ type: 'button', icon, label, styleRef }` | Its `label`, exactly, is the emitter a binding names. |
-| Template (static HTML) | `{ type: 'template', template }` | Rendered through Angular's HTML sanitiser (scripts and event handlers are removed). Inline `style="…"` works: the platform turns each into a generated class. A style containing `{ } < >` is dropped. |
-
-**A lookup** — a field that picks a record of another entity — is an attribute holding that record's key
-(`uiIntent: 'lookup'`) and a relationship
-`{ type: 'many-to-one', from: '<this entity>', to: '<the entity it picks from>', foreignKey: '<the field>', ownership: 'shared' }`.
-The platform lists the records of the relationship's `to`; declared one-to-many from the other side, it would list
-the wrong table. Each record is shown — and searched — by the attribute that names it, which that entity declares:
-`display: '<the attribute that names one record>'` (a name or a number — `display: 'nama_lead'` on Account), beside
-its `table` and `identity`; without it the lookup shows the first attribute, whatever that is. Deleting a record a
-lookup still points to is refused (`IN_USE`).
-It lists every record of that entity unless its attribute narrows it:
-`lookupOptions: { filter: [{ junction: '', column: '<an attribute of the entity it picks from>', operator: '=', value1: "'<value>'" }] }`
-(e.g. only offers whose state is the accepted one; operators `=`, `<>`, `<`, `>`, `<=`, `>=`, `in`, `not in`,
-`is null`, `is not null`; the user's search is added to it). A lookup attribute declared `unique` (one record per
-pick — one offer makes one contract) hides the records another record already picked, keeping this record's own
-pick; nothing else to declare, and the database refuses a duplicate anyway (`DUPLICATE`).
-
-Any item may carry `expressions: { hide: '<expression>' }`, evaluated against `model` and `formState` while the
-form is open. `formState.readonly` is `true` in view mode (§3.2), so an item can show only while editing
-(`hide: 'formState.readonly'`) or only while viewing (`hide: '!formState.readonly'`).
-
-⚠️ A repeat or grid whose key is **not** a declared detail table is UI-only: the platform treats it as screen
-state, loads nothing into it and saves nothing from it — silently.
-
-### 3.2 What the platform does for you
-
-- **Load.** Opening `form/<app>-<entryPoint>/<id>` reads the master and every collection on the screen in one
-  request, each collection in its declared order (`orderBy`, then `id`). A new record (`null`) reads nothing.
-- **Form ↔ data.** Typing updates the form data immediately, grid rows included; an effect that changes the data
-  (FORM_PATCH) shows on screen immediately. Nothing to wire.
-- **Save** (the `SAVE` effect). Sends the record and its collections; the server works out what was added,
-  changed and removed and writes only that, in one transaction (§6). A new record gets its key back, the form
-  reloads it, and the address changes from `/null` to that key.
-- **Row order.** Rows are numbered 1..n from their screen position into the `orderBy` column on every save.
-  Unchanged positions write nothing.
-- **View mode.** A form opened with `queryParams: { mode: 'view' }` (the address ends `?mode=view`) shows its record
-  read-only: no field can be changed — select, date, repeat and grid included — collections show no add or delete,
-  and `SAVE` / `DELETE` change nothing. It is the same form, not a second screen; `formState.readonly` is `true`.
-  A form in a dialog is never in view mode.
-
-### 3.3 A document with a workflow
-
-A document whose life is a workflow — a BPM workflow whose `entityType` is the entity — is moved through its states
-in **view mode** (§3.2): **Lihat** opens the record read-only on its own form, with a button for each transition the
-user may take, and **Tutup**. One form serves both editing and viewing — never a second "view" or "approval" form.
-
-- **The entity declares it:** `workflow: { key: '<workflowKey>', stateAttribute: '<attribute>' }`. The platform
-  starts the workflow when the form creates a record (at its initial state) and writes every state change onto the
-  state attribute, so lists and forms show the state like any other field, and a save never overwrites it.
-- **The state attribute** is a `string`, `uiIntent: 'statusBadge'`, `required`. The form shows it as
-  `{ key: '<attribute>', type: 'label', defaultValue: '<initialStateCode>' }` (rule 12); the list shows it as a column.
-- **The form** carries, besides its fields:
-  - **Simpan** and **Batal**, shown only while editing — `expressions: { hide: 'formState.readonly' }` (a Hapus
-    button on the form, if any, too);
-  - **Tutup**, shown only in view mode — `expressions: { hide: '!formState.readonly' }` — bound to `NAVIGATE` with
-    `back: true`, the entity's list as `route`;
-  - **the transition buttons:** the item `{ type: 'workflow-actions', key: 'aksi_workflow' }` — its key is no
-    attribute. The platform fills it from the screen and shows it in view mode only (a transition leaves the
-    form, which would throw away unsaved edits). Each button is a transition the signed-in user may take: their
-    roles are the role codes mapped to their user groups (an administrator holds every role). Pressing one moves
-    the record to that transition's next state, and the form goes back to where it was opened (the list, shown
-    fresh with the new state); opened directly, it reloads the record instead.
-- **Lihat** is a row action `{ icon: 'visibility', caption: 'Lihat' }`, bound `visibility` / `onClick` to
-  `NAVIGATE ['form', <form>, { $ref: 'event.id' }]` with `queryParams: { mode: 'view' }`. Where it lives is the
-  customer's choice, recorded on the process map as the lifecycle's `transitionUi`:
-  - `view` — the default: on the rows of the entity's main list, before Ubah and Hapus;
-  - `menus` — a review list for each stage that waits for someone (a map SCREEN with that `stage`), each reached
-    from its own menu item: a list over the same entity with a fixed `filter` on the state attribute,
-    `filter: [{ junction: '', column: '<table>.<state column>', operator: '=', value1: "'<STATE>'" }]`, whose only
-    row action is Lihat — no Tambah, Ubah or Hapus. The main list keeps Ubah and Hapus.
-- A menu never opens a listed entity's form as a new record.
-
-```js
-// the form (bindings: Simpan → SAVE, rule 11; Batal and Tutup → [{ type: 'NAVIGATE', back: true, route: ['list', '<list>'] }])
-items: [
-  { key: 'judul' },
-  { key: 'status_code', type: 'label', defaultValue: 'BARU' },
-  { type: 'workflow-actions', key: 'aksi_workflow' },
-  { type: 'button', icon: 'save',  label: 'Simpan', expressions: { hide: 'formState.readonly' } },
-  { type: 'button', icon: 'close', label: 'Batal',  expressions: { hide: 'formState.readonly' } },
-  { type: 'button', icon: 'close', label: 'Tutup',  expressions: { hide: '!formState.readonly' } },
-],
-
-// the main list (transitionUi view): the row button column and the Lihat binding
-{ type: 'button', buttons: [{ icon: 'visibility', caption: 'Lihat' }, { icon: 'edit', caption: 'Ubah' }, { icon: 'delete', caption: 'Hapus' }] },
-{ emitter: 'visibility', trigger: 'onClick',
-  effects: [{ type: 'NAVIGATE', route: ['form', '<form>', { $ref: 'event.id' }], queryParams: { mode: 'view' } }] },
-```
-
-### 3.4 Rows of fields
-
-A form is one field per line unless it says otherwise — fine on a phone, wasteful on a desktop. Biz-A has
-Bootstrap 5's grid: put short fields side by side in rows.
-
-- **A row** is a group `{ className: 'row g-2', items: [ <column>, … ] }`; **a column** is a group around ONE field,
-  `{ className: 'col-12 col-md', items: [{ key: '<attribute>' }] }`. The columns of a row share its width equally on a
-  screen at least 768 px wide, and stack one per line below it. `col-12 col-md-4`, `col-md-6` or `col-md-8` size a
-  column instead; `col-12 col-md-auto` fits it to its content (a checkbox).
-- ⚠️ The column class goes on the group, never on the field item: several field types (date, money, lookup, label,
-  button) also put the field's own class on an inner element, where a width class shrinks the field.
-- **Which fields:** 2–3 short ones per row — codes, names, dates, numbers, money, choices, lookups — related ones
-  together (number and date; customer and contact). Long text, a repeat, a grid, the workflow buttons and the form's
-  buttons stay full width, outside rows.
-- **By the screen's usage** — the device of the map's usage context for its actors or the screen: desktop, tablet or
-  kiosk → rows; mobile only → no rows, one field per line; not known → rows (they stack on a phone anyway).
-
-```js
-items: [
-  { className: 'row g-2', items: [
-    { className: 'col-12 col-md', items: [{ key: 'nomor' }] },
-    { className: 'col-12 col-md', items: [{ key: 'tanggal' }] },
-    { className: 'col-12 col-md', items: [{ key: 'customer_id' }] },
-  ] },
-  { key: 'catatan' },                                      // long text: full width
-  { type: 'repeat', key: 'penawaran_line', props: { ... }, items: [ ... ] },
-]
-```
-
-### 3.5 Values the system fills
-
-Three properties hand a value to the platform instead of the user — declared on the model, never computed by the form.
-
-- **A number the system gives** — `numbering` on a `string` attribute:
-
-  ```js
-  nomor_kontrak: { type: 'string', size: 30, required: true, unique: true, label: 'Nomor Kontrak',
-                   numbering: { format: 'KK/{YYYY}/{MM}/{seq:4}', reset: 'year' } },
-  ```
-
-  The database gives the number when the record is created (KK/2026/10/0001) and never changes it; whatever a form
-  sends is ignored. The format is text with `{YYYY}` `{YY}` `{MM}` `{RM}` (the month in Roman numerals) `{DD}` and
-  exactly one `{seq:N}` (the counter, padded to N digits); the rest only letters, digits, space and `/ . _ -`.
-  `reset` — `year`, `month`, `day` or `never` — says when the counter starts again at 1, and the number must show
-  that period (`{YYYY}` or `{YY}` for `year`). The attribute is `unique`, has no `defaultValue`, and its `size` fits
-  the longest number. The form shows it read-only and never asks for it; a new record shows it empty until saved,
-  so give the item a `props.placeholder` in the user's language ("Dibuat otomatis saat disimpan"). When the customer
-  has no format of their own: `<the document's initials>/{YYYY}/{MM}/{seq:4}`, restarting every year.
-  PostgreSQL databases only — the publish refuses it elsewhere.
-- **A value taken from the record a lookup picks** — `follows` on an attribute:
-
-  ```js
-  customer_id: { type: 'number', uiIntent: 'lookup', required: true,
-                 follows: { via: 'surat_penawaran_id', attribute: 'customer_id' } },
-  ```
-
-  `via` is a lookup attribute of the same entity (with its many-to-one relationship, §3.1); `attribute` is an
-  attribute of the entity it picks from, of the same type. When the user picks, the form copies the value at once and
-  shows it read-only; the database copies it again when the record is saved — on create, and whenever another record
-  is picked — so nothing else can set it. A later change to the picked record does not reach records already saved.
-  Required only when `via` is required.
-- **Lines that start from the picked record's lines** — `startsFrom` on the owned one-to-many relationship:
-
-  ```js
-  kontrakItems: { type: 'one-to-many', from: 'KontrakKerja', to: 'KontrakItem', foreignKey: 'kontrak_kerja_id',
-                  ownership: 'parent', orderBy: 'urutan',
-                  startsFrom: { via: 'surat_penawaran_id', from: 'PenawaranItem' } },
-  ```
-
-  When the user picks, the lines of the picked record (`from`: a line entity the picked entity owns) are copied into
-  the form's collection — only while it is empty, so lines the user already has are never overwritten — and are then
-  edited freely; the save inserts them as this record's own. Attributes with the same name copy; `fields: { <this
-  line's attribute>: <the picked line's attribute> }` adds the ones named differently. Keys, the parent key and the
-  row order never copy. Keep the collection (repeat or grid) on the same screen as the lookup.
-
----
-
-## 4. Bindings and expressions
-
-```js
-{ emitter: '<button label | list | icon or caption of a list button>', trigger: 'onClick' | 'onRowClick' | ...,
-  effects: [ ... ] }
-```
-
-- An effects binding runs its effects in order. A binding with `effects` must not also name a `handler`.
-- Any value inside an effect may be an expression, resolved when the event fires:
-  - `{ $ref: 'event.id' }` — a path read from `event`, `form` or `ctx` (e.g. `form.model.template_code`);
-  - `{ $ref: '…', $default: x }` — `x` when the path does not exist;
-  - `{ $const: x }` — `x` literally, never resolved.
-- List emitters: `'list'` with trigger `onRowClick` (the whole row); a top or inline list button is matched by its
-  **icon**, or by its caption when it has no icon. `event.id` is the row's key in both cases; a row click also
-  carries `event.row`, the whole row.
-
----
-
-## 5. Effects
-
-| Effect | Parameters | Behaviour |
-|---|---|---|
-| `SAVE` | `onSuccess?`, `onError?`, `onInvalid?` (effect lists) | v2 forms only. Invalid form → fields are marked, `onInvalid` runs, nothing is sent. Success → the record is reloaded, then `onSuccess`. Failure → `onError`, or the server's message is shown. |
-| `DELETE` | `id?`, `confirm?` (`false` or question text), `confirmText?`, `cancelText?`, `onSuccess?`, `onError?` | On a v2 form: the open record (saved records only). From a list row: the record `id` names (`{ $ref: 'event.id' }`), of the list's entity; the list reloads afterwards. Asks through the platform confirm dialog unless `confirm: false`. Anything but an explicit yes deletes nothing and runs neither list. Cascades by config (§6.3). |
-| `NAVIGATE` | `route` (array), `back?`, `queryParams?`, `reload?` (default `true`) | Opens a screen. `['form', '<app>-<entryPoint>', <id or 'null'>]`, `['list', '<app>-<entryPoint>']`. `back: true` returns to the screen this one was opened from, shown fresh; `route` is then only the fallback for a screen opened directly, and with neither nothing happens. A route is always an array. `queryParams: { mode: 'view' }` opens a form in view mode (§3.2). `queryParams: { copyFrom: <id> }` with the id `'null'` opens a NEW form filled from that record (Salin, §7). `replaceUrl: true` (Doc 8 M5a) turns the current screen into the target IN PLACE, so going back skips it (Ubah on a record opened to view). |
-| `NOTIF` | `message`, `level?` (`success` \| `error` \| other), `sticky?`, `duration?` | A snackbar. `success` lasts 3 s. |
-| `FORM_PATCH` | `patch` (object of field values) | Writes values into the form data; shows immediately. On a list it writes the list's `model`, which `enabled` reads (§7). |
-| `FORM_ERROR` | `field`, `message` | Shows an error naming the field. |
-| `OPEN_DIALOG` | `entryPointName`, `model?`, `afterClosedHandler?` | Opens another entryPoint in a dialog. |
-
----
-
-## 6. Saving and deleting — the contract
-
-### 6.1 How a save is understood
-
-The server compares what is sent with what is stored:
-
-| Sent | Stored | Result |
-|---|---|---|
-| row with a key | same values | nothing written |
-| row with a key | different values | UPDATE of the changed columns only |
-| row without a key | — | INSERT (the key is generated) |
-| — (row missing from a sent collection) | row | **DELETE** (soft or hard, per entity) |
-| collection **not sent at all** | rows | left alone |
-
-A field changed and then changed back writes nothing; untouched rows keep their keys; subdetail rows survive a
-save of their parent row.
-
-### 6.2 Concurrency
-
-A loaded record carries a row version. If someone else changed it meanwhile, save and delete are refused with
-`409 CONCURRENCY_CONFLICT` and write nothing — reload and retry.
-
-### 6.3 Delete
-
-`DELETE` removes the record and, at any depth, every row reached through an `ownership: 'parent'`
-relationship, through each declared foreign key — deepest first, each table by its own `deleteStrategy`
-(`soft` keeps the row and stamps it; anything else deletes it), in one transaction. A record that another row
-still **references** through a `shared` relationship (e.g. a category using a template) is refused with
-`409 IN_USE` naming the referencing table; nothing is deleted.
-
-### 6.4 Completeness — the `_incomplete` mark
-
-Because a missing row means "delete it", a partially loaded collection must never be saved as if complete.
-Whoever loads a collection partially marks its parent row:
-
-```js
-{ st_order: { id: 7, _incomplete: ['st_order_line'], st_order_line: [ /* one page */ ] } }
-```
-
-A save carrying a marked collection is refused with `400 INCOMPLETE_COLLECTION` naming it, before anything is
-read or written. A marked collection that is not sent is fine. No v2 read or component marks anything today —
-whoever first adds paging or filtering to an edited collection must set the mark.
-
-### 6.5 Server errors a screen can meet
-
-| Code | Status | Meaning |
-|---|---|---|
-| `CONCURRENCY_CONFLICT` | 409 | changed by someone else since loaded |
-| `IN_USE` | 409 | cannot delete — still referenced by the named table |
-| `DUPLICATE` | 409 | a value (or combination) a unique key already holds — named by the field's label |
-| `REQUIRED` | 400 | a required value is missing — named by the field's label |
-| `REFERENCE_NOT_FOUND` | 409 | a lookup points at a record that no longer exists — named by the field's label |
-| `INCOMPLETE_COLLECTION` | 400 | a collection marked incomplete was sent |
-| `GRAPH_READ_KEY_REQUIRED` | 400 | a graph read without a key |
-| `SHARED_RELATIONSHIP` | 400 | a collection whose relationship is not owned by its parent was sent |
-| `UNSAFE_SQL` | 400 | a name or value the ORM will not put into SQL |
-| `CROSS_TENANT_WRITE` / `AMBIGUOUS_TENANT` | 403 / 400 | a write outside the caller's tenant / with no tenant |
-
-Without an `onError`, the message is shown to the user as the server wrote it — never with SQL in it.
-
----
-
-## 7. List screens
-
-- A structure with `type: 'list'` over the entryPoint's `entity`. Items are columns `{ key, title? }`; top
-  `buttons` are `{ icon, caption }`. Optional `filter` (fixed conditions), `distinct`, `caption`.
-- Paging, per-column filter buttons, soft-deleted rows and tenant scope are handled by the platform.
-- A `list` / `onRowClick` binding makes rows clickable (pointer cursor). The row's key is fetched as a hidden
-  column only when such a binding exists; clicking a row button never also fires the row click.
-- A list of an entity that has a form opens it both ways, as in §2.3 (rule 13): the `{ icon: 'add', caption: 'Tambah' }`
-  button bound `add` / `onClick` to the form with `'null'`, and a row button column whose `edit` opens the form
-  with `event.id` and whose `delete` deletes the row's record. Row buttons show when the row is hovered or holds
-  the keyboard focus, and always on a touch screen. A row click (`list` / `onRowClick`) is optional. The rows of a
-  document with a workflow also carry Lihat, where the customer chose so (§3.3).
-- **Search:** `search: true` puts a search box above the list; it finds the rows whose text columns contain what
-  is typed. `search: { columns: ['<key>', …], placeholder: '…' }` names the columns it searches.
-- **Print:** `print: true` (or `print: { title: '…' }`) adds a print button: the rows of the current search, filter
-  and order, as one printable table.
-- **Salin** (copy as new): a row button `{ icon: 'content_copy', caption: 'Salin' }` bound
-  `{ emitter: 'content_copy', trigger: 'onClick', effects: [{ type: 'NAVIGATE', route: ['form', '<form>', 'null'],
-  queryParams: { copyFrom: { $ref: 'event.id' } } }] }`. The form opens as a NEW record holding everything the
-  row's record holds — its lines too, its date, its unique code — except its key, its number (given again on save)
-  and its workflow state. Nothing is saved until the user saves; a unique code left unchanged is refused then.
-- **Enabled per row:** any list button may carry `enabled`, an expression over `row` (the row's values by
-  attribute key) and `model` (the list's own data, written by `FORM_PATCH`), e.g.
-  `{ icon: 'edit', caption: 'Ubah', enabled: "model.canEdit && row.status !== 'POSTED'" }`. A button whose
-  expression is false — or does not evaluate — is shown disabled. The server still refuses what the user may not
-  do; `enabled` only spares the click.
-- A **selection** of rows with mass actions exists too, but a mass action runs an application handler, which a
-  Layer 3 config never names — it is not for Control Center (`docs/LIST-ENGINE.md`).
-
----
-
-## 8. Checking your config
-
-Pin the silent failures in the application's own tests, as Supertail does in
-`supertail/src/supertaillib/test/v2_add_info_template.test.js`. Control Center checks the screen rules on every
-AI write (`cli/engine/cc/configValidate.js`), so what the AI commits is what publish and the client accept:
-
-- every repeat / grid key is a declared detail table, at every level;
-- every field is a declared attribute of the entity that owns its level;
-- no binding names a handler; every Save/Delete button's label matches its binding's emitter;
-- every collection a v2 screen edits declares `orderBy` on a `number` attribute, and no v2 screen shows it;
-- NOT NULL columns a new row does not show have a `defaultValue` (repeat) or `default` (grid column);
-- a grid a saving form edits shows its add and delete (`addBtn` / `deleteBtn` with `show: true`), and its own `key` is not its detail table;
-- every required attribute can be filled; a required field a saving form only shows carries a `defaultValue` (rule 12);
-- every `SAVE` has `onInvalid`, and goes back (`NAVIGATE back`) on success (rule 11);
-- a form that saves has a cancel button bound to `NAVIGATE back` (rule 13);
-- a list of an entity with a form has the add button and its binding, and row actions `edit` and `delete`, each
-  bound (rule 13) — a review list (a fixed `filter`) only the action that opens its records: Lihat for a document
-  with a workflow, `edit` otherwise;
-- every `NAVIGATE` route is an array naming an entry point of the domain;
-- a Salin row action opens a new form with `copyFrom` (§7), and every list button's `enabled` is an expression that
-  evaluates;
-- every required lookup picks from an entity a list with Tambah maintains (rule 13);
-- every lookup attribute has its many-to-one relationship, from its entity to the one it picks from (§3.1);
-- every lookup filter names attributes of the entity it picks from, with a known operator (§3.1);
-- every entity a lookup picks from declares `display`, the attribute that names its records (§3.1);
-- every `styleRef` names a style of the domain's own `ui.styles` (§3.4);
-- an entity with a workflow declares it (`workflow: { key, stateAttribute }`); every form that saves it has a
-  `workflow-actions` item whose key is no attribute, a button shown in view mode that goes back (Tutup), and no
-  button shown in view mode that saves or deletes; and some list of it opens its records with Lihat (§3.3);
-- no menu opens a listed entity's form as a new record (§3.3).
-- every numbered attribute is a unique string with a valid format and no default; every `follows` and `startsFrom`
-  names a lookup of its entity and what the picked entity has (§3.5).
-
----
-
-## 9. Version history
-
-| Version | Date | Change |
-|---|---|---|
-| 1.0 | 2026-09-26 | First edition: forms (repeat, grid, layout rows), lists (row click, New), effects incl. SAVE and DELETE, row order, the completeness mark, error codes. |
-| 1.1 | 2026-09-26 | Template items: inline `style` now survives (converted to classes). |
-| 1.2 | 2026-10-06 | Rules 11–12 (found live on a generated screen whose Save did nothing): SAVE says what happened and goes back to where the form was opened; required fields can be filled. `NAVIGATE back`. The guide moves under `cli/engine/cc/guides/` and becomes the Phase B AI's context; the checklist grows by what Control Center checks. |
-| 1.3 | 2026-10-06 | Rule 13, the CRUD baseline (Agung): form Simpan + Batal; list Tambah + row actions Ubah / Hapus shown on hover, no row click needed; a workflow's buttons on its document's form. `DELETE` from a list row (`id`). |
-| 1.4 | 2026-10-07 | §3.3 a document with a workflow: the entity declares it (started on create, state kept on its attribute), the form shows the state and the `workflow-actions` buttons (roles from user groups), a review or approval is a filtered list — never a new-record menu. |
-| 1.5 | 2026-10-07 | A review list (a fixed `filter`) only opens its records: Ubah alone — found live when the CRUD rule gave an approval list Tambah and Hapus. |
-| 1.6 | 2026-10-07 | View mode (Agung): Lihat opens the same form read-only (`queryParams: { mode: 'view' }`) with the transition buttons and Tutup; Simpan / Batal hide there (`expressions` on `formState.readonly`). Where Lihat lives is the customer's choice on the map (`transitionUi`): the main list, or a review list per waiting stage. |
-| 1.7 | 2026-10-07 | §3.4 rows of fields (Agung): short fields side by side on Bootstrap's grid — a row group, a column group per field — by the screen's usage. The Supertail-only row styles leave the guide; a `styleRef` names the domain's own `ui.styles`. |
-| 1.8 | 2026-10-07 | §3.1: a grid hides its add and delete unless declared — an edited grid declares both (found live: a generated offer grid took no new lines). |
-| 1.9 | 2026-10-07 | §3.1 / rule 3: a grid's own `key` names the grid, never its detail table (that is `props.detailKey`) — found live: with the same name, adding a row failed (`this._controls.push is not a function`). |
-| 1.10 | 2026-10-07 | Rule 13: a required lookup's master data is maintained by some screen (a list with Tambah, its form, a menu item) — found live: a required customer lookup with no customer screen, so no offer could be saved. |
-| 1.11 | 2026-10-07 | §3.1: how a lookup is declared — many-to-one from the entity holding the field to the one it picks from (found live: declared one-to-many from the master, the customer lookup listed offers). |
-| 1.12 | 2026-10-07 | §3.5 values the system fills (Agung): a document number the database gives (`numbering`; default `<initials>/{YYYY}/{MM}/{seq:4}`, restarting every year), a value taken from the record a lookup picks (`follows`), lines that start from the picked record's lines (`startsFrom`). |
-| 1.13 | 2026-10-07 | §6.5: a refused save is named by the field's label — `DUPLICATE`, `REQUIRED`, `REFERENCE_NOT_FOUND` (found live: a duplicate reached the user as the raw database message with the statement). |
-| 1.14 | 2026-10-07 | §3.1: what a lookup lists (Agung) — a filter its attribute declares (only accepted offers), and a `unique` lookup hides the records another record already picked. |
-| 1.15 | 2026-10-07 | §3.3: after a transition the form goes back to where it was opened (Agung) — it used to stay and reload. |
-| 1.16 | 2026-10-07 | §3.1: an entity names its records by its `display` attribute, which every lookup to it shows and searches (found live: the account lookup showed the first attribute, not the name). |
-| 1.17 | 2026-10-09 | §7 the list engine (Doc 8 M2, Agung): a search box, a print button, Salin (a new form filled from the row, `copyFrom`), `enabled` per row over `row` and the list's `model` (written by `FORM_PATCH`). Selection and mass actions are application (Layer 2) features. |
+# Writing version 2 screens — authoring guide
+
+**Applies to:** Biz-A platform as of 2026-10-07 (Doc 2 steps 1–3) · **Status:** reference, v1.16
+**Audience:** anyone writing Layer 3 domain config — implementors, and the AI in Doc 1, which reads this as context.
+**Source of truth:** Doc 2 (`Doc 2 Biza_ai_ready.md`) and its implementation plan (`DOC2-IMPLEMENTATION-PLAN-2026-09-25.md`).
+**Where it lives:** `cli/engine/cc/guides/V2-SCREEN-AUTHORING.md` — Control Center hands it to the AI that writes
+configuration (Phase B), and checks the rules below on every AI write. `docs/V2-SCREEN-AUTHORING.md` is an
+identical copy; a test keeps the two equal, so edit the one under `cli` and copy it.
+Every rule below is enforced by the platform or pinned by a test; where a rule is only a convention, it says so.
+
+A version 2 screen is **configuration only**: no load code, no save code, no deleted-row tracking, no handlers.
+The platform loads the record with its details, keeps the form and its data in step, and saves the whole
+graph in one transaction. If a v2 screen seems to need a handler, first check whether an effect below already
+does the job.
+
+---
+
+## 1. The rules (read these first)
+
+1. **Every screen you write is `version: 2`.** Never produce new v1 config. `version` sits on the **entryPoint**
+   (per screen), not on `metadata` — `metadata.version` is the package's semver and means something else.
+2. **An entryPoint names its `entity`.** The entity's table is what the screen loads and saves.
+3. **Collections are keyed by the detail TABLE name** — a repeat by its `key`, a grid by its `props.detailKey` —
+   and only a declared `one-to-many` relationship makes a repeat or grid a collection. Anything else is UI-only and is neither loaded nor saved — with no error.
+4. **Every collection a v2 screen edits declares `orderBy`** on its relationship, and the order column is a
+   `number` attribute. The platform numbers rows from their screen position on save. Save **refuses** a screen
+   that edits an unordered collection.
+5. **Never show the order column on a v2 screen** — the platform owns it and overwrites whatever is typed.
+6. **Owned details declare `ownership: 'parent'`.** Delete cascades through exactly these; `shared` and
+   `independent` relationships are never followed.
+7. **Bindings declare `effects`, not a `handler`.** A binding may have one or the other, never both.
+8. **A collection you save must be complete.** Deletion is inferred from absence: a row missing from the save
+   is deleted. Never paginate, filter or lazy-load an edited collection — or, if a component must, mark it
+   incomplete (§6.4) so the save is refused instead.
+9. **Give list columns a `title`** when the attribute has no `label`, or the header shows the raw column name.
+10. **Keep config comments free of apostrophes and quote marks** — the admin App Config parser counts them.
+11. **A form tells the user what happened, and goes back to where it was opened.** Its `SAVE` carries
+    `onSuccess` (a success `NOTIF`, then `NAVIGATE` with `back: true`) and `onInvalid` (a `NOTIF` saying what to
+    complete) — without `onInvalid` an incomplete form does nothing at all. A `DELETE` goes back the same way.
+    Give `back` a `route` (the entity's list) for a form opened directly, from a bookmark or a refresh.
+12. **Every required attribute can be filled.** It is a field the user edits, or the item carries a
+    `defaultValue`, or the attribute has one. A field the form only **shows** — a `label` item, or a `statusBadge`
+    or `readonly` attribute — gets the item's `defaultValue` when it is required (a workflow state: its initial
+    state), or the form is never valid.
+13. **The CRUD baseline — every entity a user maintains gets all of it.**
+    - **Form:** its fields, **Simpan** (rule 11) and **Batal** — a button bound to `NAVIGATE` with `back: true`
+      (the entity's list as `route`), which leaves without saving.
+    - **List:** **Tambah** (§7) and, on every row, **Ubah** and **Hapus** — one row button column
+      `{ type: 'button', buttons: [{ icon: 'edit', caption: 'Ubah' }, { icon: 'delete', caption: 'Hapus' }] }`,
+      bound by icon: `edit` → `NAVIGATE ['form', <form>, { $ref: 'event.id' }]`, `delete` →
+      `DELETE { id: { $ref: 'event.id' }, confirm: '<question>' }`. The platform shows a row's actions when the row
+      is hovered (always, on a touch screen), so no row needs a click to open. A **review list** — one with a fixed
+      `filter`, like the records waiting for an approval (§3.3) — only opens its records: **Lihat** for a document
+      with a workflow, Ubah otherwise; no Tambah or Hapus — those belong to the entity's main list.
+    - **A lookup's master data:** a required lookup picks from an entity some screen maintains — that entity's own
+      list with Tambah, its form and a menu item, in this domain or another. Without one nothing can be picked and
+      the record can never be saved.
+    - **A document with a workflow** is moved through its states in **view mode**: **Lihat** opens its form
+      read-only, with a button per transition the user may take — clicking one moves the record to that
+      transition's next state — and **Tutup**; Simpan and Batal show only while editing (§3.3).
+
+---
+
+## 2. A complete example
+
+The Add-Info template screens in Supertail (`supertail/src/config/setupConfig.js`) are the reference: a list,
+and a master → detail → subdetail form, with no handler code at all. (Supertail's own screens also name Supertail's
+own styles — `styleRef: 'screenShell'`, `'inlineRow'` …; they are left out here. A domain names only the styles its
+own `ui.styles` declares.)
+
+### 2.1 Model — what the screens depend on
+
+```js
+entities: {
+  st_item_add_info_template:     { table: 'st_item_add_info_template', attributes: { template_code: {...}, template_name: {...}, active: {...} } },
+  st_item_add_info_template_det: { table: 'st_item_add_info_template_det', attributes: { field_label: {...}, sequence_no: { type: 'number', ... }, ... } },
+  st_item_add_info_options:      { table: 'st_item_add_info_options', attributes: { value: {...}, label: {...}, sequence_no: { type: 'number', uiIntent: 'number' } } },
+},
+relationships: {
+  rel_item_add_info_template_det: {
+    type: 'one-to-many', from: 'st_item_add_info_template', to: 'st_item_add_info_template_det',
+    foreignKey: 'st_item_add_info_template_id', ownership: 'parent',
+    orderBy: 'sequence_no',                       // rule 4
+  },
+  rel_item_add_info_options: {
+    type: 'one-to-many', from: 'st_item_add_info_template_det', to: 'st_item_add_info_options',
+    foreignKey: 'st_add_info_tmpl_det_id',        // declared: the <parent>_id convention is too long for Firebird
+    ownership: 'parent', orderBy: 'sequence_no',
+  },
+},
+```
+
+### 2.2 The form
+
+```js
+entryPoints: {
+  stItemAddInfoTemplateV2: {
+    entity: 'st_item_add_info_template',
+    structureRef: 'stItemAddInfoTemplateV2Structure',
+    version: 2,
+    eventBindings: [
+      { emitter: 'Simpan Add-Info Template V2', trigger: 'onClick',                  // the button label, exactly
+        effects: [{ type: 'SAVE',
+                    onSuccess: [{ type: 'NOTIF', level: 'success', message: 'Add-Info Template tersimpan.' },
+                                { type: 'NAVIGATE', back: true, route: ['list', 'supertail-stItemAddInfoTemplateListV2'] }],
+                    onInvalid: [{ type: 'NOTIF', level: 'warning', message: 'Lengkapi isian yang wajib.' }] }] },   // rule 11
+      { emitter: 'Hapus Add-Info Template V2', trigger: 'onClick',
+        effects: [{ type: 'DELETE', confirm: 'Hapus template ini beserta semua field dan opsinya?',
+                    confirmText: 'Hapus', cancelText: 'Batal',
+                    onSuccess: [{ type: 'NOTIF', level: 'success', message: 'Add-Info Template dihapus.' },
+                                { type: 'NAVIGATE', back: true, route: ['list', 'supertail-stItemAddInfoTemplateListV2'] }] }] },
+      { emitter: 'Batal', trigger: 'onClick',                                         // rule 13: leave without saving
+        effects: [{ type: 'NAVIGATE', back: true, route: ['list', 'supertail-stItemAddInfoTemplateListV2'] }] },
+    ],
+  },
+},
+structures: {
+  stItemAddInfoTemplateV2Structure: {
+    type: 'form',
+    items: [
+      { className: 'row g-2', items: [                        // a row of fields (§3.4): no key, no type
+        { className: 'col-12 col-md', items: [{ key: 'template_code', type: 'input', props: { label: 'Kode', required: true } }] },
+        { className: 'col-12 col-md', items: [{ key: 'template_name', type: 'input', props: { label: 'Nama', required: true } }] },
+        { className: 'col-12 col-md-auto', items: [{ key: 'active', type: 'bool', defaultValue: 1, props: { label: 'Aktif', showAsCheckBox: true } }] },
+      ] },
+      { type: 'repeat', key: 'st_item_add_info_template_det',  // the DETAIL TABLE (rule 3)
+        props: { label: 'Field', addBtn: { text: 'Tambah Field', icon: 'add' }, deleteBtn: { text: 'Hapus Field', icon: 'delete' } },
+        items: [
+          { key: 'field_label', ... },
+          { type: 'repeat', key: 'st_item_add_info_options', props: {...}, items: [ { key: 'value', ... }, ... ] },
+        ] },
+      { type: 'button', icon: 'save',   label: 'Simpan Add-Info Template V2' },
+      { type: 'button', icon: 'delete', label: 'Hapus Add-Info Template V2' },
+      { type: 'button', icon: 'close',  label: 'Batal' },
+    ],
+  },
+},
+```
+
+### 2.3 The list
+
+```js
+entryPoints: {
+  stItemAddInfoTemplateListV2: {
+    entity: 'st_item_add_info_template',
+    structureRef: 'stItemAddInfoTemplateListV2Structure',
+    version: 2,
+    eventBindings: [
+      { emitter: 'add', trigger: 'onClick',
+        effects: [{ type: 'NAVIGATE', route: ['form', 'supertail-stItemAddInfoTemplateV2', 'null'] }] },
+      { emitter: 'edit', trigger: 'onClick',                                          // rule 13: row actions
+        effects: [{ type: 'NAVIGATE', route: ['form', 'supertail-stItemAddInfoTemplateV2', { $ref: 'event.id' }] }] },
+      { emitter: 'delete', trigger: 'onClick',
+        effects: [{ type: 'DELETE', id: { $ref: 'event.id' }, confirm: 'Hapus template ini beserta semua field dan opsinya?' }] },
+    ],
+  },
+},
+structures: {
+  stItemAddInfoTemplateListV2Structure: {
+    type: 'list', caption: 'Add-Info Template',
+    items: [ { key: 'template_code', title: 'Kode' }, { key: 'template_name', title: 'Nama' }, { key: 'active', title: 'Aktif' },
+             { type: 'button', buttons: [{ icon: 'edit', caption: 'Ubah' }, { icon: 'delete', caption: 'Hapus' }] } ],
+    buttons: [{ icon: 'add', caption: 'Tambah' }],
+  },
+},
+```
+
+Routes are `form/<app>-<entryPoint>/<id>` and `list/<app>-<entryPoint>`; `null` as the id opens a new record.
+Publishing generates each screen's template — nothing else needs to exist.
+
+---
+
+## 3. Form screens
+
+### 3.1 Items
+
+| Item | Shape | Notes |
+|---|---|---|
+| Field | `{ key, type?, props?, defaultValue?, styleRef? }` | `key` is an attribute of the entity that owns this level. Without `type`, the attribute's `uiIntent` decides the control. Explicit `props` win over the attribute. `defaultValue` fills a new record (rule 12). A column class goes on a group around the field, never on the field (§3.4). |
+| Layout row / group | `{ className, items }` or `{ styleRef, items }` — **no `key`, no `type`** | Groups fields of the **same** entity. `className` takes Bootstrap's grid classes — rows and columns (§3.4). A `styleRef` names a style of this domain's own `ui.styles`; nothing else resolves. |
+| Repeat (a collection) | `{ type: 'repeat', key: <detail table>, props, items }` | Its fields resolve against the **detail** entity (labels, validation). Nests for subdetail. Buttons: `props.addBtn` / `props.deleteBtn` as `{ text, icon }` — `addText` alone renders an unlabeled button. |
+| Grid (a one-level collection) | `{ type: 'detail-grid', key: 'grid_<detail table>', props: { detailKey: <detail table>, columns, addBtn, deleteBtn } }` | The grid's own `key` names the grid — no attribute, never the detail table: the form holds a plain field under that key, and with the table's name the grid could add no row. Columns are `{ key, label, type?, default? }`. `default` initialises rows the user adds, never loaded rows. A hidden `id` column is added automatically. A grid hides its add and delete unless declared: a grid the user edits carries `addBtn: { show: true, label: 'Tambah <row>' }` and `deleteBtn: { show: true, icon: 'delete', key: '__hapus_<detail table>', label: ' ' }` (the delete column's own key, no attribute). |
+| Button | `{ type: 'button', icon, label, styleRef }` | Its `label`, exactly, is the emitter a binding names. |
+| Template (static HTML) | `{ type: 'template', template }` | Rendered through Angular's HTML sanitiser (scripts and event handlers are removed). Inline `style="…"` works: the platform turns each into a generated class. A style containing `{ } < >` is dropped. |
+
+**A lookup** — a field that picks a record of another entity — is an attribute holding that record's key
+(`uiIntent: 'lookup'`) and a relationship
+`{ type: 'many-to-one', from: '<this entity>', to: '<the entity it picks from>', foreignKey: '<the field>', ownership: 'shared' }`.
+The platform lists the records of the relationship's `to`; declared one-to-many from the other side, it would list
+the wrong table. Each record is shown — and searched — by the attribute that names it, which that entity declares:
+`display: '<the attribute that names one record>'` (a name or a number — `display: 'nama_lead'` on Account), beside
+its `table` and `identity`; without it the lookup shows the first attribute, whatever that is. Deleting a record a
+lookup still points to is refused (`IN_USE`).
+It lists every record of that entity unless its attribute narrows it:
+`lookupOptions: { filter: [{ junction: '', column: '<an attribute of the entity it picks from>', operator: '=', value1: "'<value>'" }] }`
+(e.g. only offers whose state is the accepted one; operators `=`, `<>`, `<`, `>`, `<=`, `>=`, `in`, `not in`,
+`is null`, `is not null`; the user's search is added to it). A lookup attribute declared `unique` (one record per
+pick — one offer makes one contract) hides the records another record already picked, keeping this record's own
+pick; nothing else to declare, and the database refuses a duplicate anyway (`DUPLICATE`).
+
+Any item may carry `expressions: { hide: '<expression>' }`, evaluated against `model` and `formState` while the
+form is open. `formState.readonly` is `true` in view mode (§3.2), so an item can show only while editing
+(`hide: 'formState.readonly'`) or only while viewing (`hide: '!formState.readonly'`).
+
+⚠️ A repeat or grid whose key is **not** a declared detail table is UI-only: the platform treats it as screen
+state, loads nothing into it and saves nothing from it — silently.
+
+### 3.2 What the platform does for you
+
+- **Load.** Opening `form/<app>-<entryPoint>/<id>` reads the master and every collection on the screen in one
+  request, each collection in its declared order (`orderBy`, then `id`). A new record (`null`) reads nothing.
+- **Form ↔ data.** Typing updates the form data immediately, grid rows included; an effect that changes the data
+  (FORM_PATCH) shows on screen immediately. Nothing to wire.
+- **Save** (the `SAVE` effect). Sends the record and its collections; the server works out what was added,
+  changed and removed and writes only that, in one transaction (§6). A new record gets its key back, the form
+  reloads it, and the address changes from `/null` to that key.
+- **Row order.** Rows are numbered 1..n from their screen position into the `orderBy` column on every save.
+  Unchanged positions write nothing.
+- **View mode.** A form opened with `queryParams: { mode: 'view' }` (the address ends `?mode=view`) shows its record
+  read-only: no field can be changed — select, date, repeat and grid included — collections show no add or delete,
+  and `SAVE` / `DELETE` change nothing. It is the same form, not a second screen; `formState.readonly` is `true`.
+  A form in a dialog is never in view mode.
+
+### 3.3 A document with a workflow
+
+A document whose life is a workflow — a BPM workflow whose `entityType` is the entity — is moved through its states
+in **view mode** (§3.2): **Lihat** opens the record read-only on its own form, with a button for each transition the
+user may take, and **Tutup**. One form serves both editing and viewing — never a second "view" or "approval" form.
+
+- **The entity declares it:** `workflow: { key: '<workflowKey>', stateAttribute: '<attribute>' }`. The platform
+  starts the workflow when the form creates a record (at its initial state) and writes every state change onto the
+  state attribute, so lists and forms show the state like any other field, and a save never overwrites it.
+- **The state attribute** is a `string`, `uiIntent: 'statusBadge'`, `required`. The form shows it as
+  `{ key: '<attribute>', type: 'label', defaultValue: '<initialStateCode>' }` (rule 12); the list shows it as a column.
+- **The form** carries, besides its fields:
+  - **Simpan** and **Batal**, shown only while editing — `expressions: { hide: 'formState.readonly' }` (a Hapus
+    button on the form, if any, too);
+  - **Tutup**, shown only in view mode — `expressions: { hide: '!formState.readonly' }` — bound to `NAVIGATE` with
+    `back: true`, the entity's list as `route`;
+  - **the transition buttons:** the item `{ type: 'workflow-actions', key: 'aksi_workflow' }` — its key is no
+    attribute. The platform fills it from the screen and shows it in view mode only (a transition leaves the
+    form, which would throw away unsaved edits). Each button is a transition the signed-in user may take: their
+    roles are the role codes mapped to their user groups (an administrator holds every role). Pressing one moves
+    the record to that transition's next state, and the form goes back to where it was opened (the list, shown
+    fresh with the new state); opened directly, it reloads the record instead.
+- **Lihat** is a row action `{ icon: 'visibility', caption: 'Lihat' }`, bound `visibility` / `onClick` to
+  `NAVIGATE ['form', <form>, { $ref: 'event.id' }]` with `queryParams: { mode: 'view' }`. Where it lives is the
+  customer's choice, recorded on the process map as the lifecycle's `transitionUi`:
+  - `view` — the default: on the rows of the entity's main list, before Ubah and Hapus;
+  - `menus` — a review list for each stage that waits for someone (a map SCREEN with that `stage`), each reached
+    from its own menu item: a list over the same entity with a fixed `filter` on the state attribute,
+    `filter: [{ junction: '', column: '<table>.<state column>', operator: '=', value1: "'<STATE>'" }]`, whose only
+    row action is Lihat — no Tambah, Ubah or Hapus. The main list keeps Ubah and Hapus.
+- A menu never opens a listed entity's form as a new record.
+
+```js
+// the form (bindings: Simpan → SAVE, rule 11; Batal and Tutup → [{ type: 'NAVIGATE', back: true, route: ['list', '<list>'] }])
+items: [
+  { key: 'judul' },
+  { key: 'status_code', type: 'label', defaultValue: 'BARU' },
+  { type: 'workflow-actions', key: 'aksi_workflow' },
+  { type: 'button', icon: 'save',  label: 'Simpan', expressions: { hide: 'formState.readonly' } },
+  { type: 'button', icon: 'close', label: 'Batal',  expressions: { hide: 'formState.readonly' } },
+  { type: 'button', icon: 'close', label: 'Tutup',  expressions: { hide: '!formState.readonly' } },
+],
+
+// the main list (transitionUi view): the row button column and the Lihat binding
+{ type: 'button', buttons: [{ icon: 'visibility', caption: 'Lihat' }, { icon: 'edit', caption: 'Ubah' }, { icon: 'delete', caption: 'Hapus' }] },
+{ emitter: 'visibility', trigger: 'onClick',
+  effects: [{ type: 'NAVIGATE', route: ['form', '<form>', { $ref: 'event.id' }], queryParams: { mode: 'view' } }] },
+```
+
+### 3.4 Rows of fields
+
+A form is one field per line unless it says otherwise — fine on a phone, wasteful on a desktop. Biz-A has
+Bootstrap 5's grid: put short fields side by side in rows.
+
+- **A row** is a group `{ className: 'row g-2', items: [ <column>, … ] }`; **a column** is a group around ONE field,
+  `{ className: 'col-12 col-md', items: [{ key: '<attribute>' }] }`. The columns of a row share its width equally on a
+  screen at least 768 px wide, and stack one per line below it. `col-12 col-md-4`, `col-md-6` or `col-md-8` size a
+  column instead; `col-12 col-md-auto` fits it to its content (a checkbox).
+- ⚠️ The column class goes on the group, never on the field item: several field types (date, money, lookup, label,
+  button) also put the field's own class on an inner element, where a width class shrinks the field.
+- **Which fields:** 2–3 short ones per row — codes, names, dates, numbers, money, choices, lookups — related ones
+  together (number and date; customer and contact). Long text, a repeat, a grid, the workflow buttons and the form's
+  buttons stay full width, outside rows.
+- **By the screen's usage** — the device of the map's usage context for its actors or the screen: desktop, tablet or
+  kiosk → rows; mobile only → no rows, one field per line; not known → rows (they stack on a phone anyway).
+
+```js
+items: [
+  { className: 'row g-2', items: [
+    { className: 'col-12 col-md', items: [{ key: 'nomor' }] },
+    { className: 'col-12 col-md', items: [{ key: 'tanggal' }] },
+    { className: 'col-12 col-md', items: [{ key: 'customer_id' }] },
+  ] },
+  { key: 'catatan' },                                      // long text: full width
+  { type: 'repeat', key: 'penawaran_line', props: { ... }, items: [ ... ] },
+]
+```
+
+### 3.5 Values the system fills
+
+Three properties hand a value to the platform instead of the user — declared on the model, never computed by the form.
+
+- **A number the system gives** — `numbering` on a `string` attribute:
+
+  ```js
+  nomor_kontrak: { type: 'string', size: 30, required: true, unique: true, label: 'Nomor Kontrak',
+                   numbering: { format: 'KK/{YYYY}/{MM}/{seq:4}', reset: 'year' } },
+  ```
+
+  The database gives the number when the record is created (KK/2026/10/0001) and never changes it; whatever a form
+  sends is ignored. The format is text with `{YYYY}` `{YY}` `{MM}` `{RM}` (the month in Roman numerals) `{DD}` and
+  exactly one `{seq:N}` (the counter, padded to N digits); the rest only letters, digits, space and `/ . _ -`.
+  `reset` — `year`, `month`, `day` or `never` — says when the counter starts again at 1, and the number must show
+  that period (`{YYYY}` or `{YY}` for `year`). The attribute is `unique`, has no `defaultValue`, and its `size` fits
+  the longest number. The form shows it read-only and never asks for it; a new record shows it empty until saved,
+  so give the item a `props.placeholder` in the user's language ("Dibuat otomatis saat disimpan"). When the customer
+  has no format of their own: `<the document's initials>/{YYYY}/{MM}/{seq:4}`, restarting every year.
+  PostgreSQL databases only — the publish refuses it elsewhere.
+- **A value taken from the record a lookup picks** — `follows` on an attribute:
+
+  ```js
+  customer_id: { type: 'number', uiIntent: 'lookup', required: true,
+                 follows: { via: 'surat_penawaran_id', attribute: 'customer_id' } },
+  ```
+
+  `via` is a lookup attribute of the same entity (with its many-to-one relationship, §3.1); `attribute` is an
+  attribute of the entity it picks from, of the same type. When the user picks, the form copies the value at once and
+  shows it read-only; the database copies it again when the record is saved — on create, and whenever another record
+  is picked — so nothing else can set it. A later change to the picked record does not reach records already saved.
+  Required only when `via` is required.
+- **Lines that start from the picked record's lines** — `startsFrom` on the owned one-to-many relationship:
+
+  ```js
+  kontrakItems: { type: 'one-to-many', from: 'KontrakKerja', to: 'KontrakItem', foreignKey: 'kontrak_kerja_id',
+                  ownership: 'parent', orderBy: 'urutan',
+                  startsFrom: { via: 'surat_penawaran_id', from: 'PenawaranItem' } },
+  ```
+
+  When the user picks, the lines of the picked record (`from`: a line entity the picked entity owns) are copied into
+  the form's collection — only while it is empty, so lines the user already has are never overwritten — and are then
+  edited freely; the save inserts them as this record's own. Attributes with the same name copy; `fields: { <this
+  line's attribute>: <the picked line's attribute> }` adds the ones named differently. Keys, the parent key and the
+  row order never copy. Keep the collection (repeat or grid) on the same screen as the lookup.
+
+---
+
+## 4. Bindings and expressions
+
+```js
+{ emitter: '<button label | list | icon or caption of a list button>', trigger: 'onClick' | 'onRowClick' | ...,
+  effects: [ ... ] }
+```
+
+- An effects binding runs its effects in order. A binding with `effects` must not also name a `handler`.
+- Any value inside an effect may be an expression, resolved when the event fires:
+  - `{ $ref: 'event.id' }` — a path read from `event`, `form` or `ctx` (e.g. `form.model.template_code`);
+  - `{ $ref: '…', $default: x }` — `x` when the path does not exist;
+  - `{ $const: x }` — `x` literally, never resolved.
+- List emitters: `'list'` with trigger `onRowClick` (the whole row); a top or inline list button is matched by its
+  **icon**, or by its caption when it has no icon. `event.id` is the row's key in both cases; a row click also
+  carries `event.row`, the whole row.
+
+---
+
+## 5. Effects
+
+| Effect | Parameters | Behaviour |
+|---|---|---|
+| `SAVE` | `onSuccess?`, `onError?`, `onInvalid?` (effect lists) | v2 forms only. Invalid form → fields are marked, `onInvalid` runs, nothing is sent. Success → the record is reloaded, then `onSuccess`. Failure → `onError`, or the server's message is shown. |
+| `DELETE` | `id?`, `confirm?` (`false` or question text), `confirmText?`, `cancelText?`, `onSuccess?`, `onError?` | On a v2 form: the open record (saved records only). From a list row: the record `id` names (`{ $ref: 'event.id' }`), of the list's entity; the list reloads afterwards. Asks through the platform confirm dialog unless `confirm: false`. Anything but an explicit yes deletes nothing and runs neither list. Cascades by config (§6.3). |
+| `NAVIGATE` | `route` (array), `back?`, `queryParams?`, `reload?` (default `true`) | Opens a screen. `['form', '<app>-<entryPoint>', <id or 'null'>]`, `['list', '<app>-<entryPoint>']`. `back: true` returns to the screen this one was opened from, shown fresh; `route` is then only the fallback for a screen opened directly, and with neither nothing happens. A route is always an array. `queryParams: { mode: 'view' }` opens a form in view mode (§3.2). |
+| `NOTIF` | `message`, `level?` (`success` \| `error` \| other), `sticky?`, `duration?` | A snackbar. `success` lasts 3 s. |
+| `FORM_PATCH` | `patch` (object of field values) | Writes values into the form data; shows immediately. |
+| `FORM_ERROR` | `field`, `message` | Shows an error naming the field. |
+| `OPEN_DIALOG` | `entryPointName`, `model?`, `afterClosedHandler?` | Opens another entryPoint in a dialog. |
+
+---
+
+## 6. Saving and deleting — the contract
+
+### 6.1 How a save is understood
+
+The server compares what is sent with what is stored:
+
+| Sent | Stored | Result |
+|---|---|---|
+| row with a key | same values | nothing written |
+| row with a key | different values | UPDATE of the changed columns only |
+| row without a key | — | INSERT (the key is generated) |
+| — (row missing from a sent collection) | row | **DELETE** (soft or hard, per entity) |
+| collection **not sent at all** | rows | left alone |
+
+A field changed and then changed back writes nothing; untouched rows keep their keys; subdetail rows survive a
+save of their parent row.
+
+### 6.2 Concurrency
+
+A loaded record carries a row version. If someone else changed it meanwhile, save and delete are refused with
+`409 CONCURRENCY_CONFLICT` and write nothing — reload and retry.
+
+### 6.3 Delete
+
+`DELETE` removes the record and, at any depth, every row reached through an `ownership: 'parent'`
+relationship, through each declared foreign key — deepest first, each table by its own `deleteStrategy`
+(`soft` keeps the row and stamps it; anything else deletes it), in one transaction. A record that another row
+still **references** through a `shared` relationship (e.g. a category using a template) is refused with
+`409 IN_USE` naming the referencing table; nothing is deleted.
+
+### 6.4 Completeness — the `_incomplete` mark
+
+Because a missing row means "delete it", a partially loaded collection must never be saved as if complete.
+Whoever loads a collection partially marks its parent row:
+
+```js
+{ st_order: { id: 7, _incomplete: ['st_order_line'], st_order_line: [ /* one page */ ] } }
+```
+
+A save carrying a marked collection is refused with `400 INCOMPLETE_COLLECTION` naming it, before anything is
+read or written. A marked collection that is not sent is fine. No v2 read or component marks anything today —
+whoever first adds paging or filtering to an edited collection must set the mark.
+
+### 6.5 Server errors a screen can meet
+
+| Code | Status | Meaning |
+|---|---|---|
+| `CONCURRENCY_CONFLICT` | 409 | changed by someone else since loaded |
+| `IN_USE` | 409 | cannot delete — still referenced by the named table |
+| `DUPLICATE` | 409 | a value (or combination) a unique key already holds — named by the field's label |
+| `REQUIRED` | 400 | a required value is missing — named by the field's label |
+| `REFERENCE_NOT_FOUND` | 409 | a lookup points at a record that no longer exists — named by the field's label |
+| `INCOMPLETE_COLLECTION` | 400 | a collection marked incomplete was sent |
+| `GRAPH_READ_KEY_REQUIRED` | 400 | a graph read without a key |
+| `SHARED_RELATIONSHIP` | 400 | a collection whose relationship is not owned by its parent was sent |
+| `UNSAFE_SQL` | 400 | a name or value the ORM will not put into SQL |
+| `CROSS_TENANT_WRITE` / `AMBIGUOUS_TENANT` | 403 / 400 | a write outside the caller's tenant / with no tenant |
+
+Without an `onError`, the message is shown to the user as the server wrote it — never with SQL in it.
+
+---
+
+## 7. List screens
+
+- A structure with `type: 'list'` over the entryPoint's `entity`. Items are columns `{ key, title? }`; top
+  `buttons` are `{ icon, caption }`. Optional `filter` (fixed conditions), `distinct`, `caption`.
+- Paging, per-column filter buttons, soft-deleted rows and tenant scope are handled by the platform.
+- A `list` / `onRowClick` binding makes rows clickable (pointer cursor). The row's key is fetched as a hidden
+  column only when such a binding exists; clicking a row button never also fires the row click.
+- A list of an entity that has a form opens it both ways, as in §2.3 (rule 13): the `{ icon: 'add', caption: 'Tambah' }`
+  button bound `add` / `onClick` to the form with `'null'`, and a row button column whose `edit` opens the form
+  with `event.id` and whose `delete` deletes the row's record. Row buttons show when the row is hovered or holds
+  the keyboard focus, and always on a touch screen. A row click (`list` / `onRowClick`) is optional. The rows of a
+  document with a workflow also carry Lihat, where the customer chose so (§3.3).
+
+---
+
+## 8. Checking your config
+
+Pin the silent failures in the application's own tests, as Supertail does in
+`supertail/src/supertaillib/test/v2_add_info_template.test.js`. Control Center checks the screen rules on every
+AI write (`cli/engine/cc/configValidate.js`), so what the AI commits is what publish and the client accept:
+
+- every repeat / grid key is a declared detail table, at every level;
+- every field is a declared attribute of the entity that owns its level;
+- no binding names a handler; every Save/Delete button's label matches its binding's emitter;
+- every collection a v2 screen edits declares `orderBy` on a `number` attribute, and no v2 screen shows it;
+- NOT NULL columns a new row does not show have a `defaultValue` (repeat) or `default` (grid column);
+- a grid a saving form edits shows its add and delete (`addBtn` / `deleteBtn` with `show: true`), and its own `key` is not its detail table;
+- every required attribute can be filled; a required field a saving form only shows carries a `defaultValue` (rule 12);
+- every `SAVE` has `onInvalid`, and goes back (`NAVIGATE back`) on success (rule 11);
+- a form that saves has a cancel button bound to `NAVIGATE back` (rule 13);
+- a list of an entity with a form has the add button and its binding, and row actions `edit` and `delete`, each
+  bound (rule 13) — a review list (a fixed `filter`) only the action that opens its records: Lihat for a document
+  with a workflow, `edit` otherwise;
+- every `NAVIGATE` route is an array naming an entry point of the domain;
+- every required lookup picks from an entity a list with Tambah maintains (rule 13);
+- every lookup attribute has its many-to-one relationship, from its entity to the one it picks from (§3.1);
+- every lookup filter names attributes of the entity it picks from, with a known operator (§3.1);
+- every entity a lookup picks from declares `display`, the attribute that names its records (§3.1);
+- every `styleRef` names a style of the domain's own `ui.styles` (§3.4);
+- an entity with a workflow declares it (`workflow: { key, stateAttribute }`); every form that saves it has a
+  `workflow-actions` item whose key is no attribute, a button shown in view mode that goes back (Tutup), and no
+  button shown in view mode that saves or deletes; and some list of it opens its records with Lihat (§3.3);
+- no menu opens a listed entity's form as a new record (§3.3).
+- every numbered attribute is a unique string with a valid format and no default; every `follows` and `startsFrom`
+  names a lookup of its entity and what the picked entity has (§3.5).
+
+---
+
+## 9. Version history
+
+| Version | Date | Change |
+|---|---|---|
+| 1.0 | 2026-09-26 | First edition: forms (repeat, grid, layout rows), lists (row click, New), effects incl. SAVE and DELETE, row order, the completeness mark, error codes. |
+| 1.1 | 2026-09-26 | Template items: inline `style` now survives (converted to classes). |
+| 1.2 | 2026-10-06 | Rules 11–12 (found live on a generated screen whose Save did nothing): SAVE says what happened and goes back to where the form was opened; required fields can be filled. `NAVIGATE back`. The guide moves under `cli/engine/cc/guides/` and becomes the Phase B AI's context; the checklist grows by what Control Center checks. |
+| 1.3 | 2026-10-06 | Rule 13, the CRUD baseline (Agung): form Simpan + Batal; list Tambah + row actions Ubah / Hapus shown on hover, no row click needed; a workflow's buttons on its document's form. `DELETE` from a list row (`id`). |
+| 1.4 | 2026-10-07 | §3.3 a document with a workflow: the entity declares it (started on create, state kept on its attribute), the form shows the state and the `workflow-actions` buttons (roles from user groups), a review or approval is a filtered list — never a new-record menu. |
+| 1.5 | 2026-10-07 | A review list (a fixed `filter`) only opens its records: Ubah alone — found live when the CRUD rule gave an approval list Tambah and Hapus. |
+| 1.6 | 2026-10-07 | View mode (Agung): Lihat opens the same form read-only (`queryParams: { mode: 'view' }`) with the transition buttons and Tutup; Simpan / Batal hide there (`expressions` on `formState.readonly`). Where Lihat lives is the customer's choice on the map (`transitionUi`): the main list, or a review list per waiting stage. |
+| 1.7 | 2026-10-07 | §3.4 rows of fields (Agung): short fields side by side on Bootstrap's grid — a row group, a column group per field — by the screen's usage. The Supertail-only row styles leave the guide; a `styleRef` names the domain's own `ui.styles`. |
+| 1.8 | 2026-10-07 | §3.1: a grid hides its add and delete unless declared — an edited grid declares both (found live: a generated offer grid took no new lines). |
+| 1.9 | 2026-10-07 | §3.1 / rule 3: a grid's own `key` names the grid, never its detail table (that is `props.detailKey`) — found live: with the same name, adding a row failed (`this._controls.push is not a function`). |
+| 1.10 | 2026-10-07 | Rule 13: a required lookup's master data is maintained by some screen (a list with Tambah, its form, a menu item) — found live: a required customer lookup with no customer screen, so no offer could be saved. |
+| 1.11 | 2026-10-07 | §3.1: how a lookup is declared — many-to-one from the entity holding the field to the one it picks from (found live: declared one-to-many from the master, the customer lookup listed offers). |
+| 1.12 | 2026-10-07 | §3.5 values the system fills (Agung): a document number the database gives (`numbering`; default `<initials>/{YYYY}/{MM}/{seq:4}`, restarting every year), a value taken from the record a lookup picks (`follows`), lines that start from the picked record's lines (`startsFrom`). |
+| 1.13 | 2026-10-07 | §6.5: a refused save is named by the field's label — `DUPLICATE`, `REQUIRED`, `REFERENCE_NOT_FOUND` (found live: a duplicate reached the user as the raw database message with the statement). |
+| 1.14 | 2026-10-07 | §3.1: what a lookup lists (Agung) — a filter its attribute declares (only accepted offers), and a `unique` lookup hides the records another record already picked. |
+| 1.15 | 2026-10-07 | §3.3: after a transition the form goes back to where it was opened (Agung) — it used to stay and reload. |
+| 1.16 | 2026-10-07 | §3.1: an entity names its records by its `display` attribute, which every lookup to it shows and searches (found live: the account lookup showed the first attribute, not the name). |