WP.org submission: close out review T4 (17 Jun) and stop the review loop

[pluginslab]

Tracking issue for closing out the WordPress.org plugin directory submission. Everything related to the submission gets discussed here, so we stop losing the thread between email rounds.

Current review: R agentic-admin/schmitzoide/1Jun26/T4 17Jun26/4.0.1 (received 17 June 2026, not yet answered)
Submitted: 28 May 2026, slug agentic-admin, account schmitzoide, version pinned at 0.11.0
Status: pended, not published

State as of 23 Aug 2026. All three T4 items are resolved in code or in the drafted reply. What remains is not engineering: merge #231, upload the zip, send the reply. The sections below keep their original wording for the record, with resolution notes added inline. The Plan checklist at the bottom is the current source of truth.

---

Why we are stuck

The list is shrinking, but two items have survived three cycles untouched.

Date	Review ID	Type	Flagged
28 May	AUTOPREREVIEW ❗OWN .../28May26/T1	auto	Ownership, wp prefix, Plugin URI 404, NVD URL 404, menu position, sw-loader.php
29 May		replied + uploaded	de-brand to individual, full prefix rename
30 May	AUTO .../30May26/T2	auto	Trialware/LABS, source accessibility, write-file, file/dir locations, external services
1 Jun		replied + uploaded	removed write-file, content-generate, LABS gate
1 Jun	R .../1Jun26/T1	human	.wasm file, remote CDN loading, file/dir ×13, cURL, wpaa_ prefix, sw-loader.php:44, unsafe SQL
11 Jun		replied + uploaded	← this reply answered T2, not the live T1
17 Jun	R .../1Jun26/T4	human	.wasm source, remote CDN loading + a direct question, uploads-scan.php:175
since		silence, 6+ weeks

