DEV Community: Susumu Takahashi

The excluded-plugin setting that Playwright ignored — fixing browser-mode updates and false residual warnings

Susumu Takahashi — Thu, 20 Aug 2026 03:08:25 +0000

The symptom

In browser-mode maintenance (Playwright, no SSH), plugins marked as "excluded from update checks" were still being updated. After the run, a "plugin updates remaining" WARNING email arrived every time.

The excluded plugins were intentionally left behind, but the residual check treated them as unfinished updates and fired a warning — a two-part problem: wrong behavior and a misleading alert.

SSH path vs. Playwright path

On SSH-capable sites, WP-CLI's --skip-plugins flag carries the ignored_plugins list into the update command. That path already excluded them correctly.

The Playwright path was different. browser_update_remaining_plugins() worked by clicking the "select all" checkbox on update-core.php and submitting the form — no filtering at all.

# Before: select-all, ignored_plugins never consulted
page.check('input[name="action"][value="update-selected-plugins"]')
for cb in page.query_selector_all('input[name="checked[]"]'):
    cb.check()

This function is the chokepoint for two flows: pure browser-mode updates (run_browser_update_flow) and the browser residual pass that runs after SSH updates (run_browser_residual_update, on by default). So even SSH sites could have excluded plugins updated by the residual pass. Browser-driven bulk updates are also outside the scope of pinpoint rollback, meaning there is no automatic recovery if a wrong update goes through.

Fix 1 — `_ignored_plugin_slugs()` and `_plugin_slug_from_checkbox_value()`

When excluded plugins are configured, the fix replaces the select-all approach with per-checkbox evaluation.

def _ignored_plugin_slugs(site: dict) -> set[str]:
    raw = site.get("ignored_plugins", "")
    return {s.strip().lower() for s in raw.split(",") if s.strip()}

def _plugin_slug_from_checkbox_value(value: str) -> str:
    return value.split("/")[0].strip().lower() if "/" in value else value.strip().lower()

Plugin checkboxes on update-core.php use a value like contact-form-7/wp-contact-form-7.php. The slug is the part before the slash. Normalizing to lowercase covers casing differences in user input.

With excluded plugins configured:

ignored = _ignored_plugin_slugs(site)
if ignored:
    for cb in page.query_selector_all('input[name="checked[]"]'):
        val = cb.get_attribute("value") or ""
        slug = _plugin_slug_from_checkbox_value(val)
        if slug and slug not in ignored:
            cb.check()
        # if value is missing, keep it checked (safe side: update rather than skip)

Sites with no excluded plugins keep the original behavior (select-all with individual fallback) exactly as before.

Fix 2 — `_browser_plugin_residual_state()` stops false residual warnings

The residual check had the same gap. Before the fix, any remaining update form on update-core.php counted as "updates pending." An excluded plugin left intentionally on the page was enough to trigger a WARNING.

def _browser_plugin_residual_state(page, site: dict) -> bool:
    ignored = _ignored_plugin_slugs(site)
    checkboxes = page.query_selector_all('input[name="checked[]"]')
    if not checkboxes:
        return False  # no form = nothing pending
    if not ignored:
        return True   # no exclusions = form present = pending (original behavior)
    for cb in checkboxes:
        val = cb.get_attribute("value") or ""
        slug = _plugin_slug_from_checkbox_value(val)
        if slug not in ignored:
            return True  # at least one non-excluded plugin still pending
    return False  # only excluded plugins remain — not pending

After this change, a site where only excluded plugins remain on update-core.php resolves to False (not pending), and no WARNING email is sent.

Test coverage

tests/test_browser_ignored_plugins.py — 21 new tests:

Slug normalization (7): slug/file.php format, single-file format, case and whitespace variation, missing value
Exclusion behavior (9): single exclusion, multiple exclusions, all excluded (zero updates), no exclusions (all updated), nonexistent slug in exclusion list does not over-exclude
Residual check (5): only excluded remain → not pending, excluded + non-excluded remain → pending, no exclusions (original behavior), no form → not pending

The cp932 crash in the build gate that only happened on Windows — static detection, behavioral testing, and a negative check

Susumu Takahashi — Wed, 19 Aug 2026 01:26:25 +0000

The symptom

During the Windows build for v1.6.11, the build gate reported "version number consistency check failed." But the version numbers were correct everywhere.

The real cause was not a version mismatch. The build gate in build_app.py calls tools/bump_version.py via subprocess and checks its exit code. The success messages in bump_version.py contained emoji (✅ and similar). On Japanese Windows, the default code page is cp932, which cannot encode those characters. Python raised a UnicodeEncodeError on the very first write to stdout, the process exited non-zero, and the build gate misread that as a version inconsistency.

UnicodeEncodeError: 'cp932' codec can't encode character '✅' in position 0

Why it didn't show up on Mac

macOS terminals use UTF-8 by default. Running bump_version.py directly or via subprocess on Mac produces no encoding errors — emoji flows through cleanly.

On Japanese Windows, the process inherits the cp932 code page. U+2705 (✅) has no cp932 representation, so the write fails immediately. Because the build was always done on Mac first, this failure had no chance to appear in local testing. It only surfaced when the Windows build ran.

Fix 1 — replace emoji with ASCII

All emoji in tools/bump_version.py output were replaced with ASCII equivalents.

# Before
print(f"✅ {file}: {old} → {new}")
print(f"❌ NG: {file}")

# After
print(f"[OK] {file}: {old} → {new}")
print(f"[NG] {file}")

Emoji in terminal output can be helpful, but when output is consumed by another process over a pipe, encoding compatibility cannot be assumed. Tools invoked from build scripts should limit their output to ASCII.

Fix 2 — force UTF-8 in the subprocess call

The build gate was also updated to enforce UTF-8 on its end.

result = subprocess.run(
    [sys.executable, "tools/bump_version.py", "--check"],
    capture_output=True,
    encoding="utf-8",
    errors="replace",
    env={**os.environ, "PYTHONUTF8": "1", "PYTHONIOENCODING": "utf-8"},
)

PYTHONUTF8=1 forces UTF-8 for stdin/stdout/stderr in Python 3.7+. PYTHONIOENCODING=utf-8 covers older-style enforcement. errors="replace" prevents a crash if any unencodable character slips through — defense in depth.

Fix 3 — three-layer regression guard in `test_windows_cp932_safety.py`

Fixing the bug is not enough if the same failure can re-emerge. Three test layers were added to catch it before it reaches Windows.

