Skip to content

docs(agents): forbid string-editing post_content, add /edit-block-content - #23

Open
Schmandarine wants to merge 1 commit into
mainfrom
docs/never-string-edit-post-content
Open

docs(agents): forbid string-editing post_content, add /edit-block-content#23
Schmandarine wants to merge 1 commit into
mainfrom
docs/never-string-edit-post-content

Conversation

@Schmandarine

Copy link
Copy Markdown
Collaborator

Closes #22

Docs only — no code, no behaviour change.

What's here

File
packages/cli/AGENTS/edit-block-content.md New skill /edit-block-content — the safe procedure for changing a block's field values on a live page
AGENTS.md Hard rule section + a line in What NOT to do + skills-table row
skills/wordpress/SKILL.md Same rule condensed, so it ships via npx skills add brmbh/wordpress

The procedure it mandates

snapshot → parse_blocks() → modify → serialize_blocks() → wp_slash() → verify → diff

wp_slash() is the load-bearing call: wp_update_post() and wp_insert_post() run wp_unslash() on their input, so handing them clean content strips one backslash level and turns every block-attribute escape into literal page text (&u0026, \r\nrn).

And the verify step, which is what actually prevents recurrence:

wp post get <ID> --field=content | grep -oE '[^\\]u00[0-9a-f]{2}|[a-zäöüß]rn[A-ZÄÖÜ]'   # must print nothing

The skill also covers recovery, because the instinctive fix makes it worse: deleting the junk tokens in the ACF field destroys the original character with no trace, which is exactly what happened downstream of the incident in #22.

Notes for review

  • Skill wrappers are auto-discovered from AGENTS/*.md by brmbh add skills, so there's no registration list to update — /edit-block-content appears on the next install.
  • The rule reaches consuming projects only with the next @brmbh/cli publish.
  • A doctor check that scans a whole site for these artifacts is deliberately not in here — noted as out of scope on No guardrail against string-editing post_content — silently corrupts block attributes #22, worth its own issue.

…tent

An agent changing a field value on a live page has had no guidance, so the
obvious approach — str_replace on post_content — silently strips one
backslash level from the block's attribute JSON. Every escape degrades
into literal page text: & becomes u0026, \r\n becomes rn. It stays
valid JSON, so nothing errors and it ships.

Adds the /edit-block-content skill (snapshot, parse_blocks, wp_slash,
verify, diff, plus recovery for already-corrupted content), and states the
rule in AGENTS.md and the setup skill so it ships to consumers via
npx skills add brmbh/wordpress.

The verify grep is the load-bearing part: a rule an agent can check beats
one it can only remember.

Refs: #22
@Schmandarine Schmandarine added documentation Improvements or additions to documentation blocks ACF block factory agentic Agent-facing surface labels Aug 13, 2026
@Schmandarine

Copy link
Copy Markdown
Collaborator Author

Follow-up filed: #24 — the doctor check for finding existing damage, listed as out of scope here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agentic Agent-facing surface blocks ACF block factory documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

No guardrail against string-editing post_content — silently corrupts block attributes

1 participant