pi-apexlang 0.1.0

package/skills/apexlang/references/policies/memory-bank/30-pages/apex.interactive-report.md

@@ -0,0 +1,71 @@
+# Interactive Report Page Standards
+
+### Purpose
+- Define deterministic layout and configuration for Interactive Report pages.
+- SQL snippets containing `{{...}}` are `metavariable_template` examples. Bind every variable from schema evidence before emitting SQL or APEXlang.
+
+### Rules (Non-Negotiable)
+1. Use `pageTemplate: @/standard` with `templateOptions: #DEFAULT#`.
+2. Main region must be `type: interactiveReport` with `appearance.template: @/interactive-report` and `componentAppearance.template: @/standard`.
+3. Default pagination is `rowRangesXToY`; include `messages.whenNoDataFound`, align numeric columns to `end`, and override the pagination type only when the user prompts for a catalog option listed in `20-data/apex.sql.md`.
+4. Apply navigation/breadcrumb requirements from `apex.page.md`.
+5. When report navigation is added or changed, ask every time which link mode is required: same application page, another application page, or URL redirect.
+6. For same-application navigation, prefer declarative page targets when the DSL supports them; do not default to `type: url`, `f?p=...`, or SQL-computed URL columns.
+7. Every Interactive Report `column (...)` must define `heading { heading: ... }`, including hidden technical ID columns. Hiding a column does not waive the required structural heading metadata.
+8. Every projected SQL column must have a matching Interactive Report `column (...)` definition before finals. Do not rely on implicit generated columns for delivered artifacts.
+9. If the report SQL references same-page page-item binds, emit `source.pageItemsToSubmit` with those exact item names so refreshes use current context.
+10. Interactive Report column links must use the column-level `link {}` block with normal Interactive Report column `type` values such as `plainText`; do not copy Classic Report `type: link`, `reportColumnQueryId`, or `derivedColumn` into Interactive Report columns.
+
+### Guidance
+- Follow `templates/page-examples/interactive-report-page/interactive-report-page._index.md` for canonical column definitions, filter options, and toolbar settings.
+- Keep `appearance.templateOptions` to exact accepted values only. `#DEFAULT#` is a standalone entry, documented caller-facing tokens stay unsuffixed, and documented composites such as hidden-header pairs remain one atomic value.
+- Make the primary-key decision explicit:
+  - when row navigation or row identity is intended, keep the PK column and wire the navigation declaratively
+  - otherwise hide the PK column with `type: hidden`, while still keeping the required `heading { heading: ... }`
+- Keep column aliases uppercase.
+- Do not emit `reportColumnQueryId` or `derivedColumn` for interactive report columns; those attributes belong to classic report columns only in this repository contract.
+- Use friendly display names for headings and apply format masks via the `appearance` block.
+- Follow `references/policies/memory-bank/30-pages/apex.report-column-rendering.md` for SQL data-only behavior and column formatting markup placement.
+- When linking to a page in the same application, use declarative page-target syntax at the region or column level when supported. If the target page is modal, the parent page must include an `apexafterclosedialog` dynamic action that refreshes the originating report region via `templates/business-logic/dynamic-actions/dynamic-actions.refresh-region-after-dialog.md`.
+- For column-level links, use `#COLUMN_ALIAS#` in `target.items` for current report-row values and reserve `&ITEM.` for page/app/session substitutions.
+- Interactive reports should include a default guidance layer. Provide concise user-facing guidance for business-significant columns and all derived, status, and action columns using the supported guidance hook in the selected template family; when the runtime shape has no dedicated column-help hook, surface that guidance in page or region help.
+- Parent-child child reports must bind to the hidden parent context item and list that item in `source.pageItemsToSubmit`; parent-context create/edit buttons should be placed in the report toolbar slot such as `rightOfInteractiveReportSearchBar`.
+
+### Filtering With Page Items
+- When an Interactive Report uses page-item-driven text search or filtering, normalize both sides of user-entered text predicates with `LOWER()` for `=` / `!=` / `LIKE`.
+- Canonical examples:
+  ```sql
+  where (:P3_SEARCH is null
+     or lower(s.{{source.displayColumn}}) like '%' || lower(:P3_SEARCH) || '%')
+  ```
+  ```sql
+  where lower(s.{{source.statusColumn}}) = lower(:P3_STATUS)
+  ```
+- Non-compliant examples:
+  ```sql
+  where s.{{source.displayColumn}} like '%' || :P3_SEARCH || '%'
+  ```
+  ```sql
+  where upper(s.{{source.displayColumn}}) like '%' || upper(:P3_SEARCH) || '%'
+  ```
+
+
+### Example Query
+```sql
+select {{source.pk}},
+       {{source.displayColumn}},
+       {{source.statusColumn}},
+       {{source.createdOnColumn}},
+       {{source.amountColumn}},
+       {{lookup.valueColumn}}
+  from {{source.table}}
+```
+
+- Include `comments { comments: ... }` by default on key IR columns as descriptive metadata describing SQL projection, display behavior, reuse intent, and whether the wording is provisional or sourced. Require the attributes `Display Label`, `Display in Report`, `Display in Form`, `Format Mask`, `Value Required`, `Read Only`, `Primary Display Column`, and `Authorization Scheme`; include `Summary` only when a short leading business-intent sentence materially helps maintenance. When `Summary` is present, keep the field order `Summary`, `Display Label`, `Display in Report`, `Display in Form`, `Format Mask`, `Value Required`, `Read Only`, `Primary Display Column`, `Authorization Scheme`. Mirror executable settings such as `appearance.formatMask` and `security.authorizationScheme` when those blocks are emitted.
+- This applies to simple, single-region, or starter interactive reports as well. Keep the copy short, but do not omit the guidance layer because the report is lightweight.
+- Hidden technical IDs may skip user-facing guidance, but they must still keep the required `heading { heading: ... }` block. Important technical, derived, status, and action columns still require developer comments.
+- Critique should fail when an interactive report column omits the `heading` block or omits `heading.heading`, even when the column is hidden.
+- Critique should fail when an interactive report column includes classic-report-only attributes such as `reportColumnQueryId` or `derivedColumn`.
+- Critique should fail when SQL projections are missing matching `column (...)` blocks or when same-page bind items are missing from `source.pageItemsToSubmit`.
+- Critique should fail when visible business columns, derived columns, status columns, or action columns are left without the expected default guidance or maintainability comments.
+- Column-level `security { authorizationScheme: ... }` remains optional and must reference `{your-app-alias}/shared-components/authorizations.apx` when restrictions are required.