Layer 1 — static detection: read the source file and verify that no cp932-incompatible character is present.

def test_bump_version_no_cp932_unsafe_chars():
    src = pathlib.Path("tools/bump_version.py").read_text(encoding="utf-8")
    for i, ch in enumerate(src):
        try:
            ch.encode("cp932")
        except (UnicodeEncodeError, UnicodeDecodeError):
            raise AssertionError(
                f"cp932-unsafe char U+{ord(ch):04X} at pos {i}: {ch!r}"
            )

Layer 2 — behavioral verification: run bump_version.py --check in a subprocess with PYTHONIOENCODING=cp932 set and assert that it exits 0.

def test_bump_version_check_runs_under_cp932():
    result = subprocess.run(
        [sys.executable, "tools/bump_version.py", "--check"],
        capture_output=True,
        env={**os.environ, "PYTHONIOENCODING": "cp932"},
    )
    assert result.returncode == 0, result.stderr

Layer 3 — negative check: inject an emoji intentionally and confirm that layer 1 raises AssertionError. This ensures the detector cannot become a test that always passes.

def test_cp932_detector_catches_emoji():
    with pytest.raises(AssertionError):
        src = "print('✅ ok')"
        for ch in src:
            ch.encode("cp932")

What to take away

When development and builds both happen on Mac, Windows-specific encoding failures have nowhere to appear until the Windows build runs. The failure mode here — correct Mac behavior, crash on Windows, misread error message pointing at the wrong cause — is easy to miss and easy to misdiagnose.

Designing tests that simulate Windows encoding constraints on Mac, before the Windows build, catches this category of failure at the CI level rather than at the point of release.

Placing corrections exactly where an LLM is tempted to sound plausible instead of right

Susumu Takahashi — Tue, 18 Aug 2026 00:12:55 +0000

Background

The support chatbot on our landing page feeds the contents of a knowledge base to an LLM as its system prompt, then lets it answer whatever a user asks. Running it in practice surfaced something a generic instruction like "answer accurately" doesn't cover: the same plausible-sounding mistake, repeated consistently, for certain specific kinds of questions.

An LLM has absorbed a huge amount of general technical knowledge. That's exactly why, the moment it's asked something, it tends to combine that general knowledge into an answer that sounds thoroughly convincing. The tricky part is that the answer is convincing enough that being wrong is hard to notice.

Example 1: guessing a hosting provider's SSH hostname format

When a user asks "I don't know my SSH hostname," an LLM is tempted to lean on general patterns and offer something like "it's usually formatted like such-and-such." And to be fair, some hosting providers do have typical hostname conventions.

But that's a dangerous kind of helpfulness. The actual format varies by hosting provider, plan tier, and even contract vintage — sometimes even within the same provider across different plans. An LLM offering "the common format" has no guarantee whatsoever that it matches this particular user's actual contract. If it's wrong, the user ends up with a new kind of confusion on top of the original one: "I looked exactly where the app told me to, and it's not there."

The correct answer is "check your hosting provider's control panel for the SSH connection details, and copy the exact string shown there" — not a guessed format sample. But the judgment that not offering a specific format is the right move isn't something a generic "answer accurately" instruction reliably produces on its own.

Example 2: a plausible-sounding but wrong "you need to convert this" instruction

Another case involves the format of private keys issued by one hosting provider we support. These keys are issued in PKCS#8 format, and since version 1.6.3 the app reads that format natively, with no extra steps.

But if an LLM is only given the question "my private key won't load," it can reach for general SSH knowledge and suggest something plausible-but-wrong, like "you might need to convert it to PuTTY format (.ppk)" — a step that's both unnecessary and beside the point for the current version. This is the same pattern: a suggestion that sounds helpful and technically coherent, but is simply incorrect for this product. The correct answer is the far simpler "update the app to the latest version, then point it at the downloaded key file as-is" — but the LLM finds the general-purpose conversion procedure more plausible-sounding.

Why a generic instruction alone isn't enough

Instructions like "answer accurately" or "don't guess when you don't know" can be written once, up front, in the system prompt. But they're too abstract to catch individual traps like these. From the model's perspective, both guessing a hostname format and describing a key-conversion procedure are "generally correct technical knowledge" — nothing in an abstract instruction signals that this specific product's circumstances make that generally-correct knowledge wrong here.

The fix: place a targeted correction right next to the trap

The approach we took was to attach a note — invisible to the end user — directly at the exact spot in the knowledge base where a particular question and fact live. Right next to the relevant FAQ entry, a note says, in effect: "when this question comes up, there's a plausible-sounding mistake the model tends to make here; the actual answer is this instead."

Rather than stating one abstract "don't hallucinate" rule in a single place, the idea is closer to administering a targeted inoculation at each specific spot where a mistake actually occurs. Whenever a new trap surfaces, a note gets added right at that spot. In practice, a pile of small, localized corrections does more for real answer quality than a single sweeping rule stated once at the top.

Wrap-up

An LLM's confidence and its accuracy are often hard to tell apart. Users tend to trust specific, confidently-stated information more, which makes it worse when that confidence turns out to be misplaced. Rather than relying solely on generic instructions to improve accuracy, identifying the exact spots where mistakes actually happen and placing a targeted correction there — one trap at a time — is the unglamorous foundation that makes a genuinely knowledgeable-sounding chatbot actually knowledgeable.

A support chatbot needs to be designed for what it won't answer, not just what it will

Susumu Takahashi — Mon, 17 Aug 2026 02:32:16 +0000

Background

The support chatbot on our landing page has a simple job: answer questions about the product's features, pricing, and troubleshooting. But a conversational AI built to answer questions shares a common weakness. Left unguarded, it tends to comply with requests designed to surface its own system prompt verbatim, or with phrasing that falsely claims special authority to unlock a different kind of answer.

The chatbot works by feeding a knowledge base file to the LLM as its system prompt, then letting it answer whatever the user asks. Rather than implementing this defense in application code — say, a regex filter on incoming messages — we chose to write it as an explicit policy inside the system prompt itself.

Thinking in categories of information, not keywords

The first decision was to describe what must be protected — things like source code or credentials — as categories of information, rather than relying on a list of specific banned words.

A filter built around "block any question containing word X" is trivially bypassed by rephrasing. Letting the model itself judge "does this question touch this category?" lets it generalize to phrasings nobody anticipated in advance. Unlike a static keyword filter, this leans on the model's own language understanding to hold up against variation in wording.

