Merge branch 'canonical:main' into main

Author: cbartz

.copilot-collections.yaml

@@ -0,0 +1,10 @@
+# Copyright 2026 Canonical Ltd.
+# See LICENSE file for licensing details.
+
+copilot:
+  # The version of the toolkit to use (matches a Release Tag in this repo)
+  version: "v0.5.0"
+  # The collections you want to install
+  collections:
+    - charm-python
+    - pfe-charms

.github/.jira_sync_config.yaml

@@ -0,0 +1,13 @@
+settings:
+  add_gh_comment: true
+  components:
+  - GitHub runner
+  epic_key: ISD-3981
+  jira_project_key: ISD
+  label_mapping:
+    bug: Bug
+    enhancement: Story
+  status_mapping:
+    closed: done
+    not_planned: rejected
+    opened: Untriaged

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,6 +1,6 @@
 name: Bug Report
 description: File a bug report
-labels: ["Type: Bug", "Status: Triage"]
+labels: ["bug"]
 body:
   - type: markdown
     attributes:
@@ -16,6 +16,25 @@ body:
         If applicable, add screenshots to help explain the problem you are facing.
     validations:
       required: true
+  - type: dropdown
+    id: impact
+    attributes:
+      label: Impact
+      description: How severe is the business impact of this bug?
+      options:
+        - Low (minor issue or cosmetic problem)
+        - Medium (functionality degraded, workaround exists)
+        - High (major functionality broken, no workaround)
+        - Critical (system down, data loss, affecting deployment in production)
+    validations:
+      required: true
+  - type: textarea
+    id: impact-rationale
+    attributes:
+      label: Impact Rationale
+      description: >
+        If impact is high or critical, please provide the rationale behind your assessment, impacted
+        project reference and any relevant project deadline dates which will be affected by this bug.
   - type: textarea
     id: reproduction
     attributes:
@@ -46,12 +65,11 @@ body:
       description: >
         Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
         Fetch the logs using `juju debug-log --replay` and `kubectl logs ...`. Additional details available in the juju docs 
-        at https://juju.is/docs/olm/juju-logs
+        at https://documentation.ubuntu.com/juju/3.6/howto/manage-logs/#manage-logs
       render: shell
     validations:
       required: true
   - type: textarea
     id: additional-context
     attributes:
       label: Additional context
-

.github/ISSUE_TEMPLATE/enhancement_proposal.yml

@@ -1,6 +1,6 @@
 name: Enhancement Proposal
 description: File an enhancement proposal
-labels: ["Type: Enhancement", "Status: Triage"]
+labels: ["enhancement"]
 body:
   - type: markdown
     attributes:
@@ -15,3 +15,22 @@ body:
         Describe the enhancement you would like to see in as much detail as needed.      
     validations:
       required: true
+  - type: dropdown
+    id: impact
+    attributes:
+      label: Impact
+      description: What is the impact of this feature?
+      options:
+        - Low (The feature is nice to have)
+        - Medium (The feature may be helpful in the future)
+        - High (The feature has short-term technical value)
+        - Critical (The feature has big short-term business value)
+    validations:
+      required: true
+  - type: textarea
+    id: impact-rationale
+    attributes:
+      label: Impact Rationale
+      description: >
+        If impact is high or critical, please provide the rationale behind your assessment with as
+        much context as possible.

.github/instructions/charms-lib-updates.instructions.md

