[PATCH BlueZ v1 2/3] doc: Add bug fixing procedure for AI coding assistants

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Require AI assistants fixing bugs to verify them with a reproducer, test
the fix, state what could not be verified and leave any submission to
the human, with vulnerabilities following SECURITY.md.

Adapted from the Linux kernel's
Documentation/process/coding-assistants.rst.

Assisted-by: OpenCode:claude-opus-5.5
---
 doc/coding-assistants.rst | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/doc/coding-assistants.rst b/doc/coding-assistants.rst
index 778b3e6d81b3..6b81d740cd65 100644
--- a/doc/coding-assistants.rst
+++ b/doc/coding-assistants.rst
@@ -67,3 +67,36 @@ Additionally:
 * Use a subject prefix consistent with the history of the files touched.
 * Verify factual claims in the message (file counts, symbol names,
   paths) against the actual diff before committing.
+
+Procedure for finding and fixing bugs
+=====================================
+
+When an AI assistant is used to find and fix bugs, it **MUST** follow at
+least these steps:
+
+1. Before starting, read the whole process documentation listed above,
+   as well as any other document mentioned in the request. Do not rely on
+   isolated parts found by keyword search.
+2. Note the commit ID and locate the bug as instructed.
+3. For any bug that is not trivial, verify that it is real by writing a
+   reproducer, preferably a unit test (unit/) or a functional test
+   (test/functional/, see doc/functional-testing.rst). Unverified reports
+   are often invalid and may be ignored. Stop here if the bug turns out
+   not to be real.
+4. Write a fix for the bug. Fixes written in the same session that found
+   the bug tend to be more accurate, as the reasoning context is still
+   present.
+5. Build and verify that the fix works, using the reproducer or by
+   re-running the analysis; drop any fix that doesn't work and try
+   another one. The fix must not add build warnings, must pass
+   ``make check`` and the checkpatch.pl checks (see doc/coding-style.rst).
+6. Commit the fix with a message describing the problem and the solution,
+   following the Commit Messages section above. Add a Fixes tag pointing
+   to the commit that introduced the bug and an Assisted-by tag as
+   described above.
+7. Indicate what could not be done. If the fix could not be built or
+   tested, or no reproducer could be produced, say so explicitly.
+8. Determine whether the bug is a vulnerability. Vulnerabilities must not
+   be reported to the mailing list; follow SECURITY.md instead. Regular
+   bugs are sent to linux-bluetooth@vger.kernel.org. Leave the submission
+   to the human; the assistant must never send anything itself.
-- 
2.55.0