Making the refusal itself part of the design

The response to a request that falls into a protected category is also governed by policy. The key principle: don't explain the reasoning behind a refusal in detail.

That might look unhelpful at first glance. But the more a refusal explains why something can't be answered, the more that explanation becomes a clue about exactly where the boundary sits — and a clue about a boundary tends to help someone find a way around it. A short, matter-of-fact refusal is, somewhat counterintuitively, often the safer choice.

Why this lives in the system prompt, not an application-level filter

This kind of defense could have been implemented in application code instead. We deliberately chose to write it as policy inside the system prompt handed to the LLM.

The reason is that keyword-based filters are fragile against rephrasing. Two requests can carry the exact same intent while using entirely different words, and a static filter built to catch one may simply miss the other. Giving the model a judgment criterion — "requests with this character" — instead lets it lean on its own trained language understanding to generalize toward phrasings nobody wrote down in advance. It isn't foolproof, but it holds up better against novel wording than a static filter typically does, and that's the reasoning behind this design choice.

Wrap-up

How "on point" a support chatbot is isn't only measured by how well it answers legitimate questions. Correctly recognizing which questions it must not answer, no matter how they're phrased, is just as much a design problem as answering the ones it should. Building a category-based judgment for what must stay protected, and treating the refusal itself as something to design rather than an afterthought — folding both into policy for the LLM rather than application code — moved the bot a step beyond a simple "try to answer everything" assistant, toward something that holds up under real-world use.

The free plan wasn't actually "no registration required" — fixing a landing page claim that contradicted itself

Susumu Takahashi — Sat, 15 Aug 2026 01:06:21 +0000

Background

An external marketing review flagged what looked like a contradiction in our landing page's FAQ. Checking it against the actual code confirmed the claim was accurate.

Two statements coexisted on the same page:

Quick Start, step 2: "Register with your email to start for free"
The FAQ answer: "The Free plan requires no registration and allows up to 1 site, 3 runs per month — completely free."

One says "please register." The other says "no registration needed." Checking the implementation confirmed that the Free plan requires an email address to be registered and verified on first launch — without that step, the app cannot be used. The FAQ's "no registration required" simply wasn't true.

Conflating "free" with "no registration"

Tracing the contradiction back to its root, it came from folding two independent axes into a single phrase.

Cost axis: no credit card, no charge at any point
Procedural axis: one step — registering an email address — is required

Both are true characteristics of the Free plan here, but the phrase "no registration required" denies the procedural axis outright. Most likely, an accurate statement like "no credit card required" was shortened over time into "no registration of any kind required," and that shorter version stuck. It's a reminder that landing page copy is never really "done" — it needs to be re-verified against the implementation every time the underlying feature changes.

Fixing what's actually true, not just deleting the claim

There were two ways to resolve this:

Keep the FAQ's "no registration required" claim as-is, and remove the email registration requirement from the product instead
Leave the implementation untouched, and rewrite the FAQ to match reality

Email registration underpins verification-email deliverability and license management, so removing it wasn't a realistic option. We went with option 2 — matching the copy to what's actually true.

- The Free plan requires no registration and allows up to 1 site,
- 3 runs per month — completely free.
+ The Free plan only asks for your email address and allows up to
+ 1 site, 3 runs per month — completely free. No credit card, no
+ time limit.

The key detail: rather than just deleting the "no registration" claim, we explicitly kept the cost axis (no credit card, no time limit) in the rewritten sentence. What users usually want to know is whether they'll be asked for a credit card and how long the free tier lasts. Affirming both of those clearly, while precisely correcting only the procedural claim (email registration is required), landed on wording that neither overstates nor understates what's true.

The same phrasing also appeared in the Quick Start description.

- No credit card required. Just install it and start right away.
- The Free plan stays free forever.
+ No credit card required. Just register your email and start
+ right away. The Free plan stays free forever.

Across the Japanese and English versions and duplicate FAQ entries on two pages, three files and four separate spots were brought in line with the same corrected wording.

What we deliberately left alone

During the same review, we noticed a second inconsistency: the product name appeared on the landing page in two forms, "WP Maintenance Manager" and "WP Maintenance Pro." The binary actually being distributed carries the "Pro" name. Standardizing the landing page alone to "Manager" would have created the opposite kind of mismatch — the landing page and the distributed product disagreeing with each other.

We left that alone here and set it aside as a separate naming decision to make later. Trying to fix every inconsistency uncovered during a single review, in a single commit, risks mixing problems with very different blast radii into one change and leaving one of them half-fixed. Correcting the "no registration" claim was a wording-only fix that could be completed cleanly on its own; the product-naming mismatch touches the binary name, the installer, and past distributed builds — a decision of an entirely different order. Keeping the scopes separate was deliberate.

Wrap-up

Landing page copy can be correct the day it's written and quietly drift out of sync as the implementation changes underneath it — in this case, once email verification was added to the registration flow. This particular gap surfaced through an outside review, but the real fix is the underlying habit: periodically checking landing page claims against what the code actually does. Just as important as fixing what you find is resisting the urge to fix everything discovered in the same pass — problems with different scopes deserve to be handled on their own timelines.

Resuming email verification after the app is closed — the pending_email state that prevents re-sending

Susumu Takahashi — Thu, 13 Aug 2026 23:28:20 +0000

Background

On first launch, the desktop app asks the user for an email address, sends a confirmation email, and completes registration once the user clicks the link in that email. There was a trap here for anyone who closed the app before clicking the link.

Email does not always arrive immediately. Closing the app with the intention of clicking the link once the email shows up, then reopening later, is a perfectly natural way to use it. But on restart the app decided that registration was still incomplete and showed the first-launch screen (the email input) from the beginning. The user had to type their email address again.

That is where the second half of the trap sprang. Re-entering the address made the app call the registration endpoint on the server again, and the server issued a new verification token. The link in the email that had already arrived was now invalid. When the user finally clicked that first link, they got an "invalid link" error. Two traps, back to back.

Naming the symptom

The loop looked like this:

Enter email address → confirmation email is sent
Close the app before clicking the link
Restart → the first-launch screen reappears and asks for the email again
Re-enter → the server regenerates the token → the first email's link is invalidated
Click the link in the first email → "invalid link"

The root cause was that the app never remembered the intermediate state of "sent, awaiting verification." As far as the app was concerned, state was binary — either "not registered" or "registered" — with no room for "the email has been sent but not yet verified." So every restart fell back to treating the user as not registered.

