feat(profile): wire COS observability into kubernetes and machine scaffolds

.github/.copilot-collections.yaml

@@ -1,7 +1,7 @@
 # https://github.com/canonical/copilot-collections
 
 copilot:
-  version: v0.13.0
+  version: v0.15.0
   collections:
     - starcraft-core
     - starcraft-docs

.github/instructions/cloud-agent.instructions.md

@@ -0,0 +1,73 @@
+---
+applyTo: '**'
+excludeAgent: 'code-review'
+description: 'Guidelines for GitHub Copilot cloud agent when working in Starcraft.'
+---
+
+# GitHub Cloud Agent Instructions for Starcraft
+
+These instructions guide GitHub Copilot cloud agent when it works in Starcraft projects. These don't apply to the initial review provided by GitHub Copilot code review.
+
+## Code changes in pull request comments
+
+These instructions apply to interactions between users and the cloud agent, when they mention it with `@copilot`.
+
+### Draft changes when explicitly requested
+
+When a user mentions `@copilot` in a comment asking to draft or propose a code change, reply in a comment using GitHub's code suggestion syntax. Do not commit directly to the branch.
+
+Examples of requests that should trigger this behavior include:
+
+- "propose a change"
+- "show me what this would look like"
+- "what would this look like?"
+- "can you draft that?"
+- "show me an example"
+- "write that out"
+- "what do you suggest?"
+- "show a fix for this"
+- "give me a suggestion"
+- "how would you write this?"
+
+Reply using GitHub's code suggestion syntax:
+
+````markdown
+```suggestion
+<proposed code>
+```
+````
+
+This allows the user to review and apply the suggestion themselves with a single click.
+
+### Only commit changes when explicitly requested
+
+When a user mentions `@copilot` in a comment asking to finalize a code change, commit the change as requested.
+
+If no prior suggestion exists in the current PR conversation, propose the change first using the suggestion syntax above before committing.
+
+Examples of requests that should trigger this behavior include:
+
+- "commit what is proposed"
+- "push this code"
+- "apply these changes"
+- "go ahead and commit"
+- "push the changes"
+- "commit the suggestion"
+- "apply the fix"
+- "push what you suggested"
+- "land these changes"
+
+
+### Combined implement and commit requests
+
+If a user asks for a change **and** explicitly requests it be committed in the same message, treat it as an explicit commit request. Implement the change and commit it directly without posting a suggestion first.
+
+Examples of requests that should trigger this behavior include:
+
+- "implement X and push it"
+- "fix this and commit"
+- "make this change and push"
+- "do X and land it"
+- "apply X and commit"
+- "patch this and commit"
+- "commit a fix for this"

.github/instructions/starcraft-docs-meta.instructions.md

@@ -23,58 +23,38 @@ The meta description must be one line, because Sphinx options don't support line
 
 ## Write a meta description
 
-**Do** write the meta description *after* the page is written. The meta description is a reflection of what's actually on the page.
+Write the meta description after the page is written. The meta description is a reflection of what's actually on the page, not what the page aspires to be.
 
-**Do** reuse text from the page itself when it's convenient.
+Start with the Diátaxis category or action, such as *How to* or *Reference for*. Next, describe what the user will find on the page. Reuse text from the page itself where it's appropriate.
 
-**Do** share descriptions between documents with the same formats. For example, use the same meta description for every page of release notes, but replace the version number.
+Include a focus term or phrase, the key string that users are likely to search for. It can be a single word like *security*, or a short phrase such as *create an Ubuntu Core image*. Prefer widely recognized terminology. If your product isn't yet well known, then it's safer to use terms familiar to a global technical audience over product-specific ones.
 
-**Do** frame sentences in terms of *actions* and *facts*.
+Make every word count. There is no hard minimum length, but it should be longer and more descriptive than the title, and it should not merely repeat the wording of the title. The maximum length is 160 characters, because search engines truncate the snippet after 160 characters. This includes spaces.
 