The 11 June upload comment opens with "Thanks for the detailed automated review (ID: AUTO agentic-admin/schmitzoide/30May26/T2)". By then T2 was ten days stale and superseded by the human review T1. The code fixes did land (cURL, unsafe SQL, sw-loader.php, wpaa_ prefix and 12 of 13 file-location hits all dropped off between T1 and T4, thanks to #227), but the two items that need a decision rather than a code change were never addressed, and the accompanying reply discussed a different review.

Deadlines

• The 28 May email: "If you believe there is a requirement you cannot accomplish and choose not to make changes, your plugin submission will be rejected after three months." That is roughly 28 August 2026.
• The 1 June email: "If more issues of the same nature are found in the following review, this plugin will be rejected and will not be reviewed again."

---

What is actually left

1. Calling files remotely (the real blocker) 🔴

Flagged at T1 and again at T4. We load two things over the network at runtime:

• src/extensions/services/indexing-worker.js:23 and src/extensions/services/vector-store.js:17 do a dynamic import() of Transformers.js from cdn.jsdelivr.net
• WebLLM has raw.githubusercontent.com/mlc-ai/binary-mlc-llm-libs/ baked into its own bundle, plus model weights from Hugging Face

Bundling Transformers.js locally was attempted and broke: transformers.web.js externalises onnxruntime-common and fails at runtime with D[A] is not a function, and the src entry pulls Node-only deps (sharp, onnxruntime-node). We fell back to justifying it as an opt-in service in the readme. The reviewer did not accept that as sufficient.

But they left an opening. Their exact question, still unanswered:

Could you please clarify whether the downloaded model and runtime assets are configurable by the site owner, user-supplied, or strictly tied to the currently configured third-party providers?

That question decides whether the Guideline 6 service exception applies to us. It needs a direct, honest answer.

Open question for discussion: how do we answer it? Answered. The reply is drafted at wporg-review-reply-t4.md and leads with configurable by the site owner, which is the reading that supports the Guideline 6 exception. It also states plainly that the plugin's server-side PHP makes no external requests at all, and scopes the no-data-transmitted claim to the default local mode so the optional remote-provider path is not misrepresented. No code change: item 1 was always a reply, and it ships with the zip.

Side issue: vector-store.js:17 is still on the floating @3 range. Fixed in #230, now @3.8.1, matching indexing-worker.js. The changelog claim is accurate.

Still open: the fallback if T5 rejects this anyway. It splits in two, and the halves carry different risk:

• Model weights (HF / mlc-ai) are data. Gigabytes, provider-hosted, browser-cached, pointless to bundle. Classic service-exception case, strong position.
• Transformers.js (jsDelivr) is executable code. This is the part WP.org is conservative about, because the directory cannot review it. The @3.8.1 pin narrows the risk but does not remove it.

Transformers.js is used only by the knowledge base, so dropping the KB removes the remote code entirely and leaves only remote data. That makes the fallback surgical rather than a general retreat. Cost went up on 23 Aug though: the KB was verified working at 11,241 chunks, so it is a real feature now, not a stub.

2. .module.wasm with no source in-repo ✅ RESOLVED in #231

build-extensions/ec1161a2a3cd8c6fa687.module.wasm (171 KB), produced by the voy-search npm dependency. Listed at T1 under "Not permitted files". Softened at T4 to:

While the upstream source is documented, please consider including the source corresponding to the distributed WASM module directly in your own repository to facilitate review and verification, rather than relying solely on an external GitHub reference.

Open question: vendor the voy Rust source, or reply citing the upstream link?

Decided 23 Aug: neither. We removed the dependency. #231 drops voy-search entirely, so there is no binary to source and nothing for a T5 to re-raise. build-extensions/ now ships JavaScript and CSS only.

voy did one job, nearest-neighbour lookup over Xenova/all-MiniLM-L6-v2 embeddings. Those come out L2-normalised, so similarity is a plain dot product, and the replacement is about 50 lines in vector-store.js. Verified in the browser at 11,241 chunks: correct files, real cosine scores (0.722 / 0.680 / 0.652), index restored from IndexedDB after a hard refresh, search instant.

Note for anyone reading @ivdimova's drafted reply in the comments below: it proposed option 2, keeping the module and citing readme.txt:86. That line no longer exists, so that option is gone. Reasoning for going the other way is in #231.

3. uploads-scan.php:175 ✅ RESOLVED in #230

$well_known_dir = ABSPATH . '.well-known';

Reviewer note: "Assumes .well-known is inside ABSPATH, which can be wrong on subdirectory installs; use get_home_path() or equivalent site-root resolution instead of tying it to the WordPress core directory."

One line, and the only concrete code change requested at T4. Still unfixed in the tree. Fixed by @ivdimova in #230, merged 23 Aug as e3f083a. It also guards the wp-admin/includes/file.php require so get_home_path() is actually available on the ability's REST load path. Verified executing cleanly in a WP Playground install.

---

Blocking housekeeping

• Merge WP.org review compliance + AI connector fixes #227. Merged 1 Aug 2026 as d1d0108. It carries all the compliance work done so far, and main now has it. Everything else in this issue builds on top of it.
• Do not merge feat: MCP server endpoint (read-only, v0.12.0) #216 (MCP endpoint) until the submission clears. It was written against the pre-rename codebase and would reintroduce exactly what the reviewer rejected: WPAgenticAdmin\MCP namespace, the wp-agentic-admin/v1/mcp REST namespace, WP_AGENTIC_ADMIN_VERSION, and it edits wp-agentic-admin.php, a file WP.org review compliance + AI connector fixes #227 renamed to agentic-admin.php. It also bumps to 0.12.0 while the submission is pinned at 0.11.0. It needs a rebase onto the renamed codebase afterwards.
• Do not merge fix: upgrade protobufjs to 8.0.1, 7.5.5 (CVE-2026-41242) #232 / fix: upgrade tar to 7.5.19 (CVE-2026-59873) #233 until the submission clears. Outside automated dependency bumps opened 23 Aug by anupamme (OrbisAI Security), both targeting the stale dev branch. Audited: not malicious, the change in each is one commit touching only package.json and package-lock.json, all resolved URLs are official npm, no install hooks added. The 186-file diff GitHub shows is our own WP.org review compliance + AI connector fixes #227 work, because dev is 8 commits behind main. Irrelevant to the submission since neither package.json nor package-lock.json is in .distpackage or the built zip. fix: upgrade protobufjs to 8.0.1, 7.5.5 (CVE-2026-41242) #232 forces protobufjs across a major boundary onto onnxruntime-web, which declares a 7.x range, so it carries real build-breakage risk. Leave both alone.
• Do not merge fix: ReAct reliability pass (structured output, preferSummarize, stale docs) #229 until the submission clears. Parked by its own design.

Plan

• Merge WP.org review compliance + AI connector fixes #227 (done, d1d0108)
• Fix uploads-scan.php:175 → get_home_path() (fix: address WP.org T4 review items (#228) #230, e3f083a)
• Pin vector-store.js to @3.8.1 to match the changelog (fix: address WP.org T4 review items (#228) #230, e3f083a)
• Decide and implement the answer on remote loading (item 1). Drafted at wporg-review-reply-t4.md, reframed to lead with site-owner-configurable. Ships with the zip.
• Decide on the voy WASM (item 2). Decided: remove the dependency. fix: drop voy-search and the WASM module it distributed (#228) #231.
• Rebuild the dist zip (npm run dist), test on a clean install with WP_DEBUG on. Zip is 4.5 MB, 62 files, no binaries. Activates clean in WP Playground, zero PHP errors, 34 abilities register, uploads-scan executes.
• Browser-verify the new cosine search on a real install (WebGPU, 11,241 chunks). Correct results, real scores, index restored after hard refresh.
• Merge fix: drop voy-search and the WASM module it distributed (#228) #231.
• Upload the zip AND reply, as one step. Upload via "Add your plugin" as schmitzoide, then reply in the existing email thread quoting review ID R agentic-admin/schmitzoide/1Jun26/T4 and answer their question directly. Keep it short, they explicitly asked for brevity and said not to list all changes.
• Agree the T5 fallback on remote loading (see item 1). Not blocking the upload, but better decided now than under time pressure.

Definition of done

The reply and the zip go together. Every review email carries the same checklist: "I went to Add your plugin and uploaded the updated version" and "I replied to this email." Replying alone re-enters the queue with unchanged code, which is exactly the failure mode that produced T4.

This issue closes when the plugin is approved and published, not when we reply. If a T5 review comes back, it gets appended here rather than starting a new thread.

@ivdimova, the two decisions in items 1 and 2 are the ones worth your view before we touch any code.

Both decisions are now made (23 Aug), so this line is history. Item 1 is answered in the drafted reply, item 2 went to removal in #231 rather than either option originally listed. @ivdimova the reasoning for overriding your suggested approach on item 2 is written up in #231, and your #230 fixes are merged and untouched.

[pluginslab]

#227 merged ✅

Merged into main on 1 Aug 2026 as d1d0108. Verified on main:

• agentic-admin.php present (renamed from wp-agentic-admin.php, matches the slug)
• sw-loader.php gone (the service worker is served through admin-post.php?action=agentic_admin_sw)

main is now the compliance baseline. All remaining work in this issue branches from here.

[pluginslab]

Drafted reviewer reply from @ivdimova (18 Aug, by email)

Putting it on the record here so the reply lives with the decisions rather than in a mailbox.

Replying to review for agentic-admin/schmitzoide/1Jun26/T4. On the downloaded model and runtime assets, they are strictly tied to the inference provider the site owner selects in the plugin settings (by default the local WebLLM / MLC-AI engine). The plugin server hosts and transmits nothing: the visitor's browser fetches the model weights and runtime directly from the provider's own distribution (MLC-AI / Hugging Face). The optional in-browser knowledge-base embedding loads Transformers.js from a version-pinned static jsDelivr URL (@3.8.1) and its embedding model from Hugging Face. No prompts, posts, or admin data are transmitted anywhere; all inference runs in the browser, and the model is chosen by the site owner rather than user-supplied at runtime. On .well-known, fixed to resolve via get_home_path() instead of ABSPATH, so subdirectory installs are handled correctly (uploads-scan.php). On the .module.wasm module, it is the unmodified distributed build of the voy-search npm dependency, whose upstream source is referenced in readme.txt.

---

Item 1: framing of the remote-loading answer

The reviewer asked a three-way question: configurable by the site owner, user-supplied, or strictly tied to the currently configured third-party providers?

The draft opens on "strictly tied", which is the reading that makes the CDN look like a hardcoded dependency, and that is the one that fails Guideline 6. The service exception rests on the site owner choosing it. The draft already says this correctly further down, "the model is chosen by the site owner rather than user-supplied at runtime", it just needs to lead rather than trail.

Two smaller edits:

• "The plugin server hosts and transmits nothing" is ambiguous. Better: the plugin's server-side code makes no external requests at all, every fetch is the browser's.
• Typo in the original: "locall".

Item 2: voy .module.wasm (still open)

T4 softened this to "please consider including the source", so it reads as a request rather than a block. Two options:

1. Vendor the voy Rust source into the repo and remove the argument entirely.
2. Reply with the upstream reference (readme.txt:86 already carries https://github.com/tantaraio/voy) and keep it as is.

@ivdimova, you are closest to the build, what would you do?

Sequencing (the thing that produced T4)

The reply and a fresh zip go together. Every review email carries the same checklist: uploaded the updated version and replied to this email. Replying alone re-enters the queue with unchanged code.

Order: merge #230, settle the voy question, finalise the reply wording, rebuild, test on a clean install with WP_DEBUG on, upload as schmitzoide, then reply quoting R agentic-admin/schmitzoide/1Jun26/T4.

Rejection window is roughly 28 August 2026.

[pluginslab]

Progress 23 Aug — both remaining code items closed, reply drafted

Rejection window is ~28 August, so this is the run at it.

Housekeeping

• fix: address WP.org T4 review items (#228) #230 merged as e3f083a. uploads-scan.php now resolves .well-known via get_home_path(), and vector-store.js is pinned to @3.8.1.

Item 2 (voy .module.wasm) — decided: removed, not vendored. #231 open.

Rather than vendor the Rust source, the dependency is gone. voy-search did one job, nearest-neighbour lookup over Xenova/all-MiniLM-L6-v2 embeddings, which are emitted L2-normalised, so cosine similarity is a plain dot product. At 384 dimensions an exhaustive scan over a few thousand chunks costs single-digit milliseconds, well under the cost of embedding the query. The whole Voy API surface lived in one file.

Result: build-extensions/ ships JavaScript and CSS only. No WebAssembly, no compiled artefacts, every distributed file traceable to source. That answers "please consider including the source" more completely than including the source would, and removes the argument going into a round we were warned could be the last.

Found and fixed on the way: index() rebuilt embeddings from scratch while pushing onto the existing chunkMetadata, so a second index run left the two positionally misaligned and returned the wrong chunk for a query. Latent under Voy, load-bearing after this change.

Item 1 (remote loading) — reply reframed per the notes above. Draft is at wporg-review-reply-t4.md. It now leads with configurable by the site owner rather than "strictly tied", says plainly that the plugin's server-side PHP makes no external requests at all, and scopes the no-data-transmitted claim to the default local mode so the optional remote-provider mode is not misrepresented. The @3.8.1 pin is used as evidence that the asset URLs are static and deliberate.

Verified on the built zip (not the dev tree), extracted and mounted in a clean WP Playground install with WP_DEBUG, WP_DEBUG_DISPLAY and SCRIPT_DEBUG on:

• Activates clean at 0.11.0, zero PHP errors, warnings or notices
• 34 abilities register
• uploads-scan executes successfully, confirming the guarded wp-admin/includes/file.php require makes get_home_path() available on that load path
• site-health, security-scan, plugin-list, file-scan all execute without error
• Zip: 4.5 MB, 62 files, no .wasm/.exe/.so/.dll/.bin, no markdown, tests or package.json
• 91 unit tests pass, composer lint 0 errors, lint-js clean on every modified file

Still unverified, and it should be before upload: the browser path for the new cosine search. search() embeds via the Transformers.js CDN import and the store needs IndexedDB, neither of which has a test double here, and Playground has no WebGPU. Needs a manual pass on a real install: enable the knowledge base, index the codebase, run a code search, confirm results and scores look sane. Existing users re-index once, since the v1 → v2 IndexedDB upgrade drops the old Voy index.

Remaining to close this out

• Browser check above
• Merge fix: drop voy-search and the WASM module it distributed (#228) #231
• Upload agentic-admin.zip via "Add your plugin" as schmitzoide
• Reply in the existing thread quoting R agentic-admin/schmitzoide/1Jun26/T4

Upload and reply go together, per the definition of done.

[pluginslab]

Browser check done, it passes. All code items closed.

Correcting my earlier comment today, which said the check was "running now". It ran.

Setup: real install, WebGPU, Qwen2.5-7B, knowledge base indexed at 11,241 chunks.

Query: "find the code that verifies WordPress core file checksums"

9016: .../abilities/security/verify-core-checksums.php    (0.722)
9014: .../abilities/security/verify-core-checksums.php    (0.680)
9028: .../abilities/security/verify-plugin-checksums.php  (0.652)

What this confirms:

• The new code ran. The log line is [VectorStore] "Search results:". The old voy path logged "Voy results:", so this cannot be a stale bundle.
• Results are correct and ranked sensibly, with the sibling file third.
• Scores are real cosine values, not the topK - rank placeholder voy forced. Descending, well separated.
• No misalignment. Snippets belong to the paths above them, which is the index() bug fixed in fix: drop voy-search and the WASM module it distributed (#228) #231.
• Persistence works. After a hard refresh: Restored index from IndexedDB (11241 chunks). The v1 → v2 migration, the Float32Array round-trip and the new embedding-index store all behave.
• Performance holds. 11,241 chunks is roughly triple what I estimated in fix: drop voy-search and the WASM module it distributed (#228) #231 and the scan is still instant, so no ANN index is warranted at this scale.

Two errors appeared in the console, neither from #231, both pre-existing and worth their own issues after publication:

• [App] "Auto-load failed:" Error: Model is already loading, a race between auto-load and manual load. Model loaded fine regardless.
• Cache API operation failed: Context is stopped, service worker, during hard refresh.

---

Where this leaves the submission

All three T4 items are closed. Nothing engineering-side is outstanding.

Remaining: merge #231, then upload agentic-admin.zip as schmitzoide and send the reply from wporg-review-reply-t4.md quoting R agentic-admin/schmitzoide/1Jun26/T4. Together, per the definition of done.

The issue body has been brought up to date: items 2 and 3 marked resolved, the item 1 side issue marked fixed, the Plan checklist ticked, and #232 / #233 added to the do-not-merge list. Earlier comments are left as written, since the point of this issue is to preserve the thread. Two things in them are now stale and worth knowing when reading back:

1. The 18 Aug comment offers option 2 for the WASM as "reply with the upstream reference (readme.txt:86 already carries the voy link)". That line no longer exists, it was rewritten when the dependency was removed.
2. That same comment asks @ivdimova which option to take. Answered by action, with the reasoning in fix: drop voy-search and the WASM module it distributed (#228) #231.

Rejection window is ~28 August, so 5 days.

[pluginslab]

Submitted 27 Aug 2026 ✅

Zip uploaded via "Add your plugin" as schmitzoide, and the reply sent in the existing thread quoting R agentic-admin/schmitzoide/1Jun26/T4. Together, per the definition of done. One day inside the ~28 Aug rejection window.

What shipped

• fix: address WP.org T4 review items (#228) #230 — uploads-scan.php resolves .well-known via get_home_path(); Transformers.js pinned to @3.8.1 (@ivdimova)
• fix: drop voy-search and the WASM module it distributed (#228) #231 — voy-search and its .module.wasm removed; vector search is now plain-JS cosine
• fix: correct the External services disclosure (#228) #234 — External services disclosure corrected to match the code
• fix: bump "Tested up to" to 7.1 in both headers (#228) #235 — Tested up to bumped to 7.1 in both headers (open, needs review; this is the state of the submitted zip, so main should carry it)

The upload bounced once, worth recording

The automated scan rejected the first attempt:

readme.txt ERROR: outdated_tested_upto_header: Tested up to: 7.0 < 7.1

The obvious fix would have bounced a second time. agentic-admin.php carries its own Tested up to header, which overrides the readme, and Plugin Check flags the mismatch as a separate error. Running Plugin Check 2.1.0 locally against the built zip caught it before re-upload.

Final state of the submitted artifact, verified in a clean WP Playground install:

• Plugin Check: 29 static checks, 0 errors, 5 warnings
• The 5 warnings are pre-existing direct-DB-call cases (db-optimize.php:84, schema-extract.php:127,134, database-check.php:305) already documented in the 0.11.0 changelog. Manual-review items, not gate failures.
• Activates clean with WP_DEBUG on, zero PHP errors, 34 abilities register, version 0.11.0
• Zip: 4.3 MB, 62 files, no .wasm or any other binary

Lesson for next time: run Plugin Check against the built zip before uploading, not after a rejection. It is the same tool the automated scan uses.

---

Still open

• Merge fix: bump "Tested up to" to 7.1 in both headers (#228) #235 so main matches the submitted zip
• Agree the T5 fallback on remote loading (item 1). Unblocked now, but better decided before a reply is needed under pressure than during one.
• Keep feat: MCP server endpoint (read-only, v0.12.0) #216, fix: ReAct reliability pass (structured output, preferSummarize, stale docs) #229, fix: upgrade protobufjs to 8.0.1, 7.5.5 (CVE-2026-41242) #232, fix: upgrade tar to 7.5.19 (CVE-2026-59873) #233 unmerged until the plugin is published

This issue stays open until the plugin is approved and published. If a T5 lands, it gets appended here.