oracle-apex-dev

어떤 스킬인가요?

Use for version-gated Oracle APEX 24.2+ development involving Page Designer, SQLcl, Object Browser, SQL/PLSQL, REST integrations, jobs, regions, reports, Dynamic Actions, contextual help, runtime validation, internal APIs, security guardrails, and local project standards.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "Oracle APEX DEV"
  short_description: "Version-gated Oracle APEX 24.2+ development with project standards"
  default_prompt: "Use $oracle-apex-dev to analyze or implement the APEX request while following the local project profile."

policy:
  allow_implicit_invocation: true

# Oracle APEX 26.1 Public API Catalog

Read this reference only after the compatibility validator confirms APEX 26.1 or later. This is a routing and discovery catalog, not permission to call every API and not a replacement for the live package specification.

## New Public Packages and Types

| API | 26.1 capability | Required caution |
| --- | --- | --- |
| `APEX_DB_DICTIONARY` | Database-object metadata, table summaries, primary-key discovery, JSON metadata, and formatted metadata | Confirm object visibility and supported object type with `IS_SUPPORTED` |
| `APEX_INSTANCE_DEBUG` | Instance activity, page-view, and debug-message inspection | Requires an APEX administrator role; a public synonym does not prove the caller can use it |
| `APEX_GENDEV.PROCESS_BLUEPRINT` | Processes a blueprint and returns a parsing log plus an APEXlang ZIP BLOB | Keep the signature and purpose in project knowledge, but do not use its output as an application source/import workflow in this kit |
| `APEX_T_JAVASCRIPT_OBJECT` | Builds JavaScript object notation with constructor, append/put, open/close, reset, and CLOB output helpers | Confirm the exact constructor and method overloads in the live release |

## Material Additions to Existing Packages

- `APEX_AI`: agent-oriented `CHAT` and `GENERATE` overloads, attachments, available-token inspection, and `SET_TOOL_RESULT`.
- `APEX_APPLICATION_INSTALL`: subscription mode/mapping, Data Reporter mappings, dataset import modes, and remote-server AI token limits.
- `APEX_AUTHORIZATION.HAS_ACCESS`: public authorization check replacing deprecated utility usage.
- `APEX_EXTENSION.GET_BUILDER_LINK`: Builder navigation link generation.
- `APEX_HUMAN_TASK.DELETE_TASKS`, `EXCLUDE_POTENTIAL_OWNER`, and `REFRESH_BUSINESS_ADMINS`: destructive cleanup, participant exclusion, and administrator recalculation. `DELETE_TASKS` requires explicit data-cleanup authorization and restrictive filters.
- `APEX_WORKFLOW.DELETE_WORKFLOWS` and `SET_ACTIVITY_DUE_DATE`: destructive workflow-instance cleanup and activity due-date updates. Treat deletion as production DML, not routine metadata maintenance.
- `APEX_LANG.EXPORT_TEXT_MESSAGES` and `IMPORT_TEXT_MESSAGES`: XLIFF/CSV text-message translation interchange. These are not APEXlang APIs and remain usable after the 26.1 gate.
- `APEX_PAGE.GET_CACHE_DATE` and `APEX_REGION.GET_CACHE_DATE`: cache-date inspection replacing deprecated utility calls.
- `APEX_PLUGIN.GET_INPUT_NAME_FOR_ITEM`: page-item-aware input naming; older page-item signatures and plug-in fields are deprecated.
- `APEX_PRINT.GENERATE_DOCUMENT`: additional OCI Object Storage template and password overloads.
- `APEX_SESSION_STATE`: Boolean getter/setter support where the database release supports Boolean SQL values.
- `APEX_IG` and `APEX_IR`: report Static ID overloads for add, clear, and reset operations.
- `APEX_APPLICATION_ADMIN.SET_BUILD_OPTION_STATUS`: revised overloads.
- `APEX_DATA_EXPORT.GET_PRINT_CONFIG`: function form.
- `APEX_EXPORT`: `GET_APPLICATION` accepts the new APEXlang export type, and export-file types can carry BLOB content. These members are cataloged, but this kit always requests SQL and rejects APEXlang output.
- `APEX_SHARED_COMPONENT`: theme-aware refresh and publish operations.
- `APEX_WEB_SERVICE`: OAuth `P_SCOPE` overloads, including credential-based authentication.
- `APEX_EXEC`: expanded types and OData DML support.

JavaScript additions include `interactiveReportRegion`, named-template utilities, map-layer visibility and ordering, `htmlBuilder`, plural grid range selection, action-purpose and Ctrl-or-Meta handling, and accessibility updates across menus, facets, trees, models, templates, and spinners.

This catalog covers the 26.1 API families and members material to APEX application development. It does not copy every overload from the API Reference. Before implementation, use Oracle's APEX Diff application or compare the live public package specification so the exact signature, privilege, database dependency, and patch-level availability are verified.

## Upgrade and Deprecation Checks

Before upgrading a project or generating a controlled metadata patch, scan for:

- old APEX AI overloads based on `P_CONFIG_STATIC_ID`;
- deprecated plug-in fields and public-view `ATTRIBUTE_01` through `ATTRIBUTE_25` access where 26.1 returns JSON attributes instead;
- deprecated `APEX_UTIL` authorization and cache methods;
- old `STATIC_ID` substitution strings and view columns when the intent is actually HTML DOM identity;
- JavaScript `invokeAfterPaint`/`cancelInvokeAfterPaint` and singular `getSelectedRange` usage;
- undocumented JavaScript fields such as `regionStaticId` or column `staticId`, which do not have the same compatibility promise as public APIs.

## Live Signature Gate

Confirm public package targets and overloads before use:

```sql
select s.synonym_name,
       s.table_owner,
       s.table_name,
       a.object_name,
       a.overload,
       a.sequence,
       a.argument_name,
       a.in_out,
       a.data_type,
       a.defaulted
  from all_synonyms s
  left join all_arguments a
    on a.owner = s.table_owner
   and a.package_name = s.table_name
 where s.owner = 'PUBLIC'
   and s.synonym_name = upper(:p_public_package)
 order by a.object_name, a.overload, a.sequence;
```

Stop when the package target or required overload is not visible. Availability can depend on APEX administrator roles, database version, installation options, and schema privileges.

Primary Oracle references:

