website/TEAMS.md

@@ -1139,7 +1139,7 @@ decoration. One settings key does the whole job, because `settings` already stor
 `updated_at` per key:
 
 ```
-teams_forum_uploads_ack = "<warning text version>"     e.g. "1"
+teams_forum_uploads_ack = "<warning text version>"     "1" — the wording in §5.5.5
   → updated_by  = the admin who acknowledged     (existing column)
   → updated_at  = when                            (existing column)
 ```
@@ -1158,20 +1158,66 @@ honouring a stale acknowledgement forever defeats versioning. So: **uploads keep
 persistent admin banner requires re-acknowledgement, and **no other forum setting may be saved until
 it is given**. Non-destructive, and impossible to ignore.
 
-**Draft warning text — the org lead should own the final wording.** This is liability language for
-the project, not something to settle in a design doc; it is drafted here so the mechanism can be
-built against something real:
+**The wording, version 1** — supplied by the org lead 2026-08-17 and normative for the build. It is
+**two surfaces, not one**, and the split matters: the first is always on screen and explains what the
+setting is, the second appears only at the moment of change and is what the acknowledgement records.
 
-> **Enabling uploads means your community can store files on your server.**
+**(a) Settings help text** — rendered beneath the image-mode selector at all times, in every mode:
+
+> Image uploads are disabled by default.
 >
-> Runic Gateway is software you are running yourself. The Runic Gateway project has no access to,
-> control over, or responsibility for any material your community uploads to your server. You — the
-> operator of this deployment — are solely responsible for what is stored and served from it,
-> including moderating it and complying with the law in your jurisdiction.
+> Enabling uploads allows users to store files on infrastructure that you control.
 >
-> Uploads are attributed to the account that made them and can be removed by your staff at any time.
+> By enabling this feature, you acknowledge that you are responsible for:
 >
-> ☐ I understand and accept responsibility for material uploaded to this server.
+> - Moderating uploaded content
+> - Managing storage and backups
+> - Complying with applicable laws and regulations
+> - Establishing policies for your community
+>
+> RunicGateway does not provide hosted storage or content moderation services. All uploaded content
+> is stored on your own infrastructure.
+
+**(b) Confirmation dialog** — shown only when changing the mode *to* `uploads`:
+
+> ⚠ Image uploads are currently disabled.
+>
+> Enabling uploads will allow users to store files on your server.
+>
+> ☐ I understand that uploaded files will be stored on infrastructure that I control.
+> ☐ I understand that I am responsible for community moderation policies on this installation.
+>
+> `Cancel` · `Enable uploads`
+
+**Two checkboxes, one recorded acknowledgement.** `Enable uploads` stays disabled until both are
+ticked, but the request still carries a single `acknowledge: 1` and the stored value is still the
+text **version**. Recording two booleans would add nothing — there is no reachable state where an
+operator consented to one clause and not the other and proceeded anyway — while the version is what
+actually answers the question that matters later: *which text did they agree to?*
+
+**Three additions proposed on top, marked so they can be dropped.** Each closes a gap the text above
+does not currently cover; none is liability language, so none changes what is being agreed to:
+
+1. **In the help text, after the bullets** — the reassuring counterpart, and the reason §5.5.4's
+   attribution table exists at all:
+   > Uploads are attributed to the account that made them, and your staff can remove them at any time.
+2. **In the dialog** — the expectation gap most likely to bite. An operator who turns uploads off
+   because of a problem will assume the problem goes with it, and it does not:
+   > Disabling uploads later stops new files being accepted. It does not delete files already
+   > uploaded — remove those from the forum moderation tools.
+3. **In the help text** — the blast radius, since "users" is doing a lot of work. Forum access is not
+   the same as game membership (§2.5 path 3), so this genuinely surprises:
+   > Anyone with access to a team forum can upload, including members granted access manually who have
+   > no linked game account.
+
+**Not covered by this text, and needing its own line: `remote` mode.** The wording above is
+upload-specific, and correctly so — nothing is stored in `remote` mode, which is why it takes a
+non-blocking advisory rather than an acknowledgement. It still needs one, because the operator's
+server is doing the displaying:
+
+> Images hosted elsewhere are loaded by each visitor's browser directly from the site hosting them.
+> That site can see your visitors' IP addresses, and you do not control whether the image changes or
+> disappears.
 
 #### 5.5.6 Publication