f100.sql is the APEX application export for the Customer Feedback demo app (application ID 100, workspace DEMO). The deploy workflow imports it via:

sql> apex import -applicationid 100 -workspacename DEMO -file apex/f100.sql

The f100.sql checked into this repo is a synthetic placeholder — it intentionally does NOTHING. It carries a sentinel string (APEX_SYNTHETIC_PLACEHOLDER_NO_IMPORT) that the deploy workflow detects to skip the APEX import step entirely. This lets the rest of the pipeline (secrets, environments, gates, releases) be demonstrated end-to-end before any real APEX app has been built.

The deploy step prints a GitHub Actions notice (::notice::APEX import skipped: ...) when the placeholder is in use.

Security tip when working in this directory: never paste decoded wallet contents into a file under apex/ (or anywhere in the repo). The base64-encoded wallet.b64 produced by docs/SETUP.md Step 3 is also sensitive — it decodes back to the wallet. .gitignore excludes *.b64, wallet/, and all wallet artifact patterns, but always run git status before committing anything in this folder.

Once you've built a real APEX app via docs/BUILD_APEX_APP.md, overwrite this file with the real export and commit. The pipeline detects the missing sentinel and runs the import for real. After a successful real-export deploy, verify.sql will log OK: APEX app 100 found in workspace DEMO. and the APEX app will be reachable through your APEX Builder.

Before a customer demo against your real ADB, replace it with a real export from your APEX workspace:

# 1. Build the app in your DEMO workspace via the APEX Builder
#    (App Builder -> Create from table CF_FEEDBACK -> Wizard).
#    Keep the application ID as 100 to match the pipeline.

# 2. Export the real app with SQLcl:
sql ADMIN/yourpass@yourdb_high
SQL> cd /path/to/apex/apex
SQL> apex export -applicationid 100

# 3. Commit the generated f100.sql:
git add apex/f100.sql
git commit -m "chore(apex): replace synthetic export with real APEX export"
git push

The rest of the pipeline (workflows, schema, secrets, environments) is unchanged when you swap in a real export.

The deploy workflow runs apex import unconditionally. An empty or invalid file would fail and break the deploy. The synthetic file passes import (or fails predictably and visibly) so the surrounding plumbing — secrets, environments, gates, releases — can be demonstrated even before a customer provisions their APEX workspace.

It uses Oracle's documented wwv_flow_imp.* PL/SQL API. The internal structure matches what apex export produces, but only at the bare minimum needed to register an application of ID 100 in workspace DEMO. It does not include real pages, reports, or forms — those come from a real export.

• Workspace: DEMO
• Parsing schema: DEMO_SCHEMA (or whatever schema you own CF_FEEDBACK in)
• Application ID: 100
• Application alias: feedback

If you change any of these, update apex/f100.sql, scripts/deploy.sql, and the apex import call in .github/workflows/deploy.yml.

For real production work, prefer the split-export form for cleaner Git diffs:

SQL> apex export -applicationid 100 -split -skipExportDate -expOriginalIds -dir ./apex

This produces a directory tree (apex/f100/...) where each page is a separate file. Then import via:

sql> apex import -applicationid 100 -workspacename DEMO -file apex/f100/install.sql

For the 15-minute customer demo, the single-file form is easier to show in PR diffs.