chore(assets): update plugin directory icon and banner artwork

[galbus]

What changed

Replaces the WordPress.org plugin directory artwork with the new BeyondWords brand assets — all four required sizes in .wordpress-org/:

File	Role
icon-128x128.png	required icon
icon-256x256.png	retina icon
banner-772x250.png	required banner
banner-1544x500.png	retina banner

Why

The directory listing was still showing the previous artwork. These are the only four sizes WordPress.org reads, so the new source files (512×512 icon, 3088×1000 banner) are downscaled into the set rather than added alongside it.

Reviewer notes

• The banner source is 3088×1000, which divides exactly into both banner sizes (÷2 and ÷4) — no crop, no letterboxing, aspect ratio preserved.
• The icon keeps the white background of the source artwork.
• Assets only — no PHP, JS or CSS touched, so no test impact.
• The script now targets assets/ and cleans up the stale .wordpress-org/ directory left by earlier deploys.

🤖 Generated with Claude Code

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check

[gouravkhunger]

@galbus This is an initial automated PR review.

Soft score: Requires changes

• Banner sizes/downscales are exact and the artwork reads well — that part is right.
• deploy-assets.sh copies into SVN /.wordpress-org/, but WordPress.org serves from /assets/ — live SVN still has the old bytes there, so merging this changes nothing on the listing.
• The new icon is flat black on an opaque white square; the old one was the gradient mark on transparency — looks like the wrong source variant, and it clashes with the gradient banner in this same PR.

Full review

Architectural map

What it is: four binary PNG replacements in .wordpress-org/. Zero lines of PHP, JS, CSS, config or test code. git show --stat confirms: 4 files changed, 0 insertions(+), 0 deletions(-).

Affected subsystems

WordPress.org plugin-directory presentation only. Nothing in src/, no runtime path, no build entry. The plugin ZIP is unaffected — .wordpress-org/ is not shipped in the distributed artifact, only pushed to the SVN asset area.

Dependency graph changes

None. No composer.json, package.json, or autoload map touched, so no composer dump-autoload needed.

Public API / DB / auth changes

None on all three. No REST routes, meta keys, options, filters, nonces, capabilities, escaping or sanitisation involved.

Verified asset facts

File	Dimensions	Old → new bytes
icon-128x128.png	128×128	21,561 → 5,123
icon-256x256.png	256×256	46,496 → 11,484
banner-772x250.png	772×250	60,079 → 52,021
banner-1544x500.png	1544×500	157,626 → 285,234

All four dimensions are exactly the sizes WordPress.org reads. Banners are clean 2×/4× downscales of the 3088×1000 source — no crop, no letterboxing, text legible at 772×250. Banner artwork itself looks correct and on-brand.

---

Findings

1. The deploy script writes to a path WordPress.org does not read — the listing will not change (major)

.github/scripts/deploy-assets.sh lines 36-39 copy the directory into $PLUGIN_SVN_PATH/.wordpress-org. WordPress.org serves directory artwork from /assets, not from a dot-directory at SVN root.

Live SVN confirms both directories exist and both still hold the old artwork:

https://plugins.svn.wordpress.org/speechkit/assets/icon-128x128.png          → 21561 bytes (old)
https://plugins.svn.wordpress.org/speechkit/.wordpress-org/icon-128x128.png  → 21561 bytes (old)
local .wordpress-org/icon-128x128.png                                        →  5123 bytes (new)

So merging this PR pushes the new files into /.wordpress-org/, leaves /assets/ untouched, and the directory listing keeps showing the previous artwork — the exact problem the PR sets out to fix. This is pre-existing infra, not introduced here, but it blocks the stated outcome. Fix is one line: copy to $PLUGIN_SVN_PATH/assets, and the stray /.wordpress-org/ in SVN should be svn rm'd.

2. The new icon is flat black on opaque white; the old one was the gradient mark on transparency (major)

The previous icon-256x256.png was the BeyondWords atom in the purple→red brand gradient with a transparent background (corner pixel RGBA 0,0,0,0). The new one is solid black on an opaque white square (corner pixel 255,255,255,255).

That reads as the wrong source file — a monochrome/black logo variant rather than the full-colour one — and it clashes with the new banner in the same PR, which uses the purple/magenta gradient with a white mark. The white square also stops sitting cleanly on non-white card backgrounds. The PR notes "keeps the white background of the source artwork", so it may be deliberate; worth confirming against the brand pack before merge, because a black icon next to a gradient banner is the one visual inconsistency here.

3. Missing changelog entry (blocking per repo rules)

AGENTS.md non-negotiable #4: every PR is listed in the changelog before it merges. grep -n "620" readme.txt returns nothing. #618 was added to the 7.0.0 block, so follow that — one bullet under **Codebase Enhancements**.

Risky files

None in the correctness sense — no executable code. Risk is entirely reputational/visual: these are the first thing a user sees on the directory page, and asset pushes on main are not gated by a preview.

Deployment/config

deploy_assets runs on push to main (not on tag), so this ships on merge, independently of a version bump. No config or secrets changes. deploy-assets.sh is untouched by this PR — see finding 1 for why it should be.

Review priority order

1. Deploy destination (assets/ vs .wordpress-org/) — without this the PR is a no-op in production.
2. Icon colourway and background — confirm black-on-white is the intended brand asset.
3. Changelog entry.
4. Banner artwork — looks good, no action.

[galbus]

Thanks @gouravkhunger — both points verified, one fixed and one needs a decision.

1. SVN deploy path — confirmed and fixed in da9efe8.

deploy-assets.sh copied into $PLUGIN_SVN_PATH/.wordpress-org, which is our repo's source directory name; WordPress.org reads the listing artwork from /assets in SVN. So this was a pre-existing bug and you're right that merging the PNGs alone would have changed nothing on the live page. The script now copies to assets/, and also removes the stale .wordpress-org directory from SVN so the mistargeted copy left by earlier deploys gets cleaned up in the same commit.

2. Icon variant — confirmed, but it's a deliberate hand-off and I've left it for @galbus to call.

Your read of the bytes is exact:

	background	mark
old icon-256x256.png	fully transparent (min alpha 0)	purple→pink gradient
new icon-256x256.png	opaque white (100% of pixels alpha 255)	flat black

That's not a downscaling artifact — the supplied 512×512 source is itself flat black on opaque white, so the variant difference is in the input, not in anything this PR did to it. I've flagged the clash with the gradient banner rather than substituting artwork I wasn't given; swapping to a transparent gradient icon is a branding decision, not a build fix. @galbus — if the intended source was the gradient-on-transparency mark, send it over and I'll regenerate both sizes.

Also still outstanding, unrelated to this review: the changelog entry. readme.txt has no unreleased version block (7.0.0 shipped 11th August), so this needs a **Codebase Enhancements** line once the next version number is decided.

🤖 Addressed by Claude Code

[galbus]

@gouravkhunger assets used here have been supplied by @ptrko. If they don't look correct on deploy then we can update them directly using SVN without bumping the plugin version.