APEXRESTDocumentation
Project / Implementation status

Implementation status

On this page

The current source and bundled plugin version is 2.4.0. The current contract is described in architecture, testing and the acceptance matrix.

Implemented

Verification

The 2026-11-01 chart AJAX repair passed 12 focused chart/runtime repository tests, typecheck and lint. The real-assets crypto demo was checked in the built-in browser: Solana, Avalanche and Bitcoin selections updated both SVG series and the report while the document submission ID stayed unchanged; changing the chart width from 761 to 521 pixels retained Avalanche/Bitcoin. These are local preview observations, not Oracle runtime evidence. The synthetic-theme regressions cover multiple series, submitted-item normalization/deduplication, undeclared-item rejection, unfiltered chart registration and subsequent width redraws. Detailed output is in ignored docs/evidence/crypto-atlas-ajax-20261101/.

The current 2026-10-31 repository review leaves six confirmed implementation defects open: missing remote mutation confirmation for parameterless query calls and calls inside CTAS (reconfirmed from the previous review); an exit-drain kill reported as a successful process/migration; an uncancelled drain timer sending SIGKILL after normal process close; password-file parent-directory symlink escapes; unqualified parameterless routines accepted in Composer read/write authorization expressions; and full APEXlang restore importing the configured alias while verifying the backed-up alias. The first two are P1 findings. Isolated probes reproduced the process signals, actual planner/gate and fake-Oracle apply/history behavior, credential containment, Composer binding and restore configuration/verification mismatch. Runtime implementation was not changed. Detailed findings, reproduction sources and logs are private under ignored docs/evidence/code-review-20261031/.

The review's local checks cover 436 passing unit cases with one optional skip, 115 contracts, 46 installer cases and 29 packaging cases, plus build, typecheck, lint, documentation/site checks, Composer catalog consistency, repository-plugin parity and CLI/stdio smoke. The initial restricted run could not bind the ORDS/proxy fixture ports or write the default npm cache; targeted loopback retries and a separate packaging run with a temporary cache passed, and the original failures are retained. These counts combine the original run with those targeted retries. Real Oracle/JVM interruption, connected deployment/restore, Windows, browser behavior and fresh native model-host qualification were not rerun.

The separately authorized runtime and complete dependency audits flagged the same nine packages (one critical, three high, five moderate); including dev dependencies added no affected packages. The direct Zod 4.6.2 dependency retains the oversized-collection validation defect: a bounded local probe produced 101 issues for 100 invalid elements despite a maximum length of two. Update the locked dependencies and verify relevant contracts/packaging; do not treat all advisory counts as reachable exploits. Current MCP source uses stdio rather than HTTP/OAuth, and the SDK OAuth advisory explicitly excludes stdio clients. Audit output and the bounded Zod probe are private in the same review directory. No dependencies were changed. Release readiness remains false: three required reports are stale and six are missing for 2.3.0.

Decisions selection repository checks passed: 430 unit checks (one real SQLcl pooling check skipped), 115 contracts, and 29 packaging checks after repeating the npm inventory case with a temporary cache. Typecheck, lint, documentation/site checks, bundled-plugin parity and repository-plugin CLI/stdio smoke passed. The private summary is docs/evidence/decisions/local.json. These are local repository/transport checks. At that checkpoint the live API had not been exercised; the subsequent live run below is a separate evidence scope. Fresh native-host execution remains unqualified.

The separately authorized 2026-10-29 Decisions run confirmed real API selection with the saved private key: 92 attempts, 89 Decisions responses and three HTTP-error local fallbacks. For each of four fixed 26.1/26.2 English/Ukrainian scenarios, 20 successful warm-process measurements passed the declared component/contract-group and release-isolation checks. Full MCP median/p95 seconds were 1.01/1.60 (26.1 grid), 1.13/1.90 (26.1 dashboard), 1.15/1.59 (26.2 grid), and 1.02/1.66 (26.2 faceted search). Actual successful-response usage was 1,896,655 input tokens, including 797,415 cache-read tokens, and zero output tokens. Initial CLI processes have only one sample per scenario; no cold-process p95 or cold-backend claim is made. API errors were not automatically retried; supplemental measurements preserved the failures. Raw samples and labels are private in docs/evidence/decisions/live-benchmark.json.

