reverting assembly metadata rules

Author: skopacz1

contributing_to_docs/doc_guidelines.adoc

@@ -39,12 +39,10 @@ Every assembly file must contain the following metadata at the top, with no blan
 :_mod-docs-content-type: ASSEMBLY                               <1>
 [id="<assembly-anchor-id>"]                                     <2>
 = Assembly title                                                <3>
-                                                                <4>
-include::_attributes/common-attributes.adoc[]                   <5>
+include::_attributes/common-attributes.adoc[]                   <4>
+:context: <assembly-context>                                    <5>
                                                                 <6>
-:context: <assembly-context>                                    <7>
-                                                                <8>
-toc::[]                                                         <9>
+toc::[]                                                         <7>
 ----
 <1> The content type for the file. For assemblies, always use `:_mod-docs-content-type: ASSEMBLY`. Place this attribute before the anchor ID or, if present, the conditional that contains the anchor ID.
 <2> A unique (within OpenShift docs) anchor ID for this assembly. Use lowercase and hyphens, for example: `cli-developer-commands`.
@@ -58,8 +56,7 @@ toc::[]                                                         <9>
 * The assembly title, which is the first line of the document, is the only level 1 ( `=` ) title.
 Section headers within the assembly must be H2 ("Level 1" in AsciiDoc terminology), formatted as `==`. When you include modules, you must add leveloffsets in the include statements. You can manually add more H2 (`==`) section headers in the assembly.
 ====
-<4> You must include a blank line after H1 ("Level 0" in AsciiDoc terminology) headings.
-<5> Includes attributes common to OpenShift docs.
+<4> Includes attributes common to OpenShift docs.
 +
 [NOTE]
 ====
@@ -70,21 +67,18 @@ Section headers within the assembly must be H2 ("Level 1" in AsciiDoc terminolog
 ----
 :_mod-docs-content-type: ASSEMBLY
 include::_attributes/common-attributes.adoc[]
-
 [id="installing-ibm-cloud-private"]
 = Installing a private cluster on {ibm-cloud-title}
-
 :context: installing-ibm-cloud-private
 
 toc::[]
 ----
 ====
-<6> You must include a blank line after each `include::` statement.
-<7> Context used for identifying headers in modules that is the same as the anchor ID. Use lowercase and hyphens, for example `cli-developer-commands`.
-<8> A blank line. You *must* have a blank line here before the `toc::[]`.
+<5> Context used for identifying headers in modules that is the same as the anchor ID. Use lowercase and hyphens, for example `cli-developer-commands`.
+<6> A blank line. You *must* have a blank line here before the `toc::[]`.
 +
 After the heading block and a single whitespace line, you can include any content for this assembly.
-<9> The table of contents for the current assembly.
+<7> The table of contents for the current assembly.
 
 [id="module-file-metadata"]
 == Module file metadata
@@ -950,12 +944,12 @@ IMPORTANT: You cannot link to a repository that is hosted on www.github.com. An
 TIP: If you want to build a link from a URL _without_ changing the text from the actual URL, just print the URL without adding a `[friendly text]` block at the end; it will automatically be rendered as a link.
 
 ==== Guidance for including outside sources
-In general, avoid linking to sources outside of an official Red Hat domain whenever possible. 
+In general, avoid linking to sources outside of an official Red Hat domain whenever possible.
 
-Some acceptable exceptions to this rule include: 
+Some acceptable exceptions to this rule include:
 
-1. Links to third-party product documentation when it would be otherwise unreasonable or impossible to write procedures using another product. 
-2. Upstream resources for a feature or component based on an upstream project when re-writing the resource for downstream use would be too arduous to write for too little value, or too difficult to maintain. 
+1. Links to third-party product documentation when it would be otherwise unreasonable or impossible to write procedures using another product.
+2. Upstream resources for a feature or component based on an upstream project when re-writing the resource for downstream use would be too arduous to write for too little value, or too difficult to maintain.
 3. Upstream API references
 
 If you feel you need to link to an outside source, discuss it with a content strategist, and then make sure you have approval from your PM and engineering stakeholders and the Product Operations team member who works in your area.