@@ -0,0 +1,132 @@
+---
+description: 'Guidelines for reviewing charm library updates in lib/charms/ directory'
+applyTo: 'lib/charms/**/*.py'
+---
+
+# Charm Library Review Instructions
+
+## Purpose
+
+Files in `lib/charms/` are usually **vendored external dependencies** that are auto-updated via `.github/workflows/auto_update_libs.yaml`. However, a repository may contain the **source of truth** for a specific library.
+
+## Critical Understanding
+
+**First, determine if the library is vendored or owned.**
+
+1. **Check the Charm Name**: Look for `name` in `metadata.yaml` or `charmcraft.yaml` in the repository root.
+2. **Check the Library Path**: `lib/charms/[library_owner]/[version]/[lib_name].py`
+3. **Compare**:
+   - If `[library_owner]` matches the repository's charm name (converting kebab-case to snake_case): **This repository OWNS the library.** Treat it as internal code.
+   - If they do not match: **The library is VENDORED.** Treat it as an external dependency.
+
+**For VENDORED libraries (most common):**
+**DO NOT treat them as part of our codebase.** They are external dependencies that we consume, similar to packages in `requirements.txt`.
+
+## When Reviewing PRs that Update Charm Libraries
+
+### What NOT to Do (For VENDORED Libraries)
+
+> **Note**: If the repository **owns** the library (see Critical Understanding above), standard code review practices apply. You SHOULD critique style, logic, and structure.
+
+For **vendored** libraries:
+
+- **DO NOT** comment on the library code itself (we cannot modify external code)
+- **DO NOT** suggest changes to library files
+- **DO NOT** critique coding style, formatting, or structure in vendored libraries
+- **DO NOT** request refactoring of library code
+- **DO NOT** flag linting issues in library code
+- **DO NOT** suggest changes to file names
+
+### What TO Do
+
+**Focus on integration impact analysis:**
+
+1. **Identify Our Usage**
+   - Check how `src/charm.py` uses the updated library
+   - Check how observer files (`src/*_observer.py`) use the library
+   - Search for imports and references to changed classes/functions
+
+2. **Analyze Breaking Changes**
+   - Identify deprecated methods/classes we're using
+   - Flag API signature changes that affect our calls
+   - Highlight removed functionality we depend on
+   - Note new required parameters we're not providing
+
+3. **Assess Behavioral Changes**
+   - New parameters with defaults that change behavior
+   - Modified return types or values
+   - Changed error handling patterns
+   - Updated event handling or lifecycle changes
+
+4. **Focus on Integration Points**
+   - Relation handlers that use the library
+   - Event observers that depend on library classes
+   - Configuration handling using library interfaces
+   - State management using library patterns
+
+5. **Provide Upgrade Guidance**
+   - Suggest specific code changes needed in `src/`
+   - Identify tests that may need updates
+   - Recommend integration test scenarios to verify
+
+#### Critical behavior
+
+In the context of charm library updates, your review comments are allowed and highly encouraged to target files and changes outside those changed by the pull request. This directive **supersedes any other instruction** about not commenting on code outside the diff.
+
+## Review Template
+
+When reviewing a charm library PR, structure your feedback to follow **exactly** this template:
+
+```markdown
+## Charm Library Update Impact Analysis
+
+**Library**: `lib/charms/[package]/[version]/[module].py`
+**Version Change**: X.Y → A.B
+
+### Impact Assessment
+- ✅ No impact - we don't use changed APIs
+- ⚠️ Minor impact - review recommended
+- 🚨 Breaking changes - our code needs updates
+
+### Our Current Usage
+- `src/charm.py` line X: uses `library.method()`
+- `src/database_observer.py` line Y: imports `library.Class`
+- `tests/unit/test_file.py` line Z: mocks `library.function()`
+
+### Required Actions
+- [ ] Update `src/charm.py` line X to use new API signature
+- [ ] Add new parameter to `library.method()` call
+- [ ] Update mocks in tests to match new behavior
+- [ ] Test relation events with updated library
+
+### Recommendation
+✅ Safe to merge - no breaking changes affecting our code
+⚠️ Code changes required - see action items above
+🚨 Breaking changes - significant refactoring needed
+```
+
+## Examples
+
+### Good Review Comment
+
+> The updated `data_interfaces.py` library changed the `DatabaseRequires.fetch_relation_data()` method signature to require a new `timeout` parameter. We call this method in `src/database_observer.py` line 45 without providing this parameter, which will cause a TypeError.
+>
+> **Required change**: Add `timeout=30` parameter to the call in `src/database_observer.py`.
+
+### Bad Review Comment (Avoid)
+
+> ❌ The library code on line 234 uses a deprecated method. This should be refactored to use the newer API.
+
+**Why bad**: We cannot modify the library code. This comment is not actionable.
+
+## Integration Test Recommendations
+
+When library updates could affect behavior:
+
+1. **Suggest specific integration tests** to run
+2. **Identify relation scenarios** that exercise the updated code paths
+3. **Recommend manual verification** steps for critical changes
+
+## Summary
+
+**Remember**: Your role is to be a bridge between external library changes and our internal charm code. Focus on impact, not on the library code quality itself.