package/skills/apexlang/references/policies/memory-bank/30-pages/apex.layout.md

@@ -0,0 +1,135 @@
+# Page Layout Standards
+
+## Purpose
+Defines the default region layout contract for page generation so APEXlang pages use the native 12-column flow efficiently instead of over-specifying grid coordinates.
+
+This file applies to generated application page artifacts, templates, and non-modal page layouts unless a page-type rule defines a narrower contract.
+
+## Layout Scopes
+Each layout container owns its own 12-column grid. Evaluate `column` and `columnSpan` only within the current scope.
+
+Supported scopes:
+- page slot rows, for example top-level BODY regions
+- nested region rows grouped by `layout.parentRegion + layout.slot`
+- item rows grouped by `layout.region + layout.slot`
+- button rows grouped by `layout.region + layout.slot`
+
+Parent and child spans never add together across scopes. A parent region may consume part of the page grid, while items, buttons, or nested regions inside that parent still get their own local 12-column budget.
+
+## Default Rule
+- Prefer implicit flow for equal-width sibling components within the current scope.
+- Use `layout.sequence` to control order.
+- Use `layout.startNewRow: false` on the second and later components in the same row.
+- Omit `layout.column` and `layout.columnSpan` for equal-width rows.
+
+## Page-Template-First Shell Rule
+- When the requirement is a true shell composition such as sidebar + main content, side rail + body, or left rail + stacked detail, evaluate the page template family before reaching for explicit body-grid coordinates.
+- Prefer a page template with semantic slots such as `leftColumn` + `body` only for documented filter/sidebar shells such as faceted search. Master-detail Content Row workbenches use the standard page template plus a BODY grid split.
+- For Theme 42 side-column page templates, treat the rail width as a fixed build-pinned shell detail of about `15rem`; if that width is not suitable, prefer explicit body-grid coordinates instead of trying to stretch the page-template rail.
+- Side-column page templates are especially appropriate when the rail content is meant to select, filter, or switch the content shown in the main body, such as contextual sub-navigation, parent selectors, or section choosers.
+- When a side rail provides contextual sub-navigation across a local page group, repeat that sub-navigation on each linked page in the group instead of showing it only on the landing page.
+- Use explicit `column` and `columnSpan` in `body` only when the required width ratio, stacking pattern, or page family cannot be expressed cleanly by the page template shell.
+- Do not default the left region to `column: 1`; a first region in a scoped row may declare only `columnSpan` when that is sufficient.
+
+## Equal-Width Row Recipes
+- `stack`
+  - One region per row.
+  - Omit `startNewRow`, `column`, and `columnSpan`.
+- `two-up-equal`
+  - First region in row: omit `startNewRow`.
+  - Second region in row: `startNewRow: false`.
+  - Omit `column` and `columnSpan` on both.
+- `three-up-equal`
+  - First region in row: omit `startNewRow`.
+  - Second and third regions: `startNewRow: false`.
+  - Omit `column` and `columnSpan` on all three.
+- `kpi-strip`
+  - Use the same equal-width flow rules as `three-up-equal`, extended to the number of KPI siblings in the row.
+  - Prefer 2-6 KPIs in one row when labels are short and content is single-value.
+
+## When Explicit Grid Coordinates Are Allowed
+Use `layout.column` and `layout.columnSpan` only for intentionally asymmetric layouts within the current scope, such as:
+- sidebar + main content
+- faceted search
+- parent-child split
+- wizard or modal shell-specific positioning
+- prompt-explicit uneven widths
+
+Allowed asymmetric examples:
+- `sidebar-main`: 3/9 or 4/8
+- `parent-child-split`: 4/8
+- `master-detail-content-row`: standard page template; parent Content Row in `BODY` at `columnSpan: 3` or `4`, followed by the child region in the same body row with `startNewRow: false`
+- `three-zone`: 3/6/3
+
+## Mixed-Layout Interpretation
+- Within one scoped row, do not mix fully implicit equal-width flow with explicit-grid placement.
+- However, allow the anchored-sibling asymmetric pattern:
+  - the first region may declare `columnSpan` only
+  - later sibling regions in the same row may declare `column`
+- Treat `columnSpan` on the first sibling plus `column` on a later sibling as a valid asymmetric row pattern, not invalid mixed layout.
+- Use this exception only when the row is intentionally asymmetric. Equal-width rows still omit explicit coordinates.
+
+## Generation Contract
+- Generated `applications/**` artifacts are subject to deterministic layout linting; do not treat final app files as exempt from these rules.
+- For standard non-login pages, top-level regions should use `layout.slot: body`.
+- Reserve `layout.slot: contentBody` for login and modal-dialog page-template contracts that explicitly define that semantic slot.
+- Decide the row recipe per layout scope before emitting components.
+- For equal-width rows, do not emit fallback coordinates "just to be safe".
+- Do not mix implicit-flow and explicit-grid placement within the same scope row unless the pattern is intentionally asymmetric.
+- If a row is equal-width, the first component must omit `startNewRow`; later siblings in that row must set `startNewRow: false`.
+- The total explicit `columnSpan` in any single row must never exceed 12 within that scope.
+
+## Analytical Page Defaults
+- KPI strips: equal-width flow by sequence.
+- Dashboards must create a `layout_row_plan` before emitting KPI strips, chart rows, report/detail rows, or side-by-side component rows.
+- `layout_row_plan` entries must include `slot`, `row`, `recipe`, and ordered `regions` static IDs.
+- Each `layout_row_plan` entry is exactly one physical row. Stacked full-width detail, contextual summary, and cards sections each get their own one-region entry; do not put multiple stacked sections in the same `regions` array.
+- Two charts: one `two-up-equal` row.
+- Three charts: one `three-up-equal` row.
+- Four charts: two `two-up-equal` rows.
+- Five charts: one `two-up-equal` row, then one `three-up-equal` row.
+- More than five charts: repeat `two-up-equal` and `three-up-equal` rows, preferring balanced rows.
+- In each chart row, the first chart omits `startNewRow`; second-and-later charts in that row use `startNewRow: false`.
+- Do not literally stack multiple dashboard charts unless the prompt explicitly requests vertical stacking or a chart is intentionally a detail/full-width section.
+- Detail/report sections below KPIs/charts: `stack` unless the prompt explicitly requests a split.
+
+## Master-Detail Content Row Defaults
+- When a parent Content Row selects context for a child report, use a left/right parent-child split instead of stacked full-width regions.
+- Emit the parent Content Row first with `layout.columnSpan: 3` or `4`; omit `layout.column` unless another region in the same scope requires an explicit start column.
+- Emit the child report second with `layout.startNewRow: false`; do not add redundant `column` / `columnSpan` unless a runtime or template-specific contract requires explicit coordinates.
+- Place parent-context page items as hidden technical items, not as visible body controls, unless the prompt explicitly requests a manual selector.
+- Place create/edit/detail buttons for the child context inside the child report toolbar slot instead of laying them out in body-grid columns.
+- Place primary page-level create actions in the breadcrumb/title-bar region when the page has a breadcrumb region; do not anchor them to an unrelated child report.
+
+## Asymmetric Layout Recipes
+- `sidebar-main-stacked-detail`
+  - Choose the page-template shell version first when a page template can express the requested left rail + main body composition closely enough.
+  - Template-shell version:
+    - sidebar or parent context region: `layout.slot: leftColumn`
+    - main detail/report regions: `layout.slot: body`
+  - Explicit body-grid version:
+    - left region first: `layout.columnSpan: 4`
+    - right top region: `layout.column: 5`, `layout.startNewRow: false`
+    - right stacked sibling below: `layout.column: 5`
+  - Do not force `layout.column: 1` onto the left region for this recipe.
+  - Do not treat `columnSpan` on the left region plus `column` on the right siblings as invalid mixed layout.
+
+## Asymmetric Layout Recipes
+- `sidebar-main-stacked-detail`
+  - Choose the page-template shell version first when a page template can express the requested left rail + main body composition closely enough.
+  - Template-shell version:
+    - sidebar or parent context region: `layout.slot: leftColumn`
+    - main detail/report regions: `layout.slot: body`
+  - Explicit body-grid version:
+    - left region first: `layout.columnSpan: 4`
+    - right top region: `layout.column: 5`, `layout.startNewRow: false`
+    - right stacked sibling below: `layout.column: 5`
+  - Do not force `layout.column: 1` onto the left region for this recipe.
+  - Do not treat `columnSpan` on the left region plus `column` on the right siblings as invalid mixed layout.
+
+## Anti-Patterns
+- Do not emit `column: 1`, `columnSpan: 6`, `column: 7`, `columnSpan: 6` for a simple two-up row.
+- Do not assign explicit `column` / `columnSpan` to every sibling on a dashboard when APEX native flow can place them correctly.
+- Do not omit `startNewRow: false` from second-or-later equal-width siblings.
+- Do not add child spans to parent spans when validating a row budget; each scope resets to 12 columns.
+- Do not model master-detail parent selection as a visible select list plus a separate full-width child report when a Content Row parent list is the primary browse affordance.

