Closed general

AI reprimand gap: page create asks no bloat question, and page undelete is a friction-free bloat backdoor

John Lauer · 2mo ago ·closed by Colby Knox

Filed at John's request so Colby sees it, from a real incident today (2026-08-02).

What happened

An AI thread was asked to make a screen-takeover etiquette guide a core skill for all Adom users. Instead of adding it to the adom/adom pack (which ALREADY shipped a skill with that exact name), it found the standalone slug soft-deleted, ran page undelete, and pushed content into the resurrected page. John: "oh my god. you created wiki bloat."

The key tooling finding: page undelete restored a bloat-deleted page with zero friction, which bypassed every creation checkpoint at once: the create-time slug conflict, the hero-in-front-of-a-human gate, and the new-page lint. The CLI reprimands shared-identity publishes and placeholder changelogs, but neither page create nor page undelete asks the bloat question at all.

Ask

Add an AI reprimand to both paths:

  1. page create: require --because "<why no existing home fits>" and print the wiki-bloat rule ("before creating anything, first find where it should already live") plus pack-search suggestions derived from trigger overlap with existing pages and skillpacks. Reject placeholder justifications the same way placeholder changelogs are rejected.

  2. page undelete: print WHO deleted the page, WHEN, and the deletion changelog, then refuse without --confirm-not-bloat, an explicit acknowledgment that the page may have been deliberately removed as bloat. A soft-delete is very often a judgment someone already made; resurrecting it should carry at least as much friction as creating it.

Context

The incident and the rules it produced are recorded in the wiki-bloat skill (adom/adom-wiki-skillpack, "Case study 2: the UNDELETE loophole"). Until the CLI gains these gates, that skill is the only line of defense, and it only works on AIs that read it before acting, which is exactly what failed today.

1 Reply

Colby Knox · 2mo ago

The wiki half is live on prod; the CLI half is filed on the CLI's own tracker (adom/adom-wiki-cli#20), so this can close here.

Shipped, server-side, so it catches every client including raw API

  1. The undelete loophole is gated. POST /undelete now refuses without ?confirm=<owner>/<slug> and returns UNDELETE_NEEDS_CONFIRM with exactly the disclosure you asked for: who deleted the page and when (from the action log), plus the bloat framing ("a soft-delete is often a judgment someone already made; restoring bypasses every creation checkpoint"). The prose hint names the exact retry, so current CLIs are not broken, they just have to read the reprimand, which is the point. This would have stopped the 2026-08-02 incident cold: the resurrection required an explicit "I checked, this is not bloat" act.

  2. Creation now asks the bloat question on the one response a creator reads. The first publish of a slug returns a SIMILAR_PAGES_EXIST hint naming existing pages related by title, with the rule spelled out: before building here, check whether one of them is where this content should already live. It never blocks (the server cannot know intent, and false-positive refusals would be worse than the disease), but hint passthrough puts it in front of every AI publisher automatically.

Filed on the CLI (adom/adom-wiki-cli#20), per your ask

  • repo undelete --confirm-not-bloat mapping to the confirm param, with the disclosure printed prominently.
  • page create --because "<why no existing home fits>", rejecting placeholder justifications the way placeholder changelogs are rejected, printed BEFORE the network call. Kept client-side deliberately: a server-mandatory justification field would break every existing client, while the undelete gate (rare operation, real incident) earns the hard server break.

Until the CLI ships those, the server gate plus the wiki-bloat skill are the lines of defense, and the gate does not depend on anyone reading anything first.

Log in to reply.