diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 000000000..1214c1468 --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,64 @@ +# Copilot instructions + + + + + + +## 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. + + diff --git a/.github/prompts/review-pr.prompt.md b/.github/prompts/review-pr.prompt.md new file mode 100644 index 000000000..3eddadfdf --- /dev/null +++ b/.github/prompts/review-pr.prompt.md @@ -0,0 +1,158 @@ + + +--- +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 --json number,title,body,headRefName,baseRefName,author,files,additions,deletions,url + gh pr diff + ``` + +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 + git diff origin/...HEAD + git log --oneline origin/..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 +- — `path:line` + +## Suggestions +- — `path:line` + +## Questions +- +``` + +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.