fix: KP's feedback

requirements/specifications/general/context-parameters.md

@@ -173,14 +173,14 @@ So the following RPC event:
         },
         {
             "name": "b",
-            "required": false,
+            "required": true,
             "schema": {
                 "type": "string"
             }
         },
         {
             "name": "c",
-            "required": false,
+            "required": true,
             "schema": {
                 "type": "number"
             }
@@ -230,7 +230,7 @@ Would have its result transformed to:
                     }
                 },
                 "required": [
-                    "a"
+                    "a", "b", "c"
                 ]
             }
         }

requirements/specifications/openrpc-extensions/app-passthrough-apis.md

@@ -11,7 +11,7 @@ See [Firebolt Requirements Governance](../../governance.md) for more info.
 | Yuri Pasquali   | Sky            |
 
 ## 1. Overview
-This document describes how one Firebolt App can provide a capability that may be used by another Firebolt App, with the platform as a permission broker that passes the requests and respones to each app with out feature-specific logic.
+This document describes how one Firebolt App can provide a capability that may be used by another Firebolt App, with the platform as a permission broker that passes the requests and responses to each app without feature-specific logic.
 
 This document covers the App Pass-through Firebolt OpenRPC extension as well as how Firebolt implementations should detect and execute app provided pass-through APIs.
 
@@ -175,8 +175,6 @@ This section only applies to platform methods that have an `event` tag.
 
 App provided event registration **MUST** not return an availability error due to a lack of providers, since one may be launched at a future point.
 
-**TODO**: do we want to search the catalog and return unavailable if none are possible? Seems overkill.
-
 To ensure that event provider methods all behave the same the provider method **MUST** have a `result` schema with `"type"` set to `"null"`, since it will not expect any data in the response from the platform after pushing the notification.
 
 The platform method result schema **MUST** either:
@@ -185,8 +183,6 @@ The platform method result schema **MUST** either:
 >
 > Have a property that matches the *last* parameter schema on the provider method so that the result can be passed through.
 
-**TODO**: Find event context params spec and move into this branch
-
 Example platform method with context:
 ```json
 {
@@ -235,9 +231,6 @@ Matching provider method:
         {
             "name": "capabilities",
             "x-provides": "xrn:firebolt:capabilities:example:foo"
-        },
-        {
-            "name": "event"
         }
     ],
     "params": [
@@ -272,7 +265,7 @@ Otherwise if the platform method result schema has a property that matches the *
 Finally the platform **MUST** dispatch the notification to the app that registered for the event via the original platform method, using all but the last parameter as context.
 
 ## 5. Provider Candidates
-The Firebolt Device Manfist **MUST** have a list of `ProviderPolicy` configurations that map capabilities to policies for determining candidate providers:
+The Firebolt Device Manifist **MUST** have a list of `ProviderPolicy` configurations that map capabilities to policies for determining candidate providers:
 
 ```json
 {

requirements/specifications/openrpc-extensions/lifecycle-api-gating.md

@@ -14,7 +14,7 @@ This document describes the the `x-lifecycle` Firebolt OpenRPC extension.
 
 Some APIs require that they are only called when an app is in a certain Lifecycle state.
 
-To facilitate these APIs, Firebolt denotes an OpenRPC extension to limit the states than ap app is allowed to be in when a method request is made.
+To facilitate these APIs, Firebolt denotes an OpenRPC extension to limit the states that an app is allowed to be in when a method request is made.
 
 This document is written using the [IETF Best Common Practice 14](https://www.rfc-editor.org/rfc/rfc2119.txt) and should include the following summary in the Overview section:
 

requirements/specifications/openrpc-extensions/push-pull-methods.md

@@ -14,7 +14,7 @@ This document describes the Push / Pull Firebolt OpenRPC extension.
 
 Some APIs require both a push and a pull version so that data can be provided on request, or out of band.
 
-To facilitate these APIs, Firebolt denotes an OpenRPC tag with OpenRPC extensions to auto-genrate the push notifcation, pull provider, and pull request APIs from the main push API.
+To facilitate these APIs, Firebolt denotes an OpenRPC tag with OpenRPC extensions to auto-generate the push notifcation, pull provider, and pull request APIs from the main push API.
 
 This document is written using the [IETF Best Common Practice 14](https://www.rfc-editor.org/rfc/rfc2119.txt) and should include the following summary in the Overview section:
 

src/sdks/discovery/test/suite/content.test.ts

@@ -20,8 +20,6 @@ import { test, expect } from "@jest/globals";
 import { Content } from "../../build/javascript/src/firebolt-discovery";
 
 test("Content.requestUserInterest()", () => {
-  const expTime: number = new Date().getTime() + 100;
-  Content.requestDetails
   return Content.requestUserInterest(Content.InterestType.INTEREST, Content.InterestReason.PLAYLIST).then((entity:Content.EntityDetails) => {
     expect(entity).toBeDefined()
     expect(entity.info.title).toBe("Cool Runnings")