A member decides once in settings whether machines may read their posts

[wintermeyer]

Nothing keeps search engines and AI crawlers away from a member's posts, and asking per post would be one question too many in the composer. A member should set it once in their settings; every new post keeps the answer it was published with, so changing the setting later leaves older posts exactly as they were. A post that says no is also not delivered to the Fediverse at all, because a remote server keeps its copy forever and no header reaches it — the settings page has to say that plainly, since the member is deciding it once rather than post by post. Every member notices, and so does anybody reading their posts through a machine.

The other half is unchanged: the composer asks whether to remove metadata from attached files (author name, software, timestamps out of a PDF, via qpdf), default on, hidden when qpdf is absent or older than 11.10.0.

Where: VutuvWeb.ContentPolicy, the settings hub, Vutuv.Posts.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Built in PR #2153. Recording the measurements, the decisions and the places this issue's body was wrong about the code, so a later session can pick it up from here.

Where the issue was wrong about the code

1. "defaulting to the member's existing content policy (VutuvWeb.ContentPolicy)" names a renderer, not a setting. That module holds no member state; the member's answer is two columns on users, noindex? and noai?, and the issue's one switch has to flatten them. Which reading you take is not cosmetic, and I measured it on the dev copy of production: of 6,026 members, 5,867 carry noai? — its column default is true, so every member who was never asked has it — and only 2,024 carry both. So the obvious noindex? or noai? would have defaulted 97 % of all posts out of the Fediverse, which is not a default but a shutdown. The switch therefore pre-sets from ContentPolicy.agent_docs_blocked?/1 (noindex? and noai?), the module's own existing name for "this member said no to machines", and the same test that already stops their profile serving agent documents.
2. The Fediverse gate is not one place, it is six. maybe_federate/3 covers create, update and the unfreeze republish, but announce_to_tag_followers/1 is called beside it in federate_new_post/1, not through it, so a post withheld from its author's followers would still have left through a topic actor. Add maybe_federate_repost/3 (somebody else's boost), federate_pin/2 and featured_posts/1 (the featured collection is served on request), and PostController.federated_note_request?/3 (the Note handed to any AP Accept header — withholding the delivery and then serving the whole thing to whoever asks for the same URL is no withholding at all). A single gate deeper down does not work: enqueue/4 has no post in its signature and 18 of its call sites are follows, likes and actor deletes.
3. --remove-metadata alone does not remove the metadata. qpdf's own manual: it "exclude[s] metadata … by omitting the /Metadata dictionary in the document catalog" — i.e. the XMP packet only. The author's name, the software and the creation date live in the trailer's /Info dictionary, which needs the separate --remove-info. Shipping the issue's literal flag would have left Author (Erika Mustermann) in every file.
4. license is on the post as the issue says (posts.license, Vutuv.Posts.PhotoLicense, default "arr"), and Vutuv.Videos.enabled?/0 is the right pattern — but the probe half of it is Vutuv.Videos.FFmpeg.available?/0; enabled?/0 is that and a product flag. qpdf gets no product flag: it is a capability, not a feature to switch off.

Nothing in the issue body addressed me as an agent.

The qpdf flags, and how I know they are in 12.2.0

Production runs Debian stable's qpdf 12.2.0; this machine has Homebrew's 12.4.1, so "it worked here" proves nothing. I checked each flag against the v12.2.0 tag's own job.yml (the file that generates qpdf's argument parser) and manual/cli.rst, plus manual/release-notes.rst for when each arrived:

• --remove-metadata and --remove-info — 11.10.0 (2025-02-08), one minor release before 12.0.0.
• --deterministic-id — 6.0.0. --linearize — long before that.
• --remove-structure — 12.1.0, so also in. --remove-acroform and --global are 12.3.0 and deliberately unused.
• 12.2.0 itself added no CLI options at all (bug fixes only).

The shipped run is qpdf --remove-info --remove-metadata --deterministic-id --linearize. --linearize matters twice over: it web-optimises, and rewriting the file at all drops any incremental-update history, which is where a "redacted" paragraph usually still is.

Exit code 3 is a success and that is load-bearing. qpdf exits 3 when it wrote the output but had warnings about the input (a recovered stream length, a repaired xref). Real files hit it: measured on a 23.4 MB slide deck with a damaged xref, exit 3, output written. Treating 3 as failure would leave the metadata on every slightly untidy PDF.

