(shardingsphere) branch master updated: Forbid local machine paths in agent outputs (#38817)

[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 f9a8675ccd0 Forbid local machine paths in agent outputs (#38817)
f9a8675ccd0 is described below

commit f9a8675ccd065d55d5256a595a1387b8ca6f844e
Author: Liang Zhang <zh...@apache.org>
AuthorDate: Fri Jun 5 23:29:22 2026 +0800

    Forbid local machine paths in agent outputs (#38817)
    
    Add path portability guidance for generated code, tests, scripts, and skills.
    Require handoff checks to verify code and skills avoid local machine paths.
---
 AGENTS.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index e304aff1f43..5a289353288 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -105,6 +105,8 @@ Dangerous operation detected! Operation type: [specific action] Scope of impact:
 - **Think before coding**: inspect existing code, contracts, tests, and relevant standards before editing; do not guess, hide uncertainty, or invent unsupported facts.
 - **Simple first**: solve the verified goal with the smallest clear implementation that preserves existing behavior.
 - **Precise modification**: change only the files and code paths required by the task; avoid drive-by refactors and unrelated cleanup.
+- **Path portability**: when writing code, tests, scripts, or skills, do not hard-code local machine paths or workspace-specific absolute paths.
+  Use repository-relative paths, configurable parameters, temporary directories, or documented environment variables instead.
 - **Scope declaration gate**: before planning or editing, determine and declare the requested change boundary.
   If the boundary is clear from the user request, state the inferred scope explicitly before making changes.
   If the boundary is missing or ambiguous, pause and ask the developer to confirm it before making changes.
@@ -139,6 +141,7 @@ Dangerous operation detected! Operation type: [specific action] Scope of impact:
 - **Risk gate:** if any action fits the Dangerous Operation Checklist, pause and use the confirmation template before proceeding.
 - **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 and mark retained values `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.
 - **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.