(shardingsphere) branch master updated: Add AI handoff verification guardrails (#38860)

[zh...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

terrymanu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git


The following commit(s) were added to refs/heads/master by this push:
     new 1cdbf585ca7 Add AI handoff verification guardrails (#38860)
1cdbf585ca7 is described below

commit 1cdbf585ca7616f7c6a1e0c9cd57f4ff1d73ffa4
Author: Liang Zhang <zh...@apache.org>
AuthorDate: Wed Jun 17 15:33:52 2026 +0800

    Add AI handoff verification guardrails (#38860)
    
    - Add changed-file based GitHub Actions impact checks
    - Add public contract propagation checks for external identifiers
    - Add full external output safety and generated baseline verification gates
---
 AGENTS.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index cdec6388950..8250d81d77a 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -157,6 +157,18 @@ Dangerous operation detected! Operation type: [specific action] Scope of impact:
 - **Planning rules:** use Sequential Thinking with 3-10 actionable steps (no single-step plans) via the plan tool for non-trivial tasks; convert all hard requirements (SPI usage, mocking rules, coverage/test naming, forbidden APIs) into a checklist inside the plan and do not code until each item is addressed or explicitly waived.
 - **Execution discipline:** inspect existing code before edits; keep changes minimal; default to mocks and SPI loaders; keep variable declarations near first use without marking local variables `final`; inline single-use locals by default unless reuse/readability justifies retention; delete dead code and avoid placeholders/TODOs.
   Verify code and skills do not contain local machine paths before handoff.
+- **CI impact gate:** before handoff, determine affected GitHub Actions from changed files.
+  Use `rg` or small `sed` ranges to inspect only matching workflow `paths`, job names, and execution commands instead of reading every workflow file.
+  For production code, tests, E2E, build configuration, or project-rule changes, run the local equivalent of the affected workflow command when practical.
+  For docs-only or clearly unrelated changes, or when a workflow-equivalent run is not practical, state the rationale, residual risk, and narrower verification that was run.
+- **Public contract propagation gate:** when changing any public contract or externally visible identifier, search the affected reference surfaces with `rg` before handoff.
+  This includes API names, SQL syntax, configuration keys, YAML keys, SPI types, error codes, protocol fields, CLI commands, resource identifiers, canonical documentation names, descriptors, examples, distributions, tests, E2E fixtures, and baseline resources.
+  Exclude generated directories such as `.git` and `target`.
+  If a compatibility alias remains, document whether it is discoverable; if it must stay hidden, cover that with a focused test or contract check.
+- **External output safety gate:** when changing externally visible errors, diagnostics, log summaries, HTTP/JSON payloads, CLI output, or exception conversion, test the complete external output when inputs may contain connection strings, credentials, tokens, SQL text, filesystem paths, or user data.
+  Do not rely only on nested-field assertions when the full payload could still expose sensitive or misleading text.
+- **Generated contract and baseline gate:** when a change can affect snapshots, baselines, golden files, fingerprints, expected SQL cases, protocol descriptors, generated schemas, or client/model-visible metadata, regenerate or verify those artifacts with the existing project tool or test before handoff.
+  Run the corresponding contract, golden, baseline, or E2E check when practical; otherwise report why it was not practical and what narrower verification was used.
 - **AGENTS.md maintenance:** do not add or update a `Session Notes` section in `AGENTS.md`. Keep task-specific notes in the active conversation, issue, or PR; only stable project-level rules may be generalized into this file.
 - **Post-task self-check (before replying):** confirm all instructions were honored; verify no placeholders/unused code; ensure Checkstyle/Spotless gates for touched modules are satisfied or explain why not run and what to run; list commands with exit codes; call out risks and follow-ups; complete all applicable checks before replying and do not rely on users to find missed rule violations.
 - **End-of-task format/style gate:** for any task that edits files, run `./mvnw spotless:apply -Pcheck -T1C` after the final edit, then run `./mvnw checkstyle:check -Pcheck -T1C` when production, test, or project-rule files are touched.