Add Coding Standards and AI Tool Advice.

.github/instructions/git.instructions.md

@@ -21,6 +21,6 @@ alwaysApply: false
 2. **Make changes** locally.  
 3. **Commit** with a clear message.  
 4. **Push** the branch.  
-5. **Open a PR** via the `github` MCP server (see `github.instructions.md`).  
+5. **Open a PR** via the `github` command line interface.  
 
 ---

.github/instructions/github.instructions.md

@@ -7,7 +7,6 @@ alwaysApply: false
 
 ## Overview
 This project uses GitHub as its primary version control and collaboration platform. All code contributions, fixes, and features must go through a pull request (PR) workflow.
-You have access to an MCP server named **`github`** (running `mcp-github`) which can create branches, push commits, and open PRs directly from the Continue.dev environment. See `.vscode/mcp.json` for configuration.
 
 ## Branching Strategy
 - **Default branch:** `main`
@@ -32,25 +31,14 @@ You have access to an MCP server named **`github`** (running `mcp-github`) which
 5. Small PRs are preferred — keep them focused on one logical change.
 
 ## Tooling
-Use the **`github`** MCP server (configured in `.vscode/mcp.json`) to:
+Use the github command line interface to:
    - Create branches
    - Commit and push changes
    - Open pull requests
    - Check PR status
-## Example MCP Server Commands
-You can instruct Continue.dev to:
-- `Use the github MCP server to create a new branch called fix/memory-leak`
-- `Push the current branch and open a pull request titled "Fix memory leak in cache manager"`
-- `List open pull requests for this repo`
-- `Merge PR #45 after approval`
 
 ## Automation
 - CI/CD runs automatically for all PRs.
 - Approved PRs can be merged by maintainers.
-- Use **squash merging** to keep history clean.
 
-## Notes for Continue.dev
-- You are allowed to automate branch creation and PR submission using the `github` MCP server.
-- If multiple PRs are required, ensure each is isolated to its own branch.
-- You may request human review before merging.
 ```

BUILD.bazel

@@ -93,6 +93,11 @@ genrule(
     outs = ["doxygen_docs.zip"],
     cmd = """
       set -e
+      case "$$(uname -s)" in
+        Darwin)  PATH="/opt/homebrew/bin:/usr/local/bin:$$PATH" ;;
+        Linux)   PATH="/usr/local/bin:$$PATH" ;;
+        MINGW*|MSYS*|CYGWIN*) PATH="/usr/bin:/usr/local/bin:$$PATH" ;;
+      esac
       DOXYFILE_GEN="$(@D)/Doxyfile.generated"
       OUT_DIR="$(@D)/doxygen_output"
       OUT_ZIP="$$(pwd)/$@"

docs/coding_standards_and_ai_advice.md

@@ -0,0 +1,62 @@
+# Coding agents and coding standards
+
+Coding agents are improving quickly, and the best tool or model for a task can change from one month to the next. This note collects the coding guidance and tooling recommendations that were assembled during the first quarter of 2026, when most of the modernisation work for release 3.0.0 was completed.
+
+This document does not prescribe a specific MCP server setup. MCP servers can be powerful, but they also introduce security risks, so the right deployment strategy depends on the environment.
+
+## Coding Standards
+
+Consistent style matters even more when both humans and coding agents are reading and editing the same code. The preferred conventions are documented in the `.github/instructions` directory, which is where GitHub Copilot looks for its persistent instructions.
+
+1. [C++](../.github/instructions/cpp.instructions.md)
+2. [Bazel](../.github/instructions/bazel.instructions.md)
+3. [Git](../.github/instructions/git.instructions.md)
+4. [GitHub](../.github/instructions/github.instructions.md)
+
+## Recommended Tools for Coding Agents
+
+### clangd
+
+https://clangd.llvm.org
+
+Language servers are familiar to most IDE users, but coding agents usually cannot interact with them directly. MCP wrappers can expose a language server to an agent, but they often do so by forwarding raw JSON responses that still need to be interpreted. If you also run Serena, prefer to let Serena handle the language-server integration.
+
+### Serena
+
+https://github.com/oraios/serena
+
+Serena is the most useful tool in this workflow. It provides semantic analysis and retrieval features that help coding agents stay focused on the right parts of the codebase and understand the structure of the language they are working in.
+
+### Code Context Engine
+
+https://github.com/elara-labs/code-context-engine
+
+Code Context Engine builds and maintains an index of the codebase, which lets a coding agent inspect the relevant parts of a file without scanning unrelated content across many files.
+
+One observation from this tooling landscape is that different systems solve different problems. Serena helps explain what the code is doing, while a code index helps locate where the interesting code lives. That is more useful than simply surfacing syntactically similar code, which is often not enough to guide a change.
+
+## Documentation and Code Completion
+
+Code documentation for DDS3 is generated with Doxygen, which extracts formatted comments from the source code. Run the following command to generate the local documentation:
+
+```
+bazelisk build //:doxygen_docs
+```
+
+The generated HTML pages are available under `doxygen_output/html/`. Open `doxygen_output/html/pages.html` to read the documentation.
+
+### Extracting compile_commands.json
+
+Language servers such as clangd rely on a `compile_commands.json` file, which describes how the project is built.
+
+On macOS or Linux, the following command generates that file when the `bazel-compile-commands` utility is installed:
+
+```
+bazel-compile-commands //...
+```
+
+https://github.com/kiron1/bazel-compile-commands
+
+An alternative is Hedron Compile Commands, which can be integrated into the Bazel build. It appears to be less actively maintained, but it is still worth knowing about:
+
+https://github.com/hedronvision/bazel-compile-commands-extractor