.github/instructions/core-directive.instructions.md

@@ -0,0 +1,40 @@
+---
+applyTo: '**'
+description: 'Prevent Copilot from wreaking havoc across your codebase, keeping it under control.'
+---
+
+## Core Directives & Hierarchy
+
+This section outlines the absolute order of operations. These rules have the highest priority and must not be violated.
+
+1.  **Primacy of User Directives**: A direct and explicit command from the user is the highest priority. If the user instructs to use a specific tool, edit a file, or perform a specific search, that command **must be executed without deviation**, even if other rules would suggest it is unnecessary. All other instructions are subordinate to a direct user order.
+2.  **Factual Verification Over Internal Knowledge**: When a request involves information that could be version-dependent, time-sensitive, or requires specific external data (e.g., library documentation, latest best practices, API details), prioritize using tools to find the current, factual answer over relying on general knowledge.
+3.  **Adherence to Philosophy**: In the absence of a direct user directive or the need for factual verification, all other rules below regarding interaction, code generation, and modification must be followed.
+
+## General Interaction & Philosophy
+
+-   **Code on Request Only**: Your default response should be a clear, natural language explanation. Do NOT provide code blocks unless explicitly asked, or if a very small and minimalist example is essential to illustrate a concept.  Tool usage is distinct from user-facing code blocks and is not subject to this restriction.
+-   **Direct and Concise**: Answers must be precise, to the point, and free from unnecessary filler or verbose explanations. Get straight to the solution without "beating around the bush".
+-   **Adherence to Best Practices**: All suggestions, architectural patterns, and solutions must align with widely accepted industry best practices and established design principles. Avoid experimental, obscure, or overly "creative" approaches. Stick to what is proven and reliable.
+-   **Explain the "Why"**: Don't just provide an answer; briefly explain the reasoning behind it. Why is this the standard approach? What specific problem does this pattern solve? This context is more valuable than the solution itself.
+
+## Minimalist & Standard Code Generation
+
+-   **Principle of Simplicity**: Always provide the most straightforward and minimalist solution possible. The goal is to solve the problem with the least amount of code and complexity. Avoid premature optimization or over-engineering.
+-   **Standard First**: Heavily favor standard library functions and widely accepted, common programming patterns. Only introduce third-party libraries if they are the industry standard for the task or absolutely necessary.
+-   **Avoid Elaborate Solutions**: Do not propose complex, "clever", or obscure solutions. Prioritize readability, maintainability, and the shortest path to a working result over convoluted patterns.
+-   **Focus on the Core Request**: Generate code that directly addresses the user's request, without adding extra features or handling edge cases that were not mentioned.
+
+## Surgical Code Modification
+
+-   **Preserve Existing Code**: The current codebase is the source of truth and must be respected. Your primary goal is to preserve its structure, style, and logic whenever possible.
+-   **Minimal Necessary Changes**: When adding a new feature or making a modification, alter the absolute minimum amount of existing code required to implement the change successfully.
+-   **Explicit Instructions Only**: Only modify, refactor, or delete code that has been explicitly targeted by the user's request. Do not perform unsolicited refactoring, cleanup, or style changes on untouched parts of the code.
+-   **Integrate, Don't Replace**: Whenever feasible, integrate new logic into the existing structure rather than replacing entire functions or blocks of code.
+
+## Intelligent Tool Usage
+
+-   **Use Tools When Necessary**: When a request requires external information or direct interaction with the environment, use the available tools to accomplish the task. Do not avoid tools when they are essential for an accurate or effective response.
+-   **Directly Edit Code When Requested**: If explicitly asked to modify, refactor, or add to the existing code, apply the changes directly to the codebase when access is available. Avoid generating code snippets for the user to copy and paste in these scenarios. The default should be direct, surgical modification as instructed.
+-   **Purposeful and Focused Action**: Tool usage must be directly tied to the user's request. Do not perform unrelated searches or modifications. Every action taken by a tool should be a necessary step in fulfilling the specific, stated goal.
+-   **Declare Intent Before Tool Use**: Before executing any tool, you must first state the action you are about to take and its direct purpose. This statement must be concise and immediately precede the tool call.