Deployment safety rules

These are the current APEXREST product rules for application and database work. Installation, a project configuration and a tool response never supply user consent. The host filesystem permissions govern access to the current project and other required directories; there is no folder trust list to maintain.

Environments and precedence

Read-only dictionary batches verify identity from the same session before any row is returned. Queries may execute together, but a mismatch discards the entire batch.

Production takes precedence over locality. A target is production when apexrest.json marks its environment kind: production or its exact target digest appears in productionTargets in $APEXREST_HOME/production-trust.json. Changing an environment label does not remove a registered production mark. APEXREST reads this classification file and never edits it. Legacy approval keys may be present but are ignored: neither a signature, CI=true, a local grant nor human confirmation enables production deployment. Authorized read-only diagnostics and browser inspection remain available.

Locality is determined from the effective deploy connection, not baseUrl, an environment name or a project flag. Direct SQLcl uses the connected JDBC endpoint (show connection); ORDS uses the effective connection URL. A loopback endpoint must also identify a server on this host or in a currently running local Docker or Podman container. Remote container contexts, forwarded or unresolved server identities receive the remote rules. Missing locality evidence never grants destructive local privileges. The database/service/schema/workspace/application identity is verified independently before writes. See the Oracle SQLcl connection documentation.

Application authorization and exact plans

An explicit request to create, update or import an identified DEV/QA/TEST application authorizes its necessary import. The agent completes the task without asking the same permission again. apexrest_ship records that instruction as a temporary deploy grant bound to the exact canonical project, target digest and plan digest. It preserves unrelated policy entries and removes its grant after the attempt. Legacy trustedProjects is optional ignored compatibility data.

Plans bind source, configuration, toolchain, target and import selection, and expire after 30 minutes. Source/configuration/compiler drift, target changes, a different project or a forged plan block apply. Regenerate a plan when sources or its validity change; this does not authorize a different application or unrelated work.

apexrest_ship mode:plan compiles with Oracle, reads the target and saves a concrete local plan. mode:apply uses the application's task instruction. An optional plan selects an already reviewed saved plan. Production always fails with PRODUCTION_DEPLOY_DENIED before a grant or database write.

Actual dangerous database operations

SQL inspection distinguishes executable operations from comments and string data. Examples include ALTER TABLE customers RENAME COLUMN old_name TO new_name, DROP TABLE customers, truncation, DML, privilege changes, dynamic SQL and executable program replacement. A remote plan shows databaseReview.operations: action, object, column/new name where relevant, consequences and dependency observations. A table deletion removes data and constraints and can invalidate dependent code; a column rename requires updating dependent SQL and application queries. Missing dependency visibility is reported as unavailable, never as no dependencies.

For remote DEV/QA/TEST targets, describe these concrete effects in chat and obtain explicit human confirmation. Apply the same saved plan with confirmation: { planDigest, userRequest }, where userRequest is the human's actual confirmation. The runtime checks the exact digest; confirmation cannot authorize another plan, target or changed SQL. The CLI accepts --confirmation as a JSON object. Local targets use the local policy above and need no separate dangerous-operation confirmation.

Deleting an APEX page or component is application metadata work and does not add a database-danger confirmation. The application backup protects that workflow. Authentication/authorization changes must remain within explicitly authorized task scope; the remote confirmation also binds any such reviewed risk.

Migration and package inputs remain contained, frozen SQL/PLSQL files. Names, immutable checksums and ordered migration history are checked. SQLcl host commands, credential switching and unbound external scripts are unsupported even on a local server: local database permission is not permission to execute arbitrary host commands. SQLcl imports/scripts retain restriction level -R 2. DDL is not assumed transactional, and an APEX application backup does not restore business data.

Backups and coordination

Ordinary imports use checksummed, target-bound, private APEXlang snapshots. Page changes retain only the selected pages; full imports retain the full application. Restore uses a separate exact plan and a fresh snapshot; production restore is blocked. Existing legacy SQL backups remain explicitly restorable. Application backups restore APEX metadata, not business data. A creation snapshot records absence and cannot undo creation through an empty import; deletion requires a separately reviewed operation.

Clean supported APEX requires no APEXREST control tables. Local durable migration history and schema ownership live under $APEXREST_HOME/deployment-control/. Runners sharing that home are serialized. Independent homes/machines require external serialization; changing or deleting durable history is not recovery. Preserve foreign/live ownership and unrelated local or server changes.

APEX 26.2 partial imports

Eligible partial plans bind an exact page/shared-component file list, baseline, fresh server snapshot and validated effective tree. Pages use native selected export. Oracle 26.2 rejects native APEXlang LOV/list export selectors, so shared-component imports explicitly bind a full APEXlang source observation while retaining backups and readback comparisons only for the selected files. The runtime reuses its pre-apply observation as the backup source, freezes sources and executes one SQLcl apex import -files call. It never silently expands an explicit file import to a full import. A page file is the import unit; this does not claim child-region granularity.

Readback checks selected files using the qualified formatting/default equivalence rules. Scalar values, fenced code, nondefault security and ambiguous identities remain strict. Both hashes, normalization rules and observation scope are retained. Unselected server freshness is not established by a selected comparison. A real mismatch remains a verification failure and enters reconciliation; successful command output does not mask a different result. Same-component conflicts block; other-component changes are preserved by selected import. Managed-home ownership is acquired before the fresh drift check; independent machines/homes require external serialization. See APEX 26.2 support.

Interrupted imports and recovery

An interrupted/lost response is initially outcome_unknown. The runtime first reads the actual server and compares it with the reviewed desired and baseline sources. If the desired result is already present, it records recovered success without reimport. If content is still the baseline or a compatible partial result, it preserves evidence, reconciles the working checkpoint, releases only the stopped run's ownership and creates a fresh exact plan for the required remaining application import. The ship worker makes at most one automatic retry per attempt.

apexrest_ship mode:recover with the original run UUID and task instruction resumes that workflow after a stopped worker. CLI deploy status --run UUID remains read-only and reports the observed classification. Third-party content changes, live/foreign workers and local source/configuration drift block recovery. SQL migrations/packages and metadata restore scripts are never blindly replayed: their actual database effects and durable history require separate review. Production remains blocked. Cancellation never implies rollback.

Completion and optional browser checks

A confirmed server deployment without errors is success. Oracle compiler validation, target checks and applicable import integrity checks remain mandatory. Browser verification is performed only when the user requests it; it uses the built-in browser by default or the browser the user selects. An ordinary deployment has no browser approval or not_run caveat cycle. When a browser check is requested, report actual observed behavior separately; opening a URL alone is not evidence. No automated application suites are run and no browser is installed.

Local ENV credentials and truthful evidence

Credentials may be read from a local ENV file for an authorized target connection or browser login when the file is a regular, user-owned, Git-ignored and untracked file. Parse ENV as literal data; never source it as shell code or execute substitutions. Connection setup accepts envFile with optional urlKey, usernameKey and passwordKey (defaults: ORDS_URL, ORDS_USERNAME, ORDS_PASSWORD). Password values never appear in operation results, chat, logs or public artifacts. A browser login may consume the same authorized local source without a password-paste or folder-trust step; do not capture cookies/profiles or persist secrets in application source.

Report implementation, repository fixtures, Oracle compiler/import results and requested browser observations accurately. Generated verification output belongs in ignored docs/evidence/. A local build or import does not prove fresh native-host discovery or UI behavior.

View this page source