chore(docs): more vale cleanup (ly hyphens, optional plurals, exclamations, etc)

Author: tobz

bin/agent-data-plane/src/components/ottl_transform_processor/mod.rs

@@ -49,7 +49,7 @@ impl OttlTransformConfiguration {
 
 #[async_trait]
 impl SynchronousTransformBuilder for OttlTransformConfiguration {
-    /// Builds the OTTL Transform transform from the current configuration.
+    /// Builds the OTTL `Transform` from the current configuration.
     ///
     /// Registers the `set` editor function, parses each trace statement, and returns
     /// the transform. Statements may be editor calls like `set(attributes["key"], "value")`

bin/correctness/panoramic/src/cli.rs

@@ -26,7 +26,7 @@ pub struct RunCommand {
     #[argh(option, short = 'd')]
     pub test_dirs: Vec<PathBuf>,
 
-    /// run only specific test(s) by name (comma-separated)
+    /// run only specific tests by name (comma-separated)
     #[argh(option, short = 't')]
     pub tests: Option<String>,
 

bin/correctness/panoramic/src/config.rs

@@ -254,7 +254,7 @@ pub enum AssertionConfig {
     },
 }
 
-/// Which log stream(s) to check.
+/// Which log streams to check.
 #[derive(Clone, Debug, Default, Deserialize)]
 #[serde(rename_all = "lowercase")]
 pub enum LogStream {

docs/agent-data-plane/releasing.md

@@ -30,7 +30,7 @@ The release process for ADP roughly looks like this:
   the release notes. (above the auto-generated `What's Changed` section)
 - Click `Publish release`.
 - Go to the [GitLab CI pipelines dashboard](https://gitlab.ddbuild.io/DataDog/saluki/-/pipelines) for the repository and
-  find the pipeline that was triggered for the newly-created Git tag. It may take a minute or two for the repository
+  find the pipeline that was triggered for the newly created Git tag. It may take a minute or two for the repository
   sync and pipeline creation to occur.
 - The pipeline should progress through the `test`, `build`, `correctness`, and `release` stages without issue.
 - Once all stages have completed, the `release` stage will have a number of blocked jobs: standalone image publishing,
@@ -40,7 +40,7 @@ The release process for ADP roughly looks like this:
 - Once triggered, they should run to completion.
 - Once complete, you should be able to navigate to a public container image registry that we use, such as [Docker
   Hub](https://hub.docker.com/r/datadog/agent-data-plane/tags), and find the resulting images: if the tag was `0.2.0`,
-  you should be able to see a recently-published image with a tag that looks like `0.2.0` and `0.2.0-fips`.
+  you should be able to see a recently published image with a tag that looks like `0.2.0` and `0.2.0-fips`.
 - Post a release announcement in the `#agent-data-plane` Slack channel
   in the following format:
   ```

docs/development/common-language.md

@@ -20,4 +20,4 @@ processes. You're encouraged to read the RFC, but here's a quick rundown:
 - **MAY**/**OPTIONAL**: this is legitimately optional ("dealer's choice")
 
 Like RFC 2119 mentions, these should be used sparingly and only when necessary to clarify expectations... so if you see
-them, pay attention!
+them, pay attention.

docs/development/contributing.md

@@ -1,6 +1,6 @@
 # Contributing
 
-First of all, thank you for looking to contribute to Saluki! We're excited to have you here.
+First of all, thank you for looking to contribute to Saluki. We're excited to have you here.
 
 This document covers some simple guidelines for both filing issues and contributing code to the project.
 
@@ -16,7 +16,7 @@ you can.
 ## Pull requests
 
 You've gotten to the point of working on a fix or a new feature, and now you want to contribute that upstream. This is
-awesome!
+awesome.
 
 We strive for a high level of quality in terms of pull requests, and this guide is meant to help you understand what we
 expect from a PR so that you're not surprised during the review process.
@@ -84,9 +84,9 @@ ready for actual reviews.
 
 #### Before the first PR review
 
-Before the first PR review, meaningful commits are best: logically-encapsulated commits help the reviews go quicker and
+Before the first PR review, meaningful commits are best: logically encapsulated commits help the reviews go quicker and
 make the job for the reviewer easier. Conflicts with `main` can be resolved with a `git rebase origin/main` and a force
-push if it makes future review(s) easier.
+push if it makes future reviews easier.
 
 #### After the first review
 

docs/development/style-guide.md

@@ -311,7 +311,7 @@ When documenting performance, memory, or design trade-offs, be explicit about wh
 - **Name both sides**: "This represents a trade-off between throughput and memory usage"
 - **Quantify when possible**: "Approximately 150–200 bytes per context based on typical metric names and tags"
 - **Acknowledge variability**: "The optimal value is workload-dependent"
-- **Provide guidance**: "A good starting point is 1MB per 5000 unique contexts"
+- **Provide guidance**: "A good starting point is 1 MB per 5000 unique contexts"
 
 Example:
 

docs/reference/adrs/index.md

@@ -20,4 +20,4 @@ Adding a new ADR is a straightforward process:
     <a :href="record.url" v-html="record.pretty_title" />
   </li>
 </ul>
-<p v-else><b>No ADRs defined yet!</b></p>
+<p v-else><b>No ADRs defined yet.</b></p>

docs/reference/proposals/index.md

@@ -20,4 +20,4 @@ Adding a new proposal is a straightforward process:
     <a :href="record.url" v-html="record.pretty_title" />
   </li>
 </ul>
-<p v-else><b>No proposals defined yet!</b></p>
+<p v-else><b>No proposals defined yet.</b></p>

lib/datadog-agent-commons/src/ipc/config.rs

@@ -143,7 +143,7 @@ pub struct RemoteAgentClientConfiguration {
 
     /// Maximum message size for gRPC messages.
     ///
-    /// Defaults to `128 * 1024 * 1024` (128MB).
+    /// Defaults to `128 * 1024 * 1024` (128 MB).
     #[serde(
         rename = "agent_ipc_grpc_max_message_size",
         default = "default_grpc_max_message_size"