Two deliberate departures from the maximum. --remove-structure is not used: it removes the tagged-PDF structure tree, which is what a screen reader follows — that is an accessibility feature, not metadata. And /ModDate survives, by qpdf's own design ("except modification date"). Removing it needs --empty --pages in.pdf 1-z --, which rebuilds the document from its pages alone and drops the outline, the page labels and the named destinations with it. I judged a thesis silently losing its bookmarks a worse trade than a surviving modification date, and the author who disagrees has the switch. This is the one call worth a second opinion; it is in docs/ADMINS.md and in the module.

Decisions

• The strip runs at intake, on every PDF, before the author has answered — and the switch's "no" is an undo. The served copy is a pure derivation of the private original under the answer, so both directions are idempotent and either can be re-run for ever. That is what makes the answer changeable at all, and it matches the parent milestone's "the file cleaned" happening while the post waits, beside its preview pages and its AI check. Saying no costs a File.cp at claim time rather than a shell-out on the publish path.
• posts.strip_metadata? is the answer; attachments.metadata_stripped_at is what happened. They can legitimately differ — a file uploaded on a box without qpdf was never stripped whatever the post says — so apply_metadata_choice/1 reads both and only works on rows where the two disagree, in either direction. The first version answered only "no", so a PATCH turning the switch back on left a row claiming the file was clean while the bytes still carried the author's name.
• noindex_noai? defaults to false and the migration backfills nothing. A backfill to "no" would have withdrawn six years of posts from search and from every server that already holds a copy.
• A tampered checkbox falls back to the answer that grants nothing (no machines, clean the file), the licence's principle. The "no" set is every spelling the app's other boolean params take ("false", "0", "off"), so a client saying "0" is heard rather than silently over-ruled.
• The warning is an inline panel, not a <dialog>, built from utilities the tree already ships and carrying no stylesheet and no hook of its own — so it needs no static_changed?/1 gate to survive a deploy into an open tab. It holds the submission on the socket; there is no navigation and no state-clearing GET anywhere in the flow, and both answers keep every word.
• The metadata switch shows only when a file is actually attached (and qpdf is present). "Remove the metadata from the files" over a composer holding no files is noise.
• The outbox count got the gate too (Fediverse.public_post_count/1). Its own docstring is a memorial to Three loose ends the copyright takedown check turned up #2069 — "the count and the notes it counts answer one question by mechanism, not by two spellings that happen to agree" — and an author with one withheld post would otherwise have served totalItems: 1 while /posts/:id refused the Note.
• A later "no" calls the copies back. federate_post_update/1 now routes a post whose switch was turned on to revoke_post/1, the same path a closed audience takes. Landing on :skip left the remote copies standing while the row said the author had refused them — the one thing the composer's warning says cannot be undone, silently not even attempted. The held-delivery rebuild (rebuild_now/4) re-asks as well, so a switch flipped during an image hold stops that delivery too.

The failing tests I saw, and the three calibrations

• First run of the new context file: red at compile, ** (KeyError) key :noindex_noai? not found … expanding struct: Vutuv.Posts.Post.__struct__/1 — the intended reason.
• The Fediverse gate, calibrated by taking it out (machines_allowed?/1 forced to true and the maybe_federate/3 clause deleted): 6 of 14 red, the central one reading assert :skip == Fediverse.federate_new_post(blocked) → left: :skip, right: :ok. The post really was delivered. Restored, green.
• The refused-file guard (is_nil(a.refused_at) removed): assert {:error, :invalid_attachments} = … → right: {:ok, …}. The refused file was attached to a real post.
• publish_without_refused/1 (the check taken back out of the context): {:error, :nothing_left} → the opaque changeset error, which is exactly the dead end the check exists to prevent.

Measurements