package/skills/apexlang/references/policies/memory-bank/30-pages/apex.login-page.md

@@ -0,0 +1,24 @@
+## Login Page Standards
+
+### Purpose
+- Guarantee login pages use the canonical layout, authentication wiring, and button behaviour.
+
+### Rules (Non-Negotiable)
+1. Use `pageTemplate: @/login` with `templateOptions: #DEFAULT#`.
+2. Include username/password items using the hidden templates from the login page example (`page-examples/login-page/login-page._index.md`).
+3. Buttons region must contain a single `LOGIN` button using `@/text` template, `hot: true`, and `behavior.action: definedByDynamicAction` (per the template).
+4. Login page processes must only handle authentication primitives:
+   - `APEX_AUTHENTICATION.LOGIN` via `type: invokeApi`
+   - `SEND_LOGIN_USERNAME_COOKIE` when Remember Username is enabled.
+   All other processes are to be created as application processes unless user explicitly mentions them to be as page processes.
+
+5. Do not add navigation or breadcrumb entries; login pages remain isolated.
+6. When creating a custom login page, update `application.apx` so `navigation.loginUrl` points to that login page.
+   - Use the same page number as the generated login page, following the same `f?p=&APP_ID.:<page_number>:&APP_SESSION.::&DEBUG.:::` pattern used for `navigation.homeUrl`.
+   - Do not leave `navigation.loginUrl` pointing to `LOGIN`, `9999`, or any previous page when the actual login page is different.
+   - If the login page alias is renamed, `navigation.loginUrl` must still be updated to the active custom login page target rather than relying on an outdated alias.
+
+### Guidance
+- Mirror `templates/page-examples/login-page/login-page._index.md` for item definitions, session state configuration, and process order.
+- When customizing text or layout chrome, use template options and static content regions rather than altering the authentication logic.
+- Whenever a login page is added or moved off the default seed, verify `application.apx > navigation.loginUrl` is updated in the same change.

