oracle-apex-export

Oracle APEX Export

Export supported Oracle APEX applications from 24.2 onward and application-schema database source with an explicit publication intent.

Before Exporting

1. Read repository instructions and .oracle-apex-ai/project-profile.md.
2. Read .oracle-apex-ai/export-policy.json when present.
3. Confirm the configured SQLcl connection by checking the expected USER and SERVICE_NAME, then confirm app ID, workspace, schema owner, and destination paths.
4. Confirm the live APEX version and run validate_oracle_apex_compatibility.py; stop below 24.2.
5. Inspect current Git status and existing versioned artifacts.
6. Determine the mode from export-modes.md.
7. Confirm whether official repository publication was explicitly requested.

Do not infer official export authorization from a development, diagnosis, compile, or test request.

Modes

• temporary-inspection: disposable read-only APEX export outside official folders.
• initial-baseline: first complete APEX export plus full application-schema structural DDL.
• application-snapshot: complete official APEX application export only.
• release: complete official APEX application export plus a full or partial five-file database bundle and pending DDL/DML.
• builder-fallback: manual App Builder download when the project permits it and SQLcl export is unavailable.

Read export-modes.md for entry and exit criteria.

APEX Export Contract

For official APEX exports:

• use the app ID and export options from the project profile;
• export to a candidate directory first;
• prefer a split source tree containing install.sql and application/;
• include readable/ only on supported APEX releases before 26.1;
• on APEX 26.1 or later, do not request READABLE_YAML, because Oracle produces APEXlang instead;
• include a monolithic f<APP_ID>.sql when the project requires it;
• do not assume a split export also creates the monolithic file; run the project-approved non-split application export when both forms are required;
• treat split SQL, the version-allowed readable YAML, and the monolithic file as one atomic application snapshot;
• reject .apx, APEXlang directories, and APEXlang generate/export/validate/import commands in every version;
• make the Supporting Objects decision explicit;
• validate candidate structure and content before replacing the official snapshot;
• compare the diff to the requested application and scope;
• keep secrets, credentials, and environment-specific substitutions out of public artifacts.