Persisting pending_email to the config file

The fix is to persist that intermediate state. The moment the confirmation email is sent successfully, the target address is saved to app_config.json as pending_email.

Note: app_config.json is the app's local configuration file, holding per-user settings such as the license key and the registered email. JSON (JavaScript Object Notation) is a structured data format that is easy for both machines and humans to read.

It is saved only when the server reports a successful send (status: ok). Creating an "awaiting verification" state when the send itself failed would leave the user waiting for an email that never went out.

# Save the email only on a successful send
if data.get('status') == 'ok':
    try:
        from core.license import _load_config, _save_config
        cfg = _load_config()
        cfg['pending_email'] = email
        _save_config(cfg)
    except Exception as e:
        print(f'[registration_start] failed to save pending_email (ignored): {e}')

The save is wrapped in try/except and never blocks the registration flow. pending_email is only an aid for resuming; even if it cannot be written, the primary goal — sending the confirmation email — has already been achieved.

Startup check and returning to the right screen

Next, the startup status API returns this pending_email.

return jsonify({
    'first_launch':     is_first_launch(),
    'registered_email': registered_email,
    # Email sent before verification, so we can resume the waiting screen on restart
    'pending_email':    cfg.get('pending_email', ''),
})

On the front end, when it is a first launch (first_launch) and a pending_email exists, the app goes straight to the verification-waiting screen instead of the email input.

if (data.first_launch) {
    document.getElementById('firstLaunchModal').style.display = 'flex';
    // If an email was already sent, resume the waiting screen instead of asking again.
    if (data.pending_email) {
        _flEmail = data.pending_email;
        const inp = document.getElementById('flEmailInput');
        if (inp) inp.value = data.pending_email;
        _flUpdateVerifyMessage();
        flShowStep('step_verifying');   // go to the waiting screen
    }
}

Now someone who closed the app before clicking the link comes back, on restart, to a screen that says "A confirmation email has been sent to this address. Click the link in the email, then press 'Verified'." No need to type the email address a second time.

Not regenerating the token is the whole point

The single most important part of this design is that returning to the waiting screen does not call the server's registration endpoint again. The resume path only reflects the address read from the local config file onto the screen; it never talks to the server.

A registration request to the server comes with the issuance of a new token. Calling it during resume would invalidate the link in the email that had already arrived — rebuilding the very trap we were trying to remove. Resume is kept to purely mirroring local state onto the screen, which keeps the first email's link valid.

If the user actively wants to resend the email, the waiting screen has a separate "Resend email" button. A resend is an explicit action, so regenerating the token there is fine. Separating automatic resume (leaves the token alone) from manual resend (updates the token) is the key distinction.

Clearing conditions

pending_email is a marker for "verification not yet complete," so it must be removed once verification finishes. The routine that records completion sets the registered flag and drops pending_email at the same time.

def mark_registration_done(email: str):
    """Persist the completed-registration flags to app_config.json on verification."""
    cfg = _load_config()
    cfg['email_registered'] = True
    cfg['registered_email'] = email
    # Clear the awaiting-verification marker (resume is no longer needed)
    cfg.pop('pending_email', None)
    _save_config(cfg)

That closes the state cycle: not registered → email sent sets pending_email → verification clears pending_email and marks registered. Close the app anywhere in between, and the next launch lands you back at the correct point.

Wrap-up

It is a small change — persisting the intermediate "sent but not yet verified" state to a config file — but it stops an interruption before clicking the link from turning into an error. Representing state as something richer than a binary, with an "in progress" phase saved in a resumable form, is a plain and widely applicable pattern for any flow that can be interrupted.

Around the same time, we also revisited the deliverability of the confirmation email itself. That is covered in a separate article.

SPF, DKIM, and DMARC together — why the missing DMARC record was blocking registration emails

Susumu Takahashi — Thu, 13 Aug 2026 00:46:10 +0000

Background

Registration confirmation emails were not reliably reaching users on Gmail and Outlook outside Japan — sometimes landing in spam, sometimes not arriving at all. Investigation pointed to a single root cause: the wpmm.jp domain had SPF and DKIM configured, but no DMARC record.

What each of the three does

SPF (Sender Policy Framework) declares in DNS which IP addresses are authorized to send mail for a domain. Receiving servers check the sending IP against the SPF record to confirm the source is legitimate.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message headers and body. The receiving server looks up the public key in DNS and verifies that the message has not been tampered with and was signed by a party controlling that domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits above both. It tells receiving servers what to do when SPF and DKIM alignment fails, and it collects aggregate reports about how mail from the domain is being treated.

The key point is that SPF and DKIM are independent checks. Without DMARC, there is no single authoritative statement about how the alignment result should influence delivery decisions. Major providers including Gmail weigh the absence of DMARC when scoring incoming mail.

Adding the DMARC record

The following TXT record was added to the wpmm.jp DNS:

_dmarc.wpmm.jp  TXT  "v=DMARC1; p=none; rua=mailto:info@wpmm.jp"

p=none means "collect data, but do not reject or quarantine mail that fails alignment." Starting with p=reject or p=quarantine risks blocking legitimate mail if DKIM alignment turns out to be misconfigured somewhere. The safe approach is to start with p=none, monitor the reports, and tighten the policy gradually.

rua=mailto:info@wpmm.jp sets the destination for aggregate reports. Google and other receivers periodically send XML summaries showing which mail passed or failed SPF/DKIM alignment. This moves visibility from passive (you notice when users complain) to active (you see the numbers).

Propagation was confirmed against both Xserver's authoritative DNS and Google Public DNS before considering the change live.

Hardening `register_free.php`

The same release also tightened the sending code itself.

Stop silently swallowing send failures: mb_send_mail() returns false on failure, but the return value was not being checked. A failed send would report success to the user and leave no trace in the server log.

// Before: return value ignored
mb_send_mail($to, $subject, $body, $headers);
echo json_encode(['status' => 'ok']);

// After: detect failure and return an error
if (!mb_send_mail($to, $subject, $body, $headers)) {
    http_response_code(500);
    echo json_encode(['status' => 'error', 'message' => 'Failed to send email']);
    exit;
}

Add headers that reduce spam scores: Reply-To, Date, and Message-ID were added explicitly.

$headers .= "Reply-To: info@wpmm.jp\r\n";
$headers .= "Date: " . date('r') . "\r\n";
$headers .= "Message-ID: <" . uniqid('wpmm-', true) . "@wpmm.jp>\r\n";

