gemini.md

# Gemini Coding Assistant Project Guidelines

## High-Level Flow

Follow the following flow to implement any feature. Refer to each chapter of
this document for detailed guidelines.

1. Understand the requirements and Design the solution
2. Implement the solution and test it
3. Commit the code changes

Agent should not skip to next step without explicit permission from user.

## Understand the requirements and Design the solution

AI Agents should start in the design mode. In this mode, the agent should
understand the requirements and design the solution.

Agent should act as a senior software engineer to design the solution and reason
with the user.

Agent should use the following source as reference:

- workspace files
- Use the build.md to configure the Meson. Use the `subprojects` directory.
- Refer to the docker system file for include headers.

AI Agent should not use MCP commands unless user explicitly requests it.

The implementation plan should consist of the following:

- High level design
  - when my requirements are ambiguous, first ask, don't guess.
- step by step implementation plan
  - elaborate all impacted files and reason.
- test cases

AI Agent should save the implementation plan in the temporary markdown file.

## Implement the solution and test it

AI Agents should start in the implementation mode. In this mode, the agent
should implement the solution and test it.

AI Agent should act as a senior software engineer to implement the solution. If
the implementation plan needs to be revised, ask for user's approval first.

AI Agent should compile the code in the docker container based on `build.md` and
make sure the code compiles successfully.

AI Agent should use `.clang-format` to format the code before compiling.

AI Agent should create all unit tests under `tests/` directory. Then, it should
run all the tests in a clean docker container (with no cached artifacts).

If any unit test case fails, fix it and recompile, and test again. Agent should
not run shortcut and alter the test cases in the plan.

Setup a subagent based on the implementation plan and lesson.md file to review
the code changes.

## Local Presubmit and Commit

Before commit, run local presubmit test:

- Create a dummy commit (`git commit -m "temp: strip shmem"`) removing
  `shared_mem_dep` and `absl_status_dep` in root `meson.build`.
- Copy `common_clang_tidy_config.yaml` from Google3 Kokoro platform configs into
  the workspace root.
- Use the `openbmc/ubuntu-unit-test` Docker container (prioritize Google3
  version).
- Use `openbmc-build-scripts` from `/openbmc_build_scripts/` under g3 third
  party or upstream OpenBMC.
- Run `run-unit-test-docker.sh` inside the docker container w/ `-c 1`.
- Drop dummy commit w/ `git reset --hard HEAD~1` upon completion.

Ask the user to provide the bug id.

The commit message should follow the OpenBMC git format:

- Title: `subsystem: short description` (<= 50 chars).
- Blank line.
- Body: Detailed explanation of why and what, wrapped at 72 chars.
- Footer: `Tested: <brief test performed>`
- Footer: `Google-Bug-Id: <bug id>`
- Footer: `Signed-off-by: Name <email>`

**Guidelines for Content:**

- **Highlight the Generic Idea**: Focus on the bug fix or the core feature.
  Explain the high-level design decisions.
- **Condense Implementation Details**: Do not include low-level details (like
  specific variable names, sentinel values, or small code changes) in the main
  body.
- **Use a 'Misc' Section**: Move unrelated or minor changes (like macro usage,
  timeout increases, formatting) to a separate `Misc:` section at the end of the
  body.

For example:

```text
benchmark: refine control plane benchmarks

Refined the control plane benchmarks to use full device paths in Flatten
model keys and 'contains'/'contained_by' edges in Graph model.

Signed-off-by: Hao Jiang <jianghao@google.com>
```

Using `@mcp:buganizer:` to upload the implmenetation plan to the bug.

- upon `git commit --amend`, update the implmenetation plan in the original
  comment number.