Add Copilot instructions and PR-review prompt synced from armada

.github/copilot-instructions.md

@@ -0,0 +1,64 @@
+# Copilot instructions
+
+<!-- Repo-specific guidance goes here. Hand-edit freely above the synced
+     block. The synced block at the bottom is overwritten by
+     equinor/armada/scripts/sync-copilot.sh. -->
+
+<!-- BEGIN SYNCED FROM equinor/armada@6696246 -->
+<!-- AUTO-GENERATED — do not edit between these markers. Run scripts/sync-copilot.sh in armada to refresh. -->
+
+## Flotilla–SARA system context
+
+This repository is part of the Equinor Flotilla–SARA robotics system. Sibling
+repositories that may be affected by changes here include:
+
+- **isar** — mission API and `robot_interface` definition; publishes MQTT events.
+- **isar-robot / isar-anymal / isar-taurob** — robot-specific implementations of
+  the ISAR `robot_interface`.
+- **flotilla** — operator backend (ASP.NET) + frontend (React) + Mosquitto
+  broker; consumes ISAR MQTT messages.
+- **sara** + **sara-anonymizer / sara-constant-level-oiler / sara-stid /
+  sara-thermal-reading / sara-fence-detection / sara-timeseries** — inspection
+  data platform; SARA orchestrates the analysis steps via Argo workflows and
+  ingests `IsarInspectionResultMessage` events.
+- **robotics-infrastructure / analytics-infrastructure** — Kustomize/ArgoCD
+  deployments for the above.
+- **armada** — integration-test harness that runs `flotilla`, `isar-robot` and
+  `sara` together; also the canonical source of this shared Copilot config.
+
+For the full architecture overview see the README in
+[`equinor/armada`](https://github.com/equinor/armada).
+
+## Pull request reviews
+
+When asked to review a pull request, follow the workflow in
+`.github/prompts/review-pr.prompt.md`. If that prompt file is not available in
+your Copilot surface (e.g. some IDE integrations), apply this condensed
+checklist instead:
+
+1. **Cross-repo impact.** Does the diff touch a contract used by sibling repos?
+   In particular: ISAR MQTT message models, the ISAR `robot_interface`, SARA
+   Argo workflow step inputs/outputs, shared schemas, or deployment manifests
+   under `*-infrastructure`. If so, name the sibling repo(s) that likely need a
+   coordinated PR.
+2. **Tests.** New/changed behaviour has unit or integration tests. Consider
+   whether `armada` integration tests need updating as well.
+3. **Security.** No secrets, credentials, or private endpoints committed. New
+   outbound network calls or new dependencies are justified.
+4. **Backward compatibility.** Public contracts (HTTP, MQTT topics/payloads,
+   CLI flags, config keys, database schemas) remain compatible, or a migration
+   path is documented.
+5. **Observability.** Logs and metrics are present where the change affects
+   runtime behaviour or failure modes.
+6. **Style.** Matches the repo's language conventions (C# / TypeScript /
+   Python / Kustomize) and passes the repo's existing lint/format gates.
+7. **Docs.** README or in-repo docs updated when user-visible behaviour
+   changes.
+8. **Commits & PR hygiene.** Commit messages follow the repo's convention; the
+   PR description explains the *why*, not just the *what*.
+
+Output the review as four sections — **Summary**, **Blocking**, **Suggestions**,
+**Questions** — and cite findings as `path:line`. Use `- _none_` for empty
+sections. No emojis.
+
+<!-- END SYNCED -->

.github/prompts/review-pr.prompt.md