-<table>
-<thead>
-<tr class="header">
-<th>Type</th>
-<th>Starts with phrases like...</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td><p>Action</p></td>
-<td><p>Get started with</p>
-<p>Learn about</p>
-<p>Find information about</p></td>
-</tr>
-<tr class="even">
-<td><p>Fact</p></td>
-<td><p>The encabulator is a circuit that</p>
-<p>The Chef init profile sets up a basic project file for</p>
-<p>Starcraft is compatible with</p></td>
-</tr>
-</tbody>
-</table>
+For pages with the same format, share descriptions between them. For example, use the same meta description for every page of release notes, but change the version number.
 
-**Do** put key terms near the start.
+### Avoid these mistakes
 
-**Do** aim for an average of 140 characters. Cut any detail about the topic that isn't essential to helping the user make a decision.
+Avoid calls to action like *find*, *discover*, *explore*, or *read*. These are so overused that they have become noise words. The user's needs and actions in the moment are out of your control; the snippet should be a glimpse of the information on the page. Tutorials are the exception, where *learn* is appropriate.
 
-**Don't** exceed 160 characters. Search engines will cut the snippet short.
+Avoid qualities or claims about the product and its features, like *simple*, *easy*, or *best-in-class*. Marketing rhetoric, sales pitches, and business clichés like the following aren't appropriate for documentation:
 
-**Don't** write to market, motivate, or compel. Marketing prose with rhetoric like the following isn't appropriate for documentation.
+*Don't just write code; deliver a product. Start your journey today and turn your project into a production-ready, evergreen, blazing-fast, full-stack app.*
 
-> Don't just write code; deliver a product. Start your journey today and turn your project into a production-ready snap.
+### Examples
 
-**Don't** include qualities or claims like *simple*, *easy*, or *best-in-class*.
+For _Tutorial_ > _Craft a snap_ in Snapcraft:
 
-**Don't** include key terms that aren't on the page.
+> Learn the essentials of Snapcraft. In this tutorial, we package a small Python app into a snap.
 
-**Don't** use pronouns such as *you*, *your*, *we*, or *our*. These waste space and don't match the tone of a description.
+For _How to_ > _Change from core24 to core26_ in Snapcraft:
 
-## Example
+> How to migrate a snap from core24 to core26.
 
-This is an example of a good meta description for *Set up Starcraft*.
+For the _Reference_ > _GNOME extension_ in Snapcraft:
 
-``` rst
-.. meta::
-    :description: Learn how to install Starcraft on a local system. Starcraft is available as a snap on all GNU/Linux systems that support systemd.
-```
+> Reference documentation for the GNOME extension, which adds the components for desktop apps that require GTK 3, GNOME 42 and higher, and GLib.
+
+For _Explanation_ > _Parts lifecycle_ in Snapcraft:
+
+> Explanation of the build process of a part in Snapcraft, with a breakdown of the individual steps and the effect each has on the snap filesystem.

.github/renovate.json5

@@ -1,3 +1,4 @@
 {
   extends: ["github>canonical/starflow:renovate.json5"],
+  ignorePaths: ["docs/**"],
 }

.github/workflows/check-renovate.yaml

@@ -19,7 +19,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
       - name: Install node
         uses: actions/setup-node@v6
         with:

.github/workflows/copilot-collections-update.yaml

@@ -4,6 +4,10 @@ on:
     - cron: "0 9 * * 1" # Run every Monday at 09:00 UTC
   workflow_dispatch:
 
+permissions:
+  contents: write
+  pull-requests: write
+
 jobs:
   check-update:
     # Pinned to @main to get the latest logic, but the content version is controlled by .github/.copilot-collections.yaml

.github/workflows/policy.yaml

@@ -13,7 +13,11 @@ jobs:
     outputs:
       source-files: ${{ steps.filter.outputs.source-files }}
     steps:
