feat(docs): Add conditions field to specifications and documentation

- Updated the documentation to include the new Conditions document type, detailing its purpose and validation requirements.
- Enhanced the types.md file to list the Conditions document type, ensuring clarity in the available document types.

Author: nathanbogale

docs/src/architecture/08_concepts/signed_doc/types.md

@@ -14,6 +14,7 @@ All Defined Document Types
 | [Category Parameters](docs/category_parameters.md) | 48c20109-362a-4d32-9bba-e0a9cf8b45be | `#6.37(h'48c20109362a4d329bbae0a9cf8b45be')` |
 | [Category Parameters Form Template](docs/category_parameters_form_template.md) | 65b1e8b0-51f1-46a5-9970-72cdf26884be | `#6.37(h'65b1e8b051f146a5997072cdf26884be')` |
 | [Comment Moderation Action](docs/comment_moderation_action.md) | 84a4b502-3b7e-47fd-84e4-6fee08794bd7 | `#6.37(h'84a4b5023b7e47fd84e46fee08794bd7')` |
+| [Conditions](docs/conditions.md) | b664afc2-6472-4028-b90f-875bf6eefab8 | `#6.37(h'b664afc264724028b90f875bf6eefab8')` |
 | [Contest Ballot](docs/contest_ballot.md) | de1284b8-8533-4f7a-81cc-ff4bde5ef8d0 | `#6.37(h'de1284b885334f7a81ccff4bde5ef8d0')` |
 | [Contest Ballot Checkpoint](docs/contest_ballot_checkpoint.md) | 58608925-bda3-47df-b39a-ae0d0a1dd6ed | `#6.37(h'58608925bda347dfb39aae0d0a1dd6ed')` |
 | [Contest Delegation](docs/contest_delegation.md) | 764f17fb-cc50-4979-b14a-b213dbac5994 | `#6.37(h'764f17fbcc504979b14ab213dbac5994')` |

specs/generators/uv.lock

@@ -1283,6 +1283,16 @@
           "type": "Campaign Parameters",
           "validation": "In addition to the validation performed for `Document Reference` type fields: \n\n* Any linked referenced document that includes a `parameters` metadata must match the \n`parameters` of the referencing document,\nor a parent of those `parameters`.\n\nFor example, a linked reference to `Contest Parameters` is transitively a reference to\nthe Parameters document it references, and each parameters document they reference \nuntil the `Brand` parameters document is reached.\n\nThe use case here is for Templates.\nThe profile template, or proposal templates could be defined at any of these\nlevels, and as long as they all refer to the same chain of parameters in the\nhierarchy they are all valid."
         },
+        "conditions": {
+          "description": "An array of references to Conditions documents that define terms and conditions required at this level.\n\nLists the required condition documents for this level of the system hierarchy.\nSpecifies which terms users must accept when submitting documents at this level.\nThe field is optional - if not present, no conditions are required at that level.",
+          "format": "Document Reference",
+          "required": "optional",
+          "multiple": true,
+          "type": [
+            "Conditions"
+          ],
+          "validation": "If present, must be an array of valid Conditions document references.\nAll referenced documents must exist and be of type \"Conditions\".\nThe array must be sorted according to CBOR Deterministic Encoding rules.\nAll array elements must be unique."
+        },
         "ref": {
           "description": "Reference to a Linked Document or Documents.\nThis is the primary hierarchical reference to a related document.\n\nIf a reference is defined as required, there must be at least 1 reference specified.\nSome documents allow multiple references, and they are documented as required.\n\nThe document reference serves two purposes:\n\n1. It ensures that the document referenced by an ID/Version is not substituted.\n\tIn other words, that the document intended to be referenced, is actually referenced.\n2. It Allows the document to be unambiguously located in decentralized storage systems.\n\nThere can be any number of Document Locations in any reference.\nThe currently defined locations are:\n\n* `cid` : A CBOR Encoded IPLD Content Identifier ( AKA an IPFS CID ).\n* Others may be added when further storage mechanisms are defined.\n\nThe document location does not guarantee that the document is actually stored.\nIt only defines that if it were stored, this is the identifier\nthat is required to retrieve it.\nTherefore it is required that Document References\nare unique and reproducible, given a documents contents.",
           "format": "Document Reference",
@@ -2245,6 +2255,16 @@
           ],
           "validation": "In addition to the validation performed for `Document Reference` type fields: \n\n* Any linked referenced document that includes a `parameters` metadata must match the \n`parameters` of the referencing document,\nor a parent of those `parameters`.\n\nFor example, a linked reference to `Contest Parameters` is transitively a reference to\nthe Parameters document it references, and each parameters document they reference \nuntil the `Brand` parameters document is reached.\n\nThe use case here is for Templates.\nThe profile template, or proposal templates could be defined at any of these\nlevels, and as long as they all refer to the same chain of parameters in the\nhierarchy they are all valid."
         },
+        "conditions": {
+          "description": "An array of references to Conditions documents that define terms and conditions required at this level.\n\nLists the required condition documents for this level of the system hierarchy.\nSpecifies which terms users must accept when submitting documents at this level.\nThe field is optional - if not present, no conditions are required at that level.",
+          "format": "Document Reference",
+          "required": "optional",
+          "multiple": true,
+          "type": [
+            "Conditions"
+          ],
+          "validation": "If present, must be an array of valid Conditions document references.\nAll referenced documents must exist and be of type \"Conditions\".\nThe array must be sorted according to CBOR Deterministic Encoding rules.\nAll array elements must be unique."
+        },
         "ref": {
           "description": "Reference to a Linked Document or Documents.\nThis is the primary hierarchical reference to a related document.\n\nIf a reference is defined as required, there must be at least 1 reference specified.\nSome documents allow multiple references, and they are documented as required.\n\nThe document reference serves two purposes:\n\n1. It ensures that the document referenced by an ID/Version is not substituted.\n\tIn other words, that the document intended to be referenced, is actually referenced.\n2. It Allows the document to be unambiguously located in decentralized storage systems.\n\nThere can be any number of Document Locations in any reference.\nThe currently defined locations are:\n\n* `cid` : A CBOR Encoded IPLD Content Identifier ( AKA an IPFS CID ).\n* Others may be added when further storage mechanisms are defined.\n\nThe document location does not guarantee that the document is actually stored.\nIt only defines that if it were stored, this is the identifier\nthat is required to retrieve it.\nTherefore it is required that Document References\nare unique and reproducible, given a documents contents.",
           "format": "Document Reference",