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

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 #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 #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 #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 #232 / #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 #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. #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 #229 until the submission clears. Parked by its own design.

Plan

• Merge #227 (done, d1d0108)
• Fix uploads-scan.php:175 → get_home_path() (#230, e3f083a)
• Pin vector-store.js to @3.8.1 to match the changelog (#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. #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 #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.