Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Task][Docs] Adapt AGENTS.md working principles to ShenYu and refresh build facts

Aperta Adatta ai principianti
  • Qualcosa non va?
#8,211 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@qiaolezi001 ci sta già lavorando.

Dal 29/10/2026.

  • #8227 di @qiaolezi001 — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
74/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
documentation

Direzione di ricerca

Leggi il file AGENTS.md del repository, il pom.xml nella directory principale e le istruzioni per contribuire. Aggiorna la sezione sui principi di lavoro affinché copra i quattro temi, mantenendo le indicazioni esistenti sul progetto e sull’architettura. Verifica nel POM la fonte della versione e le fasi e le opzioni di esclusione di Checkstyle/RAT. Rivedi il risultato rispetto ai criteri di accettazione e a scenari rappresentativi di configurazione e reattivi. Il lavoro è concluso quando la documentazione è accurata, concisa e limitata alle indicazioni per i collaboratori.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

in: document type: enhancement

Goal

Add concise working principles to the repository's AGENTS.md so coding agents make focused, verifiable changes while respecting ShenYu's multi-module architecture and compatibility boundaries. Keep the existing project overview, commands and architecture guidance, and correct two stale build facts.

The four themes are think before coding, simplicity first, surgical changes, and goal-driven execution. Adapt them to ShenYu rather than copying absolute rules that force routine clarification, minimize line counts, or require the same test/build sequence for every change.

Verified documentation gaps

Reviewed apache/shenyu@750673e3f619e335333150ff1b2d14070d5d5c31 (2.7.3-SNAPSHOT):

Proposed scope

1. Think before coding: establish facts and material assumptions
  • Inspect the relevant source, configuration, tests and current issue/PR state before proposing implementation. Distinguish implemented behavior, unmerged work and planned capabilities.
  • State assumptions and tradeoffs that affect correctness, compatibility or the requested scope. Investigate repository evidence first; ask when a material ambiguity still prevents a correct decision. Routine reversible implementation choices do not require a new confirmation gate.
  • For multi-step work, provide a short plan with observable verification. Do not require a lengthy plan for trivial edits.
2. Simplicity first: choose the smallest complete solution
  • Reuse existing plugin, SPI, configuration and observation mechanisms before adding another framework or registry. Avoid speculative options and unrelated features.
  • Measure simplicity by necessary behavior and maintenance cost, not the fewest lines or files. A requested public extension contract may legitimately start with one implementation; it needs a concrete use case and a compatible boundary.
  • Keep necessary handling for invalid external input, network failures, cancellation, reload races and resource ownership. These are expected gateway conditions, not impossible scenarios that should be deleted for brevity.
3. Surgical changes: limit scope while completing the affected contract
  • Match surrounding style and keep unrelated formatting, cleanup and refactors out of the change. Remove imports/helpers made unused by the change; report unrelated findings separately.
  • Preserve existing public SPI, plugin names, configuration defaults and supported legacy behavior unless the requested change explicitly addresses them.
  • A complete fix may require coordinated changes across shared DTOs, Admin persistence/validation and events, data sync, gateway consumers, starters and tests. Check the affected plugin/selector/rule flow rather than enforcing a one-file change.
  • When persistence or seed/upgrade metadata is affected, check the maintained dialects and upgrade paths. Do not expand every ordinary change into a database migration task.
4. Goal-driven execution: verify behavior at the right boundary
  • Define success in observable terms. For a bug, prefer a regression that exposes it and verifies the fix. For a refactor, preserve the relevant externally observable behavior.
  • Match validation to risk and scope: use ./mvnw and focused module/dependency checks first, then the broader checks required by the change and repository/CI policy. Compilation or a build with -DskipTests is not evidence that behavior tests passed.
  • Reactive changes should exercise relevant subscription, completion/error/cancellation, buffer/resource release and actual transport/body/session lifetimes. For example, verify cancellation reaches the original upstream call rather than only cancelling an unrelated derived future. Header readiness, body completion and WebSocket session termination are different boundaries.
  • Documentation-only and other low-impact edits need proportionate content/link/configuration checks, not artificial Java tests that merely mirror text. Do not impose universal test-first or full-repository-build rules.
  • Report what was checked, the result, and material checks not run. Retain existing Checkstyle, Apache license/RAT and contribution requirements; these principles do not exempt a change from required checks.

Acceptance criteria

  • AGENTS.md contains a short, actionable working-principles section covering the four themes without becoming another architecture document or a long approval checklist.
  • It explicitly permits routine autonomous decisions and the smallest complete cross-module fix; it does not introduce mandatory confirmation for every assumption or use line/file count as the correctness target.
  • Existing plugin/SPI and configuration compatibility, relevant Admin-to-gateway propagation, and affected SQL dialects are considered where applicable.
  • Verification guidance is risk-based, uses the Maven wrapper, distinguishes actual behavior tests from compile/skip-test evidence, and explains relevant reactive lifetime boundaries.
  • Version authority and Checkstyle/RAT phase descriptions agree with the reviewed POM; existing build/test commands are reviewed for consistency.
  • Existing project guidance is preserved. This task is limited to contributor/agent documentation: no plugin runtime change, dependency addition, new approval system or unrelated workflow rewrite.

Validation

Review the documentation against the checked-in POM, affected contribution instructions and representative configuration/reactive change scenarios. No new runtime test suite is needed solely to validate this documentation update.

Lingua principale
Java
Stelle
8.9k
Fork
3.1k
Merge medio
2g 2h
PR unite (30g)
414

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/shenyu

Tutte le issue di apache/shenyu

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.