A missing Message-ID is a common spam signal. Date is required by RFC 5322 but mb_send_mail() does not always add it automatically.

What changed

After adding the DMARC record, Google started sending aggregate reports to info@wpmm.jp. The reports confirm that legitimate mail from wpmm.jp is passing DKIM alignment, and spoofed mail is failing.

Email deliverability does not improve overnight — sender reputation builds gradually. What DMARC provides immediately is the ability to see what is happening, rather than relying on user complaints to find out.

When maintenance ends with an error, the plugin update badge disappears — designing a backend marker and frontend count sync

Susumu Takahashi — Wed, 12 Aug 2026 02:26:39 +0000

The WordPress maintenance tool shows a badge on each site card when there are pending plugin updates. Under normal operation, when maintenance completes successfully, the badge clears until the next dashboard scan picks up fresh data. That's correct behavior.

But a report came in: when maintenance ends with a warning or an SSH error partway through, the badge disappears even if plugins were left unupdated. "If the update didn't finish, I need to know — but the badge is telling me there's nothing left to do."

Why the badge was disappearing

Tracing the bug, the root cause was in the frontend badge-update logic, which was built on a hard-coded assumption: maintenance complete = all plugins updated = zero remaining.

When the frontend received a maintenance-complete event, it deleted the site's entry from the badge cache (_updatesDashState). "The run is done, so the count must be zero." That assumption.

The assumption breaks whenever maintenance ends in a "failed" state:

A DB backup fails before the plugin update phase is ever reached
An SSH disconnect interrupts mid-update
An HTTP check detects a site anomaly, triggers rollback, and exits with a warning

In all of these cases, a completion event still fires (the flow always ends, whether cleanly or not). The old design deleted the badge cache on that event — regardless of how many plugins were actually left behind.

The fix: a backend marker line

The redesign is: the backend outputs the real remaining count, and the frontend reads it before deciding what to show the badge. Replace the assumption with observed facts.

The backend (_check_pending_updates_ssh() in maintenance_agent.py) now emits one marker line into the streaming log whenever the post-update residual check completes:

[SiteName] Pending plugins remaining: 2 {akismet, contact-form-7}

In Japanese mode:

[サイト名] 未更新プラグイン: 2 件 {akismet, contact-form-7}

The marker includes the count and also the plugin slugs in {}. The slugs are there so the frontend can populate the badge cache with real plugin names — the same names that appear in the cross-site dashboard.

Key design constraint: the marker is only emitted if the residual check actually runs. If the run failed before reaching the plugin update phase (e.g., a DB backup error aborted early), no marker is output. The frontend treats that as "unknown" and leaves the existing badge untouched.

if plugin_count_known:
    _names_part = '{' + ', '.join(plugin_remaining_names) + '}'
    logger.info(
        f"[{site_name}] Pending plugins remaining: {plugin_remaining_count} {_names_part}"
    )

Three-path frontend logic

The frontend (templates/index.html) scans each streaming log chunk for the marker regex, records site_id → {count, names[]} in _postMaintPluginCount, and applies it at completion time via _applyPendingCountsForSites().

Three paths for each site:

State	Badge action
Marker present, N = 0	Delete cache entry (badge hidden — update succeeded)
Marker present, N > 0	Upsert entry with real plugin names (badge shows count)
No marker	Do nothing (leave existing badge as-is)

The "no marker" case is deliberately passive. The frontend has no way to know why the residual check never ran. "When information is missing, don't change anything" is the conservative fallback.

function _applyPendingCountsForSites(siteIds) {
    for (const sid of siteIds) {
        if (Object.prototype.hasOwnProperty.call(_postMaintPluginCount, sid)) {
            _applyPostMaintPluginCountToBadge(sid, _postMaintPluginCount[sid]);
        }
        // no marker → leave badge alone
    }
}

Scoped plugin updates

The tool supports "update only these specific plugins" mode. In this mode, the badge should still show the total pending count for the whole site — not just the count of the selected plugins that were skipped.

If you update one of three pending plugins, two remain. The badge should say two, not "zero selected-scope plugins remaining." The backend captures the count before applying the scope filter, so the marker always reflects site-wide truth.

Consolidating three call sites

Previously, "update the badge after maintenance" was duplicated in three places:

_refreshCompletedSitesNow() — per-site immediate refresh
Full-run completion event handler
Scoped plugin update completion handler

Each had its own "delete the cache entry" code. The fix replaced all three with calls to _applyPendingCountsForSites(). One function, one place to change next time badge behavior needs to evolve.

Summary

Aspect	Detail
Bug	Hard-coded "done = zero remaining" deleted the badge cache on every completion event
Root cause	Frontend judged by the completion event alone, without reading what the backend actually found
Fix	Backend emits a marker line with the real count; frontend parses it and sets the badge accordingly
Three paths	N=0 → hide; N>0 → show with real names; no marker → preserve existing
Design principle	"If information is missing, don't change state" — conservative fallback under uncertainty

A badge that shows "updates pending" is only useful if it reflects reality. When maintenance runs clean, clear it. When maintenance fails partway through, keep it — or better, update it with what actually remains.

For the initial badge implementation, see the pending plugin count badge design. For the cache lifetime design that controls how long badge data persists, see dashboard cache lifetime pitfalls.

A csh bug we thought we fixed came back in a new feature — designing a login-shell-independent SSH command wrapper

Susumu Takahashi — Mon, 10 Aug 2026 05:48:33 +0000

In May 2026, bash commands sent over SSH stopped working correctly on WordPress sites hosted on Sakura Internet. The root cause: Sakura's default login shell is csh, which can't interpret bash syntax. We patched the codebase, consolidating all bash-syntax c.run() calls behind a _safe_run helper, and the problem went away. (That original incident is documented in the csh login-shell portability article.)

Then in June 2026, a report came in: DB backups were failing every single time on all Sakura-hosted sites with an "SSH update error."

Why the same problem came back

The cause: a new feature had walked into the same trap.

The v1.6.9 development cycle added progress monitoring to DB backups — sampling the backup file size every 30 seconds while the dump ran, then writing a one-line summary after completion. The script looked like this:

wp db export /path/backup.sql 2>&1 &
PID=$!
while kill -0 $PID 2>/dev/null; do
  echo "size=$(wc -c < /path/backup.sql)"
  sleep 30
done
wait $PID; exit $?

The script is correct bash. The problem is that paramiko's exec channel runs commands through the user's login shell on the server. On Sakura, that login shell is csh. csh can't interpret these constructs:

Syntax	What csh does
`2>/dev/null`	`Ambiguous output redirect` — or silently returns empty output (most dangerous)
`$!`	Can't hold the background process ID
`while ...; do ... done`	`for: Command not found` style error
`VAR=val`	Variable assignment doesn't work

The earlier fix covered the existing code. The new feature called c.run() directly — outside the scope of that fix — and had no guard at all.

The first fix attempt: base64 encoding

The first approach: base64-encode the script body, send it as a string, and have the server decode and run it through /bin/sh.

import base64

def wrap_remote_sh_v1(script):
    encoded = base64.b64encode(script.encode()).decode()
    return f"echo {encoded} | openssl base64 -d -A | /bin/sh"

echo <base64> runs fine in any shell. The server decodes with openssl base64 -d and pipes the output to /bin/sh. The login shell only needs to handle echo, a pipe, and an external command call — nothing bash-specific.

Testing on a Sakura instance confirmed the progress script ran correctly.

It broke again on heteml

While validating the fix across environments, a new fact emerged:

heteml (ssh-layer.heteml.net) has neither openssl nor a base64 command.

The base64 approach depends on openssl base64 -d. On heteml, that's command not found. The Sakura problem would be solved, but heteml would fail completely. Dependencies on external commands break silently on servers you haven't tested against.

The final design: `/bin/sh -c`

To eliminate external-command dependencies entirely, the approach shifted to passing the script directly as an argument to /bin/sh -c.

import shlex

def wrap_remote_sh(script):
    if '\n' in script or '\r' in script:
        raise ValueError(
            "wrap_remote_sh requires a single-line script "
            "(csh single-quotes cannot span newlines); "
            "join statements with ';' instead"
        )
    return "/bin/sh -c " + shlex.quote(script)

shlex.quote() is Python's standard library function for POSIX single-quoting. Embedded ' characters become '\''. The result looks like this:

wrap_remote_sh("echo hi && wc -c < /tmp/file")
# → "/bin/sh -c 'echo hi && wc -c < /tmp/file'"

When csh receives this via the exec channel, it treats the single-quoted content as a single token and hands it to /bin/sh. The shell that interprets 2>/dev/null, $!, and while...do...done is /bin/sh, not csh. The login shell is irrelevant.

Zero external-command dependencies. /bin/sh exists on every server.

One constraint applies: the script must be a single line. csh single-quotes can't span newlines — a multi-line script will produce Unmatched '. Multi-line logic needs to be joined with semicolons into a single line (note: do; is a shell syntax error in sh; use do <cmd> to connect statements inside a loop). Violations throw a ValueError so the issue is caught at development time, not at runtime.

Verified across three environments

After the fix, we verified on three environments:

Environment	Login shell	openssl / base64	Result
Sakura	csh	present	✅ Progress script ran to completion
Xserver	bash	present	✅ Same
heteml	bash	absent	✅ No external commands needed

The base64 approach had failed on heteml. The /bin/sh -c approach passed all three.

A static test to prevent it from coming back

Having wrap_remote_sh available doesn't guarantee it gets used in the next new feature — that's exactly the pattern that caused this regression in the first place.

The test suite now includes a static check: scan maintenance_agent.py for any c.run() call that contains csh-unsafe syntax without going through wrap_remote_sh:

def test_no_csh_unsafe_bare_crun_in_maintenance_agent(self):
    src = (PROJECT_ROOT / "maintenance_agent.py").read_text(encoding="utf-8")
    for i, line in enumerate(src.splitlines(), 1):
        if "c.run(" not in line:
            continue
        if "wrap_remote_sh" in line:
            continue
        # csh-unsafe markers: redirects, command substitution, loops
        if re.search(r'2>|`\$!`|\$\(|while |for.*in.*do', line):
            self.fail(f"line {i}: csh-unsafe c.run without wrap: {line.strip()}")

If a future change adds a c.run() containing 2> without wrapping it, the test fails. The check is mechanical — no human review required.

Summary

Aspect	Detail
Problem	A new feature called `c.run()` directly, outside the scope of the earlier csh fix
Root cause	paramiko runs commands through the server's login shell; Sakura's default login shell is csh, which can't parse bash syntax
First attempt	base64-encode the script, decode with `openssl base64 -d` — broke on heteml (no openssl)
Final fix	Single-quote the script with `shlex.quote()`, pass it as the argument to `/bin/sh -c`
Regression prevention	A static source-code test detects unwrapped csh-unsafe `c.run()` calls automatically

When a bug class that was already fixed comes back in new code, it usually means the original fix covered existing code, but a separate guard was needed for new additions. Either a development habit of checking "am I going through the safety wrapper?" or a mechanical test that enforces it — one of the two needs to be in place. Read alongside the original incident to see how the same bug class evolved over time.

Deploying and committing to git are not the same "done" — the trap of assuming uploaded means synced

Susumu Takahashi — Sun, 09 Aug 2026 00:52:10 +0000

Near the end of a release, every file transfer to the production server succeeded, and the version file that triggers distribution was updated too. With that confirmed, the release got reported as complete — except the local git repository never actually had those changes committed.

Note: "Deploying" here means transferring changed files to the production server (via scp, for example) so they're actually live for users. "git push" is a separate operation that records the change history in a remote repository.

What happened

This release involved transferring seven files to the production server: five landing-page update-notice files, the version file that triggers distribution, and a progress-log file. The transfer itself succeeded completely, and the production site confirmed it was showing the new version number.

The problem: after editing these files locally, the work moved straight to the transfer step without ever committing. The files on the production server were fully up to date, but the local git repository had no record of those changes — and the release got reported as complete in that state.

Why this is easy to miss

Transferring files with scp and recording them in the repository with git commit / git push are completely independent operations, both as commands and as goals. Verifying production (HTTP 200, checking the rendered content) confirms "did the deployment succeed" — a different question from "is the local change history recorded." Treat the first check as proof of "done," and the second check quietly never happens.

When both steps get mentally bundled into one "release complete" state, there's no natural moment to notice that only one of them actually finished. In this case, it surfaced because someone else looking at the repo noticed it hadn't been committed yet.

The fix — treat "uploaded" and "git synced" as two separate checks

Add a git-sync verification step to the deploy checklist, independent from the file-transfer confirmation.

# Commit before deploying
git add <changed files>
git commit -m "..."
git push origin main

# Transfer to the server via scp
scp <files> user@server:path/

# Verify production
curl -s -o /dev/null -w "%{http_code}" https://example.com/version.json

# Verify git sync (make this its own explicit step)
git status   # confirm "nothing to commit, working tree clean"
git rev-list --left-right --count origin/main...main   # confirm "0 0"

That last git rev-list command counts how many commits differ between the local and remote branches in each direction. Output of 0 0 means local and remote are fully in sync. It turns "I'm pretty sure I pushed" from a subjective memory into something a command output confirms mechanically.

What this incident reveals

The root of this incident was treating two states with different meanings — "transferred via scp" and "committed to git" — as a single mental category called "release complete." The fix isn't really a technical mechanism; it's splitting the checklist into finer granularity. "Reflected in production" and "change history recorded" became two separate, explicit verification steps, and only when both are confirmed does the work count as done.

Summary

Aspect	Detail
Problem	Transferring files to production (scp) and recording them in git (commit/push) are independent steps, but only one got verified before calling the work "done"
Why it's easy to miss	Verifying production confirms deployment success, not whether local change history was recorded — two different questions
Fix	Add git-sync verification as its own explicit item on the deploy checklist
Verification commands	`git status` and `git rev-list --left-right --count origin/main...main` (expecting `0 0`) confirm sync mechanically instead of relying on memory

A word like "done" that can carry multiple meanings is an easy trap for a checklist to fall into at too coarse a granularity. Naming each thing that actually needs to finish, and turning each into its own verification step, is what closes this kind of gap.

Checking that a count didn't change — a sanity check before writing a reorder API's result

Susumu Takahashi — Fri, 07 Aug 2026 00:18:39 +0000

Building a drag-and-drop reorder feature for a list of items means sending the new order to the server and saving it. If there's even a small flaw in the reordering logic, that save can quietly persist data with items missing or duplicated.

Note: A "sanity check" here means a lightweight check that the result of a process satisfies a condition that should obviously hold — not a thorough validation, just a last-resort check for "is this clearly wrong?"

The shape of the reorder logic

The new order from a drag-and-drop interaction arrives at the server as an array of IDs. The server reorders the existing data to match.

# Place items according to the order sent by the client
reordered = []
placed_ids = set()
for sid in dedup_order:
    if sid in by_id:
        reordered.append(by_id[sid])
        placed_ids.add(sid)

# Anything not covered by the order gets appended,
# keeping its existing relative order
for site in data:
    sid = str(site.get('_id', '')).strip()
    if sid and sid in placed_ids:
        continue
    reordered.append(site)

This two-step structure makes sense on its own. The order the client sends might only cover a filtered or searched subset of the data. Appending whatever wasn't covered by that order, while preserving its existing relative position, prevents items that weren't currently visible from disappearing.

The risk that remains

The problem is what happens if the combination of "place in order" and "append the rest" has a flaw of its own. ID deduplication, string-conversion edge cases, malformed entries — the more complex this logic gets, the more the underlying assumption ("every item appears exactly once in the output") is at risk of breaking. If there's a bug here, the reordered data could end up shorter than the original (items lost) or longer (items duplicated).

The fix — verify the count matches right before writing

Right before writing the reordered result to disk, check one more thing: does the input count match the output count?

# Sanity check: counts must match (no items lost or duplicated)
if len(reordered) != len(data):
    app.logger.error(
        'reorder_sites: count mismatch (in=%d, out=%d) — refusing to write',
        len(data), len(reordered),
    )
    return jsonify({
        'status': 'error',
        'message': 'Reorder count mismatch; refusing to save',
    }), 500

_atomic_write_json(filepath, reordered)

If the counts don't match, the error log records both the input and output counts, and the write itself is aborted. There's no need to pinpoint exactly where the reorder logic went wrong — whether the result is safe to save can be determined mechanically.

Why a count match is enough of a defense

This reorder operation doesn't change the content of any item — it only changes the order. That means before and after, the set of elements should always stay the same. If the count changed, something either disappeared or got duplicated. A matching count doesn't prove the content is perfectly intact, but as a lightweight way to catch obvious corruption — items lost or duplicated — comparing counts does the job.

What this design gets right

This isn't about writing the reorder logic perfectly — it's about catching a flaw in that logic before it turns into data corruption, even when the logic itself isn't perfect. The more complex a piece of logic gets, the harder it is to cover every case in tests. Identifying one invariant that should always hold before and after, and checking only that at the very end, acts as insurance against bugs that tests didn't anticipate.

Summary

Aspect	Detail
Feature	An API that takes a drag-and-drop reorder result as an array of IDs and reorders existing data to match
Risk	A flaw in the two-step "place in order, then append the rest" logic can cause data loss or duplication
Fix	Compare input and output counts right before writing; abort and return an error on mismatch
Design principle	Not aiming for perfect logic, but mechanically preventing a write while an invariant is broken

Code that rewrites a batch of items at once tends to be written assuming the logic works correctly. Thinking through what happens when that assumption breaks is what actually protects the data. The trap of a word like "done" lumping together multiple distinct meanings shows up again in the incident that conflated deploy-complete with git-commit-complete.

A version bump that got left behind — fixing it with a single source of truth and a `--check` gate

Susumu Takahashi — Wed, 05 Aug 2026 23:55:12 +0000

Bumping a desktop app's version number sounds like a one-line change. In practice it can mean editing five different files at once. During one release, exactly one of those files got missed, and an installer nearly got built carrying the old version number.

Note: A "version bump" just means incrementing the version number — say, from 1.6.9 to 1.6.10. The operation sounds trivial, but it can end up scattered across multiple files in practice.

What happened

This app's version number lives in five separate places:

The VERSION variable in version.py
MyAppVersion in the Windows installer definition file (.iss)
The version number and download URLs in version.json
Two download links on the landing page (Japanese and English versions)

Every release, these got updated by hand, relying on memory of "which files need touching this time." During one release, the .iss file on the Windows build side was left at the old version — and it only surfaced when someone happened to notice, visually, that the version number still looked old right before rebuilding. There was no automated check that would have caught it.

Why memory-based manual edits invite this kind of failure

Five files isn't a huge number on its own, but the list of "files to touch this release" lived entirely in someone's head. Succeeding once is no guarantee the same steps get reproduced correctly next time. On top of that, each file uses a different syntax (a Python variable assignment, an INI-style definition, JSON, link strings inside PHP), which makes a quick grep-based sanity check more tedious than it sounds.

The fix — list every target file in one place, and fold verification into the same script