-      - uses: dorny/paths-filter@fbd0ab8f3e69293af611ebaee6363fc25e6d187d # v4.0.1
+      - name: Checkout code
+        uses: actions/checkout@v7
+        with:
+          fetch-depth: 0
+      - uses: dorny/paths-filter@7b450fff21473bca461d4b92ce414b9d0420d706 # v4.0.2
         id: filter
         with:
           # Combine multiple negation checks into a union (¬A ∧ ¬B ∧ ¬C), because individual entries are checked independently (A ∨ B ∨ C).
@@ -36,6 +40,10 @@ jobs:
       # 2. Ignore requirements files in spread tests, as some of these intentionally
       #    contain vulnerable versions.
       # 3. Docs contain requirements.txt files that don't specify versions.
-      requirements-find-args: '! -name requirements-noble.txt ! -path "./tests/spread/*" ! -path "./docs/**"'
-      # osv-extra-args: "--config=source/osv-scanner.toml"
-      uv-export: false
+      osv-extra-args: "--config=osv-scanner.toml"
+      osv-exclude-paths: |
+        docs
+        tests/spread
+      uv-export-no-groups: |
+        docs
+        docs-starter-pack

.github/workflows/qa.yaml

@@ -17,10 +17,10 @@ jobs:
       source-files: ${{ steps.filter.outputs.source-files }}
     steps:
       - name: Checkout code
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
-      - uses: dorny/paths-filter@fbd0ab8f3e69293af611ebaee6363fc25e6d187d # v4.0.1
+      - uses: dorny/paths-filter@7b450fff21473bca461d4b92ce414b9d0420d706 # v4.0.2
         id: filter
         with:
           # Combine multiple negation checks into a union (¬A ∧ ¬B ∧ ¬C), because individual entries are checked independently (A ∨ B ∨ C).

.github/workflows/release-publish.yaml

@@ -14,7 +14,7 @@ jobs:
     runs-on: [self-hosted, jammy]
     steps:
       - name: Checkout
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
       - name: Fetch tag annotations
         run: |
           # Note: we fetch the tags here instead of using actions/checkout's "fetch-tags"

.github/workflows/schema.yaml

@@ -10,7 +10,7 @@ jobs:
 
     steps:
       - name: Checkout
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
 
@@ -34,7 +34,7 @@ jobs:
 
     steps:
       - name: Checkout
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
 

.github/workflows/spread-docs.yaml

@@ -2,7 +2,7 @@ name: Spread tests for docs
 on:
   pull_request:
     paths:
-      - .github/workflow/spread-docs.yaml
+      - .github/workflows/spread-docs.yaml
       - spread.yaml
       - .readthedocs.yaml
       - docs/**/code/**
@@ -21,7 +21,7 @@ jobs:
     runs-on: [self-hosted, linux, amd64, noble, medium]
     steps:
       - name: Checkout code
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
       - name: Build snap
@@ -39,7 +39,7 @@ jobs:
       systems: ${{ steps.select.outputs.systems }}
     steps:
       - name: Checkout charmcraft
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
           submodules: true
@@ -64,7 +64,7 @@ jobs:
           sudo ip6tables -P FORWARD ACCEPT
 
       - name: Checkout charmcraft
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
           submodules: true
@@ -75,7 +75,7 @@ jobs:
           mkdir "${{ github.workspace }}"
 
       - name: Checkout charmcraft
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
           submodules: true
@@ -92,7 +92,7 @@ jobs:
 
       - name: Install spread
         run: |
-          go install github.com/snapcore/spread/cmd/spread@latest
+          go install github.com/canonical/spread/cmd/spread@latest
 
       - name: Run spread
         run: |

.github/workflows/spread-manual.yaml

@@ -43,7 +43,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout code
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
       # speed up build times by using wheels, when available
@@ -84,7 +84,7 @@ jobs:
           rm -rf "${{ github.workspace }}"
           mkdir "${{ github.workspace }}"
       - name: Checkout charmcraft
-        uses: actions/checkout@v6
+        uses: actions/checkout@v7
         with:
           fetch-depth: 0
           submodules: true