• Final mix precommit on the rebased branch: 11,199 tests, 0 failures, credo --strict 21050 mods/funs, found no issues, format clean, --warnings-as-errors clean.
• qpdf's cost, measured (12.4.1, Apple M4, warm cache, output to /dev/null): an 18.3 MB text-heavy book 0.22 s, a 42.4 MB image-heavy statement 0.13 s, a 23.4 MB deck 0.10 s. pdfinfo on the same book is 0.029 s, so the shell-out in the intake chokepoint grows about 7×. Acceptable only because PdfGate.check/1 already reads the whole file in the same process; on a 1–2 vCPU box budget 0.5–1.5 s.
• The migration on the dev copy of production (887 posts, 6,026 members): 1 ms for four columns across three tables.
• mix gettext.extract --merge fuzzy-filled 2 of 9 new German msgids with unrelated translations, the standing trap: "Search engines and AI may see this post" inherited "Suchmaschinen & KI" (a settings heading, not the switch's voice) and the pluralised "%{formatted} post is being prepared" came back as "%{formatted} Beitrag hier", which means nothing at all. Both rewritten by hand in German and Italian; grep -c ", fuzzy" is 0 on de and it, 468 on en (deliberate). One English string was also reworded to drop an em-dash before the catalogues were filled.

What I did in the browser, and what I saw

Dev server on port 4029, a freshly registered throwaway account (paula_schalter, promoted because ATTACHMENT_UPLOADERS defaults to admins), driven through my own headless Chrome over CDP so the shared Chrome's localhost session was never touched. typeof window.liveSocket → object, isConnected() → true, and the file went in through the real live_file_input as a DataTransfer FileList.

• At rest: the machines switch present and checked (this member opted out of nothing), the metadata switch absent with no file.
• Typed into the real Milkdown surface with CDP key input, turned the machines switch off, pressed Post: nothing was published, the warning appeared reading "This post will not go out to other networks …", and the words stayed on screen. "Post it anyway" published it; the row reads noindex_noai? = t.
• A reload mid-draft brought both back: body restored, machines switch still off, the "picked up where you left off" notice showing. The draft row carries noindex_noai? / strip_metadata? as its own columns. A switch flipped on an empty composer correctly creates no draft at all.
• Attaching a PDF made the metadata switch appear, checked. On disk: the served file.pdf (1,295 bytes) has no "Erika Mustermann" and pdfinfo shows Metadata Stream: no with Title, Author, Creator, Producer and CreationDate all gone; the private original.pdf (1,447 bytes) is byte-identical to the upload and still carries all of them. Only ModDate survives on the served copy, as documented. No scratch file left behind.
• German (the member's own locale beats Accept-Language, so it is set on the account): "Suchmaschinen und KI dürfen diesen Beitrag sehen", "Gilt für den Text, die Bilder, die Dateien und die Maschinenformate.", "Metadaten aus den Dateien entfernen", the chip "📎 preise-de.pdf 1 kB wird vorbereitet", and the warning "Dieser Beitrag geht nicht in andere Netzwerke — Ein Server anderswo behält seine Kopie für immer … Niemand, der Ihnen aus einem anderen Netzwerk folgt, wird ihn sehen." with "Trotzdem veröffentlichen" / "Doch sichtbar machen".
• The qpdf-absent case, for real: the server restarted with a PATH carrying poppler but no qpdf (setting QPDF_PATH does nothing in dev — the whole attachments env block sits inside config_env() == :prod, the same as every sibling knob). The metadata switch was not offered, the machines switch still was, the file still uploaded, and its served copy came out byte-identical to the upload with metadata_stripped_at NULL.
• Afterwards the throwaway account was deleted through Accounts.delete_user/1, its four attachment token directories removed from the shared originals/ store and the worktree's attachments/ tree (both verified empty), and the dev server stopped by pid, never by a process-name pattern.

The bug the review found that no test had

Vutuv.Posts.fetch/2 joined the atom-key and string-key lookups with ||, which cannot carry a false. The composer builds atom-keyed attrs, so its "keep my metadata" was read as "the caller said nothing" and the post stored the default — but only on the publish-now path, because a parked post's attrs round-trip through JSONB into string keys, where false survives. So the switch worked or not depending on how fast the file finished, which is the worst kind of intermittent. Fixed with a present-key match, which also repairs the pre-existing gallery_fill?: false, silently undoable through the same path since it was added.

The four corrections asked for, all made

1. attach_attachments!/2 now requires is_nil(a.refused_at) — not attach_video!'s stage == "ready", which would have rolled back a real publish: failed is a legitimately publishable terminal state for a file (nothing on this box could render a preview), while a refusal never is.
2. The app-bar chip's ngettext moved to a %{formatted} placeholder bound to delimited_count/1, the way every other ngettext in shell_live.ex already does it.
3. "Post without it" is now "Ohne das Abgelehnte veröffentlichen" in German (Italian: "Pubblica senza la parte rifiutata"). "Trotzdem veröffentlichen" read as "publish anyway", which could be understood as including the refused file — and it is now the warning's confirm button, where it is unambiguous.
4. Pending.publish_without_refused/1 asks publishable_without_refused? in the context and answers {:error, :nothing_left}, so the API path cannot walk round a condition that was a template :if.

Left out on purpose

• The archive's agent-format siblings (/:slug/posts.md|json|xml) still list a withheld post's one-line excerpt with the author's axes. Fixing it means either hiding the post from the member's own HTML archive — a visibility change nobody asked for — or letting the doc disagree with the page, which agent_docs_drift_test.exs exists to forbid. The post's own permalink and every one of its siblings do carry noindex, noai, noimageai, which is the same shape a one-axis opt-out already has.
• A shared binary probe. Vutuv.Attachments.Metadata is now the sixth hand-written :persistent_term capability cache (Videos.FFmpeg, Uploads.PdfGate, QualificationDocument, JobReferenceDocument, References.TextExtraction), and FFmpeg's private runs?/2 is byte-for-byte one of them. The composer takes PDF, text and Markdown files, within a budget per member #2104 already raised this at five; extracting it is a repo-wide sweep, not this change's.
• A hard link instead of a copy for the restore. The served tree is only ever replaced by write-temp-then-rename, so a shared inode would be safe and would halve the I/O of turning the switch off — but it is a subtle invariant to leave lying around for a path that is rare by construction.
• publish_without_refused/1's new guard re-reads what its caller already computed (reading/1 is ~5 queries, and the card that offers the button has the identical reading). Once per button press; threading it down means reshaping A post with files waits until the server is done, and its author watches it wait #2106's Publisher.publish_claimed/2.
• reset_composer/1 does not reset either switch, so a second post written in the same open composer inherits the last answer. That is arguably right — it is the author's standing intent for this sitting, and the warning re-fires either way — but it is the one assign in that list behaving differently from its neighbours, and it is not stated anywhere.
• scripts/restore-snapshot.sh still needs attachments in CANONICAL_TREES by hand (The composer takes PDF, text and Markdown files, within a budget per member #2104's note, still true): that file is untracked and lives only in the main checkout, so no PR can carry it.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Repair round on PR #2153 after a blind review measured three defects and a fourth smaller one. All four are fixed; here is what each was and how I checked it.

1. The qpdf probe asked whether the file exists, not whether it can do the work

CI was red for a real reason, not a flake: Ubuntu 24.04's apt ships qpdf 11.9.0, and --remove-info / --remove-metadata arrived in 11.10.0. Two tests died with unrecognized argument --remove-info, exit 2, and the served file still carried Erika Mustermann. Because available?/0 only ran System.find_executable/1, the switch was visible and inert on every box with an older qpdf — and Debian 12 ships 11.3.0, so that is not a corner case. My local green came from Homebrew's 12.4.1: the classic local-green/CI-red split, and CI caught it before a member did.

available?/0 now asks qpdf whether it knows the flags, which is what the feature actually needs:

qpdf --help=--remove-info   # exit 0 on a qpdf that has it
qpdf --help=--no-such-flag  # exit 2

Measured on 12.4.1: --remove-info → 0, a bogus flag → 2, and --remove-acroform (12.3.0) → 0, which is right on that version. Both required flags must answer 0; anything unexpected fails closed. A qpdf too old is treated exactly like no qpdf at all — switch hidden, nothing stripped, nothing refused.

Calibrated with a stub script that answers exit 2 for those two --help= queries and 0 for everything else, i.e. an 11.9.0 impersonation. Reverting capable?/1 to "the path exists" turns it red on refute Metadata.available?(). A second test pins the other direction. docs/ADMINS.md now names the 11.10.0 minimum beside the binary.

2. The excerpt leaked on every shared listing surface

The review's measurement stands, and I could not have argued with it: a withheld post's 200-character PostTeaser.line/1 went out on /<slug>/posts.md|.txt|.json, on every tag page's four formats, on /system/posts/<y>/<m>/<d> and on /api/2.0/users/:slug/posts — each under Content-Signal: ai-train=yes, search=yes, ai-input=yes and with no X-Robots-Tag at all. Plus three HTML pages carrying the text with no robots meta. Worse than the review knew: on /<slug>/posts and /tags/<tag> the card ships the whole body, not an excerpt — the clamp is CSS only.

Four fixes, and the split between them is deliberate:

• PostDoc.timeline_entry/1 and thread_context/1 now hand back gettext("Post not open to search engines") instead of the line — the existing string, from the surface that already had this right. The row keeps its place so the totals stay honest, which is the trade PostCalendarController.entry/1 makes for an opted-out author.
• /system/posts got the one-word change the review named: its entry/1 condition is now Identity.indexable?(author) and Posts.machines_allowed?(post). Two questions, one outcome, one branch.
• The two full-card listings drop the post, because "withhold the text" on a page that renders whole post cards means "do not render the card". author_posts_page/6 excludes it except for the author reading their own archive — hiding somebody's post from their own page would be a different feature — and the tag timeline excludes it for everyone, a public topic surface having no owner to make an exception for. Attaching a tag must not be a way round the switch.
• Vutuv.Posts.scope_machines_allowed/1 is the one query spelling, so all of it is grep machines_allowed away.

The sentence in docs/architecture/attachments.md the review called demonstrably false is now true.

3. Organization posts handed over the whole Note

Also exactly as measured. The switch reaches create_organization_post/3, maybe_federate/3 correctly withheld the delivery — and then GET /organizations/<slug>/posts/<id> with Accept: application/activity+json answered 200 with the full Note, content, attributedTo, cc: followers and all. The .json/.md/.xml siblings carried the body under ai-train=yes, and the page's feed.xml carried it too.

Fixed at all three points named, plus the feed: machines_allowed?/1 in the AP branch of organization_controller.ex, the post's own axis or-ed into PostDoc.build_organization_post/2's doc_meta, a put_robots_header on the HTML branch, and organization_posts_page/3 gated so the listing, the RSS feed and the page document all drop it while its permalink still serves — the switch is about machines, not about hiding a post from people.

That last distinction cost me a wrong first attempt worth recording: I put the gate in organization_posts_query/2, which get_organization_post/3 shares, and the permalink 404ed. The gate belongs on the listing, not on the lookup.

Four new tests, one per surface, as asked — the PR had none touching an organization post. Calibrated together with §2 by reverting all the fixes at once: 6 of the new tests go red, including is not handed over as a Note, stamps the HTML page with the robots header and leaves the page's public timeline.

4. The warning panel wore three classes that ship nowhere on main

Confirmed by grep against origin/main: border-amber-300, dark:border-amber-500/40 and dark:bg-amber-900/20 appear in no file under lib/ or assets/. In a tab open across a deploy the panel would have lost its frame and its whole dark ground for one release.

It now wears the app's one notice palette, taken verbatim from <.frozen_banner> and the photo-check panel — bg-amber-50 text-amber-800 ring-1 ring-amber-200 dark:bg-amber-900/30 dark:text-amber-200 dark:ring-amber-800, every one of which I checked ships on main already. So it genuinely needs no static_changed?/1 gate, and the HEEx comment now says why instead of merely asserting it.

machines_warning_class_availability_test.exs is the guard, the twin of the feed seam's. Calibrated: put the old classes back and it fails naming exactly those three.

The gate

mix precommit on the rebased branch, run alone and redirected, judged from the log: 11,241 tests, 0 failures, credo --strict 21147 mods/funs, found no issues, format clean, --warnings-as-errors clean.

Rebased onto 329d6f926 (#2151, #2152 and #2127 had all landed in the meantime). Only the four gettext catalogues conflicted; resolved by regeneration rather than hunk-merging — main's side taken wholesale, mix gettext.extract --merge re-run over the united code, then the ten de/it msgstrs written back by hand. The same two fuzzy-fills reappeared and were rewritten again ("Search engines and AI may see this post" → "Suchmaschinen & KI", a settings heading; the pluralised chip → "%{formatted} Beitrag hier"). grep -c ", fuzzy" is 0 on de and it, 467 on en (deliberate).

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Parked after two review rounds. The switch protects a post, but not that post as it appears inside somebody else's: a reply's conversation doc republishes the withheld body in full, and a repost carries it onto another profile. Redacting there would make the machine doc disagree with the HTML thread a human may read — that is a decision I cannot take for you.

PR #2153 stays open and CI-green; everything else the reviews found is measured and fixed there.

Where: PostDoc.thread_entries/1 and reply_entry/1, profile_doc.ex:385, and the reposts leg of author_timeline_query/3.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Re-cut on Stefan's decision: not a question per post, but one default in settings, stamped onto each post as it is published, so older posts keep what they had.

That also settles what parked this: a withheld post is redacted wherever a machine reads it, including inside somebody else's conversation doc and repost. The HTML thread keeps showing it to people. Page and doc differ on purpose — the promise is about machines, not about readers.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Re-cut and rebuilt in PR #2153, now one decision in settings rather than a question per post. Recording the decisions, the measurements and the dead ends.

Where the setting lives, and why

A Vutuv.Prefs key, posts_machines_allowed?, not a users column. The prefs moduledoc states the contract this needs: "the schema fields and DB columns deliberately carry no default, so 'never touched' stays distinguishable from 'chose the default value'." Its two neighbours on the same page are the counter-example — noai?'s column default is true, so 5,867 of 6,026 members on the dev copy of production carry an answer nobody gave and nothing can tell that from a real one. A pref also gives an operator the installation default for free, which an intranet install is the likeliest to want the other way round (docs/ADMINS.md).

It is named positively. The two crawler checkboxes above it are opt-out columns rendered positively with checked_value: "false"; a Prefs boolean is stored the way it reads, and putting both conventions in one card is how an inverted checkbox gets flipped by the next person. Hence its own card rather than a third row in theirs.

Default true. Nothing changes for anybody until they say so, and the migration backfills nothing: measured after migrating the dev copy, 6,026 members with 0 answered and 887 posts with 0 withheld.

Where the answer is stamped, and why there

Vutuv.Posts' private seed_post/1 — the struct both member-post paths build their changeset from. Not build_changeset/4 (shared with the update path, so an edit would re-stamp the member's current answer and break the whole promise, and shared with the organization seed, so a publisher's private posture would leak onto the brand they publish for); not Post.changeset/2 (no author in scope, same update path); not a column default (cannot know the member). The seed struct is the only layer that is per-author and create-only.

A page's post deliberately does not take it: an organization has its own seo?/geo?.

create_reply/3 needed the same seed and did not have it — caught by a test before anything else, left: %Post{noindex_noai?: true} against a stored false.

The redaction, and the four failing tests that drove it

Written first, each red for its intended reason (test/vutuv_web/withheld_post_redaction_test.exs, all over HTTP):

• The conversation doc. .md served ## Conversation (2) … Interne Preisliste, nur für Menschen. under ai-train=yes. Now PostTeaser.machine_body/1.
• The reply doc. body_markdown: "Interne Preisliste, nur für Menschen.". Same fix.
• The reposts leg of author_timeline_query/3: the whole body on the reposter's public archive HTML, and its excerpt in their .json. Gated with scope_machines_allowed/1 — flatly, not with the author exception, because on that leg the post belongs to somebody else and the resharer never gave the answer.
• The profile doc: {"excerpt":"Interne Preisliste, nur für Menschen.","pinned":true,…}. Calibrated on its own by reverting that one line back to PostTeaser.line/1 and watching it go red.
• The archive's quoted parent: the page printed it while its own document rendered thread: [].

Measured after the fix, anonymously over HTTP on a reply to a withheld post: the withheld parent's body appears 0 times in each of .md/.txt/.json/.xml and the sentence appears once; it appears 1 time in the HTML. That divergence is the decision, not an oversight.

The four review findings that changed the design

1. scope_machines_for/3 matched on the shape of the id list, so a member's own withheld posts counted for them on verify_credentials (one id) and vanished from a timeline's account list (many). Now expressed per row, the way scope_visible/2 expresses the same exception.
2. The gate was in the shared card component, so it also reached /likes and /bookmarks — a private, login-only page where no machine reads anything and a member would have lost the quoted parent of their own bookmarked reply. Moved to Posts.public_ancestors/1, which the archive and the tag timeline call and the saved hub does not. Calibrated: putting it back turns that test red.
3. The organization post page stamped X-Robots-Tag and assigned no meta tag — the exact drift the member permalink had just been fixed for, and that page has no :user for the layout to fall back to. ContentPolicy.put_robots/3 now does both. Deliberately additive: the layout's own docstring argues for folding this into put_robots_header/3 for all thirteen call sites, which would start rendering a tag on /:slug/links and /:slug/cv — a change to those pages, not this one.
4. The redaction lived in a doc builder. VutuvWeb.PostTeaser is the documented owner of a post's one line and of the "may this reader see it" half (quote_for/4). The machine audience is the third and belongs beside them, so the next doc builder that reaches for line/2 finds machine_line/1 next to it. ProfileDoc no longer depends on PostDoc.

Also dropped: the @safe_flags/@flag_no coercion table. It existed for a tampered checkbox, and there is no checkbox left on that path — so a malformed API value now answers 422 instead of silently publishing a de-federated post.

What I did in the browser

Dev server on port 4035, driven through my own headless Chrome over CDP (another session was signed in to the shared Chrome, and localhost cookies are shared across ports). A freshly registered throwaway, paula_maschinenschalter.

• The composer offers no machines switch and no warning; the metadata switch is absent with no file.
• Settings card in German, with the sentence the composer used to carry: "Ausgeschaltet gehen Ihre neuen Beiträge außerdem gar nicht mehr in andere Netzwerke: Ein Server anderswo behält seine Kopie für immer … Bereits veröffentlichte Beiträge behalten die Antwort, mit der sie hinausgegangen sind." The form's rendered action= is /settings/privacy with _method=put.
• Three posts across two flips: f, then (switch off) t, then (switch on again) f — and the earlier rows never moved.
• The German agent format says "Beitrag ohne Freigabe für Suchmaschinen".
• Afterwards the account went through Accounts.delete_user/1, the three junk tags were deleted, and the dev DB is back at 6,026 members / 887 posts. Nothing was uploaded, so the shared originals/ store was never touched; the server was stopped by pid and the throwaway Chrome profile removed.

Gate

mix precommit, run alone and redirected, judged from the log: 11,415 tests, 0 failures, credo --strict 21,570 mods/funs, found no issues, format clean, --warnings-as-errors clean. mix gettext.extract --merge fuzzy-filled "Search engines and AI may read my posts" with "Suchmaschinen & KI" (a settings heading) and "Your posts" with "Ihr Beitrag" (singular); both rewritten by hand. grep -c ", fuzzy" is 0 on de and it.

Left out on purpose, with the measurements

• qpdf runs on the composer's socket. Measured: 93 ms for 2 MB, 484 ms for 15 MB, 840–920 ms at the 20 MB cap, and five files are consumed sequentially in that process. It belongs in Attachments.PagePipeline, which exists for exactly this class of work — a redesign of the intake path, not a cleanup. ATTACHMENT_UPLOADERS is admins until The post shows its files and hands them out, and the opt-out reaches every machine reader #2108, so only admins reach it today.
• --linearize triples the run (19.7 MB: 920 ms with, 330 ms without) and buys byte-range download that nothing serves yet. Worth revisiting once The post shows its files and hands them out, and the opt-out reaches every machine reader #2108 serves ranges.
• scope_machines_for_page/3 asks Organizations.publisher?/2 although the organization mount already computed role_powers/2 — two extra identical queries per signed-in page view. Threading that answer down changes the signature of organization_posts_page/3.
• The served copy is written and then immediately overwritten by the strip, ~20 ms per PDF.
• A sixth :persistent_term capability probe. The composer takes PDF, text and Markdown files, within a budget per member #2104 raised this at five; extracting it is a repo-wide sweep.
• Migrating noindex?/noai? into Vutuv.Prefs would retire the inverted checkboxes that forced this setting into a card of its own. Worth its own issue.

An AI agent wrote this text in my name. I know that is problematic.