tools/bump_version.py centralizes the list of target files and their matching patterns into a single script.

VERSION_TARGETS = [
    {"path": "version.py",
     "checks": [{"regex": r'^VERSION\s*=\s*"([^"]+)"',
                 "replace": 'VERSION = "{version}"', "label": "VERSION"}]},
    {"path": "WP_Maintenance_Pro.iss",
     "checks": [{"regex": r'#define\s+MyAppVersion\s+"([^"]+)"',
                 "replace": '#define MyAppVersion   "{version}"',
                 "label": "MyAppVersion"}]},
    # ... version.json and both index.php files (JP/EN) listed the same way
]

The script has two modes:

# Bump everything from the old version to the new one
python tools/bump_version.py 1.6.11 2026-06-11

# Don't bump anything — just verify current consistency
python tools/bump_version.py --check

--check mode treats VERSION in version.py as the source of truth and verifies every other file against it. If even one mismatch turns up, it prints exactly which file, which field, and what value it found, then exits with code 1.

def check_all(expected_version):
    mismatches = []
    for target in VERSION_TARGETS:
        content = _read(os.path.join(PROJECT_ROOT, target["path"]))
        for chk in target["checks"]:
            m = re.search(chk["regex"], content)
            actual = m.group(1) if m else "<not found>"
            if actual != expected_version:
                mismatches.append((target["path"], chk["label"], actual, expected_version))
    return mismatches

Wiring the check into the build script as a gate

Running --check on its own still leaves the same problem: someone has to remember to run it. So the verification gets wired directly into the app's build script, which refuses to proceed if anything's inconsistent.

_check_result = subprocess.run(
    [sys.executable, "tools/bump_version.py", "--check"],
    capture_output=True, text=True,
)
if _check_result.returncode != 0:
    print("Release file version consistency check failed")
    print(_check_result.stdout)
    sys.exit(1)

This means the check always runs before signing and distribution, regardless of whether the person building remembers --check exists. Because the same script runs on both Mac and Windows, it also doubles as a cross-platform consistency check.

What this design gets right

This isn't really about "editing a version string" — it's about answering who guarantees consistency across files scattered in multiple places, and where. Centralizing the list of target files in one script makes it obvious where to add a new file when the release process grows. And by folding "bump" and "verify" into two modes of the same script, rather than two separately maintained pieces of logic, there's no duplicate implementation of the matching rules to drift out of sync.

Summary

Aspect	Detail
Problem	Version number scattered across 5 files; memory-based manual updates dropped one of them
Fix	Centralize target files and regex patterns in one script with both bump and verify modes
Verification	Treat `version.py` as the source of truth, regex-match every other file against it, report specific mismatches
Permanence	Wire the check into the build script as a gate, removing the dependency on someone remembering to run it

Consistency across multiple files, even once fixed by hand, tends to drift again on the next pass. The core of this design is refusing to let verification depend on a choice — instead pinning it to a path (the build) that always gets taken anyway. The same principle — not perfecting the logic, but mechanically catching it when an invariant breaks — shows up again in the count sanity check on a reorder API.

Follow-up: The cp932 crash in the build gate that only happened on Windows

DEV Community: Susumu Takahashi

The excluded-plugin setting that Playwright ignored — fixing browser-mode updates and false residual warnings

The symptom

SSH path vs. Playwright path

Fix 1 — _ignored_plugin_slugs() and _plugin_slug_from_checkbox_value()

Fix 2 — _browser_plugin_residual_state() stops false residual warnings

Test coverage

The cp932 crash in the build gate that only happened on Windows — static detection, behavioral testing, and a negative check

The symptom

Why it didn't show up on Mac

Fix 1 — replace emoji with ASCII

Fix 2 — force UTF-8 in the subprocess call

Fix 3 — three-layer regression guard in test_windows_cp932_safety.py

What to take away

Placing corrections exactly where an LLM is tempted to sound plausible instead of right

Background

Example 1: guessing a hosting provider's SSH hostname format

Example 2: a plausible-sounding but wrong "you need to convert this" instruction

Why a generic instruction alone isn't enough

The fix: place a targeted correction right next to the trap

Wrap-up

A support chatbot needs to be designed for what it won't answer, not just what it will

Background

Thinking in categories of information, not keywords

Making the refusal itself part of the design

Why this lives in the system prompt, not an application-level filter

Wrap-up

The free plan wasn't actually "no registration required" — fixing a landing page claim that contradicted itself

Background

Conflating "free" with "no registration"

Fixing what's actually true, not just deleting the claim

What we deliberately left alone

Wrap-up

Resuming email verification after the app is closed — the pending_email state that prevents re-sending

Background

Naming the symptom

Persisting pending_email to the config file

Startup check and returning to the right screen

Not regenerating the token is the whole point

Clearing conditions

Wrap-up

SPF, DKIM, and DMARC together — why the missing DMARC record was blocking registration emails

Background

What each of the three does

Adding the DMARC record

Hardening register_free.php

What changed

When maintenance ends with an error, the plugin update badge disappears — designing a backend marker and frontend count sync

Why the badge was disappearing

The fix: a backend marker line

Three-path frontend logic

Scoped plugin updates

Consolidating three call sites

Summary

A csh bug we thought we fixed came back in a new feature — designing a login-shell-independent SSH command wrapper

Why the same problem came back

The first fix attempt: base64 encoding

It broke again on heteml

The final design: /bin/sh -c

Verified across three environments

A static test to prevent it from coming back

Summary

Deploying and committing to git are not the same "done" — the trap of assuming uploaded means synced

What happened

Why this is easy to miss

The fix — treat "uploaded" and "git synced" as two separate checks

What this incident reveals

Summary

Checking that a count didn't change — a sanity check before writing a reorder API's result

The shape of the reorder logic

The risk that remains

The fix — verify the count matches right before writing

Why a count match is enough of a defense

What this design gets right

Summary

A version bump that got left behind — fixing it with a single source of truth and a `--check` gate

What happened

Why memory-based manual edits invite this kind of failure

The fix — list every target file in one place, and fold verification into the same script

Wiring the check into the build script as a gate

Fix 1 — `_ignored_plugin_slugs()` and `_plugin_slug_from_checkbox_value()`

Fix 2 — `_browser_plugin_residual_state()` stops false residual warnings

Fix 3 — three-layer regression guard in `test_windows_cp932_safety.py`

Hardening `register_free.php`

The final design: `/bin/sh -c`