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 e8e36355944 Align Codex changes with repository context (#40142)
e8e36355944 is described below
commit e8e3635594468c75083cd825f4ec51d3d1f09efa
Author: Liang Zhang <[email protected]>
AuthorDate: Sat Oct 10 21:22:17 2026 +0800
Align Codex changes with repository context (#40142)
* Normalize GraalVM CI workflow
* Align Codex changes with repository context
---
.codex/context/documentation-wording.md | 5 ++-
.codex/harness/agents/cases.toml | 43 +++++++++++++++++++++-
.../references/rules/implementation.md | 1 +
AGENTS.md | 6 ++-
4 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/.codex/context/documentation-wording.md
b/.codex/context/documentation-wording.md
index 3a56bd361d1..7567aa4b50a 100644
--- a/.codex/context/documentation-wording.md
+++ b/.codex/context/documentation-wording.md
@@ -19,6 +19,8 @@
Apply this file whenever creating or revising documentation, Skills, prompts,
comments, configuration descriptions, or other prose.
+- Before drafting an addition, read the enclosing section and peer items with
the same purpose to determine its structure, abstraction level and detail.
+ Place necessary detail using the existing structure and expand only as
required for the requested outcome.
- Make each rule understandable to people and Codex on the first reading.
State what to inspect, what action to take, what result identifies a problem,
and how to verify it; labels such as `authority source`, `constraint strength`,
`behavior value`, or `proper ownership` do not replace these instructions.
- State the core rule, fact, or action first. Follow it with necessary
applicability conditions, exceptions, and verification methods in that order.
- Use established project technical terms. Do not coin uncommon umbrella
terms; when an unavoidable technical term first appears, immediately explain
what it means.
@@ -33,4 +35,5 @@ Apply this file whenever creating or revising documentation,
Skills, prompts, co
- Keep an example only when it resolves ambiguity, adds an independent
decision condition, or materially helps execution. Otherwise remove it or
separate it from the rule.
- Simplification must preserve the original scope, obligation strength, valid
exceptions, and verification requirements. Do not shorten mechanically or make
readers infer a rule that the original text stated explicitly.
- Keep each new or changed complete sentence on one physical line, and break a
line only after punctuation ends the complete sentence. Do not reflow untouched
text merely to make formatting consistent. Never modify ASF license text or its
internal formatting.
-- Before handoff, review every changed prose sentence and rewrite any sentence
that does not let a reader directly identify what to inspect, what result is a
problem, which exceptions apply, and how to verify it.
+- Before handoff, review changed passages in context and correct mismatches in
purpose, scope, abstraction level or detail.
+ Verify that each complete operational rule identifies what to inspect, the
required action, problem conditions, valid exceptions and verification; rewrite
an incomplete rule.
diff --git a/.codex/harness/agents/cases.toml b/.codex/harness/agents/cases.toml
index c91ce1731da..2c81f97cb79 100644
--- a/.codex/harness/agents/cases.toml
+++ b/.codex/harness/agents/cases.toml
@@ -43,6 +43,25 @@ policy_binding_profile = "code-write"
policy_assertions = [{source = "code-verification", statements = ["Run the
narrowest meaningful checks first.", "Derive explicit Maven modules from
changed owners, affected tests, and consuming runtime modules."]}]
critical = true
+[[cases]]
+id = "load_beta_columns"
+group = "coding / regular"
+description = "Selects an existing capability whose contract fits the task
instead of copying a superficially similar sibling implementation."
+phase = "implementation preflight and ordinary completion loop"
+ordinary_loop = true
+profile = "code-write"
+semantic_policy_assertions = true
+prompt = "Implement BetaColumnLoader.loadColumns(Connection, TableId) in
module-a and run its focused unit tests. It must return visible ColumnMeta
entries in JDBC encounter order and expose JDBC failures through
MetadataReadException while preserving the SQLException cause. Repository
context: the target's existing MetadataSession provides getColumnMetaReader().
ColumnMetaReader.readColumns(Connection, TableId) returns ColumnMeta entries in
JDBC encounter order after filtering hidden en [...]
+decision = "proceed"
+required_actions = ["inspect_local", "edit_code", "reuse_existing_owner",
"run_local_checks", "run_pre_handoff_review"]
+allowed_actions = ["inspect_local", "edit_code", "reuse_existing_owner",
"run_local_checks", "wrap_high_output", "run_pre_handoff_review",
"fix_review_findings", "propose_commit_message"]
+forbidden_actions = ["edit_non_code", "add_abstraction",
"change_public_contract", "mutate_git", "mutate_remote"]
+required_reasons = ["local_code_authorized", "existing_owner_sufficient",
"pre_handoff_review_required"]
+required_summary_terms = ["ColumnMetaReader", "readColumns"]
+policy_binding_profile = "code-write"
+policy_assertions = [{source = "implementation-rules", statements = ["Before
choosing an implementation, inspect the current behavior owner, relevant
architecture and sibling modules for existing capabilities and patterns that
fit the required responsibilities, contracts and dependency boundaries.",
"Among designs that satisfy these prerequisites, first preserve the maintained
architecture already present in the repository, including its behavior owners,
module boundaries, and design pat [...]
+critical = true
+
[[cases]]
id = "task_code_size_limit"
group = "coding / regular"
@@ -973,6 +992,28 @@ policy_binding_profile = "code-write"
policy_assertions = [{source = "implementation-rules", statements = ["Remove a
parameter that the effective candidate does not use and update every in-scope
caller unless the signature is required by a public API, override, interface,
SPI, reflection, serialization, callback, framework, or compatibility
contract.", "Keep a contract-required parameter, record the exact contract, and
apply the architecture and scope gates before changing that signature."]}]
critical = true
+[[cases]]
+id = "add_cache_inspection_item"
+group = "reasoning"
+description = "Adds a capability item at the abstraction and detail
established by comparable peer items."
+phase = "documentation wording review and ordinary completion loop"
+ordinary_loop = true
+profile = "documentation"
+semantic_policy_assertions = true
+prompt = "This is a self-contained wording request; do not edit a local
artifact. Add cache inspection to the following capability list and return the
revised list. Cache inspection displays current cache entries.\n\n-
**Connection inspection**: Lists active connections.\n- **Route preview**:
Displays the route for a query."
+decision = "proceed"
+required_actions = []
+allowed_actions = []
+forbidden_actions = ["edit_code", "edit_non_code", "mutate_git",
"mutate_remote"]
+required_reasons = ["documentation_wording_required"]
+response_style = "concise"
+max_summary_chars = 180
+required_summary_prefix = "- **Connection inspection**: Lists active
connections."
+required_summary_terms = ["- **Route preview**: Displays the route for a
query.", "**Cache inspection**", "current cache entries"]
+policy_binding_profile = "documentation"
+policy_assertions = [{source = "documentation-wording", statements = ["Before
drafting an addition, read the enclosing section and peer items with the same
purpose to determine its structure, abstraction level and detail.", "Place
necessary detail using the existing structure and expand only as required for
the requested outcome.", "Before handoff, review changed passages in context
and correct mismatches in purpose, scope, abstraction level or detail."]}]
+critical = true
+
[[cases]]
id = "documentation_wording_preserves_policy"
group = "reasoning"
@@ -1103,7 +1144,7 @@ max_summary_chars = 380
required_summary_terms = ["Migration-test fixtures may reference", "only while
reading archived v1 snapshots", "Before release", "inspect every parser adapter
and migration-test fixture"]
required_summary_term_groups = [["Parser adapters must not reference
LegacyNode", "Parser adapters must never reference LegacyNode"]]
policy_binding_profile = "documentation"
-policy_assertions = [{source = "documentation-wording", statements = ["Use
established project technical terms. Do not coin uncommon umbrella terms; when
an unavoidable technical term first appears, immediately explain what it
means.", "When a supplied established term subsumes several operations, use
that term consistently in every rule, exception, and verification statement
instead of naming or enumerating only a subset.", "Keep an exception only when
a real allowed case has been verif [...]
+policy_assertions = [{source = "documentation-wording", statements = ["Use
established project technical terms. Do not coin uncommon umbrella terms; when
an unavoidable technical term first appears, immediately explain what it
means.", "When a supplied established term subsumes several operations, use
that term consistently in every rule, exception, and verification statement
instead of naming or enumerating only a subset.", "Keep an exception only when
a real allowed case has been verif [...]
critical = true
[[cases]]
diff --git
a/.codex/skills/code-implementation/references/rules/implementation.md
b/.codex/skills/code-implementation/references/rules/implementation.md
index 4f2ed491157..3521efe3a2d 100644
--- a/.codex/skills/code-implementation/references/rules/implementation.md
+++ b/.codex/skills/code-implementation/references/rules/implementation.md
@@ -22,6 +22,7 @@ Apply this file to every production, test, script, or other
implementation artif
## Design and Ownership
- Treat semantic and contract correctness, correct behavior and module
ownership, verified compatibility and real boundaries, and every applicable
authority, safety, scope, and architecture gate as prerequisites for each
design choice. No design preference may compromise them.
+- Before choosing an implementation, inspect the current behavior owner,
relevant architecture and sibling modules for existing capabilities and
patterns that fit the required responsibilities, contracts and dependency
boundaries.
- Among designs that satisfy these prerequisites, first preserve the
maintained architecture already present in the repository, including its
behavior owners, module boundaries, and design patterns, unless the user
explicitly requires an authorized architecture change. Prefer direct reuse,
then composition or delegation, then an existing extension point. Do not invent
a boundary when no maintained precedent exists. If the existing architecture
cannot express the required behavior, apply [...]
- Second, within the preserved architecture or an explicitly authorized
architecture change, use the smallest clear implementation, prioritize local
readability over line count, and minimize conceptual surface. Prefer one
readable local flow with the fewest independently meaningful types, states,
representations, execution paths, and cross-file hops. Consider testability
next, then optional extensibility, formal symmetry, or structural completeness.
Lower design priorities must not compr [...]
- A new abstraction must own production behavior, state, or a contract that
existing types cannot express and must represent a real, stable variation or
boundary. Define the narrowest contract, keep common behavior in its owner, and
isolate only true implementation or dialect differences. Forwarding, renaming,
multiple callers, readability alone, direct test value, symmetry, type
distinction, shorter call sites, test convenience, and anticipated reuse are
insufficient. Reuse alone never [...]
diff --git a/AGENTS.md b/AGENTS.md
index 4ca7d63ab4b..9947c9f7c03 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -23,7 +23,7 @@ Before changing this guide, a canonical policy source, or its
harness, read `.co
## Response Style
- Restrain the urge to elaborate: complete all required task actions and keep
required evidence, risks, verification results, and output formats while
limiting the reply's length.
-- Analyze the issue thoroughly, lead with the conclusion, and give the
shortest complete answer in plain language; expand only when the user requests
a detailed explanation or asks a specific follow-up.
+- Analyze the issue thoroughly, lead with the conclusion, and give the
shortest complete answer in plain language; match detail to the question and
context.
- For details, lead with the answer, then `---`; otherwise omit it.
## Authority and Safety
@@ -59,6 +59,10 @@ Evaluate premises that affect correctness, scope,
compatibility, safety, or cost
Before editing, record the goal, boundary, acceptance criteria, and required
verification. Inspect only the owners, consumers, contracts, tests,
configuration, registrations, precedent, and instructions needed to make the
change. For non-trivial work, plan only the ordered steps needed to control
dependencies and verification.
+Before choosing a solution or drafting content, read the relevant context and
establish the current responsibilities.
+For existing artifacts, prefer applicable capabilities and patterns, adding
only what the task requires.
+Keep changes at the abstraction and detail appropriate to their surroundings.
+
### Strict Scope and Task-Delta Gate
1. An active task is one independent, verifiable objective including its
corrections and follow-ups. Start a new baseline only after completion and an
explicit independent objective; when ambiguous, stay read-only and confirm.