package/skills/apexlang/references/policies/memory-bank/30-pages/apex.map-page.md

@@ -0,0 +1,29 @@
+## Map Page Standards
+
+### Purpose
+- Ensure map pages use a consistent layout, Universal Theme template, and map region configuration.
+
+### Rules (Non-Negotiable)
+1. Set `pageTemplate: @/standard` with `templateOptions: #DEFAULT#`.
+2. Main region must be `type: map` (or the appropriate map plug-in) with `appearance.template: @/standard`.
+3. Define map attributes (controls, `initialPositionAndZoom`, layer `source { ... }`, tooltip/info-window, and `columnMapping.geometryColumnDataType`) exactly as shown in `page-examples/map-page/map-page.example.md` and the `region-components/map/*` family.
+4. Apply navigation/breadcrumb requirements from `apex.page.md`.
+5. For `initialPositionAndZoom.type: sqlQuery`, the SQL select-list aliases must exactly match every configured `initial*Column` name. If `initialZoomlevelColumn` is emitted, the SQL must return that alias too.
+6. Multi-marker maps must use a viewport that fits the marker set. Do not center on `avg(latitude)` / `avg(longitude)` with a fixed zoom such as `4 as zoom_level`; that focuses the map on an arbitrary example location and can hide outlying points.
+7. Prefer a SQL-derived `boundingBox` from `min(longitude)`, `min(latitude)`, `max(longitude)`, and `max(latitude)` for table-backed multi-marker maps. Omit `infiniteMap` when authoring a bounding box because that feature disables bounding-box metadata.
+8. Use `initialPositionAndZoom` with a fixed zoom only when requirements explicitly identify one known geography or single-location viewport.
+9. Map layers that depend on same-page context must use live-valid refresh/session-state patterns for the active compiler. Do not emit unsupported map-layer `source.pageItemsToSubmit`, and do not use `v('P...')`, `nv('P...')`, or string-concatenated session-state workarounds.
+10. When requirements say marker selection opens a form, the map layer must include a declarative `link { target: { page, items } }` that passes the marker primary key, and `columnMapping.primaryKeyColumn` must identify the marker key column.
+
+### Guidance
+- Mirror `templates/page-examples/map-page/map-page.example.md` for page-level structure, `body` slot usage, SQL-driven `initialPositionAndZoom`, and the standard table-backed layer pattern.
+- Use `templates/region-components/map/*` for the concrete map-region and map-layer attribute vocabulary, including `geometryColumnDataType: longitudeLatitude`.
+- In SQL-driven initial positioning, treat `initialLongitudeColumn`, `initialLatitudeColumn`, and optional `initialZoomlevelColumn` as references to the SQL output alias names, not to the source table column names.
+- For broad store/customer/location maps, start from `map.region.bbox-sql.md` rather than fixed-zoom initial positioning. A typical longitude/latitude bounds query returns `min(longitude) as min_lon`, `min(latitude) as min_lat`, `max(longitude) as max_lon`, and `max(latitude) as max_lat` over the same filtered dataset used by the layer.
+- Map-layer source modes are:
+  - `source { tableName: ... }` for the preferred baseline
+  - `source { type: sqlQuery sqlQuery: ... }` for new SQL-backed layers
+  - `source { type: functionBody plsqlFunctionBody: ... }` for advanced fallback cases
+- Legacy bare `source { sqlQuery: ... }` remains accepted for existing artifacts during transition, but new SQL-backed examples should use `source.type: sqlQuery`.
+- When combining maps with Smart Filters, target a companion report/cards results region and refresh the sibling map explicitly. Do not point Smart Filters directly at the map region.
+- In master-detail map pages, the parent selector must refresh the map and any sibling detail report after changing the selected context item.