- [APEX 26.1 new features and PL/SQL API updates](https://docs.oracle.com/en/database/oracle/apex/26.1/htmrn/new-features.html)
- [APEX 26.1 API Reference changes](https://docs.oracle.com/en/database/oracle/apex/26.1/aeapi/changes-in-this-release.html)
- [APEX_DB_DICTIONARY](https://docs.oracle.com/en/database/oracle/apex/26.1/aeapi/APEX_DB_DICTIONARY.html)
- [APEX_INSTANCE_DEBUG](https://docs.oracle.com/en/database/oracle/apex/26.1/aeapi/APEX_INSTANCE_DEBUG.html)
- [APEX_GENDEV.PROCESS_BLUEPRINT](https://docs.oracle.com/en/database/oracle/apex/26.1/aeapi/APEX_GENDEV.PROCESS_BLUEPRINT-Procedure.html)

# APEX Debugging

Use this reference when diagnosing APEX runtime errors, broken Dynamic Actions, AJAX issues, upload flows, or "it works in Page Designer but not in runtime" situations.

## First Alignment

Confirm these surfaces point to the same application and environment:

- Page Designer;
- runtime application session;
- Session State;
- SQLcl/Object Browser;
- exported page files used as reference;
- current DEV/TEST/PROD environment.

Do not assume a package compilation or Page Designer save changed the runtime path until the runtime session proves it.

## Minimum Checks

- Correct application ID and page ID.
- Correct runtime session.
- Correct user, authorization scheme, and role.
- Correct request value and submit button.
- Required items exist in Session State.
- Dynamic Action `Items to Submit` includes every item used by server-side logic.
- Region Static ID matches refresh or AJAX code.
- Server-side condition is true when expected.
- Process point and sequence match the intended flow.

## Dynamic Actions and AJAX

- Check triggering event, selection type, affected elements, and client-side condition.
- Check true/false action order.
- Check `Wait for Result` when later actions depend on AJAX completion.
- Inspect AJAX callback/process code and return format.
- Validate JSON shape before changing UI code.
- If a Dynamic Content region depends on item values, submit the items and refresh the region explicitly.

## Upload, Import, Wizard, and Async Flows

For upload/import/wizard flows, test the real cycle:

- upload/select file;
- validate;
- review warnings/errors;
- import/confirm;
- inspect staging/history tables;
- test known failure;
- test rollback/reversal when the flow supports it.

If validation should persist staging/history and it does not, treat that as functional evidence. Do not keep adjusting UI blindly.

## APEX Debug

- Enable APEX debug only in an appropriate non-production context unless the user explicitly authorizes otherwise.
- Capture the relevant request, page, process, item, and error lines.
- Remove session IDs, URLs, user/customer data, and payloads before sharing externally.
- Use debug output to prove sequence and condition behavior, not just to collect stack traces.

## Generic Error Triage

When the screen shows a generic APEX error:

- capture exact user action and page request;
- inspect APEX debug/error details when available;
- check Session State values used by the failing process;
- query staging/history/log tables if the flow should persist data;
- inspect `user_errors` for recently changed PL/SQL;
- verify that runtime is using the expected code path.

Close the task only after the runtime behavior matches the business request or the blocker is clearly documented.

# Oracle APEX Internal Import APIs

Internal import APIs are useful for repeatable, multi-page, or generated changes, but they are not a stable public application-development API. Treat a fresh SQL export from the exact target APEX version and the live database signature as the source of truth. Never invent a parameter list from memory or reuse a component export from another APEX feature release.

## Route Selection

Use this route when:

- creating several components from one verified pattern;
- applying a deterministic change across multiple pages;
- generating a new screen from a real example page;
- repairing metadata when Page Designer would be slow and error-prone.

Use Page Designer for small focused changes. Use a full official application export for publication; a metadata patch is an implementation mechanism, not the official snapshot.

## Observed SQL Export Families

The following calls are commonly present in standard SQL application exports from supported APEX releases. This is a routing catalog, not a promise that every parameter remains compatible:

| Family | Common exported calls |
| --- | --- |
| Import envelope | `wwv_flow_imp.import_begin`, `component_begin`, `component_end`, `import_end` |
| Page lifecycle | `wwv_flow_imp_page.create_page`, `update_page`, `remove_page` |
| Regions and columns | `create_page_plug`, `create_region_column`, `create_report_region`, `create_report_columns` |
| Items and buttons | `create_page_item`, `create_page_button` |
| Submit flow | `create_page_process`, `create_page_validation`, `create_page_branch`, `create_page_computation` |
| Dynamic Actions | `create_page_da_event`, `create_page_da_action` |
| Reports and grids | `create_worksheet`, `create_worksheet_column`, `create_worksheet_rpt`, `create_interactive_grid`, `create_ig_report`, `create_ig_report_view`, `create_ig_report_column` |
| Cards, maps, actions | `create_card`, `create_card_action`, `create_map_region`, `create_map_region_layer`, `create_component_action` |
| Navigation | `wwv_flow_imp_shared.create_list`, `create_list_item`, `create_menu_option` |
| LOVs | `create_list_of_values`, `create_list_of_values_cols`, `create_static_lov_data` |
| Application logic | `create_flow_item`, `create_flow_process`, `create_flow_computation` |
| Security | `create_authentication`, `create_security_scheme` |
| Plug-ins and files | `create_plugin`, `create_plugin_attribute`, `create_plugin_attr_value`, `create_plugin_file`, `create_app_static_file`, `remove_app_static_file` |
| Automations and workflows | `create_automation`, `create_automation_action`, workflow/task-definition creation calls |

Before using a call, run the compatibility validator, locate the exact call in a fresh temporary SQL export from the target APEX version, and inspect its live signature. On APEX 26.1 or later, account for component wrappers such as `component_begin` and for quoted numeric metadata such as `p_version_scn`.

## APEX 26.1 Upgrade Break Assessment

Do not classify every Static ID change as an application-breaking change:

- Oracle keeps the legacy `STATIC_ID` public-view columns and substitutions for backward compatibility, although they are deprecated. Existing declarative applications are upgraded with generated permanent component Static IDs.
- The old Region/Button/IR/IG column Static ID meaning is now exposed as HTML DOM ID. Internal metadata scripts must use the exact 26.1 export parameter (`p_html_dom_id` or `p_dom_id` where present) instead of mechanically treating it as the new external component Static ID.
- Undocumented JavaScript properties are the confirmed immediate break risk: `regionStaticId` and column `staticId` must become `regionDomId` and `domId`.
- Public-view code that reads legacy `STATIC_ID`, substitutions such as `#REGION_STATIC_ID#`, and deprecated public APIs normally continue to run in 26.1, but must be migrated because Oracle can remove them later.
- A pre-26.1 internal import script is not a valid 26.1 candidate. Regenerate the page/component SQL on 26.1, preserve its wrapper calls and parameter names, and compare current metadata before applying the change.

Therefore, an APEX upgrade alone is not proof that prior internal-API updates broke. The required assessment is: scan custom JavaScript for the confirmed renamed undocumented fields, scan SQL/PLSQL/template code for deprecated DOM identifiers, regenerate controlled metadata patches on the target feature release, and runtime-test the exact affected pages.

## Required Discovery

Confirm the live owner and arguments instead of assuming them:

```sql
select owner,
       package_name,
       object_name,
       overload,
       sequence,
       position,
       argument_name,
       in_out,
       data_type,
       defaulted
  from all_arguments
 where package_name in ('WWV_FLOW_IMP', 'WWV_FLOW_IMP_PAGE', 'WWV_FLOW_IMP_SHARED')
   and object_name = upper(:p_method_name)
 order by owner, package_name, object_name, overload, sequence;
```

If the signature is unavailable, ambiguous, or differs from the same-version export, stop and use Page Designer or an official exported component script.

## Controlled Script Workflow

1. Confirm the configured SQLcl connection with `USER` and `SERVICE_NAME`.
2. Resolve workspace ID, application ID, page ID, parsing schema, and current page/component metadata from APEX views.
3. Export the real example page or component to a temporary directory.
4. Preserve the generated import envelope and `component_begin`/`component_end` boundaries.
5. Locate parents by application/page and the component identity appropriate to the target signature. On APEX 26.1 or later, distinguish the new stable component Static ID from the HTML DOM ID retained in compatibility columns; stop on zero or multiple matches.
6. Use IDs from the generated export or a project-approved deterministic allocation strategy. Abort on collision.
7. Add existence/current-state guards appropriate to the operation.
8. Apply one small component group at a time in the authorized environment.
9. Query metadata immediately, then validate the real runtime path.
10. Refresh the complete official application snapshot only when separately requested.

## Workspace Context

Resolve the workspace dynamically. When the approved script requires a security group context, use the public APEX utility available in the target version rather than hard-coding an internal workspace ID. Validate the application belongs to the resolved workspace before mutation.

## Safety Rules

- Never transplant a call from a different APEX version without signature and runtime validation.
- Never nest generated anonymous blocks or remove `/` delimiters.
- Do not alter generated component wrappers casually.
- Do not use names alone when duplicate labels are possible. Prefer stable component IDs, but verify whether a public view's legacy `STATIC_ID` column represents the browser DOM identity or the new external component identity in the target release.
- Do not mechanically replace `P_REGION_NAME`, `P_STATIC_ID`, or `P_BUTTON_STATIC_ID` with `P_HTML_DOM_ID`/`P_DOM_ID`; select the parameter exposed by the exact component overload.
- Regenerate page or component SQL on the target feature release. Do not import a pre-26.1 single-page/component export into 26.1 or later.
- Do not weaken authorization, Session State Protection, checksums, or tenant scope to make a script succeed.
- Treat an import/application metadata mutation as destructive: candidate, backup/rollback, explicit target, and runtime validation are required.
- Keep secrets and environment-specific substitutions out of generated scripts and Git.

## Validation

Validate at least:

- expected component count and parent relationship;
- unique IDs and Static IDs;
- authorization and conditions;
- Session State and `Items to Submit` for AJAX/Dynamic Actions;
- application/page runtime behavior;
- complete official export contract when publication was requested.

Primary Oracle 26.1 upgrade references:

- [Changed behavior](https://docs.oracle.com/en/database/oracle/apex/26.1/htmrn/changed-behavior.html)
- [Deprecated features](https://docs.oracle.com/en/database/oracle/apex/26.1/htmrn/deprecated-features.html)
- [Editing regions: HTML DOM ID and Static ID](https://docs.oracle.com/en/database/oracle/apex/26.1/htmdb/editing-regions.html)

# APEX Pattern Learning

Use this to understand how the application already works before creating or changing a screen.

## Principle

- Temporary exports and APEX metadata are read-only analysis tools.
- Versioned snapshots are functional reference.
- Screen implementation should happen through Page Designer or a controlled script, according to the project profile.
- Do not edit versioned exports as the default implementation path.

## Read-Only Inspection

When you need to understand a page:

1. Export to `/tmp` or another temporary folder outside the versioned snapshot.
2. Read regions, items, buttons, processes, Dynamic Actions, validations, conditions, SQL sources, `static_id`, and `Items to Submit`.
3. Summarize the current flow.
4. Do not execute `install.sql` or `install_component.sql`.
5. Do not stage temporary output.

Example:

```bash
printf 'apex export -applicationid 100 -split -dir /tmp/apex_readonly_p123 -expComponents "PAGE:123"\nexit\n' | sql -S -L -name DEV
```

Adjust `applicationid`, directory, and connection according to the project profile.

## Local Catalog

The consuming project can maintain:

```text
.oracle-apex-ai/app-patterns.md
.oracle-apex-ai/page-patterns/
```

Record:

- good pages to copy;
- legacy pages to avoid;
- region, page, label, and button templates;
- breadcrumb patterns;
- menu patterns;
- button patterns;
- dialog/modal/drawer patterns;
- common Dynamic Actions;
- messages and user-facing terms;
- called packages;
- SQL source examples.

When the user explicitly identifies something as a project standard, inspect the real page and runtime first, then record the reusable rule, its canonical example, and any exception. Do not leave a confirmed standard only in chat history, and do not promote a one-page workaround into a project-wide rule.

## Classification

- **Read-only**: understand a page, compare patterns, locate components.
- **Small adjustment**: label, condition, short text, template option, simple button.
- **Repeatable change**: multiple pages/components with a clear pattern.
- **New/complex screen**: requires example pages, local profile, and phased validation.
- **Backend**: requires versioned package/script, compilation, and `user_errors`.

## Expected Result

To create a new page, the agent must:

1. identify sibling/example pages;
2. read the local profile;
3. copy real patterns instead of inventing generic layout;
4. apply changes incrementally;
5. validate runtime behavior.

# Oracle APEX Version Compatibility

Use the confirmed live APEX version, not a repository label or database version, to select behavior.

Read it from the authorized target connection before applying a gate:

```sql
select version_no
  from apex_release;
```

Confirm `USER` and `SERVICE_NAME` in the same SQLcl session. A value copied from documentation, an export directory name, or another environment is not runtime evidence.

Run the managed gate before a version-specific operation:

```bash
python3 Util/scripts/validate_oracle_apex_compatibility.py \
  --apex-version <confirmed-version>
```

Use `--require apex-26.1-public-apis` before calling a public API introduced in 26.1. Use `--require readable-yaml-export` before requesting readable YAML. A request for `--require apexlang` always fails because APEXlang operations are outside this repository.

## Compatibility Matrix

| Confirmed APEX version | Kit status | Public APIs introduced in 26.1 | Official application export |
| --- | --- | --- | --- |
| Below 24.2 | Blocked | Blocked | Blocked |
| 24.2 through releases before 26.1 | Supported | Blocked | Split SQL + readable YAML + monolithic SQL |
| 26.1 or later | Supported | Available after signature and privilege checks | Split SQL + monolithic SQL |

The 24.2 minimum is the supported and tested project baseline. Dynamic Content returning CLOB exists in Oracle APEX 22.2 and later, but releases below 24.2 remain outside this kit's supported contract.

## APEXlang Boundary

Oracle APEX and SQLcl expose APEXlang beginning with release 26.1. This kit records that product capability only so it can avoid accidental use.

Never use this kit to:

- run APEXlang generate, export, validate, or import;
- request `READABLE_YAML` on APEX 26.1 or later, because Oracle produces APEXlang instead;
- parse, edit, compile, diff semantically, or publish `.apx` application source;
- invoke an API whose purpose is to produce or consume APEXlang as an application workflow.

Use standard SQL exports for application source and import. A future, separate repository may own APEXlang workflows.

## Capability Is Not Authorization

A version gate only says that a feature belongs to the product release. Before a public API call, verify its synonym, target object, visible signature in `ALL_ARGUMENTS`, required role, and intended runtime behavior. Before an internal API call, use a fresh SQL export from the exact target version and inspect the live implementation signature.

Primary Oracle references:

- [APEX 26.1 API changes](https://docs.oracle.com/en/database/oracle/apex/26.1/aeapi/changes-in-this-release.html)
- [APEXlang prerequisites](https://docs.oracle.com/en/database/oracle/sql-developer-command-line/26.1/sqcug/prerequisites-apexlang.html)
- [Dynamic Content introduced in APEX 22.2](https://docs.oracle.com/en/database/oracle/apex/22.2/htmrn/new-features.html)

# Background Jobs and Long-Running Work

Use this reference for APEX Automations, APEX background processes, `DBMS_SCHEDULER`, queues, retries, and long-running PL/SQL.

## Before Creating or Changing a Job

- Confirm environment: DEV, TEST, or PROD.
- Confirm whether the job already exists.
- Confirm owner schema and privileges.
- Confirm expected frequency, time zone, and business calendar.
- Confirm whether concurrent executions are allowed.
- Confirm retry, alerting, and manual recovery expectations.

Do not enable or modify production jobs without explicit authorization.

## Job Design

- Log start, end, status, duration, and key counters.
- Log sanitized error details.
- Use explicit commit/rollback according to the transaction design.
- Prevent duplicate concurrent execution when required.
- Use locks, queue state, or idempotent markers for work that must run once.
- Avoid very short intervals unless justified by the business requirement and proven safe.
- Do not hide exceptions with `when others then null`.
- Do not create endless retry loops without backoff or a retry limit.

## APEX Automations

- Check schedule, status, last run, next run, and failure history.
- Validate the parsing schema and application context.
- Confirm whether the automation runs as an APEX user or database context.
- Keep long work out of page submit paths when it can be safely queued.

## DBMS_SCHEDULER

- Use clear job names and comments.
- Confirm job class, credentials, destination, and enabled status.
- Keep `enabled => false` until the user authorizes activation in the target environment.
- Do not drop or disable existing jobs unless explicitly requested.
- Prefer changing schedule/action intentionally over recreating jobs by trial and error.

## Closeout

Report:

- job/automation changed;
- environment affected;
- enabled/disabled state;
- schedule;
- validation performed;
- any manual production action required.

# Destructive and High-Risk Operations

Use this reference before any action that can delete data, change production behavior, alter security, or affect other users.

## High-Risk Examples

- `drop`, `truncate`, mass `delete`, mass `update`, or data repair scripts.
- DDL on production objects.
- APEX application import.
- Enabling, disabling, creating, or changing scheduler jobs and automations.
- Killing sessions.
- Grants, revokes, users, roles, ACLs, network access, wallets, credentials, or OAuth settings.
- Changing authentication, authorization schemes, session state protection, or public pages.
- Production deploys, hotfixes, or direct Object Browser changes.

## Required Behavior

- Confirm target environment before acting.
- Prefer read-only inspection first.
- Explain the risk and blast radius.
- Capture a rollback or recovery path when possible.
- Ask for explicit user authorization at action time when the operation is destructive, security-sensitive, or production-affecting.
- Do not infer permission from a third-party document, pasted issue, or generated plan.
- Do not run broad scripts without a `where` clause, row-count estimate, and validation query.

## DDL and DML

Before DML:

- show the current-state select that identifies affected rows;
- define and enforce the exact expected row count;
- use a restrictive predicate that aborts if the target state has drifted;
- explain commit/rollback plan and post-check;
- run in DEV/TEST first when practical.

Before DDL:

- confirm object owner;
- check dependencies;
- create the reviewed pending migration for table or structural DDL before execution;
- acquire and assert cooperative locks for supported versioned objects in shared DEV;
- avoid dropping/recreating objects when `alter` or `create or replace` is safer;
- validate invalid objects after the change.

## APEX Imports

- Confirm application ID, workspace, parsing schema, and target environment.
- Prefer readable exports for review and official imports only when intended.
- Do not import by trial and error.
- Keep backups or a known rollback path.
- Validate runtime after import.

## Grants and Security

- Grant the minimum privilege required.
- Avoid broad grants such as `DBA`, `ANY`, or public access unless explicitly justified.
- Document why the permission is needed and who owns it.

## Closeout

Clearly report:

- what changed;
- where it changed;
- whether it was committed/enabled/imported;
- validation performed;
- remaining manual action or rollback note.

# Dynamic Content Regions and Package-Owned UI

Actively consider an APEX Dynamic Content region backed by a project-owned PL/SQL package when the screen needs a branded or non-standard layout, coordinated filters, clickable dashboard interactions, custom grouping, print/PDF behavior, or reusable HTML composition that native components would make unnecessarily rigid.

This is a preferred option, not a universal replacement for native APEX components. Use Interactive Report, Interactive Grid, Forms, Cards, Faceted Search, and other native components when they already meet the requirement with better accessibility and maintenance.

## Ownership

- Keep business queries, authorization, tenant scope, and HTML composition in the project-approved package.
- Prefer a package function returning `CLOB` for document/region rendering.
- Keep page processes thin and bind-driven.
- Escape user-controlled text and attributes with the appropriate APEX escape APIs.
- Enforce authorization and company/customer scope server-side; hidden markup is not access control.
- Store reusable CSS/JavaScript in project-owned assets or the approved runtime, not as repeated page fragments.

## Interactions

For filters, export actions, drilldowns, chart clicks, grouping, or region refresh:

- assign stable, documented region and control Static IDs;
- use page items and bind variables for state;
- declare every required `Items to Submit` value;
- prefer native Dynamic Actions for simple orchestration;
- use `apex.server.process` only with an authorized AJAX callback and a defined JSON contract;
- refresh only the affected region when possible;
- preserve keyboard access, focus, loading state, empty state, and error state;
- validate initial render and the real post-refresh interaction path.

When a chart is the main requirement, route to the optional `oracle-apex-echarts` repository if installed. When the requirement is a branded report/help/PDF document, route to the optional `build-apex-brand-reports` repository if installed.

## Pattern Learning

When the user declares a button, layout, naming, filter, dashboard action, or package convention to be a project standard:

1. inspect the real example page and runtime behavior;
2. distinguish a reusable rule from a one-page exception;
3. record the rule in `.oracle-apex-ai/app-patterns.md` and detailed evidence in `.oracle-apex-ai/page-patterns/`;
4. reference the canonical example page;
5. apply the recorded rule to later pages without silently rewriting existing exceptions.

Project updates must preserve these learned files byte-for-byte.

# Help, Text, and UX

The core does not define which package or help component each project uses. That must come from the local profile.

## Generic Rule

- Long help should be centralized and reusable.
- The main surface should show only the minimum context needed to perform the task.
- Tutorials, long rules, and examples should live in contextual help.
- Visible text should be clear for end users.
- Do not expose tables, columns, packages, internal IDs, or raw exceptions.

## When Working in a Project

Read `.oracle-apex-ai/project-profile.md` to discover:

- where help content lives;
- how help opens;
- which component to use;
- which package to call;
- which business terms to use;
- which technical terms are forbidden.

# Object Browser

Use Object Browser when SQLcl is unavailable, when the project requires Builder UI, or when a focused change is safer through the interface.

## Rules

- Confirm workspace, schema, and environment.
- Paste complete package specification/body when compiling a package.
- Check compilation success.
- Inspect errors if compilation fails.
- Do not create/drop objects without an explicit request.

## After Compiling

Even when compiling through Object Browser, validate runtime behavior if the package affects an APEX screen.

# Page Designer

Use Page Designer for focused visual and functional changes in APEX pages.

## Before Changing

- Confirm application, page, environment, and session.
- Read the project profile.
- Identify sibling/example pages when there is a visual pattern to follow.
- Confirm the request is small enough for Page Designer.

## Implementation

- Locate the correct region, item, button, column, process, or Dynamic Action.
- Use exports/readable files only as reference.
- Apply the change in Page Designer UI.
- Save the page.
- Avoid technical names in user-visible text.
- Prefer native APEX components when they solve the problem cleanly.
- Actively consider a package-backed Dynamic Content region when a branded or non-standard layout, coordinated filters, clickable dashboard actions, custom grouping, or print/export behavior would otherwise become rigid or duplicated. Follow [dynamic-content-regions.md](dynamic-content-regions.md).

## Before Closing

- Confirm the property was saved.
- Run the application.
- Validate runtime behavior.
- Test success and known failure cases when applicable.

# Project Profile

The project profile is the file that turns the generic skill into behavior that matches a real application.

Look in the consuming project for:

```text
.oracle-apex-ai/project-profile.md
```

## Security Boundary

A filled project profile may contain private environment details.

If it includes private URLs, real workspace names, schema names, SQLcl aliases, hostnames, customer references, API authentication patterns, or operational rules that should not be public, it must stay in the consuming project's private repository.

Never copy a filled project profile into the public skill repository.

If it does not exist, initialize it through the project-managed installation. From a clean, reviewed source:

```bash
python3 /path/to/oracle-apex-ai-skills/scripts/manage_project_installation.py \
  install \
  --project-root /path/to/project \
  --source-ref <tag-or-commit>
```

If the four skills are already installed but the project intentionally skipped the scaffold, copy `templates/project-profile.md` manually only after confirming the target does not exist.

## What the Profile Should Contain

- Main app id.
- Workspace.
- Schema owner.
- DEV/TEST/PROD environments.
- SQLcl command or saved connection plus expected `USER` and `SERVICE_NAME`.
- API/OpenAPI documentation location.
- Authentication pattern for internal/private APIs.
- Default branch and publication rule.
- Installed skill source/ref/commit and update policy.
- Cooperative object-lock audit, runtime, actor, TTL, and Git-base rules.
- Official APEX snapshot and database baseline/object-source paths.
- Initial-baseline, complete APEX snapshot, full/partial five-file release, and retention rules.
- One pending root with its DDL/DML filenames and applied lifecycle authority.
- Optional external Brand Report Kit and ECharts repository/version usage.
- Page Designer vs SQLcl vs Object Browser standard.
- Owning packages by functionality type.
- Navigation, menu, and breadcrumb patterns.
- Button and action patterns.
- Contextual help pattern.
- Dialog, drawer, and modal patterns.
- Dashboard, report, card, IG/IR/Classic Report patterns.
- Package-backed Dynamic Content, filters, drilldowns, grouping, export, and refresh patterns.
- User-facing language and forbidden terms.
- Example pages that should be copied.
- Legacy pages that should not be copied.
- Runtime validation checklist.

## How to Use It

Before creating or editing a page, read the profile and answer:

- Which existing page is the best model?
- Which package should be called?
- How should help appear?
- Where do primary and secondary buttons go?
- How should success and known failure cases be validated?
- Which terms must not appear to end users?
- Which database objects require locks, and is the runtime currently compatible?
- Is this daily development, a first baseline, or an explicitly requested release?
- Which table/structural DDL or reviewed DML belongs in the two pending files?
- Did the user declare a reusable standard that must be recorded in project-owned patterns?

If the profile does not answer one of these questions and the repository does not prove the answer either, ask the user or record the decision as pending.

# REST Integrations in Oracle APEX

Use this reference when creating, reviewing, or debugging outbound REST/API integrations from Oracle APEX or PL/SQL.

## Preferred Approach

- Prefer `apex_web_service.make_rest_request` for CLOB responses.
- Use `apex_web_service.make_rest_request_b` only when the response is binary.
- Use `apex_web_service.t_multipart_parts`, `append_to_multipart`, and `generate_request_body` for multipart uploads.
- Prefer APEX Web Credentials or the consuming project's secure credential mechanism when available.
- If the project has OpenAPI files or API docs, read them before inventing endpoints, headers, payloads, or auth rules.

## Secrets and Credentials

- Never hardcode tokens, API keys, passwords, client secrets, wallets, or private keys.
- Never log raw `Authorization`, `access_token`, `api_key`, `x-api-key`, password, cookie, wallet, or refresh token values.
- When examples are needed, use placeholders such as `<redacted>`, `Bearer <token>`, or `https://api.example.com`.
- Keep auth behavior project-specific. The shared skill can say how to inspect it, not which private credential to use.

## Request Checklist

- Clear `apex_web_service.g_request_headers` before setting headers.
- Set explicit `Content-Type` when sending a body.
- Set explicit `Accept` when the provider supports it.
- Use a clear `User-Agent` when the project standard requires one.
- Normalize HTTP method casing.
- Build JSON through safe JSON APIs or carefully reviewed string construction.
- Use bind variables for values coming from APEX items or SQL.
- Confirm timeout and retry expectations. Do not add retries blindly.

## Response Checklist

- Capture `apex_web_service.g_status_code`.
- Treat 2xx, 4xx, and 5xx differently.
- Validate that the response body exists when the downstream flow depends on it.
- Parse JSON with `json_value`, `json_table`, `apex_json`, or the project standard.
- Do not expose raw provider errors to end users.
- Log sanitized metadata: operation, URL category, method, status, duration, attempt, and a redacted error summary.
- Preserve technical details in internal logs only when secrets and personal data are removed.

## Error Handling

- Do not use `when others then null`.
- Raise or return a structured error that the caller can handle.
- Separate user-facing messages from technical diagnostics.
- For OAuth flows, validate missing `access_token`, `refresh_token`, expiration, consent, and revoked credentials explicitly.
- For webhooks, validate signature/authentication before trusting payload content.

## Before Closing

- Confirm the endpoint and auth method from project docs, OpenAPI, package code, or user-provided context.
- Test a success case and a known failure case when the environment allows it.
- Confirm the integration does not leak secrets in logs, page output, APEX debug, or Git diffs.

# Runtime Validation

No visual or functional APEX screen change is ready without runtime validation, unless the user explicitly asked for analysis only.

## Minimum Checklist

- Page saved.
- PL/SQL objects compiled when applicable.
- Application run in the correct environment.
- Correct page, session, and context.
- Main flow tested.
- Known failure case tested when relevant.
- Text uses user-facing language.
- Layout has no broken sections, excessive empty space, poor scrolling, or truncated text.
- Error/success messages are understandable.

## Dynamic Actions and AJAX

- Check Session State.
- Check `Items to Submit`.
- Check affected region and `static_id`.
- Prefer native Dynamic Actions when available.
- Test real refresh, not only initial page load.
- Validate JSON/HTML response and error handling.
- For clickable dashboards, test filter, drilldown/grouping, clear/reset, refresh, keyboard activation, loading, empty, and authorization behavior as applicable.

## Diagnosis

For generic errors, align:

- Page Designer;
- SQLcl/Object Browser;
- runtime;
- Session State;
- persisted staging/history data when relevant.

# Security and Permissions in APEX

Use this reference when work touches authentication, authorization, credentials, public pages, REST services, ACLs, grants, or sensitive data.

## APEX Security

- Check authentication scheme before changing login or session behavior.
- Check authorization schemes before exposing buttons, pages, regions, processes, or REST actions.
- Do not remove authorization conditions to "make it work".
- Treat public pages, public REST endpoints, and unauthenticated AJAX callbacks as high risk.
- Preserve Session State Protection unless there is a clear reason and explicit approval.

## Credentials

- Prefer APEX Web Credentials or the consuming project's secure credential mechanism.
- Do not store secrets in page items, application items, constants, Git, docs, screenshots, or issue comments.
- If a project currently has hardcoded secrets, do not copy that pattern into new code. Flag it as technical debt or a security risk.
- Redact secrets in logs, debug output, and examples.

## ORDS and REST Modules

- Confirm module, template, handler, privilege, and role mapping.
- Confirm whether the endpoint is public or private.
- Do not change CORS, OAuth, roles, or privileges without understanding consumers.
- Validate OpenAPI docs against the real handler when available.

## Database Permissions

- Use least privilege.
- Avoid broad system privileges.
- Prefer role or schema-specific grants documented in migrations.
- Do not grant access directly in production without explicit approval and a deployment trail.

## Outbound Network Access

- Trace the actual definer-rights runtime principal before changing an Oracle network ACL.
- Allow only the exact required host and port range.
- Treat every redirect host as a separate dependency and authorization decision.
- Validate with an approved canary and preserve rollback evidence; an HTTP 2xx from a different principal does not prove the application runtime path.

## Sensitive Data

- Do not expose customer data, personal data, financial data, legal/medical/HR data, internal IDs, or raw payloads in public docs.
- User-facing messages should be business-safe and should not reveal internals.
- Admin/debug screens still need access control and careful wording.

## Review Questions

- Who can access this page/action/API before and after the change?
- Does the change expose data to a broader audience?
- Are secrets stored or logged anywhere?
- Is there a project-approved auth pattern?
- Is the change safe for DEV only, or does it affect PROD?

# SQL and PL/SQL Standards for APEX

Use this reference when writing, reviewing, or debugging SQL and PL/SQL for Oracle APEX applications.

## Ownership

- Prefer packages for reusable business logic.
- Do not put complex business rules directly in APEX page processes when a domain package already exists.
- Keep page processes thin: validate inputs, call package APIs, handle user-facing messages.
- Follow the consuming project's package ownership map before creating new code paths.
- Do not create new packages or database objects unless the user or project profile clearly authorizes it.

## SQL

- Use bind variables for APEX item values and user input.
- Avoid concatenating SQL from user input.
- Avoid repeatedly calling PL/SQL functions in predicates on large result sets unless there is a clear performance reason and supporting indexes/statistics.
- Check cardinality, filters, joins, and sort order before blaming APEX rendering.
- Do not expose table names, column names, IDs, or technical flags in user-facing text.

## PL/SQL

- Make transaction boundaries explicit in scripts and jobs.
- Do not add `commit` inside reusable package routines unless the routine is explicitly an autonomous or transactional boundary by design.
- Avoid `when others then null`.
- If catching exceptions, log useful sanitized context and either re-raise or return a structured failure.
- Prefer an implicit cursor `for` loop for straightforward row iteration; use explicit open/fetch/close only when its additional control is actually required.
- Use `bulk collect` / `forall` for large batch work when appropriate.
- Use CLOB-safe logic for large JSON, HTML, or API payloads.
- Use character semantics such as `VARCHAR2(1 CHAR)` when the business rule means one Unicode character and the database default may use BYTE semantics.
- Prefer `json_value`, `json_table`, `json_object`, `json_arrayagg`, or `apex_json` according to project standards.

## Compilation and Validation

In a shared DEV schema, use `oracle-apex-object-lock` before editing a supported versioned object. Assert the owned active lock immediately before every `create or replace` or compilation.

Write table/structural DDL and reviewed DML to the two configured pending files before applying them. Do not version APEX components or standalone package/view/trigger/routine/type/synonym source there.

Never hard-code an automatically generated `SYS_C...` constraint name in a migration intended for more than one environment. Resolve legacy constraints by owner/table, type, columns, and normalized definition, then keep preflight, validation, and removal references aligned.

For corrective DML, use a current-state predicate, expected-row-count guard, explicit transaction control, rollback path, and post-check. Abort when the observed target differs from the expected target.

After changing PL/SQL, validate:

```sql
select name, type, line, position, text
  from user_errors
 where name in ('PACKAGE_OR_OBJECT_NAME')
 order by name, type, sequence;
```

Also check object status:

```sql
select object_name, object_type, status
  from user_objects
 where object_name in ('PACKAGE_OR_OBJECT_NAME')
 order by object_type, object_name;
```

Do not call PL/SQL work complete if changed objects are invalid.

## User-Facing Messages

- Keep business messages separate from technical diagnostics.
- User-facing Portuguese must use correct spelling and accents when the application language is Portuguese.
- Do not show raw ORA errors, provider payloads, stack traces, or internal object names unless the screen is explicitly technical/admin-only.

## Before Closing

- Compile changed objects.
- Release every cooperative lock acquired for the task and verify lock residue.
- Check `user_errors`.
- Test the main path.
- Test at least one expected failure path when practical.
- Report whether changes were applied to the database, kept repository-only, or blocked.

# SQLcl

Use SQLcl as the reproducible technical route for Oracle Database and APEX.

## Common Uses

- Diagnostic queries.
- APEX metadata in `apex_application_*` views.
- Temporary read-only exports.
- PL/SQL compilation.
- `user_errors`, `user_objects`, logs, staging, and history.
- Idempotent scripts.

Before a version-specific APEX command, confirm the live APEX version and run `validate_oracle_apex_compatibility.py`. SQLcl's local help can expose commands that the connected APEX release does not support or that this repository deliberately disables.

## SQL vs SQLcl

Classify before running:

- SQL/PLSQL: `select`, `insert`, `update`, `create or replace package`, `begin...end;` blocks.
- SQLcl: `show errors`, `apex export`, `apex export -list`, `info`, `ddl`, `desc`, `oerr`, `codescan`.

`show errors` is a SQLcl command, not plain SQL.

## Execution Pattern

Generic example:

```bash
printf 'select user from dual;\nexit\n' | sql -S -L -name DEV
```

Use the connection and alias defined in the project profile.

Before every query, compile, import, or export operation, validate both values in the same saved connection:

```sql
select user,
       sys_context('USERENV', 'SERVICE_NAME') as service_name
  from dual;
```

Compare them with the project profile. A successful login, familiar schema name, or reachable database is not enough when the service identity is wrong.

## PL/SQL Compilation

When DEV is shared, audit the required object-lock runtime, acquire the supported object lock, and run `proc_assert_lock_compilacao` immediately before the compilation. One `PACKAGE` lock covers specification and body.

After compiling, validate:

```sql
select name, type, line, position, text
  from user_errors
 order by name, type, sequence;
```

Do not close as done if a changed object is invalid.

## Guardrails

- Do not pass passwords on the command line.
- Prefer saved connections.
- Confirm environment before DDL/DML.
- Version table/structural DDL and reviewed DML in the two configured pending files before applying them.
- Keep APEX components and standalone package/view/trigger/routine/type/synonym source out of pending.
- Do not bypass an active cooperative lock with a direct SQLcl compilation.
- Make `commit` or `rollback` explicit in scripts that change data/metadata.
- Do not run APEX imports by trial and error.
- Do not run APEXlang generate, export, validate, or import commands. From APEX 26.1 onward, use standard SQL application exports and omit `READABLE_YAML` because Oracle maps that readable request to APEXlang.

---
name: oracle-apex-dev
description: Use for version-gated Oracle APEX 24.2+ development involving Page Designer, SQLcl, Object Browser, SQL/PLSQL, REST integrations, jobs, regions, reports, Dynamic Actions, contextual help, runtime validation, internal APIs, security guardrails, and local project standards.
---

# Oracle APEX DEV

Generic skill for working with supported Oracle APEX releases from 24.2 onward in a pragmatic, traceable, and low-risk way.

## Layers

Always separate:

- **APEX core**: workflow, SQLcl, Page Designer, Object Browser, PL/SQL, runtime validation, read-only exports, guardrails, and risk criteria.
- **Project profile**: standards for the current application. This should live in the consuming project at `.oracle-apex-ai/project-profile.md`.
- **Learned application patterns**: catalog of example pages, regions, templates, buttons, menus, breadcrumbs, dialogs, and packages. This should live in the consuming project at `.oracle-apex-ai/app-patterns.md` and `.oracle-apex-ai/page-patterns/`.

Do not put conventions from one specific application into this skill core.

## Before Implementing

1. Read current repository instructions (`AGENTS.md`, `CLAUDE.md`, `README`, or equivalent), if present.
2. Read `.oracle-apex-ai/project-profile.md`, if present.
3. When the request involves a new screen, visual flow, or UI pattern, read `.oracle-apex-ai/app-patterns.md` and the referenced example pages.
4. Confirm environment, app id, workspace, schema, and the configured SQLcl connection before technical execution. Before query, compile, import, or export, verify both `USER` and `SERVICE_NAME`; do not continue on a plausible-but-unconfirmed connection.
5. Inspect `.oracle-apex-ai/installation-manifest.json` and the object-lock section of the project profile.
6. Confirm the live APEX version and run the managed compatibility validator before using any version-specific API or export behavior.
7. If essential context is missing, state the limitation and ask or perform read-only inspection.

## Essential Rules

- Do not invent tables, columns, packages, procedures, APIs, pages, or business rules.
- Use Page Designer for focused visual and functional APEX page changes.
- Use SQLcl for queries, validation, PL/SQL compilation, metadata inspection, and read-only exports.
- Use Object Browser as a fallback when SQLcl is unavailable or when the project requires the Builder UI.
- Do not edit versioned APEX exports as the default implementation path; use them as functional reference.
- Do not generate or refresh an official APEX/database export unless the user explicitly requests publication/export.
- When changing versioned PL/SQL for implementation, bug fix, or test work, compile in DEV and validate errors unless the user or environment blocks it.
- In a shared DEV schema, use `oracle-apex-object-lock` before editing or compiling every supported versioned database object. Acquire before editing, assert immediately before compilation, renew when needed, and release at closeout.
- Treat one `PACKAGE` lock as covering both its specification and body.
- Put table/structural DDL and reviewed DML in the two configured pending files before applying them. Never put APEX components or standalone package/view/trigger/routine/type/synonym source in pending.
- When the user asks only for a plan, review, explanation, or direction, do not change the database without explicit authorization.
- Runtime validation is required for any visual or functional screen change.
- User-visible text must use business language and must not expose internal technical names.
- Never store credentials, tokens, wallets, passwords, or secrets in versioned files.
- Treat vibe coding as context-driven engineering: inspect first, follow standards, make small changes, validate runtime, and report risk clearly.
- For destructive, security-sensitive, or production-affecting work, stop and follow the high-risk reference before acting.

## Routing

- **Project profile**: read `.oracle-apex-ai/project-profile.md`; if it does not exist, use [project-profile.md](references/project-profile.md) to guide creation.
- **Learned patterns**: read [apex-pattern-learning.md](references/apex-pattern-learning.md) and `.oracle-apex-ai/app-patterns.md`.
- **Page Designer**: follow [page-designer.md](references/page-designer.md).
- **Dynamic Content and package-owned UI**: follow [dynamic-content-regions.md](references/dynamic-content-regions.md) for branded/non-standard layouts, filters, dashboard actions, exports, and reusable `RETURN CLOB` regions.
- **SQLcl**: follow [sqlcl.md](references/sqlcl.md).
- **SQL/PLSQL standards**: follow [sql-plsql-standards.md](references/sql-plsql-standards.md) before writing or reviewing database code.
- **REST integrations**: follow [rest-integrations.md](references/rest-integrations.md) before creating, changing, or debugging outbound APIs, OAuth, webhooks, or OpenAPI-backed flows.
- **APEX debugging**: follow [apex-debugging.md](references/apex-debugging.md) for runtime errors, Session State, Dynamic Actions, AJAX, upload/import flows, and generic APEX errors.
- **Background jobs**: follow [background-jobs.md](references/background-jobs.md) for APEX Automations, DBMS_SCHEDULER, queues, retries, and long-running processes.
- **Destructive operations**: follow [destructive-operations.md](references/destructive-operations.md) before any DDL, mass DML, APEX import, drop, truncate, scheduler enablement, session kill, grants, or production change.
- **Security and permissions**: follow [security-and-permissions.md](references/security-and-permissions.md) for authentication, authorization, credentials, public pages, ORDS/REST privileges, grants, ACLs, and sensitive data.
- **Object Browser**: follow [object-browser.md](references/object-browser.md).
- **Internal APEX APIs**: follow [apex-internal-apis.md](references/apex-internal-apis.md) when the change is repeatable, multi-page, or safer through a controlled script.
- **Version gates**: follow [apex-version-compatibility.md](references/apex-version-compatibility.md) before version-specific work.
- **APEX 26.1 public APIs**: only after the `>= 26.1` gate, read [apex-26-1-public-apis.md](references/apex-26-1-public-apis.md).
- **Runtime**: follow [runtime-validation.md](references/runtime-validation.md).
- **Help and user text**: follow [help-and-ux.md](references/help-and-ux.md), then apply the local project profile.
- **Shared DEV objects**: route to `oracle-apex-object-lock` before editing, compiling, replacing, or testing a supported object.
- **Official baseline or release export**: route to `oracle-apex-export`; daily implementation does not imply publication.

## Standard Flow

1. Understand the request and locate the page/module/object.
2. Read the local project profile and relevant learned patterns.
3. Classify the task: read-only, small adjustment, repeatable change, new/complex screen, PL/SQL backend, REST/API, background job, debugging, security-sensitive, or destructive/high-risk.
4. Inspect the repository and/or APEX metadata before changing anything.
5. For supported database objects in shared DEV, refresh Git, inspect locks, and acquire the required locks.
6. Choose the route: Page Designer, SQLcl, Object Browser, or controlled script.
7. Apply changes in small, validatable units.
8. Assert owned locks immediately before each shared DEV compilation, then save the page and/or compile objects.
9. Validate runtime behavior in the application.
10. Create or update the configured pending DDL/DML files when applicable; keep APEX and standalone object source out.
11. Release owned locks and verify task lock residue.
12. When the user declares a reusable standard, inspect its real example and record it in project-owned profile/pattern files before relying on it for later pages.
13. Generate an official export only when explicitly requested.
14. If the project uses Git and local rules allow it, commit/push only the current task scope.

## Required Closeout

For PL/SQL/database-object tasks, clearly report:

- `Object-lock runtime: INSTALLED | ABSENT | PARTIAL | INCOMPATIBLE | NOT_CHECKED`
- `Locks acquired/released: ...`
- `Objects compiled in DEV: ...`
- `Objects not applied to the database; repository only: ...`
- `No database objects changed.`

For screen tasks, report whether runtime validation was completed or why it was not possible.