@@ -0,0 +1,158 @@
+<!-- AUTO-GENERATED from equinor/armada@6696246 — do not edit. Run scripts/sync-copilot.sh in armada to refresh. -->
+
+---
+mode: agent
+description: Review a pull request in a Flotilla–SARA repository.
+---
+
+# Review a pull request
+
+You are reviewing a pull request in a repository that is part of the Equinor
+Flotilla–SARA robotics system. Be direct, technical, and concise. No emojis.
+Cite every finding as `path:line`.
+
+## 1. Determine what to review (auto-detect)
+
+Pick the **first** of the following that applies:
+
+1. **Explicit PR provided by the user.** If the user supplies a PR number, URL,
+   or branch name, use the GitHub CLI:
+
+   ```bash
+   gh pr view <pr>   --json number,title,body,headRefName,baseRefName,author,files,additions,deletions,url
+   gh pr diff <pr>
+   ```
+
+2. **Current branch is associated with an open PR.** Try:
+
+   ```bash
+   gh pr view --json number,title,body,headRefName,baseRefName,author,files,additions,deletions,url
+   gh pr diff
+   ```
+
+   If this succeeds, review that PR.
+
+3. **Local branch diff against the default branch.** Determine the default
+   branch — try `gh` first, then fall back to `git`:
+
+   ```bash
+   gh repo view --json defaultBranchRef -q .defaultBranchRef.name \
+     || git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@'
+   ```
+
+   Then review the diff:
+
+   ```bash
+   git fetch origin <default-branch>
+   git diff origin/<default-branch>...HEAD
+   git log --oneline origin/<default-branch>..HEAD
+   ```
+
+If none of these yields a non-empty diff, ask the user which PR or branch to
+review and stop.
+
+## 2. Build context
+
+Before commenting:
+
+- Read the PR description (or, for branch-only review, the commit messages) to
+  understand intent and any linked issues.
+- Skim the changed files in full where the diff is non-trivial — do not review
+  hunks in isolation.
+- Note the repo's role in the Flotilla–SARA system (see
+  `.github/copilot-instructions.md`) so you can reason about cross-repo impact.
+
+## 3. Review checklist
+
+Walk through every item. For each, either record a finding or note that the
+item is satisfied.
+
+1. **Correctness vs. intent.** Does the implementation match what the PR
+   description and linked issues say it should do? Are edge cases and error
+   paths handled?
+
+2. **Cross-repo impact.** Explicitly check whether the diff touches a contract
+   shared with sibling repos:
+
+   - ISAR MQTT message models (`IsarStatus`, `IsarTask`, `IsarMission`,
+     `IsarBattery`, `IsarPressure`, `IsarRobotInfo`, `IsarRobotHeartbeat`,
+     `IsarCloudHealth`, `IsarInspectionResultMessage`, ...).
+   - The ISAR `robot_interface` (Python ABC defined in `isar`, implemented by
+     `isar-robot`, `isar-anymal`, `isar-taurob`).
+   - SARA Argo workflow step contracts (inputs/outputs of
+     `sara-anonymizer`, `sara-constant-level-oiler`, `sara-stid`,
+     `sara-thermal-reading`, `sara-fence-detection`, `sara-timeseries`).
+   - Shared HTTP/REST schemas (`flotilla` ↔ frontend, `flotilla` ↔ `isar`,
+     `sara` ↔ analysis steps).
+   - Deployment manifests under `robotics-infrastructure` or
+     `analytics-infrastructure` (kustomize overlays, ConfigMaps).
+
+   For each affected contract, **name the sibling repo(s) that likely need a
+   coordinated PR** and describe what the matching change should do.
+
+3. **Tests.**
+   - New or changed behaviour is covered by unit or integration tests.
+   - Existing tests are updated where their assumptions changed.
+   - Consider whether `armada` integration tests need to be added or updated
+     (especially when changing flotilla ↔ isar ↔ sara interactions).
+
+4. **Security.**
+   - No secrets, credentials, tokens, certificates, or private endpoints in
+     the diff.
+   - New outbound network calls are justified and documented.
+   - New dependencies are reputable, pinned, and licensed compatibly.
+   - Input validation on any externally-reachable surface.
+
+5. **Backward compatibility.** Public contracts remain compatible, or the PR
+   provides a migration path:
+   - HTTP routes and request/response shapes.
+   - MQTT topic names and payload schemas.
+   - CLI flags and environment variables.
+   - Database schemas (look for missing/incorrect EF Core or Alembic
+     migrations).
+   - Config file keys.
+
+6. **Observability.** Where the change affects runtime behaviour, failure
+   modes, or performance: are logs at appropriate levels added/preserved? Are
+   metrics or traces updated? Are error messages actionable?
+
+7. **Style and conventions.** Code matches the repo's language conventions
+   (C# / TypeScript / Python / Kustomize / Bash) and would pass the repo's
+   lint/format gates (csharpier, prettier, eslint, ruff, black, mypy, etc.) if
+   run locally.
+
+8. **Docs.** README, in-repo docs, or PR template fields are updated when
+   user-visible behaviour or developer workflow changes.
+
+9. **Commits & PR hygiene.** Commit messages follow the repo's convention
+   (typically https://cbea.ms/git-commit/); each commit builds; the PR
+   description explains the *why*, not just the *what*; linked issues present.
+
+## 4. Output
+
+Produce **exactly** these four sections, in this order, in Markdown. Use
+`- _none_` for empty sections. Do not add other top-level sections.
+
+```
+## Summary
+<1–3 sentences: what the PR does and your overall assessment.>
+
+## Blocking
+- <Issue that must be resolved before merge.> — `path:line`
+
+## Suggestions
+- <Non-blocking improvement.> — `path:line`
+
+## Questions
+- <Question for the author that the diff alone cannot answer.>
+```
+
+Rules for the output:
+
+- Be specific. Quote short snippets only when needed for clarity.
+- Prefer concrete suggested changes (a one-line diff or a short code block)
+  over vague advice.
+- When you flag cross-repo impact in **Blocking** or **Suggestions**, name the
+  sibling repo(s) explicitly, e.g. `Coordinated PR likely needed in
+  equinor/flotilla (backend MQTT message model).`
+- Do not restate the entire diff. Do not invent findings to fill sections.