package/skills/apexlang/references/policies/memory-bank/30-pages/apex.page.md

@@ -0,0 +1,239 @@
+# Page Standards
+
+## Purpose
+Defines naming, navigation, and hierarchy rules for creating new Oracle APEX pages.
+These standards ensure all pages follow consistent structure and navigation behavior.
+
+## Page skeleton and block order
+- Required order for page objects:
+  1) appearance
+  2) nav
+  3) css (conditional; only when a CSS exists under #APP_FILES#css/*.css and governance requires inclusion)
+  4) security
+  5) regions/items/buttons/processes in canonical order per templates
+- CSS placement:
+  - The css block must appear immediately after nav and before security.
+  - The css block must use:
+    css {
+        fileUrls: #APP_FILES#css/CUSTOM_FILE_NAME.css
+    }
+  - Do not include css when no CSS file is present or when no deterministic selection is provided; Critique records Missing Inputs instead of guessing.
+- JavaScript placement:
+  - Approved fields only:
+    - js.functionAndGlobalVarDeclaration (namespace globals, e.g., var APP = APP || {};)
+    - js.executeWhenPageLoads (minimal, idempotent logic; prefer Dynamic Actions for UI behavior)
+  - Prohibited:
+    - eval/new Function
+    - Inline HTML event handlers (onclick, onload, etc.)
+    - External URLs; all assets must be served from #APP_FILES# or Theme Files
+- Global page (Page 0) specifics:
+  - Keep global JS minimal and idempotent; avoid heavy logic.
+  - If runtime template omits nav, templates may include a minimal nav to keep css placement deterministic.
+
+---
+
+- Global page DSL must exactly mirror `templates/page-examples/global_page_0/global_page_0._index.md`; do not emit `appearance`, `templateOptions`, or other attributes unless governance explicitly adds them to the template.
+
+---
+
+## Navigation Rules
+1. **Navigation List Entry**
+   - For every new **non-modal** page, add a corresponding entry to:
+     ```
+     /shared-components/lists.apx
+     ```
+   - Ensure naming consistency and logical placement in the navigation hierarchy.
+   - Parent entries that contain children must not define a direct link block; only child entries carry links.
+
+2. **Breadcrumb Entry**
+   - For every new **non-modal** page, add a breadcrumb entry in:
+     ```
+     /shared-components/breadcrumbs.apx
+     ```
+   - Only include entries for pages that actually exist.
+   - For form/modal pages, pass the primary key item in the target (e.g., P[PAGE]_ID:&P[PAGE]_ID.).
+   - Sequence numbers should be logical and incremental.
+   - Maintain the correct breadcrumb hierarchy relative to parent pages.
+
+3. **Page 0 (Global Page)**
+   - Page 0 (`p00000-global-page.apx`) MUST remain the canonical minimal skeleton unless a user explicitly requests global components intended to render on **all** pages.
+   - Do **not** emit `security`, `authorizationScheme`, `authentication`, `pageAccessProtection`, `formAutoComplete`, page authorization, or page-level session/security properties on Page 0.
+   - If a validator, generator, or template requests normal non-login page security on Page 0, the validator/generator/template is wrong. Fix that source; do not mutate Page 0 to satisfy it.
+   - Hidden page items on Page 0 remain subject to hidden-item SSP only when they are explicitly and intentionally added as global items.
+
+---
+
+## Page Grouping
+- The correct page-level grouping key is `pageGroup` and it MUST BE SET AT THE PAGE ROOT.
+- Do not use `group` at page scope; `group` is reserved for region/item grouping inside component templates (e.g., interactive report column groups).
+- Reference groups declared in the target application artifact (for example, `{target_root}/application.apx`) for whole-application runs.
+
+Example (page root with `pageGroup`):
+```plaintext
+page 42 (
+    name: Records
+    alias: RECORDS
+    title: Records
+    pageGroup: @administration
+    ...
+)
+```
+
+Navigation and Breadcrumb DSL patterns (non-modal pages)
+- Navigation Menu entry (shared-components/lists.apx):
+```plaintext
+list navigation-menu (
+  ...
+  entry records (
+    label: Records
+    layout { sequence: 20 }
+    link { target: f?p=&APP_ID.:42:&APP_SESSION.::&DEBUG.::: }
+  )
+)
+```
+- Breadcrumbs entry (shared-components/breadcrumbs.apx):
+```plaintext
+breadcrumb breadcrumb (
+  ...
+  entry records (
+    name: Records
+    pageNumber: 42
+    appearance {
+      parentEntry: @home
+    }
+    execution {
+      sequence: 20
+    }
+    link {
+      target: f?p=&APP_ID.:42:&APP_SESSION.::&DEBUG.:::
+    }
+  )
+)
+```
+- Breadcrumb entry validity:
+  - `parentEntry` is valid only inside `appearance {}`.
+  - `execution { parentEntry: ... }` is invalid.
+
+Critique Gate — Navigation & Grouping (non-modal)
+- If grouping is requested, `pageGroup` must appear at the page root; `group` used at page root is FORBIDDEN and must be replaced with `pageGroup` as the parameter name (non-negotiable).
+- Navigation Menu: shared-components/lists.apx must include an entry targeting f?p=&APP_ID.:&PAGE_ID.:&APP_SESSION.::&DEBUG.::: for the new page.
+- Breadcrumbs: shared-components/breadcrumbs.apx must include a matching entry for the new page.
+- Missing entries or misuse of `group` at page root must be flagged as failures.
+
+### Breadcrumb / Title Bar Region Resolution
+- The primary header region rendered in the title bar occupies `REGION_POSITION_01` (often a staticContent hero that hosts the breadcrumb).
+- When a user prompt requests placing buttons “in the breadcrumb” or “title bar”, locate the actual region assigned to `REGION_POSITION_01` and reference its static ID in `layout.region` (e.g., `@test-application`). Do not assume an alias like `@breadcrumb` exists unless explicitly created.
+- Avoid creating duplicate button container regions in the header; reuse the existing hero/breadcrumb region per apex.buttons.md.
+
+## Naming Conventions
+1. **Page File Naming**
+   - Use the following format for all APEX page files:
+     ```
+     p[page_number].apx
+     ```
+     Example: `p00001.apx`, `p00002.apx`
+   - Zero-padding ensures consistent sorting and file naming across projects.
+
+2. **Internal References**
+   - When referring to page-level components, use the **page number prefix**:
+     ```
+     P[page_number]_[item_name]
+     ```
+     Example: `P3_NAME`, `P5_TITLE`
+
+---
+
+
+## Modal Drawer/Page Policy
+- When `appearance.pageMode: modalDialog`, do not set `pageTemplate`. Only `dialogTemplate` is required.
+- `appearance.dialogTemplate` MUST use a canonical alias from templates/theme defaults only: `@/modal-dialog`, `@/drawer`, or `@/wizard-modal-dialog`.
+- `@/modal` is invalid and must be rejected by critique.
+- Navigation and breadcrumb entries for modal pages should use `serverSideCondition: never` unless explicitly displayed.
+
+## Server-Side Execution — invokeApi Preferred with Thin Wrapper Exception (Non‑Negotiable)
+- Page processes that call PL/SQL package procedures/functions MUST use:
+  - Prefer `type: invokeApi`
+  - Provide `invoke { package: PKG_NAME procedureOrFunction: PROC_OR_FUNC }`
+  - Provide one `parameter ( ... )` block per argument with explicit direction (in | out | in out) and value mapping:
+    - `value { item: Pn_ITEM }` for item-based values
+    - `value { type: expression plsqlExpression: ... }` for expressions
+    - Include `parameter { dataType: boolean, hasDefault: true }` when required by the API signature (see login template pattern).
+- Allow a thin `type: executeCode` wrapper for packaged routines only when the block is a small named-notation package call plus direct page-item assignment required for a page-coupled loader or before-header branch-gated flow.
+- DO NOT use `type: executeCode` to re-embed business logic that belongs in the package; non-compliant wrappers must be flagged by critique (see 00-guard and 20-data/apex.logic.md).
+- This section governs page processes only. Application processes (`appProcess`) must use `type: executeCode` per 00-guard and 10-global policies.
+- Advisory threshold: if any inline PL/SQL body in page-level artifacts exceeds 4000 raw characters, critique should emit warning `PLSQL_LENGTH_WARN_001` and recommend extracting logic into `app_process_api` (or justified alternative). For processes, the preferred target shape is `type: invokeApi`, with the thin-wrapper exception used only when it is explicitly justified by runtime-safe page-item orchestration.
+- Advisory threshold: if any inline SQL body in page-level artifacts exceeds 4000 raw characters, critique should emit warning `SQL_LENGTH_WARN_001` and recommend extracting the query into a secure view that page-level artifacts reference instead of embedding inline.
+- Dynamic Content regions may use plsqlFunctionBody for rendering HTML/CLOB; they must not perform DML or manage transactions.
+
+## Linking Patterns
+- Interactive Report row links must use #COLUMN# substitution in link targets (see region-components/interactive-report/interactive-report._common.md).
+- Cards and content-row regions must use &COLUMN. substitution and define navigation in an action block as shown in the corresponding template.
+- For Classic Report, Interactive Report, and Interactive Grid navigation, ask every time which link mode is required:
+  - same application page
+  - another application page
+  - URL redirect
+- When the chosen mode is same application page and the component DSL supports it, use declarative page-target syntax instead of `type: url`, `f?p=...`, or SQL-computed `apex_page.get_url(...)`.
+- Do not mix syntaxes and avoid trailing backslashes in URLs. Always mirror the template’s pattern.
+
+## Page Alias Convention
+- Page aliases should match the descriptive portion of the filename after the page number.
+- Examples:
+  - p00001-home.apx → alias: HOME
+  - p00002-leads-report.apx → alias: LEADS-REPORT
+  - p00003-leads-form.apx → alias: LEADS-FORM
+
+## Shared Layout Contract
+- Apply `30-pages/apex.layout.md` before choosing region coordinates.
+- Treat each layout scope independently: page slot rows, nested `parentRegion` rows, item rows by `layout.region + layout.slot`, and button rows by `layout.region + layout.slot`.
+- For equal-width siblings in any scope, use implicit flow:
+  - first component in the row: omit `startNewRow`
+  - second and later siblings: `startNewRow: false`
+  - omit `column` and `columnSpan`
+- Each scope gets its own 12-column budget; child spans do not subtract from the parent row budget.
+- Use explicit `column` / `columnSpan` only for intentionally asymmetric layouts such as sidebar-main, faceted-search, or parent-child split pages.
+
+## Cards Region Standards (Non‑Negotiable)
+- For regions with type: cards:
+  - Set appearance.template: cards-container on the Cards region.
+  - Do not use @/cards; always use @/cards-container.
+  - Use only cards attributes validated by the current compiler contract.
+  - `componentAppearance.gridColumns` is optional and may be set only to `2`, `3`, `4`, or `5` when a fixed cards grid is required.
+  - Omit `componentAppearance.gridColumns` when cards should auto-determine the column count.
+  - When `title.htmlExpression`, `subtitle.htmlExpression`, `body.htmlExpression`, or `secondaryBody.htmlExpression` is emitted, set that same block's `advancedFormatting: true`.
+  - Inside cards `title.htmlExpression`, `subtitle.htmlExpression`, `body.htmlExpression`, and `secondaryBody.htmlExpression`, use `&COLUMN.` substitution strings, not `#COLUMN#`. Prefer escaped substitutions such as `&COLUMN!HTML.` for text values.
+  - Do not emit report-style pagination or inferred card key properties unless parser-confirmed.
+  - Do not emit `performance.maxRowsToProcess` for cards regions unless the cards DSL contract explicitly allows it.
+  - Card action links must use &EDIT_LINK (never #EDIT_LINK#).
+  - The region SQL must compute EDIT_LINK using apex_page.get_url and expose it:
+    ```sql
+    apex_page.get_url(
+      p_page   => :TARGET_PAGE,
+      p_items  => :TARGET_ITEMS,
+      p_values => :TARGET_VALUES
+    ) as EDIT_LINK
+    ```
+  - Set action.behavior.target: &EDIT_LINK
+
+## Content Row and Template Components
+- Use template components under templates/template-components/* when building cards/content-row style regions.
+- Default content-row page/region generation must start from `content-row.report-minimal.md` unless the prompt requests a richer scenario.
+- Define explicit column objects for every column present in the SQL select list; names should match the SQL columns exactly (typically uppercase).
+- For report-mode Content Row explicit columns, use `source.databaseColumn`; do not use `source.databaseCol`.
+- For Content Row, enable avatar rendering with `settings.displayAvatar`.
+- For Content Row, keep `plugin-avatar` configuration-only; use it for `type`, `icon`, `initials`, `description`, `shape`, `size`, and `cssClasses`, not for display toggles.
+- For Content Row, enable badge rendering with `settings.displayBadge`.
+- For Content Row, keep `plugin-badge` configuration-only; use it for `label`, `value`, `state`, `icon`, `displayLabel`, `style`, `shape`, `size`, `position`, and `columnWidth`, not for display toggles.
+- For Content Row, badge scenarios use `settings.displayBadge` for visibility and `plugin-badge` for configuration fields such as `label`, `value`, `state`, `icon`, `displayLabel`, `style`, `shape`, `size`, and `position`.
+- For Metric Card, do not assume the Content Row helper placement applies. Use `plugin-avatar.displayAvatar` plus `plugin-avatar` configuration for proven avatar scenarios, and use `plugin-badge.displayBadge` plus `plugin-badge` configuration for proven badge scenarios. Still omit Metric Card `settings.displayAvatar` and `settings.displayBadge`.
+- Provide an action block for row-level navigation in the position expected by the template; `behavior.targetUrl` parameters must use &COLUMN. substitution for these region types.
+- For master-detail parent selection, use a Content Row `action ... (` with `position: fullRowLink` to set the same-page hidden context item from the parent PK, for example `P{page}_{PK}: &PK.`.
+- Do not create a visible page-item selector as the primary parent selector when a Content Row master list is present; keep the context page item hidden unless manual selection is explicitly requested.
+- Place related create/edit/detail buttons in the child report toolbar slot when the child region is an Interactive Report.
+- Action components use parentheses and must close with `)` after nested blocks.
+- Mirror the template’s formatting for attributes like htmlExpression and appearance/templateOptions; do not invent alternative literal forms.
+
+## Example
+```plaintext
+File: p00012.apx
+Navigation List: shared-components/lists.apx → “Employee Directory”
+Breadcrumbs: shared-components/breadcrumbs.apx → “Home > Employees”

package/skills/apexlang/references/policies/memory-bank/30-pages/apex.report-column-rendering.md

@@ -0,0 +1,58 @@
+# Report Column Rendering Standards
+
+## Purpose
+- Define one canonical contract for presentation markup in report columns across Classic Report, Interactive Report, and Interactive Grid.
+- Keep SQL/PLSQL data-focused and move UI markup to report-column formatting attributes supported by the active compiler contract.
+
+## Scope
+- Applies to:
+  - Classic Report columns
+  - Interactive Report columns
+  - Interactive Grid columns
+- Applies when report source is SQL/PLSQL and when column output needs visual emphasis (status badges, highlighted amounts, icons, chips, etc.).
+
+## Report Column Shape Matrix
+
+| Family | Query-position metadata | Column `type` | Heading behavior | Source metadata | Link/navigation shape |
+|--------|-------------------------|---------------|------------------|-----------------|-----------------------|
+| Classic Report | Emit `reportColumnQueryId` and `derivedColumn`. | Omit for default text; emit `type: link` when the column owns `link {}`. | Visible columns emit `heading`; hidden columns omit `heading`. | Do not emit column `source {}`. | Column-level `link { target, linkText, linkAttributes }`; use `#COLUMN#` for row values. |
+| Interactive Report | Do not emit `reportColumnQueryId` or `derivedColumn`. | Emit Interactive Report types such as `plainText` or `hidden`; do not copy Classic `type: link` unless compiler metadata proves it valid. | Every column emits `heading { heading: ... }`, including hidden columns. | Emit `source { dataType: ... }` when provided/required. | Column-level `link { target, linkText, linkAttributes }` when supported; use `#COLUMN#` for row values. |
+| Interactive Grid | Do not emit Classic query-position metadata. | Emit grid item types such as `textField`, `numberField`, or `datePicker`; do not emit `type: link`. | Heading is optional and follows grid column metadata. | Emit supported `source` fields such as `databaseColumn`, `dataType`, and `primaryKey`. | Do not copy Classic/IR column-link syntax; grid navigation is compiler-gated and saved-report `displayColumn` metadata is not navigation metadata. |
+
+## Rules (Non-Negotiable)
+1. SQL/PLSQL source must remain data-only.
+   - Do not emit HTML literals/tags in SQL/PLSQL used for report rendering.
+2. For compiler contract `mmdVersion 26.1.053`, emit column markup only inside `columnFormatting.htmlExpression`.
+   - Do not emit top-level `column ... htmlExpression: ...`.
+3. When using `columnFormatting.htmlExpression`, keep the column as plain text rendering.
+   - Do not emit `type: richText` for this pattern.
+   - Do not emit `type: plainText` unless explicitly required; plain text is the implicit default.
+4. Keep rendering logic declarative and column-scoped; do not push UI rendering into SQL projections.
+
+## Canonical Rendering Shape
+```apexlang
+column SOME_COL (
+  ...
+  columnFormatting {
+    htmlExpression: <span class="t-Badge">#SOME_COL#</span>
+  }
+)
+```
+
+## Fallback Behavior
+- If the requested report type or runtime contract does not support column-level markup rendering:
+  - keep SQL data-only,
+  - render plain text/non-HTML output,
+  - log a critique finding describing unsupported rendering capability,
+  - do not emit unsupported attributes.
+
+## Prohibited Patterns
+- Top-level `htmlExpression` directly under report `column (...)`.
+- `type: richText` on columns that use `columnFormatting.htmlExpression`.
+- HTML literals in report SQL/PLSQL source.
+- Region-specific ad-hoc rendering attributes not present in the active component contract.
+
+## References
+- `references/policies/memory-bank/00-guard/ai.guard.md`
+- `references/policies/memory-bank/20-data/apex.sql.md`
+- `assets/component-attributes.json`