Merge pull request #58 from beamable/merge-core/v7.0-into-unity/v5.0

Merge core/v7.0 into unity/v5.0 (Conflicts)

Author: allister-beamable

.github/workflows/auto-publish-branch.yml

@@ -35,10 +35,10 @@ jobs:
         id: version
         run: |
           BRANCH="${{ github.ref_name }}"
-
+              
               # Extract the product prefix (before the first /)
               PRODUCT_PREFIX="${BRANCH%%/*}"
-
+              
               # Map branch prefix to product name
               case "$PRODUCT_PREFIX" in
                 unity)
@@ -111,7 +111,7 @@ jobs:
         if: steps.check.outputs.published == 'false'
         run: echo "Skipping — ${{ steps.version.outputs.mike_alias }} has not been manually published yet."
 
-
+ 
 
       # Confirm mkdocs.yml is present before attempting a deploy
       - name: Verify mkdocs.yml exists
@@ -135,7 +135,7 @@ jobs:
         run: mike deploy "${{ steps.version.outputs.mike_alias }}" --branch gh-pages --push
 
       - name: Notify Slack
-        # if: steps.check.outputs.published == 'true'
+        # if: steps.check.outputs.published == 'true' 
         if: false
         env:
           SLACK_WEBHOOK_URL: ${{ secrets.SLACK_DOCS_CHANNEL_URL }}

.github/workflows/auto-sync-core.yml

@@ -62,7 +62,7 @@ jobs:
         with:
           token: ${{ secrets.DOCS_PAT }}
           title: "Merge ${{ github.ref_name }} into ${{ matrix.branch }} (Conflicts)"
-          body: The ${{ github.ref_name }} branch was unable to merge into ${{ matrix.branch }}. Please review the changes.
+          body: The ${{ github.ref_name }} branch was unable to merge into ${{ matrix.branch }}. Please review the changes. 
           branch: merge-${{ github.ref_name }}-into-${{ matrix.branch }}
           delete-branch: true
           base: ${{ matrix.branch }}

docs/cli/guides/configuration.md

@@ -42,7 +42,7 @@ mainFolder % dotnet beam config
  }
 ```
 
-However, if the `beam config` command was invoked from the `someOtherFolder` path, you should expect to see an error, because there is no `.beamable` folder within the parent lineage.
+However, if the `beam config` command was invoked from the `someOtherFolder` path, you should expect to see an error, because there is no `.beamable` folder within the parent lineage. 
 
 ```sh
 someOtherFolder % dotnet beam config
@@ -79,9 +79,7 @@ The Beamable CLI executes as a local dotnet tool installation. That means that t
 
 !!! info "The folder can exist in a higher folder."
 