A separate same-page generation pilot on 2026-10-29 UTC used gpt-6.1-sol / xhigh, a fixed 26.1 scaffold and three runs per flag. All six final sources passed the native Oracle offline compiler and 46 requirement/data checks, including 20 query checks under a declared SQLite Oracle-function subset. Mean active time to this threshold was 344.31 s disabled versus 178.05 s enabled, including one 3-second timeout/local fallback and every repair. Disabled runs needed three generations each; enabled runs needed one, one and four. First-attempt readiness was 0/3 versus 2/3. Mean generator usage was 59,453 versus 35,277 tokens; the two successful Decisions calls added 42,242 tokens in total. Mean known combined usage was 59,453 versus at least 49,358 tokens per page; timeout usage is unavailable, so full enabled-arm token savings cannot be determined. The successful API subset alone averaged 60.10 s and 35,209 combined tokens; it excludes the timeout and must not replace the full-arm result.

This pilot used stateless model API calls and a fixed policy reading the first two ready templates, with no adaptive host search. After the initial two-generation ceiling, every remaining failure received the same compiler-bound reference pack and up to two additional generations. All initial work remained counted; scheduling gaps and shared compiler preflight were excluded. Original scaffold hashes were preserved in all six runs. These are descriptive one-page results, not a native Codex/Claude benchmark, p95, connected Oracle SQL/import or browser proof. The task, sources, raw usage, diagnostics and analysis are private in docs/evidence/decisions/page-ab/; reusable case A261-069 records the protocol.

That run exposed excessive selection metadata dropping a correctly scored 26.2 grid contract at the 7,000-byte budget. Selection now returns compact metadata and resolved dependency links, retaining all eight selected records for the regression case without increasing the budget. After the repair, 10 focused unit checks, all 115 contracts, typecheck, lint and plugin parity passed. The fixed-case checks do not establish full semantic correctness, generated-page compilation/import/browser behavior or fresh native-host authoring.

The 2026-10-30 component-library review inspected Oracle skills HEAD 014cdb29f12dfa6a689bbe8a80ee1c5f0bf15be1: all 389 bundled 26.2 inventory documents, imported examples/catalog and license are unchanged, all 659 bundled 26.1 source files match, and no newer release directory exists. The latest APEXlang commit remains the reviewed 26.2 pin 03ee10d02273bc4002fd527089e7fbb5884f94c4 from 6 October. Full retrieval through the repository 2.3.0 MCP passed for all 389 definitions and 2,269 paginated reads, including ordinary search and an unrelated empty result. Component, public-template, pattern and plugin consistency checks passed, together with 43 focused unit tests and 43 catalog/reference contract tests. The catalogs retain 112 component families with 176 ready/one unresolved recipe, 58 patterns with 69 ready/15 unresolved recipes, and 1,350 reference-only public pages from 33 applications. Existing hash-bound compiler evidence was checked; recipe compilation, connected Oracle, browser and fresh native model-host execution were not rerun. Reviewed source pins remain unchanged. Private evidence is under ignored docs/evidence/oracle-upstream-review-20261030/.

