Honda Clarity: brake hold fix (#1247)

* Nidec Hybrid brake hold fix

* intent fix

* bump opendbc

---------

Co-authored-by: Jason Wen <haibin.wen3@gmail.com>

docs/AI_POLICY.md

@@ -0,0 +1,44 @@
+# AI policy
+
+## Why this exists
+
+We use AI tools ourselves, so this isn't an anti-AI stance. The problem is people submitting code, issues, or comments they don't actually understand. AI makes that very easy to do, and it creates real work for reviewers who have to figure out what you meant when you can't explain it yourself.
+
+If you're not going to put effort into understanding and verifying your submission, we're not going to put effort into reviewing it.
+
+## The rule
+
+You are responsible for everything you submit: code, PR descriptions, issues, bug reports, comments.
+
+1. Understand what you submit. If a reviewer asks why you did something, you answer from your own understanding, not by re-prompting. If you can't do that, don't submit it.
+
+2. Test your change. AI gets things wrong all the time. Run it, break it, confirm it actually works.
+
+3. Driving fixes need real evidence. Attach a dongle ID, upload logs, and include segments that show the fix working. A route hash by itself proves nothing.
+
+4. No AI-generated media (images, diagrams, videos) in issues or PRs.
+
+## Disclosure
+
+If AI tools helped you write something, say so. Add an `Assisted-by:` line in your commit message:
+
+```
+Assisted-by: GitHub Copilot
+Assisted-by: Claude
+```
+
+Disclosing won't count against your PR. It helps reviewers know where to look. Hiding it and getting caught will.
+
+## How we review
+
+Reviewers are looking at whether you understand your own change. Can you explain it? Can you respond to feedback without re-prompting? Does your PR description say why you made the change, not just list what changed?
+
+Good code from someone who used AI and understands what they wrote is fine. How you got there doesn't matter as long as you can stand behind it.
+
+## What happens
+
+Submissions that don't meet this bar get closed. If it keeps happening, you get blocked.
+
+## Maintainers
+
+Maintainers use AI at their discretion. They've earned that through sustained contribution and they know the codebase.

docs/CONTRIBUTING.md

@@ -1,3 +1,5 @@
+> sunnypilot follows [commaai/openpilot](https://github.com/commaai/openpilot)'s contributing guidelines. The following applies to all contributions here.
+
 # How to contribute
 
 Our software is open source so you can solve your own problems without needing help from others. And if you solve a problem and are so kind, you can upstream it for the rest of the world to use. Check out our [post about externalization](https://blog.comma.ai/a-2020-theme-externalization/).
@@ -35,6 +37,7 @@ All of these are examples of good PRs:
 * **UI design**: we do not have a good review process for this yet
 * **New features**: We believe openpilot is mostly feature-complete, and the rest is a matter of refinement and fixing bugs. As a result of this, most feature PRs will be immediately closed, however the beauty of open source is that forks can and do offer features that upstream openpilot doesn't.
 * **Negative expected value**: This is a class of PRs that makes an improvement, but the risk or validation costs more than the improvement. The risk can be mitigated by first getting a failing test merged.
+* **AI-generated contributions**: see our [AI policy](AI_POLICY.md)
 
 ### First contribution
 

openpilot/selfdrive/car/car_specific.py

@@ -56,6 +56,9 @@ class CarSpecificEvents:
       if self.CP.minEnableSpeed > 0 and CS.vEgo < 0.001:
         events.add(EventName.manualRestart)
 
+      if CS.brakeHoldActive and CS.blockPcmEnable: # set by Nidec Hybrid which cannot resume from brakehold
+        events.add(EventName.belowEngageSpeed)
+
     elif self.CP.brand == 'toyota':
       # TODO: when we check for unexpected disengagement, check gear not S1, S2, S3
       if self.CP.openpilotLongitudinalControl: