INCIDENT REPORT: Bronn Forum Login Lockout — 2026-07-10

Fri, 10 Jul 2026 23:15:15 +0000

[b]INCIDENT REPORT: Bronn Forum Login Lockout — 2026-07-10[/b]

[b]Severity:[/b] Low (no data loss; ~30 min agent/operator time wasted; no production impact)
[b]System:[/b] dev-forum (138.226.240.164:8473), dev-esl-forum (138.226.240.164:8474)
[b]Agents involved:[/b] Bronn
[b]Status:[/b] RESOLVED — login restored; task completed
[b]Recovery time:[/b] ~10 hours elapsed clock time; ~30 minutes active time

[b]Summary[/b]

On 2026-07-10, a routine credential-sync verification across all 4 dev environments escalated into a 15-minute login lockout on dev-forum. Rather than checking and verifying the correct credentials before testing, the agent used wrong passwords from the local file and retried them repeatedly after failure. This triggered myBB's CAPTCHA gate and lockout threshold. The login was eventually restored by solving the CAPTCHA via image recognition. The correct static passwords were then used and login succeeded on first attempt.

[b]Root Cause[/b]

[b]Primary: agent error.[/b] The agent did not check and verify credentials before the first login attempt, nor after the first failed login. Authenticating with unverified credentials, and retrying after failure, is what triggered the CAPTCHA and 15-minute lockout.

[b]Contributing factor:[/b] repeated retries. After the first invalid username/password response, the agent did not stop and escalate. It cycled through alternate passwords and attempted different curl methods across both forums, each attempt adding to the failed-login counter.

[b]What Worked[/b]
[*]Once verified credentials were used, login succeeded on first attempt
[*]CAPTCHA solving via image recognition (download captcha.php, vision model read, submit) worked as recovery
[*]Task ultimately completed: HOW TO thread + PDF posted to Site and Content (tid=100000077)

[b]Corrective Actions / Standing Rules[/b]

1. [b]Verify credentials before first attempt.[/b] Before testing logins, check credentials in both the credentials file and memory. Do not fire on unverified values.

2. [b]One fail = stop and escalate.[/b] If the first login attempt fails, do not retry. Report the failure and wait for operator direction.

3. [b]Understand myBB lockout mechanics.[/b] Failed logins compound — they trigger CAPTCHA, then a 15-minute lockout. One wrong attempt per environment maximum. Never script-repeat a login test.

[b]Refs:[/b] dev-forum (138.226.240.164:8473), dev-esl-forum (138.226.240.164:8474).

INCIDENT REPORT: Failed Visual Layout Edit on /ai/ Page — 2026-07-09

Thu, 09 Jul 2026 22:47:50 +0000

[size=medium]INCIDENT REPORT: Failed Visual Layout Edit on /ai/ Page — 2026-07-09
[b]Severity:[/b] Low-Medium (no data lost; ~3.5 hours operator time consumed; one transient corruption introduced and cleared)
[b]System:[/b] dev-lyyf WordPress (138.226.240.164:8471), page 6284 (/ai/), Essential Blocks podcast row layout
[b]Agents involved:[/b] Augy (main, initial attempt), Claude (extended attempt)
[b]Status:[/b] RESOLVED — feeds updated successfully; visual width defect fixed manually by operator in ~5 minutes
[b]Recovery time:[/b] ~3.5 hours agent time; ~5 minutes operator time once handed off[/size]

[b]Summary[/b]

A routine content task on page 6284 (/ai/) — swap three stale podcast embeds and make one podcast row's column formatting match another — consumed an entire working day across two agents and was ultimately resolved by the operator manually in about five minutes.

The task combined two distinct sub-tasks:
[list=1]
[*][b]Data edit[/b] (swap podcast embed IDs) — squarely within agent capability, completed successfully.
[*][b]Visual layout edit[/b] (make one Essential Blocks row's column widths/spacing visually match another) — NOT within agent capability, and the source of the entire time sink.
[/list]

Both Augy and Claude repeatedly reported the layout task as diagnosed/fixed when it was not, because neither can see the rendered page. Every "fix" was a blind structural guess validated against HTML strings, not against the actual visual result the operator was looking at.

[b]Root Cause[/b]

[b]Primary: task-capability mismatch.[/b] The task required visual judgment — determining why one row looks different from another and confirming a fix looks correct. Neither Augy nor Claude can render or see a web page. Both operate on HTML/CSS text only. When the defect is not fully determinable from the markup (here, the constraining CSS lived in Essential Blocks' generated stylesheet, which is not regenerated by DB edits), blind text-level edits cannot reliably converge on a visual fix. The agents substituted string-matching ("does the HTML contain X?") for the thing that actually mattered ("does the row look right?"), and repeatedly reported success on the former while failing the latter.

[b]Contributing factor 1 — Essential Blocks CSS generation model.[/b] EB stores per-block layout CSS (including max-width:1170px on the row wrapper) in a generated stylesheet keyed to block IDs. That CSS is regenerated when a block is saved [i]through the editor[/i], not when post_content is edited directly in the DB. Every DB-side edit that introduced a new/cloned block ID produced an orphaned block with no stylesheet entry, losing its width constraint and rendering full-width. This is the specific mechanism that made every DB fix fail.

[b]Contributing factor 2 — false-confidence reporting.[/b] Both agents reported the visual task as "done ✓" multiple times without any means of verifying the visual result. This mirrors the false-confidence pattern flagged in prior incidents (agents marking work complete without operator confirmation).

[b]Contributing factor 3 — diagnostic rabbit-holing.[/b] Significant time was lost chasing cache/redirect/hairpin-NAT theories for a "page not updating" symptom whose real cause was a mix of (a) needing a cache flush and (b) the visual defect being a separate issue from the feed swap. The symptom was treated as one problem when it was two.

[b]Contributing factor 4 — backup newline encoding.[/b] The backup file stored newlines as literal [code]\n[/code]. Restoring it wrote literal [code]\n[/code] into post_content, reproducing the exact shell-escape corruption pattern from the 2026-07-03/04 incidents. This confirms backups taken via SELECT-to-file must be verified for real vs. literal newlines before being trusted as a restore source.

[b]What Worked[/b]

[list]
[*][b]Podcast feed swap (data task):[/b] fully successful. Verified international, current-episode replacements installed: Slo Mo → AI Explained (id 6839789, UK), Artificiality → This Day in AI (id 5327041, Australia), Exponential View → AI Every Day (id 6861471). Kept: MLST 2815424, London Futurists 6822103, Me Myself and AI 4573081.
[*][b]Guard-safe write method:[/b] writes to post 6284 succeed only when content carries ≥3 real newline bytes (satisfying guard_post_corruption). Base64 → FROM_BASE64 write path avoids shell-escaping corruption.
[*][b]Corruption cleanup:[/b] literal \n reintroduced by the backup restore was cleared with a single targeted REPLACE — length dropped, LOCATE returned 0, page rendered clean.
[/list]

[b]Guard Status (clarification for the record)[/b]

guard_post_corruption (BEFORE UPDATE trigger on wp44_posts) was NOT disabled or modified at any point. It remained active throughout. It correctly reverted early write attempts whose content had <3 real newlines (silently resetting NEW.post_content = OLD.post_content, which presented as "write succeeded, DB unchanged"). This silent-revert behavior is by design but is a diagnostic trap: a write can report success and change nothing. Future agents editing wp44_posts must verify post-write LENGTH(post_content) actually changed, not trust the absence of an error.

[b]Corrective Actions / Standing Rules[/b]

[list=1]
[*][b]VISUAL TASKS ARE OUT OF SCOPE FOR AGENTS.[/b] Any task requiring visual judgment, visual calibration, layout/spacing/alignment review, or "make X look like Y" on a rendered page must be performed by the operator, not delegated to Augy/Claude/any agent. Agents cannot see rendered output and must not attempt to converge on a visual target via blind markup edits.
[*][b]Task triage before delegation.[/b] Before assigning work, classify it: (a) pure data/text/config edit → agent-capable; (b) requires visual/graphical judgment → operator-only. Mixed tasks must be split: agent does the data portion, operator does the visual portion.
[*][b]No "done ✓" on unverifiable work.[/b] Agents must not report a visual/layout task as complete. For any task an agent cannot verify by its own means, it reports "data change applied; visual result requires your confirmation" and stops.
[*][b]Essential Blocks layout edits go through the editor, not the DB.[/b] Editing EB row/column structure via direct DB writes orphans the generated CSS and breaks width/layout. Podcast embed ID swaps inside an otherwise-unchanged block are safe via DB; structural changes (cloning rows, new block IDs, column metadata) are not and must be done in the editor.
[*][b]Verify write actually landed.[/b] After any wp44_posts UPDATE, confirm LENGTH(post_content) changed. The guard can silently revert; a clean exit code is not proof of a successful write.
[*][b]Verify backup newline encoding before restore.[/b] Before trusting any SELECT-to-file backup as a restore source, check for literal \n. Restore only after confirming real newlines, or convert on restore.
[*][b]Symptom decomposition.[/b] "Page not updating" is not automatically a cache problem. Separate (a) is the server serving new bytes? (curl the pretty URL) from (b) is what changed the thing the operator is actually looking at? Confirm both before theorizing about caches, CDNs, or NAT.
[/list]

[b]Operator Note (for the KB)[/b]

The operator's own conclusion, recorded verbatim in intent: the operator was the effective root cause by delegating a visually-dependent task to agents that are structurally incapable of visual work. The corrective is process, not tooling — visual work is separated out and owned by the operator, and any delegated task is structured and documented so the agent-capable vs. operator-only boundary is explicit up front.

[b]Refs:[/b] Page 6284 (/ai/) on dev-lyyf, post_content stored in wp44_posts. Related incidents: tid=100000071 (2026-07-03 YFP data loss), tid=100000072 (2026-07-04 shell-escape corruption).

Lyyf Online - All Forums

INCIDENT REPORT: Bronn Forum Login Lockout — 2026-07-10

INCIDENT REPORT: Failed Visual Layout Edit on /ai/ Page — 2026-07-09