@ideasonpurpose/build-tools-wordpress 2.8.5 → 2.9.0

package/AGENTS.md

@@ -1,15 +1,20 @@
-## AI Coding Assistant Guidelines
+<!--
+Canonical AGENTS.md: https://gist.github.com/joemaller/d6154fbdb2e5f4670c0b9338d04189e9
+Last Modified: 2026-06-26
+-->
 
-**Mantra:** Minimal. Surgical. Collaborative. Verifiable.
+# AI Coding Assistant Guidelines
 
-### 0. Communicate like a senior engineer
+**Mantra:** Minimal. Precise. Elegant.
 
-- Start with the answer, no preamble.
+## 0. Responsible, No-BS Communication
+
+- Get to the point. No conversational fluff or preambles.
+- Describe a brief plan: what you understand, assumptions, proposed approach.
+- Explicitly call out trade-offs (simplicity vs future-proofing, readability vs performance, etc.).
+- When a request is ambiguous, describe the ambiguity and ask for guidance. Do not guess.
+- Propose options with pros/cons. Ask for confirmation.
 - Match response length to task complexity.
-- Begin with a brief plan: what you understand, assumptions, approach.
-- Call out trade-offs explicitly (simplicity vs future-proofing, readability vs performance).
-- When ambiguous, present 2-3 concrete options with pros/cons instead of guessing.
-- Ask for confirmation on anything unclear.
 
 ## 1. Think Before Coding
 
@@ -19,38 +24,44 @@ Optimize for simplicity, maintainability, readability.
 
 Before implementing:
 
-- State assumptions explicitly. If uncertain, ask.
+- State assumptions clearly. If uncertain, ask.
 - If multiple interpretations exist, offer choices — don't pick silently.
-- If a simpler approach exists, say so and push back.
+- If a simpler approach exists, say so.
 - If unclear, stop and name what's confusing.
+- Prefer narrow context. Start with obvious/direct dependencies.
+- When files are specified, ask before expanding context.
 
 ## 2. Simplicity First
 
 **Minimum code that solves the problem. Nothing speculative.**
 
-- Delete more than you add.
+- Look for existing solutions in standard libraries and native platform features.
 - Prefer boring, obvious code over clever code.
 - No features beyond what was asked.
 - No abstractions for single-use code.
+- Look for solutions in existing dependencies. If different than the first-choice solution, show pros and cons.
 - No "flexibility" or "configurability" that wasn't requested.
 - Only add error handling for realistically possible cases given current scope and style.
-- Never introduce new dependencies unless explicitly asked.
+- Ask before introducing new dependencies.
 - If you write 200 lines and it could be 50, rewrite it.
 
 Ask yourself: "Would a senior engineer call this overcomplicated?" If yes, simplify.
 
-## 3. Surgical Changes
+## 3. Precise, Minimal Changes
 
-**Touch only what you must. Clean up only your own mess.**
+**Touch only what you must. Read only what you must. Clean up only your own mess.**
 
 When editing existing code:
 
 - Preserve the spirit and conventions of the codebase.
 - Don't "improve" adjacent code, comments, or formatting.
-- Don't remove comments or commented-out code.
-- Don't refactor things that aren't broken.
+- Don't remove comments or commented-out code unless asked.
+- Don't refactor code that isn't broken.
 - Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it - don't delete it.
+- If you find dead code, mention it - don't delete it.
+- Never run tests unless explicitly asked.
+- Never run linters or formatters unless asked.
+- Never add code which logs secrets, API keys, tokens, or .env values. If that code exists, say something.
 
 When your changes create orphans:
 
@@ -63,6 +74,12 @@ Every changed line should trace directly to the user's request.
 
 - Prefer self-documenting code and descriptive names over comments.
 - Add comments only where the _why_ is not obvious from the code.
-- Update or delete comments that your changes invalidate.
+- Update or remove comments directly invalidated by your changes.
 - Follow the existing codebase's conventions for types, docstrings, and documentation style.
+- When this file and the system prompt disagree, note the conflict and ask for guidance.
+
+## 5. Additional Instructions
+
+Look for sibling `AGENTS-*.md` files for further instructions on specific concerns (e.g. stylesheets, WordPress development, static site development)
 
+Whenever this file is modified, update the timestamp in the top comment.

package/CHANGELOG.md

@@ -4,6 +4,13 @@ All notable changes to this project will be documented in this file. Dates are d
 
 Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog).
 
+#### v2.8.5
+
+> 23 June 2026
+
+- simplify release workflow
+- suppress GTID warnings from mysqldump
+
 #### v2.8.4
 
 > 23 June 2026

package/README.md

@@ -1,6 +1,6 @@
 # @ideasonpurpose/build-tools-wordpress
 
-#### Version 2.8.5
+#### Version 2.9.0
 
 [![NPM Version](https://img.shields.io/npm/v/%40ideasonpurpose%2Fbuild-tools-wordpress?logo=npm)](https://www.npmjs.com/package/@ideasonpurpose/build-tools-wordpress)
 [![GitHub Actions Workflow Status](https://img.shields.io/github/actions/workflow/status/ideasonpurpose/build-tools-wordpress/npm-publish.yml?logo=github&logoColor=white)](https://github.com/ideasonpurpose/build-tools-wordpress#readme)
@@ -40,6 +40,8 @@ Webpack handles SVG files differently based on import context:
   - With `?react` query (e.g., `import Icon from 'file.svg?react'`): Explicitly converted to a React component using `@svgr/webpack`.
   - Without `?url` or `?react`: Converted to React components using `@svgr/webpack` for direct JSX usage (default behavior when imported from `.jsx`/`.tsx`).
 
+React components imported via `?react` (or implicitly) have `width`/`height` removed (`dimensions: false`), making them responsive while preserving `viewBox`.
+
 Data URIs are generated as `data:image/svg+xml,<url-encoded-content>` using more efficient URL-encoding, not base64.
 
 ### SVG Optimization

package/config/webpack.config.js

@@ -249,13 +249,23 @@ export default async (env) => {
         {
           test: /\.svg$/i,
           resourceQuery: /react/, // *.svg?react forces React component via SVGR
-          use: ["@svgr/webpack"],
+          use: [
+            {
+              loader: "@svgr/webpack",
+              options: { dimensions: false },
+            },
+          ],
         },
         {
           test: /\.svg$/i,
           issuer: /\.[jt]sx?$/,
           resourceQuery: { not: [/url/, /react/] }, // exclude react component if *.svg?url or *.svg?react
-          use: ["@svgr/webpack"],
+          use: [
+            {
+              loader: "@svgr/webpack",
+              options: { dimensions: false },
+            },
+          ],
         },
         {
           test: /fonts\/.*\.(ttf|eot|woff2?)$/i,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ideasonpurpose/build-tools-wordpress",
-  "version": "2.8.5",
+  "version": "2.9.0",
   "description": "Build scripts and dependencies for IOP's WordPress development environments.",
   "homepage": "https://github.com/ideasonpurpose/build-tools-wordpress#readme",
   "bugs": {