Prepare Data Machine for WordPress.org plugin directory submission after 1.0

[chubes4]

Context

Once Data Machine reaches 1.0, Chris intends to submit it to the WordPress.org Plugin Directory.

That means the 1.0 cleanup needs to leave the plugin in a directory-ready state, not just a private-runtime-ready state.

Why this matters

WordPress.org submission adds constraints beyond internal correctness:

• Plugin Check findings need to be fixed or intentionally justified.
• Readme, assets, license metadata, stable tag, and headers need to be submission-ready.
• Bundled dependencies and generated/vendor files need to satisfy directory expectations.
• Domain-specific or private-runtime assumptions should be removed or documented.
• Security, escaping, sanitization, capability checks, nonces, and direct DB access need a directory-quality pass.
• Any AI assistance disclosure policy for PRs is separate from WordPress.org packaging, but the codebase should remain reviewable and attributable.

Related issues

• Plugin Check: audit custom-table direct database findings #2298 Plugin Check: audit custom-table direct database findings
• Plugin Check: review slow WP_Query argument findings #2299 Plugin Check: review slow WP_Query argument findings
• Plugin Check: fix or justify hook naming findings #2300 Plugin Check: fix or justify hook naming findings
• lint: pre-existing PHP lint debt on main (Yoda condition + statement alignment) #2369 lint: pre-existing PHP lint debt on main
• Final pre-1.0 cleanup: remove migrations and backward-compatibility paths #2418 Final pre-1.0 cleanup: remove migrations and backward-compatibility paths

Desired shape

• 1.0.0 is tagged only after WordPress.org submission readiness is verified.
• Plugin Check passes or has documented justifications for unavoidable findings.
• readme.txt, plugin headers, screenshots/assets, license, and dependency packaging are ready for submission.
• Public-facing docs describe Data Machine as a WordPress-native automation/agent runtime without private-site assumptions.
• The final package excludes obsolete migrations/backcompat and any development-only artifacts.

Acceptance criteria

• Run Plugin Check against the 1.0 candidate and resolve/justify findings.
• Run lint/tests on the 1.0 candidate.
• Verify readme.txt sections, stable tag, tested-up-to, requires-at-least, requires PHP, license, and tags.
• Verify no secrets, private endpoints, local paths, or internal-only assumptions ship in the plugin package.
• Verify vendor/dependency packaging is acceptable for WordPress.org SVN submission.
• Document the submission steps and final release checklist.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.5)
• Used for: Capturing Chris's WordPress.org submission goal as a tracked 1.0/release readiness issue.

[chubes4]

1.0 packaged-candidate work packages

The release-readiness audit confirms this issue remains the correct top-level WordPress.org gate. Its concrete milestone children are:

• Plugin Check: audit custom-table direct database findings #2298 refresh and resolve/justify packaged direct-database findings
• Plugin Check: review slow WP_Query argument findings #2299 refresh and resolve/justify packaged slow-query findings
• Plugin Check: fix or justify hook naming findings #2300 refresh and resolve/justify packaged hook naming findings
• ci: full main test suite exceeds Homeboy command budget #2850 obtain a trustworthy green full-suite main run without a command-budget timeout

The final #2424 pass also owns current package metadata gaps: stale readme.txt content/changelog, source/support links, build-ignore filename casing, WordPress.org assets, dependency/license review, private-path scan, and submission checklist. Old finding counts are evidence only; rerun Plugin Check against the final 1.0 package before changing code.

#2369 and #2798 are stale whole-tree PHPCS reports and are being closed rather than carried as false release blockers.

[chubes4]

Removed the 1.0-blocker label because this issue explicitly covers WordPress.org submission after the 1.0 tag. Package readiness remains tracked here as post-1.0 distribution work.

[chubes4]

Correction from the maintainer (2026-08-23): Data Machine 1.0.0 and the WordPress.org submission candidate are the same release. This supersedes the earlier comment describing directory submission as post-1.0. Restored this issue to the 1.0 milestone; Plugin Check, package metadata, dependency/license review, private-path scan, assets/readme readiness, and submission checklist are required before the 1.0.0 tag.

[chubes4]

Runtime-backed multisite gate remains blocked upstream

Retested PR #3361 head 7268d1c4a and exact package SHA256 e65dac886a6ee35db0003bb923b9a5779003e1e3b3bfb57b8cfecfee7c544073 through the supported current boundary:

wp-codebox run-fuzz-suite \
  --input-file .multisite-2424-workload.json \
  --format=json \
  --runner-mode=runtime-backed \
  --artifacts .multisite-2424-evidence

The dry run passes and resolves Blueprint enableMultisite, the readonly exact-package mount, network activation, two WP-CLI site bootstraps, and browser screenshot capture. The real runtime still fails before its first workload command with:

Error when executing the blueprint step #2: The current host is 127.0.0.1:56491, but WordPress multisites do not support custom ports.

Retained evidence:

• run run_5ab46731e85549e0976c34715c7481b1
• runtime runtime-mt6oqx3t-u38ffj
• .multisite-2424-evidence/manifest.json
• .multisite-2424-evidence/recipe-run-effective-recipe.json
• .multisite-2424-evidence/recipe-run-failure-diagnostics.json
• WP Codebox binary SHA256 fc817440b6efe83f8358a223dbdf46def4bf23d5c5db4e71fa1e7f1762ad76c0

Tracked upstream as Automattic/wp-codebox#2342: Automattic/wp-codebox#2342

No Data Machine package command ran, so this is not a package failure and no source change was made. Network activation/two-site bootstrap/screenshot evidence remain blocked until the upstream runtime-backed path actually applies #2316's portless URL normalization.

[chubes4]

Runtime-backed multisite package gate: passed

Retested PR #3361 head 7268d1c4a and exact package SHA256 e65dac886a6ee35db0003bb923b9a5779003e1e3b3bfb57b8cfecfee7c544073 with managed WP Codebox 0.23.4 at c3385816 through run-fuzz-suite --runner-mode=runtime-backed and Blueprint enableMultisite.

Green evidence:

• run run_3d30cd7dbbdc4739945b706538438a49
• runtime runtime-mt6pijnw-dlerex
• artifact bundle digest 4be19f384018eaa51af18d0d1d8278050a35ea0c73764b76a7370b413dbd7629
• retained bundle .multisite-2424-evidence-managed-0234-green2/runtime-mt6pijnw-dlerex/
• artifact verification: valid, zero violations
• wordpress.plugin-state: multisite true, requested network true, network activation supported, data-machine/data-machine.php network-active
• site 2 created at http://127.0.0.1/second/
• site 1: Data Machine 0.175.18, network_active=true, bootstrapped=true
• site 2: Data Machine 0.175.18, network_active=true, bootstrapped=true
• browser probe: exit 0, no-page-errors passed, console/errors empty
• screenshot files/browser/screenshot.png, SHA256 d413bea6092dbf4b588b0dc6fa9db4634cc97c1235ade39eb3aad083085a6320

Automattic/wp-codebox#2342 was closed as stale installed-runtime distribution skew: the installed public binary is 0.21.0, while current managed 0.23.4 contains #2316 and passes. The release runner must use WP Codebox >=0.23.4. The multisite package blocker is removed; exact 1.0.0 release bytes, full lint, and approved artwork remain open gates.