Critical: macOS BSD sed does not support \s character class.
The two substitutions in the version-bump step silently no-oped, the
grep fail-fast guard caught it (no remote damage), but release.sh
couldn't complete. Using POSIX [[:space:]] works on both BSD and GNU sed.
Also: extend test_git_archive_excludes_dev_files to cover .phpunit.result.cache,
.beads/, .claude/, dist/, .DS_Store — the test now fully enforces .gitattributes
export-ignore invariant.
register_update_checker() guards on is_file + class_exists so the plugin
degrades cleanly on installs that ship without the vendored lib (no update
notices, but plugin core remains functional).
Settings::register_classifier_filters() registers priority-5 callbacks on
cf7stg_classifier_thresholds and cf7stg_hard_drop_rules so the UI options
actually influence Classifier behaviour. Called from Plugin::boot(). User
filters at priority 10 override these defaults as expected. Adds 4 tests
covering the wired behaviour and override priority. Also adds dry_run_drop?
to MessageFormatter::build() @param docblock.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Replace date('Y-m-d') with wp_date('Y-m-d') in increment_drop_counter and
default_drop_counters to respect WordPress timezone settings.
- Update corresponding test assertions to use wp_date() for consistency.
- Clarify in docblock that increment_drop_counter is not atomic under concurrent
submissions; read-modify-write pattern via update_option is acceptable for
low-volume dashboard counters.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add DEFAULT_THRESHOLDS['drop'] = -5 and DEFAULT_HARD_DROP_RULES const
- Add evaluate_hard_drop(): fires when no positive signals + short latin name OR ≥3 placeholder fields
- Wire into classify(): drop overrides all other labels; synthetic reason explains trigger
- Add drop_reason_label() and 'drop' => '⛔ авто-дроп' to MessageFormatter::LABEL_MAP
- Update ClassifierTest/MessageFormatterTest to extend Cf7stgTestCase (filter isolation)
- Adjust pre-existing assertions that now correctly yield 'drop' instead of 'spam'
Fixes issues from code review in commit 249f195:
1. Tighten fixture assertions to exact counts (assertSame instead of assertGreaterThanOrEqual):
- test_count_placeholder_fields_screenshot_1_exact_count: expect 5 placeholders
- test_count_placeholder_fields_screenshot_2_exact_count: expect 5 placeholders
- test_count_placeholder_fields_screenshot_3_exact_count: expect 1 placeholder
2. Document SERVICE_FIELD_KEYS prefix-matching semantics in comment:
clarify that keys starting with _wpcf7 are skipped via strpos prefix match,
so explicit enumeration of every _wpcf7_* variant is unnecessary.
Test results: 75/75 green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three pilot-surfaced issues in one pass:
1. PhoneParser regex used '\s' in the candidate character class, so a
digit on a following flattened line bled into the phone. '+7977
6277470\n1' (phone + trailing checkbox value) parsed as 12 digits,
producing '+797762774701'. Replaced '\s' with a literal space so
newlines/tabs stop the candidate.
2. Custom-themed forms don't use 'your-name' / 'your-email' keys
(washanyanya.ru has text-211 / text-212 / name_user). Added
FieldDetector::find_name + find_email as fallbacks. Classifier
and MessageFormatter now call them if no standard key matches,
so 'Александр' in text-211 is recognised as a cyrillic name and
scored / displayed accordingly.
3. FlamingoHelper copied '_from_email' into 'your-email' without
validating it. Flamingo derives that meta from whatever field it
considers "first"; on phone-first forms it ends up holding the
phone number. Now we only copy _from_email if it contains '@',
and dropped the _from_name shortcut entirely — FieldDetector
handles the name via the actual field values.
Tests: +1 FieldDetectorTest (13 cases); +2 PhoneParserTest cases for
newline/tab bleeds; +1 ClassifierTest case; +1 MessageFormatterTest
case for custom field keys. Full suite 53/53 green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pilot on washanyanya.ru exposed that Telegram Bot API rejects tel:
URLs in inline_keyboard with HTTP 400 "Wrong port number specified
in the URL". Queue was stuck on 5 items retrying the same failure
4 times each.
- MessageFormatter: always returns reply_markup = null. The phone
number is already rendered in the '📱 ...' line, and mobile
Telegram clients linkify it automatically.
- TelegramClient::is_permanent: treat all 4xx except 429 as permanent
client-side errors, so future payload-shape bugs surface in the
dashboard widget immediately instead of burning five retry cycles.
- MessageFormatterTest updated: the old test asserting tel: in
reply_markup is replaced with one asserting reply_markup is null
and the phone still appears in the text body.
- Spec §9 + §19 updated, §19's open question closed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The regex '/([a-z0-9])([A-Z])/' does not split on underscores, so
Interface_Spam_Source, Settings_Page, Dashboard_Widget stayed as
'interface_spam_source', 'settings_page', 'dashboard_widget' after
strtolower — no file matched. Added str_replace('_', '-', ...).
Then Interface_Spam_Source's slug became 'interface-spam-source',
and the candidate 'includes/sources/interface-' . \$slug doubled
the prefix into 'interface-interface-spam-source.php'. Replaced
that candidate family with a slug-as-filename fallback that maps
interface-* slugs directly to their files.
Sanity check on plugin bootstrap: 17/17 classes/interfaces resolve.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vladimir Bryzgalov