fixup! RFC 116: store attachment data in content items

rfc-116-store-attachment-data-in-content-items.md

@@ -112,15 +112,12 @@ I propose we do this:
    **Migration concerns:** this would need to be done in two steps:
    update apps; remove fields.
 
-1. Remove the `details.attachments` field and add a *mandatory*
-   top-level `attachments` field to all formats which can have
-   attachments.
+1. Add a *mandatory* `details.attachments` field to all formats which
+   can have attachments.
 
-    **Migration concerns:** this would need to be done in six steps:
-    add *optional* top-level field; update apps to read from both
-    fields but write to the top-level one; republish docs; make field
-    mandatory; remove old field; update apps to not use
-    `details.attachments`.
+    **Migration concerns:** this would need to be done in four steps: add
+    *optional* field; update apps to write to it; republish docs; make
+    field mandatory.
 
 1. Change the `details.documents` list to store govspeak hashes.
 
@@ -199,11 +196,12 @@ schema will be:
 
 There are really two different types of attachments in documents.
 There are attachments which may be referenced in Govspeak but don't
-otherwise appear on the page; in this case the attachment hashes are more like metadata
-than actual page content.  There are also attachments which appear at
-the end of the page text, like in publications.
+otherwise appear on the page; in this case the attachment hashes are
+more like metadata than actual page content.  There are also
+attachments which appear differently to the normal page text, like in
+publications.
 
-The top-level `attachments` list would contain both types of
+The `details.attachments` list would contain both types of
 attachments, so there is one list with everything in.  The
 `details.documents` list would fulfil its current purpose: providing
 the ordered list of attachments for publication-like document types.