Added TODOs/Comments to TA-Behaviours and TA-Constraints Context files

Author: LucaFgr

TSF/trustable/assertions/TA-BEHAVIOURS_CONTEXT.md

@@ -51,9 +51,9 @@ sufficient.
   - **Answer**: The Expectations are provided via JLEX-01 and JLEX-02.
 - Argument of sufficiency for break-down of expected behaviour for all 
   Expectations
-  - **Answer**: # TODO: Not sure how to argument here. There is now way to prove that.
+  - **Answer**: TODO: Create a new statement JLS-56 about sufficiency of break-down and reference JLEX-01 and JLEX-02.
 - Validation and verification of expected behaviour
-  - **Answer**: The validation and verification of expected behaviour is done via the evidence provided for all the statements below JLEX-01 and JLEX-02 in the trustable graph. 
+  - **Answer**: The validation and verification of expected behaviour is done via the evidence provided for all the statements below JLEX-01 and JLEX-02 in the trustable graph. TODO reference JLS-03.
 
 
 **Confidence scoring**
@@ -71,20 +71,20 @@ and that the resulting system and tests are validated by appropriate strategies.
 - Could some participants have incentives to manipulate information?
   - **Answer**: We cannot imagine any incentive to manipulate information.
 - Could there be whole categories of Expectations still undiscovered?
-  - **Answer**: It is currently unlikely that there are whole categories of Expectations still undiscovered.
+  - **Answer**: It is currently unlikely that there are whole categories of Expectations still undiscovered. TODO mention SME reviews increase confidence
 - Can we identify Expectations that have been understood but not specified?
   - **Answer**: There are currently no Expectations that have been understood but not specified.
 - Can we identify some new Expectations, right now?
   - **Answer**: Currently we cannot identify any new Expectations.
 - How confident can we be that this list covers all critical requirements?
   - **Answer**: We are very confident that this list covers all critical requirements.
-- How comprehensive is the list of tests? 
+- How comprehensive is the list of tests?
   - **Answer**: Currently, the branch coverage is 93.865% and the line coverage is 99.186%, cf. JLS-27. Therefore, we deem the list of tests to be very comprehensive.
 - Is every Expectation covered by at least one implemented test?
   - **Answer**: Yes, both of the Expectations are covered by at least one implemented test.
 - Are there any Expectations where we believe more coverage would help?
   - **Answer**: No, the coverage is already on a high level and no further gains are expected by further increasing the coverage.
 - How do dependencies affect Expectations, and are their properties verifiable?
-  - **Answer**: The nlohmann/json library does not have external dependencies, so that there are none that could possibly affect the Expectations.
+  - **Answer**: The nlohmann/json library does not have external dependencies, so that there are none that could possibly affect the Expectations. TODO say that this doesnt apply to testing
 - Are input analysis findings from components, tools, and data considered in relation to Expectations?
-  - **Answer**: Not that we know of.
+  - **Answer**: TODO ask in libera chat or look through TA-Behaviours

TSF/trustable/assertions/TA-CONSTRAINTS_CONTEXT.md

@@ -53,13 +53,13 @@ reporting bugs, issues, and requests.
 - Installation manuals with worked examples
   - **Answer**: See JLS-70.
 - Configuration manuals with worked examples
-  - **Answer**: See JLS-71.
+  - **Answer**: See JLS-71. TODO adapt JLS-71 with sources for configuration.
 - Specification documentation with a clearly defined scope
-  - **Answer**: See JLS-72.
+  - **Answer**: See JLS-72. TODO check what a specification documentation actually is and whether this is covered by JLS-72 (the design goals reference)
 - User guides detailing limitations in interfaces designed for expandability or modularity
-  - **Answer**: #TODO
+  - **Answer**: #TODO answers. Expandability is not restricted, there is also no user guide about that.
 - Documented strategies used by external users to address constraints and work with existing Statements
-  - **Answer**: see AOU-10 and AOU-11.
+  - **Answer**: see AOU-10 and AOU-11. TODO search for possible additoinal AOUs to mention here.
 
 **Confidence scoring**
 
@@ -70,21 +70,21 @@ contradictions and obvious pitfalls within the defined Statements.
 
 - Are the constraints grounded in realistic expectations, backed by real-world
   examples?
-  - **Answer**: The constraints originate from S-CORE, the nlohmann/json library and the RFC-8259 standard. As these are all widely used, the constraints are grounded in realistic expectations.
+  - **Answer**: The constraints originate from S-CORE, the nlohmann/json library and the RFC-8259 standard. As these are all widely used, the constraints are grounded in realistic expectations. TODO think about what constraints are meant here
 - Do they effectively guide downstream consumers in expanding upon existing
   Statements?
   - **Answer**: The existing set of AOUs provides effective guidance for consumers.
 - Do they provide clear guidance for upstreams on reusing components with
   well-defined claims?
-  - **Answer**: # TODO
+  - **Answer**: # TODO not clear what an upstream is in our case
 - Are any Statements explicitly designated as not reusable or adaptable?
   - **Answer**: No, all statements could theoretically be adapted or reused.
 - Are there worked examples from downstream or upstream users demonstrating
   these constraints in practice?
   - **Answer**: As the nlohmann/json library is widely used, its constraints (like the installation manual) are regurlarly read and applied and therefore demonstrated.
 - Have there been any documented misunderstandings from users, and are these
   visibly resolved?
-  - **Answer**: Yes, it is documented that the [brace initialisation](https://json.nlohmann.me/home/faq/) (cf. AOU-06) regularly leads to confusion, cf. [here](https://github.com/nlohmann/json/issues/4898).
+  - **Answer**: Yes, it is documented that the [brace initialisation](https://json.nlohmann.me/home/faq/) (cf. AOU-06) regularly leads to confusion, cf. [here](https://github.com/nlohmann/json/issues/4898). TODO look for further misunderstandings
 - Do external users actively keep up with updates, and are they properly
   notified of any changes?
   - **Answer**: External users of the library are not necessarily automatically notified of an update, and are neither assumed nor required to keep up to date. If the external user forks the github repository, however, then github shows automatically whenever the upstream changes.