The public template intake verifies 1,350 page records (1,349 distinct source hashes), all 33 application dependency inventories, exact licensed source identity and hidden-file exclusion. All 168 ready component recipes, including 30 new internet-source adaptations, passed SQLcl 26.3 offline compilation with the unchanged 26.1 MMD and hash-bound dependency closure; one existing unsupported recipe remains unresolved. On 2026-10-14 two more MIT community adaptations were added: a PL/SQL Dynamic Content operations home (denioflavio/apex-plsql-dynamic-content-home) and a read-only USER_SCHEDULER_* jobs dashboard (Aftorres02/OracleAPEX-ErrorShield). Both passed the same SQLcl 26.3 offline compilation, bringing the catalog to 170 ready recipes; negative runs with an invalid property and an invalid template confirmed that the compiler rejects those inputs. The 2026-10-14 test run passed 417 unit tests (one optional skip), 114 contract tests and 29 packaging tests; MCP probes and installer tests were not rerun. On 2026-10-15 both recipes were adapted as pages 101 and 102 of the local DEV application 92620 (Oracle Database Free 23.26.3, APEX 26.2.0, ORDS 26.3, rebuilt after the previous local stack was removed) and imported without import errors. Requested browser checks in the built-in browser passed: the operations home rendered escaped cards, client-side filters toggled aria-pressed and dimmed non-matching cards, a card link carried a checksum and set P101_QUEUE, and an unchecksummed tampered value was not rendered. The scheduler dashboard showed real USER_SCHEDULER_* counts, a deliberate failed run, a job due within 60 minutes and, after the job moved out of the window, the new no-data message. A page-level console error about fetching a script also occurs on the unchanged home page and is not attributed to the recipes. A semantically identical single-file import was reported as TARGET_DRIFT because readback compares source text and the server export orders messages after componentAppearance; the recipe now uses the canonical order, and the working-copy baseline was re-initialized from the server. On 2026-10-15 a third MIT adaptation was added: a write-path drawer form (Pp-py/apexlang-skills) whose drawer loads one APEXREST_EXAMPLE_ROWS row and saves only through a declared fixture package with a ROW_VERSION guard. It passed SQLcl 26.3 offline compilation (171 ready recipes). Adapted as pages 103 and 104 of local DEV application 92620, it needed unique process executionMappingIdentifier values for the 26.2 compiler; the import reached the server, but post-import readback export failed with ORA-20987 for the new pages, while a manual APEXlang export of the same pages one minute later succeeded. Requested browser checks passed: the drawer opened from the list, a concurrent ROW_VERSION change and a case-insensitive duplicate name were refused with the drawer kept open and nothing written, create and edit closed the drawer and refreshed the list, and an unchecksummed row ID was rejected. Package errors display with their ORA-2000x prefix. A fourth MIT adaptation followed: a guarded status transition dialog from 600ner70/PTW_LV (cancel-permit pattern without page-level COMMIT, SQLERRM exposure or the source's inverted close condition). It passed SQLcl 26.3 offline compilation (172 ready recipes) and, as pages 105 and 106 of local DEV application 92620, a full import with successful readback. Browser checks passed: only Open rows show an accessible Close link, a missing confirmation and a concurrent ROW_VERSION change were refused with the dialog kept open and nothing written, a confirmed transition closed the dialog, refreshed the list and showed the success message, and a stale checksummed link to a closed row showed a warning without the action. A later single-file update of page 105 again reported TARGET_DRIFT for canonical-only differences, and after a successful full import the next full import was blocked as SYNC_SERVER_CHANGED until the baseline was re-initialized. A fifth MIT adaptation, a read-only page complexity overview from OliverLemm/apex-visualizer, inlines the source's custom complexity view into APEX dictionary queries. It passed SQLcl 26.3 offline compilation (173 ready recipes); its SQL was executed against the local dictionary before import, and as page 107 of application 92620 it passed a full import with successful readback. Browser checks passed: the pie chart showed 14 Simple and 1 Normal pages, the report listed all pages ordered by object count after column sorting was disabled, the complexity filter refreshed the report and an empty filter showed the no-data message. The source's developer-activity page was not adapted because the local workspace has no activity rows to verify it. A sixth MIT adaptation, an approval workflow from the Pp-py/apexlang-skills absences example, adds named approve/reject verbs that lock the row with FOR UPDATE and check the legal source status, status badges rendered by template directives, a required rejection reason and a danger confirmation. It passed SQLcl 26.3 offline compilation (174 ready recipes) and, as pages 108 and 109 of application 92620, a full import with successful readback. Browser checks passed: badges matched each status and only REQUESTED rows had an accessible Resolve link; rejecting without a reason and approving a request already approved by another session were refused with the dialog kept open and the other session's decision preserved; a confirmed rejection and an approval closed the dialog, refreshed the list, recorded CRM_TESTER as the decider and showed the success message. A seventh MIT adaptation, from the ErrorShield error handler, sets a page-level APEX error handling function that strips the ORA prefix from raise_application_error texts, maps named constraints to friendly messages and masks unexpected technical errors with a fingerprint-based reference code recorded in an autonomous transaction, without Logger. It passed SQLcl 26.3 offline compilation (175 ready recipes) and, as pages 110 and 111 of application 92620, a full import with successful readback. Browser checks passed: the business rule showed its text without ORA-20010, a duplicate code showed the configured constraint message, a division by zero showed only a generic message with ERR-677CA2D2 and no ORA text, a repeat reused the same code and incremented the occurrence count, and the incidents page found the code case- and space-insensitively and showed the no-data message for an unknown code. A duplicated internal detail found during the check was fixed in the package. An eighth MIT adaptation, an SLA monitor from the Public-Grievance-Redressal-System governance dashboard, classifies tickets by one shared SQL rule instead of the source's overlapping views (whose definitions are not in the repository). It passed SQLcl 26.3 offline compilation (176 ready recipes); its queries returned the expected counts against the seeded fixture, and as page 112 of application 92620 it passed a full import with successful readback. Browser checks passed after two fixes found in the browser (card icons needed the base fa class, the count axis needed integer steps): cards showed 6 open, 2 breached, 2 at risk and 67% resolved on time, the bar chart split SLA states by department, and the attention report listed breached and at-risk tickets with readable time-to-due text and badges. The rebuilt repository plugin passed 69 actual stdio MCP probes across all 33 public applications, six natural-language searches and all 30 new ready recipes. The integrated source checks passed 417 unit tests (one optional skip), 114 contract tests, 29 packaging tests and 46 installer tests. These are local source, compiler and packaged-protocol checks, not native-host discovery, SQL execution, imports or browser results. Reproducible outputs are under ignored docs/evidence/internet-templates/.

On 2026-11-01 the component library was expanded with 93 recipes adapted from official Oracle sources: 67 from oracle/skills 26.1 generation templates at 014cdb29f12dfa6a689bbe8a80ee1c5f0bf15be1 and 26 from the oracle/apex 26.2 branch at 244dd3691fa5c2897a069fc912b149b9c2853679, which added the Faceted Search Patterns, Forms Patterns and Sample Directory Search applications. They add charts, maps, calendars, faceted search layouts, processes, dynamic actions, buttons, item variants, six new component families (processes, Rich Text Editor, Geocoded Address, Display Image, Help Text, Breadcrumb) and region/report variants. Every recipe uses synthetic data and a single provenance record whose SHA-256 was rechecked against the upstream bytes. catalog:verify --changed passed all 93 with SQLcl 26.3 and the 26.1 MMD, without errors or warnings; the catalog now has 118 families with 269 ready recipes and one unresolved. Candidates the 26.1 compiler refused (button menus, viewDocument, chart lazy loading) or that need tables, mail or AI services were not added. SQL execution, imports, browser checks and native-host discovery were not run for these recipes.

The APEX 26.1.5 read-only quality run used 20 measured repetitions and excluded warm-ups, with eight metadata request kinds and an all-kinds batch. The historical signatures request used an empty probe because no package existed; it does not qualify populated package signatures. The corrected harness now gates missing object prerequisites as not_run. SQLcl-side statement medians ranged from 23 ms to 1881 ms. All-kinds median was 6.84 seconds; ten six-request concurrency rounds had a 6.76-second median. Twenty unchanged plans retained their fingerprint and three exports preserved the working copy. The 120-read resource check found no remaining owned SQLcl JVMs after 0.40 seconds, with unchanged descriptors/shared stage-directory count. Four historical comparisons remain not_comparable because fingerprints are incomplete. Details remain in private docs/evidence/qp-harness/; no connected write or browser run occurred in this review.

Review triage preserves the original faults-26.1-final.json and compiler-faults-26.1-final.json. Fixed duplicate CLI --project arguments restore MCP/CLI parity: compiler-syntax is INVALID_PROPERTY / exit 1 and workspace-case is WORKSPACE_UNCONFIRMED / exit 4 on both interfaces. The repaired review-fixes/faults-26.1-R8.json passes 2/7 A261-058 inputs; five still lack actionable next steps. A261-059 passes 2/6 diagnostic cases. Missing-item/static-ID and cosmetic indentation are accepted without errors. A structurally valid SQL report baseline compiles, and the SQL-only malformed variant is also accepted; the original fixture's region errors did not establish SQL diagnostic precision. Catalog proposals and semantic-capability gaps require review; runtime semantics and expectations are unchanged.

APEX 26.2 offline profile/MMD identity and two starters containing all six recipes compile; CodeScan advisories remain separate. Original extension-26.2-final.json failed A262-001 with VALIDATION_FAILED / exit 1, but changing the profile of 26.2 sources tested compiler refusal before proving the target. The corrected review-fixes/extension-26.2-R8.json records the target check as not_run: its connection prerequisite returns ORACLE_COMMAND_FAILED / exit 1 and a valid 26.1 source/lock is still required. A262-003 remains 17/21 top-three golden hits (80.95%), below 90%; the repeated warm median is 0.71 ms. Four exact misses/top-three lists and proposed release-exclusivity wording are in review-fixes/R8-triage.md. No connected 26.2 parity or local-versus-remote comparison is qualified.

The Claude usage adapter is implemented and verified against a historical transcript: an independent hand sum agrees at 102,416 normalized total tokens (claude-usage-real.json). Its scripted two-turn check remains pending. R2 reanalysis of both prior native reports found no write-classification changes; original sessions were preserved. Both hosts reran AGT-001/004/007/008/011 three times: agent-codex-26.1-final.json passes 11/15, and agent-claude-26.1-final.json passes 6/15, with zero observed import/browser/secret violations. Two correct Ukrainian FK-absence answers were initially rejected by the English-only oracle; reanalysis corrected them without rerunning models. Claude instruction reads are observed in all 15 sessions; its local Edit and dictionary attempts include native permission-denial hints. AGT-007 still fails citation checks, with three manual semantic-review entries per host. Original raw measurements are preserved in review-fixes/R6-before-fk-reanalysis-*.json, with triage in review-fixes/hand-back.md. AGT-007 independent semantic review is needs_review, while missing plugin use/citation still fails automatic checks. Native model/effort defaults are not pinned, active Codex payload binding remains unproven and timings are descriptive. The review repository checks passed typecheck/lint, 413 unit tests with one optional skip and 107 contracts; build/bundle/documentation/site checks are recorded in the hand-back.

The reusable APEX 26.1 server qualification catalog defines 67 A261-* baseline and quality/performance scenarios covering every current acceptance ID, with authorization boundaries, functional expectations and performance/token evidence requirements. APEX 26.2 has a separate extension catalog and separate reports; agent, Codex/Claude host and Bitcoin catalogs are also present. The current-build stdio MCP harness exercised live identity, metadata, references, working-copy baseline, Oracle validation and read-only planning on an authorized remote APEX 26.1.5 test application. Three explicitly authorized title-only full imports across MCP restarts and a fresh ship returning the original title succeeded. An independent final full export matched all 21 initial files, including hidden Oracle metadata, byte for byte. This verifies application-source preservation; it does not qualify the separate backup-restore command, business DML, browser behavior or native-host lifecycle. SQLcl 26.3 compiled the actual 26.1 sources; no 26.2 application result is claimed.

The run found and repaired two defects: hyphenated APEX workspace names were incorrectly rejected as SQL identifiers, and MCP apply forwarded an explicitly saved plan into plan mode, causing pre-write INVALID_INPUT. Regression checks retain strict SQL schema identifiers and route the exact saved plan to the existing apply worker, which still validates expiry, source/target drift, production policy, backup, coordination and grant handling before writes. Current local checks passed typecheck/lint, 396 unit cases with one optional case skipped, 70 contracts and 46 installer cases. The packaging matrix passed 28 cases initially and its remaining npm inventory case passed after moving the temporary npm cache into writable private storage; the original sandbox failure is retained. Test latency reports are descriptive smoke samples, not qualified p95 or an SLA. Oracle CodeScan reported seven existing advisory security findings, separately from compiler success.

Private evidence is under ignored docs/evidence/plugin-server/. Actual Codex token checkpoints read cumulative host usage only, retain cache accounting and mark missing/stale/reset/cross-session data unavailable; no CLI/MCP token estimates are reported as billing. Initial harness failures and sandbox listener/staging/cache limitations are preserved separately from repaired results. See the reusable test procedure for reproducible execution and evidence boundaries.

The requested APEX 26.1 browser follow-up passed nine host-browser checks on the existing test application: authorized login, authenticated reload, navigation disclosure, keyboard control, narrow shell, logout, protected Home, empty-login rejection and subsequent valid login. The embedded panel's effective narrow width was 325 pixels after requesting 390; the report records both dimensions. This is application-shell/session evidence, not business CRUD or Composer runtime qualification. Nine reusable browser definitions accompany the 67-case baseline/quality catalog. The active native MCP rejected the hyphenated workspace while the current-build CLI URL handoff succeeded; an updated bundle and fresh native session remain necessary before claiming installed-host parity.

The read-only performance follow-up passed 20 repetitions for each of six scenarios, with one excluded warm-up per scenario: fresh MCP startup/reference, warm reference search, warm project summary, live three-kind metadata batch, Oracle compiler validation and full-import planning. All 120 measured samples and six warm-ups passed; the run took 390.06 seconds and made 128 MCP tool calls. Median/nearest-rank p95 was 9.62/12.79 seconds for metadata and 6.86/7.96 seconds for planning. Warm offline compiler validation used the persistent SQLcl JVM (0.228/0.288 seconds), while connected work opened fresh vendor sessions. Oracle CodeScan retained seven existing advisory findings. This is a current-build, same-run distribution with concurrent browser observations and whole-host token deltas; no controlled historical regression baseline, per-call model billing, repeated import throughput or installed-host performance claim is established.

Per-operation SQLcl instrumentation records process readiness/spawn, saved-connection connect, execution and total durations, transport, reuse, mutation and bounded caller labels. CLI connect time remains unavailable because it belongs to the script execution interval. Recorders isolate concurrent operations and contain no SQL, bindings or usernames. Ship result details and deployment journal transitions retain timings; journal timingPhase identifies the preceding phase whose work was observed. Metadata responses add only session count/total SQLcl time by default; debugTimings: true includes the individual records. Scoped metadata reads now batch identity and all requested queries into one connected session, rejecting all rows on identity mismatch. Working-copy fingerprints batch identity and update metadata in one session. A full working-copy apply with the same read/deploy connection and no fresh export uses four connected sessions in fake-runner checks: start observation, post-freeze pre-import observation, import, post-import observation. Different connections keep a separate deploy identity check. Fresh-export paths reuse the start export as backup and retain the stronger post-freeze pre-import drift check (three total exports including plan); other export-backed paths retain the post-backup drift check; database scripts keep a post-freeze first-write barrier and exact local migration-history validation. Post-import metadata supplies the successful checkpoint. Cancellation, frozen-source checks and interrupted-write ownership remain intact. The optional same-session import guard is deferred because MCP R4 lacks a proven error-stop contract. The APEX 26.1.5 read-only follow-up passed 40 measured samples and two excluded warm-ups (20 per scenario), with 44 MCP calls in 188.97 seconds. Metadata median/p95 changed from 9.62/12.79 to 5.42/6.03 seconds; full-import plan changed from 6.86/7.96 to 3.13/4.04 seconds. Each used one fresh connected session; steady-state planning also used one reused offline compiler session. Median summed spawn/connect/execute intervals were 0.70 ms/null/5411.46 ms for metadata and 0.46 ms/null/3138.48 ms for plan. CLI spawn measures OS process creation; JVM startup and connection setup remain inside execute. Parallel plan intervals can overlap. These are separate runs on the same recorded machine/target, without controlled network/load/cache conditions. Whole-host token checkpoints are retained separately from per-call billing, which remains unavailable. The four-session apply reduction is estimated at about 12.45 seconds of saved session time using the 3.11-second read-only observation median as a proxy; it is estimated, not measured on Oracle. No import, database write or DDL was run in this follow-up. Typecheck, lint, 408 unit checks (one optional check skipped), 70 contracts, build, documentation and bundle checks passed.

Run the relevant checks in testing against the current source. Local unit, contract, installer, documentation and packaging checks establish their stated fixture/build behavior. Oracle compilation, connected imports, authenticated application browsing and fresh native model-host execution require separate checks on an authorized target. Browser checks are not inferred from compiler/import success.

The current parity source passed typecheck and lint, 383 unit checks (one additional check skipped), 62 contracts, 46 installer checks and all 29 packaging cases. Claude Code 2.1.291 accepted the plugin and marketplace manifests with strict validation. The final unit run followed the completed build and had local-listener access for its ORDS protocol fixture; npm inventory used a private temporary cache. These are repository, manifest and subprocess checks, not native model-host execution.

Host parity changes preserve the existing scoped deployment core. Both manifest launch adapters are checked from a relocated package, with equal tool contracts/reference results and shared managed connection state. Installer checks cover dual-host launch bindings, source-safe reinstall, Node changes and Claude metadata integrity. Source-bound validation and packaging results are recorded separately under ignored docs/evidence/host-parity/. Native Codex/Claude model-host execution and new Oracle/browser runs are not established by these subprocess/fixture checks. Managed setup still registers Codex only; Claude uses its native plugin commands.

On the explicitly authorized local Oracle APEX 26.2 target, page creation and isolated replacement passed Oracle compiler/import/readback checks. APEXlang restoration of the previous selected page also passed without a SQL application dump. A stopped verification was reconciled as already applied without replay; Oracle filenames are matched by unique page ID rather than alias spelling. New and changed shared LOV files passed isolated imports: their plans explicitly disclose full APEXlang observation, while backup, import and comparison retain the selected scope. A final separate full audit checks unrelated files and business-row counts; it is outside the page-only edit cycle.

The authenticated in-app browser showed the new dashboard's version marker, three zero-valued CRM cards, empty customer chart, demonstration chart and the changed shared LOV label. These observations establish this dashboard and dependency rendering, not full CRM CRUD or security qualification. Page replacement measured about 34 seconds including planning/apply/readback; new dashboard creation about 44 seconds. Shared-component creation/replacement measured about 42/49 seconds because native selected export is unavailable for these families. Local no-op measured about 30 milliseconds with zero Oracle calls. The earlier whole-export flow took about 48 seconds for plan/apply; these are individual local samples, not a controlled performance guarantee. Independent machines/homes still require external serialization.

The user reported successful live Claude Code verification on 2026-10-07. That session reported an isolated analytics-page import with --import-mode files on the local 26.2 target: an occupied page 40 blocked planning, page 70 imported, and ship mode:recover recognized the already-applied result after key-ordered classic report columns caused a readback mismatch. It also reported four expected regions and unchanged pages 40/50/60, with no browser check requested. These are session-reported observations; the follow-up commit review did not independently repeat Oracle or native-host execution.

On 2026-10-15 three working-copy sync defects found during recipe imports were fixed. Native selected export now issues one -expComponents call per component, because APEX 26.2 rejects a component list with ORA-20987 even for existing pages (reproduced with pages 1 and 10). The selected-source equivalence policy now reads scalar lists, binds fenced code to its property, ignores the order of uniquely named properties and groups and of key-ordered page, process-parameter and dynamic-action children with explicit sequences, and accepts single-line JSON-quoted code, upper-cased invoke identifiers and the defaults observed in native exports (invokeApi direction/dataType/ignoreOutput, items-event change, page cursorFocus and formAutoComplete, classic-report pagination). Planning treats server files that differ from the checkpoint only by these canonical forms as unchanged, including in the reviewed before side revalidated by apply, so a full import no longer blocks the next full or selected plan and no export is added after imports. On the local APEX 26.2 target, a two-new-page selected import, a selected import of an authored page with template-option lists and a selected import after a full import all succeeded with equivalent readback, and mode:recover closed a run interrupted before the fix; tests: 421 unit (one skip), 114 contract, 29 packaging. The equivalence policy now accepts key-ordered columns only for classic reports with unique explicit sequences; other region types, absent/duplicate sequences and changed column identities/query IDs remain strict. Conflict diagnostics name the overlapping files. Follow-up repository checks passed typecheck, lint, 32 focused equivalence/partial-import/partial-export tests and the checked-in plugin CLI/stdio MCP smoke. The source bundle and documentation were regenerated and checked. Full unit, contract, installer and packaging suites were not rerun for this follow-up.

The official inventory maintenance change passed complete archive/document/type/property reconciliation and 2,269 packaged MCP reads for all 389 definitions. Its focused checks cover exact pagination, ordinary component/property discovery, independently bound search bytes, recovery of incomplete/corrupt accelerators, integrity failure, release isolation, public Oracle enums and continued operation/diagnostic secret redaction. Independent temporary-copy forward checks also passed source refresh and synthetic MMD/new-release review decisions. These are library/compiler checks, not connected or native-host qualification.

Parity implementation checks did not register the bundle into the user's existing Codex or Claude Code profiles. Local contracts exercise relocated MCP subprocesses, and Claude's native CLI validates manifests without starting a model session. The user's subsequent Claude Code verification is reported above; independent fresh cache/skill reload and model-driven tool qualification remain open for both hosts. Parity implementation and follow-up review used isolated fixtures without changing global connection, credential, toolchain or deployment-history state.

Release readiness requires source-bound reports for every mandatory gate. Generated reports are private working output under ignored docs/evidence/; their absence blocks readiness. No connected or native-host result is inferred from a local build.

The 2.3.0 repository integration checks passed on Node 24.21.0: 431 unit checks with one optional SQLcl pooling case skipped, 115 contracts, 46 installer checks and 29 packaging cases, plus lint, typecheck, documentation/site and bundle-integrity checks. Installer loopback fixtures passed with local-listener access. The final unit run used a private managed home and a completed build; earlier restricted-environment and concurrent-rebuild failures remain in private logs. Unsigned local packaging produced version 2.3.0 artifacts without publication; full readiness remains false. These local results do not qualify fresh native-host execution, connected Oracle, browser behavior or registry distribution. Private records are under docs/evidence/decisions/version-2.3.0/.

The offline Composer harness keeps its managed home outside the new project directory, preserving the initialization conflict guard. Composer now has an explicit 26.2 profile with six immutable @1.1.0 block packages and separate CRM/Service Desk blueprints. Real SQLcl build 26.3.0.260.1620 and vendor MMD 26.2.0+3479 compiled both complete scaffolds successfully; CRM materialization and repeat no-op checks passed. The adapters use exact lowercase report type enums and stable numeric process/saved-report mappings. Compiler/MMD mismatch checks remain mandatory. Fresh functional compiler records bind each new block to its generator, configuration and complete scaffold digest. Original 26.1 packages and records retain their true scope; old records cannot qualify the current generator or 26.2. This proof performs no database SQL, import, DML, authenticated browser or native model-host operation.

The retained publisher local-evidence exception is bound to 2.2.0 and does not apply to the current 2.3.0 source. Under the existing configuration, all nine source-bound qualification reports remain required for current-version npm and full readiness. Missing, failed and stale evidence blocks its applicable gate. Publication authorization, CI, package integrity, ownership and registry clean-install checks remain separate requirements; the GitHub release workflow remains disabled.

Host-parity teardown now awaits all MCP clients before removing their working directory, tracks clients before connection and retains close failures. Its focused macOS regression and all 62 contracts passed; the subsequent hosted CI passed Windows, macOS and both Linux matrix jobs. No CI workflow or database deployment safeguard was removed.

Actual isolated Codex registration/adoption/cache checks passed with the then-current package. A native conversation completed CLI Composer materialization and no-op; its MCP selected an older duplicate plugin because quoted dotted CLI overrides were interpreted as literal keys. A supported temporary config profile resolved that routing issue and actual MCP calls read the current 1.1.0 CRM blueprint and CRUD block. This was a configuration mismatch, not a current catalog defect. The user then stopped full external qualification. The already-started local import created only disposable app 92630 and the dedicated CMP fixture tables/API in APEXREST_262_TEST, with confirmed server verification and grant removal; runtime CRUD/browser qualification is incomplete. These narrower results do not establish all six external gates. Private records remain under ignored docs/evidence/.

Repository automation

CI runs automatically only on pushes to main. Release and Oracle integration workflows are disabled in GitHub and gated off in their checked-in jobs. The publisher opts into the authorized npm target, subject to all required current evidence. Build, site generation and release dry-run create local output only.

Open checks are listed in next actions. Publication, tagging and database changes require their own applicable authorization.

Documentation website

The Markdown pipeline generates tracked GitHub Pages output under docs/, with /apexrest/ routes, responsive grouped navigation, search, section links and previous flat .html guide URLs. site:check verifies generated freshness. The safety source is integrated before generation; The local browser verified current safety rules and the coverage route, navigation/search/anchors and a 390-pixel layout with contained table scrolling. The final generated site and packaging checks passed separately from these browser observations. This local work does not publish or verify revised live Pages output.