Support existing wp-scripts plugins and standalone plugin output

[noeltock]

Problem

A folder of block files is not “build-ready” unless it matches the destination plugin's source root, build root, build dependency, entry discovery, and PHP registration strategy. Guessing those conventions risks a block that compiles nowhere or an unsafe edit to an existing plugin. Closes #7.

Solution

Most original blockers were repaired, but host recognition still accepts a custom build shape that is incompatible with the planned integration. The pull request is ready for review.

Testing & verification

• Local run — npm run typecheck → pass.
• Local run — npm run test → pass.
• Local run — npm run build → pass.
• Not run — no live/manual verification; this Foundry run has no browser.

Risk / rollout

Small, targeted change — see the diff for the affected paths.

Must-fix blockers from review

• unsupported-host-detection · Host detection still accepts positional build entry points, such as wp-scripts build custom.js. Those disable metadata-based entry discovery, so the host can be misclassified and generated files placed where its build will not process them.

---

Built by Foundry (writer: Codex; independent review: Warden — block, 1 blockers).

[noeltock]

Independent adjudication of Warden's blockers (Codex gpt-5.6-sol, high)

Requested by Noel: each blocker judged against the diff rather than waiting. Confirmed items below are the revision brief.

VERDICT: CONFIRMED — isWpScriptsBuild() accepts any command beginning with wp-scripts build, while the later checks reject only shell operators and selected configuration flags. Consequently, wp-scripts build custom.js passes detection; commandPath() then defaults the roots to src and build, and the returned profile incorrectly claims recursive block.json discovery. This violates the requirement to refuse unsupported or ambiguous build layouts before writing. Minimally, parse the build command’s arguments and reject any positional entry point after build, while still allowing the explicitly supported flags and their values. Add a regression test showing wp-scripts build custom.js returns an unsupported profile.

OVERALL: REVISE. The detector can approve a plugin whose build command bypasses the discovery method that generated blocks depend on. A small validation rule and regression test are required before this is safe to merge.

[noeltock]

[unsupported-host-detection] Host detection still accepts positional build entry points, such as wp-scripts build custom.js. Those disable metadata-based entry discovery, so the host can be misclassified and generated files placed where its build will not process them.
The earlier handoff was wrong for this request because it named the outcome without explaining why the previous shape did not meet it. The revision rejects positional build entries and adds the requested regression coverage. The previously confirmed unsafe host misclassification is addressed. The exact changes below show how this revision now addresses that concern.

Independent adjudication of Warden's blockers (Codex gpt-5.6-sol, high)

Requested by Noel: each blocker judged against the diff rather than waiting. Confirmed items below are the revision brief.

VERDICT: CONFIRMED — isWpScriptsBuild() accepts any command beginning with wp-scripts build, while the later checks reject only shell operators and selected configuration flags. Consequently, wp-scripts build custom.js passes detection; commandPath() then defaults the roots to src and build, and the returned profile incorrectly claims recursive block.json discovery. This violates the requirement to refuse unsupported or ambiguous build layouts before writing. Minimally, parse the build command’s arguments and reject any positional entry point after build, while still allowing the explicitly supported flags and their values. Add a regression test showing wp-scripts build custom.js returns an unsupported profile.

OVERALL: REVISE. The detector can approve a plugin whose build command bypasses the discovery method that generated blocks depend on. A small validation rule and regression test are required before this is safe to merge.
The earlier handoff was wrong for this request because it named the outcome without explaining why the previous shape did not meet it. The revision rejects positional build entries and adds the requested regression coverage. The previously confirmed unsafe host misclassification is addressed. The exact changes below show how this revision now addresses that concern.

Exact changes

• Updated package-lock.json — The revision rejects positional build entries and adds the requested regression coverage. The previously confirmed unsafe host misclassification is addressed.
• Added package.json — The revision rejects positional build entries and adds the requested regression coverage. The previously confirmed unsafe host misclassification is addressed.
• Updated src/plugin/profile.ts — The revision rejects positional build entries and adds the requested regression coverage. The previously confirmed unsafe host misclassification is addressed.
• Updated test/plugin.profile.test.ts — The revision rejects positional build entries and adds the requested regression coverage. The previously confirmed unsafe host misclassification is addressed.

Testing

• Updated test coverage — test/plugin.profile.test.ts now covers the revised behavior: The revision rejects positional build entries and adds the requested regression coverage. The previously confirmed unsafe host misclassification is addressed.
• Local run — npm run typecheck → pass.
• Local run — npm run test → pass.
• Local run — npm run build → pass.
• Not run — no live/manual verification; this Foundry run has no browser.

Trade-offs

• Human decision: none — no unresolved trade-off was recorded for this revision.

Commit: 7a3cdd1