-    Normally the `.config/` folder exists as a sibling of the `.beamable/` folder. However, the `.config/` folder _may_ exist in a parent folder. The closest `.config/` folder will be used. See the [dotnet tool documentation](https://learn.microsoft.com/en-us/dotnet/core/tools/local-tools-how-to-use) for more information.
-
-
+    Normally the `.config/` folder exists as a sibling of the `.beamable/` folder. However, the `.config/` folder _may_ exist in a parent folder. The closest `.config/` folder will be used. See the [dotnet tool documentation](https://learn.microsoft.com/en-us/dotnet/core/tools/local-tools-how-to-use) for more information. 
 
 
 ## Workspace Overview

docs/cli/guides/getting-started.md

@@ -8,7 +8,7 @@ Verify it is installed by running `dotnet --version` from a terminal.
 
 !!! info "We support Dotnet 8 as well."
 
-    If you are using the Beamable CLI before version 7.0, then you should be using [Dotnet 8](https://dotnet.microsoft.com/en-us/download/dotnet/8.0). Starting with CLI 7.0 and beyond, we support both versions of dotnet, but we recommend you use `net10.0`.
+    If you are using the Beamable CLI before version 7.0, then you should be using [Dotnet 8](https://dotnet.microsoft.com/en-us/download/dotnet/8.0). Starting with CLI 7.0 and beyond, we support both versions of dotnet, but we recommend you use `net10.0`. 
 
 ## Installing
 To install the Beamable CLI, run the following command in a shell.

docs/cli/guides/ms-command-line.md

@@ -96,7 +96,7 @@ dotnet beam config | jq '.data.cid'
 "123"
 ```
 
-Sometimes it is important to get the unescaped JSON, so the `fromjson` component of JQ can be used. For example, if we wanted the `cid` value, but without quotes,
+Sometimes you need the unescaped JSON; the `fromjson` component of JQ can be used. For example, if we wanted the `cid` value, but without quotes, 
 
 ```sh
 dotnet beam config | jq '.data.cid | fromjson'

docs/cli/guides/ms-logging.md

@@ -56,13 +56,13 @@ Each log has a _level_, or an _importance_ rating. Logs are one of the following
 - _Debug_
 - _Verbose_
 
-When you run a Microservice locally, you will see log messages at the _Debug_ level and above. However, in a deployed Microservice, you will only see **Information** and above. This is called the _Log Level_. Best practice is to avoid logging _Debug_ and _Verbose_ logs in production, as they negatively impact performance.
+When you run a Microservice locally, you will see log messages at the _Debug_ level and above. However, in a deployed Microservice, you will only see **Information** and above. This is called the _Log Level_. Best practice is to avoid logging _Debug_ and _Verbose_ logs in production, as they negatively impact performance. 
 
 The `Log` type has methods for each type of log level.
 
 !!! info
 
-	The default log level is `DEBUG` when you are running a service locally in development. However, deployed services use the `INFO` level by default.
+	The default log level is `DEBUG` when you are running a service locally in development. However, deployed services use the `INFO` level by default. 
 
 #### Request Dynamic Log Levels
 
@@ -93,7 +93,7 @@ However, the attribute, `a`, is available for querying in Portal. Use a custom s
 
 #### Scoped Custom Attributes
 
-It is possible to automatically add attributes to an entire sequence of logs. For example, imagine you wanted to tag a series of log lines as being part of an algorithm.
+You can automatically add attributes to an entire sequence of logs. For example, imagine you wanted to tag a series of log lines as being part of an algorithm.
 
 ```csharp
 [ClientCallable]
@@ -214,7 +214,7 @@ There are several standard log attributes that will be included automatically. S
 
 ### Third Party Log Hosting
 
-Starting with version 6.0, it is possible to send Microservice logs to a third parties. In this example, we will use  BetterStack.
+Starting with version 6.0, you can send Microservice logs to third-party log hosting services. In this example, we will use BetterStack.
 
 This section will assume you have set up a BetterStack account, and created a _Source_ such that you have a _source token_ and an _ingesting host_.
 

docs/cli/guides/ms-routing.md

@@ -73,7 +73,7 @@ var scope = cid + '.' + pid;
 ```
 #### Authorization
 
-Finally, while not required, it is important to send an HTTP authorization header in the form of a Bearer token. The bearer token should be a valid access token for a Beamable Player. These tokens can be fetched from Portal, or you can use the following command to view the token information from a local beamable CLI project.
+Finally, while not required, we recommend sending an HTTP authorization header in the form of a Bearer token. The bearer token should be a valid access token for a Beamable Player. These tokens can be fetched from the Portal, or you can use the following command to view the token information from a local beamable CLI project. 
 
 ```sh
 cat .beamable/temp/auth.beam.json
@@ -132,7 +132,7 @@ The automatic client code generation can be disabled when a project builds by mo
 
 ### Open API
 
-It is possible to use the project oapi command to generate an Open API document and then use open source tools to transpile the document into a client in some other programming language.
+You can use the project oapi command to generate an Open API document and then use open source tools to transpile the document into a client in some other programming language.
 
 ```sh
 dotnet beam project oapi --output example.json --ids MyService

docs/cli/guides/ms-workflow.md

@@ -91,7 +91,7 @@ When a service is stopped this way, you should expect to see a log in the Micros
 
 ## Observing Logs
 
-When a service is run, the process that starts the service should receive the log outputs. For example, if the service is run through the IDE, then the IDE should receive the logs from the service. However, it is possible to attach to the logs of a running service from a separate process.
+When a service is run, the process that starts the service should receive the log outputs. For example, if the service is run through the IDE, then the IDE should receive the logs from the service. However, you can attach to the logs of a running service from a separate process. 
 
 For example, imagine that a service is run through `dotnet` directly,
 

docs/cli/guides/upgrading.md

@@ -134,7 +134,7 @@ generated when the Microservices were built. However, in CLI 5+, the engine inte
 are responsible for generating the client code, and the default behaviour is that a standalone
 Microservice project will _no longer generate client code automatically_.
 
-It is possible to generate a unity client by hand using the following command,
+You can generate a Unity client by hand using the following command,
 ```sh
 dotnet beam project generate-client-oapi --output-dir ./Path/To/Your/Unity/Folder/To/Put/Clients/In
 ```
@@ -161,8 +161,8 @@ The upgrade from 3.0.x to 4.0.0 is relatively simple compared to other major
 releases.
 
 #### Removed `net6.0` and `net7.0` support
-Unfortunately, `net6.0` and `net7.0` have reached their [End-Of-Life phases](https://devblogs.microsoft.com/dotnet/dotnet-6-end-of-support/).
-The CLI 4.0 release officially drops Beamable support for these EOL .NET versions; when you update your projects, you must update your `.csproj` files to use `net8.0`.
+Unfortunately, `net6.0` and `net7.0` have reached their [End-Of-Life phases](https://devblogs.microsoft.com/dotnet/dotnet-6-end-of-support/). 
+The CLI 4.0 release officially drops Beamable support for these EOL .NET versions; when you update your projects, you must update your `.csproj` files to use `net8.0`. 
 
 In all your `.csproj` files, find the line with the `<TargetFramework>`
 declaration,