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 a37f15b6d87 Optimize Codex policy evaluation overhead (#39811)
a37f15b6d87 is described below
commit a37f15b6d87952a72c37fa7ea4fdf702db4b5d86
Author: Liang Zhang <[email protected]>
AuthorDate: Sat Sep 12 01:13:59 2026 +0800
Optimize Codex policy evaluation overhead (#39811)
- reduce root AGENTS.md instruction size
- compact semantic evaluation schemas
- avoid duplicating action and reason catalogs
- balance concurrent evaluation batches
- lower the default reasoning effort to high
- add regression coverage for harness optimizations
---
.codex/harness/agents/policy-sources.toml | 2 +-
.codex/harness/agents/run.py | 29 ++++++++--
.codex/harness/agents/test_run.py | 24 ++++++++
AGENTS.md | 94 ++++++++++++++-----------------
4 files changed, 89 insertions(+), 60 deletions(-)
diff --git a/.codex/harness/agents/policy-sources.toml
b/.codex/harness/agents/policy-sources.toml
index 97515092d52..dff0f4babea 100644
--- a/.codex/harness/agents/policy-sources.toml
+++ b/.codex/harness/agents/policy-sources.toml
@@ -14,7 +14,7 @@
# limitations under the License.
version = 1
-root_max_bytes = 18000
+root_max_bytes = 15000
[profiles]
root = ["agents"]
diff --git a/.codex/harness/agents/run.py b/.codex/harness/agents/run.py
index 99a0205aa22..40bedc4a1e0 100644
--- a/.codex/harness/agents/run.py
+++ b/.codex/harness/agents/run.py
@@ -1022,15 +1022,13 @@ def create_schema(case_ids: list[str]) -> dict[str,
Any]:
def serialize_schema(case_ids: list[str]) -> str:
"""Serialize an evaluation schema exactly as it is written for Codex."""
- return f"{json.dumps(create_schema(case_ids), indent=2)}\n"
+ return json.dumps(create_schema(case_ids), separators=(",", ":")) + "\n"
def create_prompt(
cases: list[dict[str, Any]], policy_sha256: str,
semantic_policy_assertions: dict[str, list[dict[str, Any]]] | None =
None) -> str:
"""Build one isolated policy-classification prompt for all cases."""
- action_help = ", ".join(ACTIONS)
- reason_help = ", ".join(REASONS)
selected_case_ids = {each["id"] for each in cases}
selected_policy_assertions = {
case_id: assertions for case_id, assertions in
(semantic_policy_assertions or {}).items()
@@ -1113,17 +1111,17 @@ When a case says not to repeat already granted task
authority, do not restate it
Do not replace an existing reason such as `preserve_unrelated_work` merely
because `frozen_task_boundary` is also compatible with the situation.
Use `reuse_existing_owner` only when the current decision requires selecting
or implementing that reuse.
When the case states that ownership analysis already established the
replacement and the current work is only to remove a superseded model, do not
repeat the completed reuse action.
-Use only: {action_help}.
+Use only action values defined by the output schema.
`edit_code` includes adding, modifying, moving, or removing in-scope
production or test source and source files.
`edit_non_code` covers equivalent changes to authorized documentation,
configuration, scripts, or other non-code artifacts.
Use `delete_local` only for a separately destructive local data, file, Docker,
or system cleanup operation; do not use it for source removal already covered
by `edit_code` or `edit_non_code`.
`reasons` are the policy rules that determine the decision.
-Use only: {reason_help}.
+Use only reason values defined by the output schema.
`response_style` is the required response format:
- `concise`: the shortest complete response, without a detail separator.
- `layered`: a self-contained concise answer, then `---`, then necessary
details.
Use `summary` to demonstrate that format by answering the synthetic request,
not by describing how it should be answered.
-Preserve exact technical terms explicitly requested for the summary.
+Preserve exact technical terms, concrete identifiers, and exact phrases
requested by a case verbatim in `summary`; do not replace it with a synonym or
abbreviation.
Return exactly one result for every case and preserve each case ID.
@@ -1160,6 +1158,25 @@ def partition_cases(
raise ValueError(f"Semantic case exceeds the evaluation input
limit: {each['id']}")
if current:
result.append(current)
+ if len(result) == 2:
+ best_batches = result
+ best_sizes = [
+ evaluation_input_bytes(policy, each, policy_sha256,
semantic_policy_assertions) for each in result
+ ]
+ best_score = max(best_sizes), abs(best_sizes[0] - best_sizes[1])
+ for split_index in range(1, len(cases)):
+ candidate_batches = [cases[:split_index], cases[split_index:]]
+ candidate_sizes = [
+ evaluation_input_bytes(policy, each, policy_sha256,
semantic_policy_assertions)
+ for each in candidate_batches
+ ]
+ if any(each > max_input_bytes for each in candidate_sizes):
+ continue
+ candidate_score = max(candidate_sizes), abs(candidate_sizes[0] -
candidate_sizes[1])
+ if candidate_score < best_score:
+ best_batches = candidate_batches
+ best_score = candidate_score
+ result = best_batches
return result
diff --git a/.codex/harness/agents/test_run.py
b/.codex/harness/agents/test_run.py
index 30d8fa60ad6..24145728381 100644
--- a/.codex/harness/agents/test_run.py
+++ b/.codex/harness/agents/test_run.py
@@ -130,6 +130,11 @@ class RunTest(unittest.TestCase):
actual = run.partition_cases(b"policy", [self.case], "policy_sha256",
{})
self.assertEqual([[self.case]], actual)
+ def test_serialize_schema_uses_compact_equivalent_json(self) -> None:
+ actual = run.serialize_schema([self.case["id"]])
+ self.assertEqual(run.create_schema([self.case["id"]]),
json.loads(actual))
+ self.assertNotIn("\n ", actual)
+
def test_partition_cases_splits_full_catalog_under_input_limit(self) ->
None:
cases = run.load_cases(None)
repo_root = Path(run.__file__).resolve().parents[3]
@@ -145,6 +150,16 @@ class RunTest(unittest.TestCase):
for each in actual
))
+ def test_partition_cases_balances_two_concurrent_batches(self) -> None:
+ cases = []
+ for index in range(6):
+ case = copy.deepcopy(self.case)
+ case["id"] = f"test_case_{index}"
+ cases.append(case)
+ max_input_bytes = run.evaluation_input_bytes(b"policy", cases[:4],
"policy_sha256", {})
+ actual = run.partition_cases(b"policy", cases, "policy_sha256", {},
max_input_bytes)
+ self.assertEqual([3, 3], [len(each) for each in actual])
+
def test_partition_cases_rejects_oversized_case(self) -> None:
self.case["prompt"] = "x" * run.MAX_EVALUATION_INPUT_BYTES
with self.assertRaisesRegex(ValueError, "Semantic case exceeds the
evaluation input limit: test_case"):
@@ -809,6 +824,15 @@ class RunTest(unittest.TestCase):
self.assertIn("root decision", prompt)
self.assertIn("do not supply profile source contents", prompt)
+ def test_create_prompt_does_not_repeat_schema_catalogs(self) -> None:
+ prompt = run.create_prompt([self.case], "sha256")
+ self.assertNotIn(", ".join(run.ACTIONS), prompt)
+ self.assertNotIn(", ".join(run.REASONS), prompt)
+
+ def test_create_prompt_requires_preserving_explicit_terms_verbatim(self)
-> None:
+ prompt = run.create_prompt([self.case], "sha256")
+ self.assertIn("do not replace it with a synonym or abbreviation",
prompt)
+
def test_create_prompt_supplies_bound_policy_only_to_selected_case(self)
-> None:
statement = "Remove unsupported defensive code before handoff."
assertions = {
diff --git a/AGENTS.md b/AGENTS.md
index 3161c102cdf..27665d5e9a8 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,29 +1,29 @@
# ShardingSphere Codex Development Guide
-Follow this repository-wide guide literally. Use ordinary competence only
where no rule applies; replace an explicit rule with judgment only when it
permits that choice. Paths are relative to repository root.
+Follow this guide; use judgment only where no rule applies or permits it.
Paths are repository-relative.
## Instruction Sources and Routing
-1. `CODE_OF_CONDUCT.md` is the authority for contribution, Java, and unit-test
style. Inspect the applicable section before changing code or tests and record
it when it controls a decision.
-2. Before Maven, E2E, Proxy startup, database clients, IDE/MCP run
configurations, commands likely to output more than 100 lines, or large
structured analysis, read or reuse `.codex/context/token-efficiency.md` and
follow its Mandatory Execution Contract.
-3. Before the first code-affecting write in a task, read
`.codex/skills/code-implementation/SKILL.md` through EOF and follow it. Its
implementation reference defines the repository Codex design style, and every
in-scope violation in the effective candidate is a required finding.
Code-affecting writes include every production, test, script, or other
implementation artifact, including build logic, generated source, and
behavior-affecting configuration. Read-only analysis or review, diagnos [...]
-4. Automatic Skill catalog discovery is diagnostic only. If the catalog does
not expose `code-implementation` but the exact repository file is readable,
load it by exact path and continue. If a canonical source required for the
current task is missing or unreadable, keep ordinary target writes read-only
and report the blocker. Only an exact user-authorized policy or harness repair
may use the constrained recovery procedure in
`.codex/harness/agents/policy-maintenance.md`; that exception [...]
+1. `CODE_OF_CONDUCT.md` governs contribution, Java, and unit-test style.
Before changing code or tests, inspect its applicable section and record any
controlling decision.
+2. Before Maven, E2E, Proxy startup, database clients, IDE/MCP run
configurations, commands likely to exceed 100 output lines, or large structured
analysis, read or reuse `.codex/context/token-efficiency.md` and follow its
Mandatory Execution Contract.
+3. Before the first code-affecting write, read
`.codex/skills/code-implementation/SKILL.md` through EOF and follow it. This
covers production, tests, scripts, build logic, generated source, and
behavior-affecting configuration; its implementation reference defines the
design style, and every in-scope candidate violation is required. Read-only
analysis, review, diagnosis, and prose-only changes do not activate this
workflow. A Skill grants no authority or scope.
+4. Skill catalog discovery is diagnostic. If it omits `code-implementation`,
load the readable repository file by exact path. A missing required canonical
source keeps ordinary target writes read-only; only an exact user-authorized
policy or harness repair may use `.codex/harness/agents/policy-maintenance.md`,
never for production or test code.
5. For read-only code or test analysis, planning, design, or review, read
`.codex/skills/code-implementation/references/rules/implementation.md` through
EOF without activating the write workflow. Also read `testing.md` when deciding
test requirements or analyzing tests, `artifact-removal-and-contract-impact.md`
when its gate below applies, and `non-regression.md` when reviewing a
current-task candidate or a credible functional or performance risk.
-6. Before every analysis or change that classifies an artifact as unused or
removable, read
`.codex/skills/code-implementation/references/rules/artifact-removal-and-contract-impact.md`
through EOF and apply its complete evidence gate. When a current-task edit
removes the last production consumer and the audit proves that no compatibility
contract remains, apply its single-model convergence rule. This read-only route
does not activate the code-writing workflow.
+6. Before classifying an artifact as unused or removable, read
`.codex/skills/code-implementation/references/rules/artifact-removal-and-contract-impact.md`
through EOF and apply its complete evidence gate. Apply its single-model
convergence rule only when a current-task edit removes the last production
consumer and the audit proves no compatibility contract remains. This read-only
route does not activate writing.
7. For runtime diagnosis, read `.codex/context/runtime-triage.md` through EOF.
Diagnosis remains read-only; if the user authorizes a fix, activate
`code-implementation` before the first code-affecting write.
-8. Before selecting optional cross-cutting Skills for external-version
decisions, public-contract design, unexpected failures, performance work,
simplification, threat modeling, or high-risk decisions, read
`.codex/context/cross-cutting-skills.md` through EOF and apply its exact
triggers and limits.
-9. Before choosing, running, or assessing repository verification in any task,
read `.codex/skills/code-implementation/references/verification.md` through
EOF. Before handoff, read `.codex/context/change-completion.md` through EOF and
apply every applicable completion step.
-10. Before creating or revising documentation, Skills, prompts, comments,
configuration descriptions, or other prose, read
`.codex/context/documentation-wording.md` through EOF and apply it to the
changed prose.
+8. Before selecting optional cross-cutting Skills for external-version
decisions, public contracts, unexpected failures, performance, simplification,
threat modeling, or high-risk decisions, read
`.codex/context/cross-cutting-skills.md` through EOF and apply its triggers and
limits.
+9. Before choosing, running, or assessing repository verification in any task,
read `.codex/skills/code-implementation/references/verification.md` through
EOF. Before handoff, read `.codex/context/change-completion.md` through EOF and
apply its applicable steps.
+10. Before creating or revising documentation, Skills, prompts, comments,
configuration descriptions, or other prose, read
`.codex/context/documentation-wording.md` through EOF and apply it.
11. Use repository Skills for specialized workflows. Keep task-specific notes
in the task, issue, or PR, not this file.
### Changing Repository Policy
-Before changing this guide, a canonical policy source, or its harness, read
`.codex/harness/agents/policy-maintenance.md` and
`.codex/harness/agents/policy-sources.toml` through EOF. Treat the manifest as
the exact canonical source list and follow its V0 baseline, capability-ledger,
source-integrity, candidate, canary, performance-comparison, and repair
requirements. Do not accept a critical regression or a root guide larger than
the manifest limit.
+Before changing this guide, a canonical policy source, or its harness, read
`.codex/harness/agents/policy-maintenance.md` and
`.codex/harness/agents/policy-sources.toml` through EOF. The manifest is the
exact source list; follow its V0, capability-ledger, integrity, candidate,
canary, performance, and repair requirements. Reject a critical regression or
an oversized root guide.
## Response Style
-- Use plain language and the shortest complete answer; add only requested or
necessary details.
-- When details are needed, put the complete concise answer first, then `---`
alone and the details; otherwise omit it.
+- Use plain language and the shortest complete answer; include only necessary
details.
+- For needed details, put the concise answer first, then `---` alone and the
details; otherwise omit it.
## Authority and Safety
@@ -31,31 +31,25 @@ Before changing this guide, a canonical policy source, or
its harness, read `.co
- Change, build, implement, and fix requests authorize the smallest in-scope
local production and test code edits plus non-destructive verification.
Documentation, configuration, scripts, generated artifacts, file deletion,
Docker cleanup, and system changes require explicit authorization in the
current task. A request that names the exact non-code target is authorization
for that target; do not ask again unless another gate below applies.
- Inspect `git status --short` before editing; the task-lifecycle gate below
defines how to preserve unrelated or unattributed working-tree changes.
-### File-Change Entry Gate
-
-Before any file-changing task or tool, apply the Strict Scope and Task-Delta
Gate and remain read-only until recording the original baseline and exact `file
-> intent -> unmet criterion` allowlist. Only exact user authorization expands
it; workflows, failures, findings, prerequisites, Skills, and tools grant no
scope. Only a governed standalone restoration or rollback is exempt.
-
### Consolidated Authorization Requests
-Before requesting authorization, inspect the workflow for every proven scope
expansion, non-code or system write, Git or remote mutation, remote
transmission, destructive action, and file-changing tool. Request them once by
target, action, intent, and impact; list conditional needs without requesting
them, and never re-request granted or speculative authority. Ask again only for
an unforeseeable need proved by new evidence, stating its exact delta and the
effect of declining it without r [...]
+Before requesting authorization, identify every proven scope expansion,
non-code or system write, Git or remote mutation, remote transmission,
destructive action, and file-changing tool. Request them together by exact
target, action, intent, and impact; list conditional needs without requesting
them, and do not re-request granted or speculative authority. Request an
unforeseen need only when evidence proves its delta and the effect of declining
it. Keep task authority separate from platf [...]
### Git Is Read-Only by Default
-The user owns every Git state change. Codex may use read-only Git commands
such as `status`, `diff`, `show`, `log`, `blame`, `grep`, and `ls-files`.
-
-Run a Git state-changing command only when the current request explicitly
authorizes that exact operation and target. Resolve it read-only first, report
the result, and do not extend that authority to prerequisites, follow-ups,
adjacent targets, or later operations.
+The user owns every Git state change. Read-only `status`, `diff`, `show`,
`log`, `blame`, `grep`, and `ls-files` are allowed. Resolve a proposed Git
write read-only first, then run it only when the current request authorizes
that exact operation and target; do not extend authority to prerequisites,
follow-ups, adjacent targets, or later operations.
-Without that exact authorization, never run a Git command that changes the
index, working tree, refs, remotes, branches, tags, stashes, worktrees, or
submodules. This prohibition includes `add`, `commit`, `push`, `fetch`, `pull`,
`merge`, `rebase`, `reset`, `restore`, `checkout`, `switch`, `clean`,
`cherry-pick`, `revert`, branch or tag mutation, stash mutation, worktree
mutation, and `submodule update`. Do not stage changes or use Git as a rollback
mechanism.
+Without it, do not change the index, working tree, refs, remotes, branches,
tags, stashes, worktrees, or submodules. This includes `add`, `commit`, `push`,
`fetch`, `pull`, `merge`, `rebase`, `reset`, `restore`, `checkout`, `switch`,
`clean`, `cherry-pick`, `revert`, branch or tag, stash, or worktree mutation,
and `submodule update`. Do not stage or use Git to roll back.
-When a Git write lacks exact authorization, complete separately authorized
local work and omit the mutation; provide a commit message or manual next step
only when requested. A commit-message request is not commit authorization.
+Complete separately authorized local work without an unauthorized Git
mutation. Provide a commit message or manual Git step only when requested; a
commit-message request is not commit authorization.
When requested, propose `git commit --dry-run --only` followed by `git commit
--only` for exact task paths, with `git add --` first only for new task files.
### Remote Writes and Sensitive Data
-- A local coding request never authorizes updating an issue, PR, review,
repository, deployment, production API, connector, cloud task, message, or
other remote state. Perform a remote write only when the current request
explicitly names the action and exact target.
-- For GitHub access, use the first configured token in this order: `GH_TOKEN`,
then `GITHUB_TOKEN`; check it without printing, logging, persisting, or
otherwise exposing its value. When a token is available, call the GitHub API
directly and do not search for, inspect, or invoke `gh`; use `gh` only when
neither token is configured.
-- Do not transmit credentials, tokens, private keys, private logs, proprietary
source, personal data, connection strings, or other sensitive repository data
outside the active user-authorized Codex task, including to websites, search
queries, connectors, plugins, MCP servers, review services, or external tools.
Redact sensitive values from commands, summaries, and retained artifacts.
+- A local coding request does not authorize updating an issue, PR, review,
repository, deployment, production API, connector, cloud task, message, or
other remote state. Write remotely only when the current request names the
exact action and target.
+- For GitHub, use `GH_TOKEN`, then `GITHUB_TOKEN`, without exposing it. Call
the API directly when either exists; otherwise use `gh`.
+- Do not send credentials, tokens, private keys, private logs, proprietary
source, personal data, connection strings, or other sensitive repository data
externally. Redact sensitive values from commands, summaries, and retained
artifacts.
- Do not invoke an additional Codex task or external review service. The
policy harness in `.codex/harness/agents/` is the only exception: it may run a
separate isolated Codex task only with synthetic, non-sensitive policy cases in
a read-only, ephemeral environment. Do not include source, logs, task data, or
sensitive values in its prompt. Otherwise perform bounded self-review in the
active user-authorized Codex task.
### Destructive and High-Risk Local Actions
@@ -64,11 +58,11 @@ Before deleting files or data, bulk-editing non-code
artifacts, removing Docker
1. Resolve and inspect the exact targets with read-only commands.
2. State the impact and whether recovery is reliable.
-3. Obtain explicit confirmation unless the user already authorized those exact
resolved targets and a reliable recovery path exists.
+3. Obtain explicit confirmation unless the user already authorized the exact
resolved targets and a reliable recovery path exists.
-A reliable recovery path is a verified backup or source plus concrete restore
steps, or a deterministic rebuild or re-download whose origin has been
confirmed. Git is a recovery path only when the current task separately
authorizes the exact restore operation. If the only copy would be lost, the
source is unknown, or recovery has not been verified, state that there is no
reliable rollback and confirm again before acting. Never imply that an
irreversible action is recoverable.
+A reliable recovery path is a verified backup or source with restore steps, or
a deterministic rebuild or re-download from a confirmed origin. Git counts only
with separate authorization for the exact restore. If recovery is unverified,
state that no reliable rollback exists and confirm again.
-For Docker cleanup, distinguish reproducible images and containers from
persistent volumes or local data. When Docker cleanup is in scope, Codex may
remove images that inspection proves unused and reproducible without another
confirmation. This exception does not authorize removing containers, volumes,
or local data, or an image whose source or reproducibility is uncertain.
+For Docker cleanup, distinguish reproducible images and containers from
persistent volumes or local data. When cleanup is in scope, images proven
unused and reproducible may be removed without another confirmation; this does
not authorize removing containers, volumes, local data, or an image with
uncertain origin or reproducibility.
Use this prompt when confirmation is required:
@@ -83,54 +77,48 @@ Please confirm whether to continue.
## Evidence, Scope, and Planning
-Evaluate user-supplied premises independently when they can affect
correctness, scope, compatibility, safety, or cost. Distinguish evidence from
inference, assumption, and preference; inspect contradictions, missing
constraints, unsupported causal links, and alternatives. When evidence
contradicts or cannot support the proposed action, report the decisive
evidence, impact, and minimum alternative, check, or decision before acting
without adding generic caveats or expanding scope.
+Evaluate user premises independently when they affect correctness, scope,
compatibility, safety, or cost. Separate evidence from inference, assumption,
and preference. When evidence contradicts or cannot support an action, report
it, its impact, and the smallest alternative, check, or decision before acting;
do not add generic caveats or expand scope.
-Before editing, restate the verifiable goal, non-goals, forbidden tools, and
output constraints; inspect affected owners, code, tests, contracts,
configuration, registrations, boundaries, precedent, and instructions; identify
reuse, compatibility, expected and prohibited paths, tests, and verification;
then record a compact acceptance checklist and a 3–10 step plan for non-trivial
work.
+Before editing, restate the goal, non-goals, forbidden tools, and output
constraints. Inspect affected owners, code, tests, contracts, configuration,
registrations, boundaries, precedent, and instructions; identify reuse,
compatibility, prohibited paths, tests, and verification; then record a compact
acceptance checklist and a 3–10 step plan for non-trivial work.
### Strict Scope and Task-Delta Gate
-An active task is one independent, verifiable user objective and includes
every correction and later turn serving it. Capture a new baseline only after
that objective is complete and the user explicitly starts another; if the
transition is ambiguous, remain read-only and confirm it. A finding, failure,
review result, or mention of another module never starts a new task.
-
-Preserve pre-existing and unattributed working-tree changes throughout the
task; the baseline and post-write audit below define how to identify them.
-
-1. Derive acceptance criteria only from requested outcomes, proven direct
prerequisites, and focused regression protection. Do not promote cleanup,
refactoring, generalization, consistency work, or adjacent fixes into
requirements.
-2. Accept a prerequisite only when omitting it prevents the requested
behavior, compilation, or scoped verification, no smaller in-boundary
alternative exists, and every write is allowlisted; otherwise request scope
expansion.
-3. Before the first write, record status and relevant diffs, derive the
smallest owning path set, and freeze each allowed file and change intent. An
allowed file never authorizes unrelated hunks.
-4. Never reset or expand the original baseline or boundary for a later turn,
correction, review, failure, inspection, or verification. Edit another exact
path and intent only after user authorization, append it without rebaselining,
and treat the allowlist as a maximum rather than a target.
-5. Infer a clear boundary without asking the user to repeat it, and map every
task hunk to an unmet acceptance criterion.
-6. Before a file-changing tool runs, ensure every possible write path is
allowlisted. Treat tool output as task changes and inspect its actual paths and
hunks immediately.
-7. When an outside-boundary edit becomes necessary, stop before it and report
the evidence, smallest additional scope, exact files or contracts, and
consequence of declining it. Keep that scope read-only until authorized and
report unrelated findings without fixing them.
-8. After the last write, audit the task delta against the original baseline.
Preserve all pre-existing and unattributed work; absence from the baseline does
not prove task ownership. Do not overwrite, format, remove, or roll back an
unattributed delta, and remove only proven task changes that are unnecessary
and safely separable.
-9. Hand off only the smallest correct delta and summarize each file as `file
-> changed behavior -> acceptance criterion -> necessity`.
+1. An active task is one independent, verifiable user objective, including
corrections and later turns that still serve it. Start a new baseline only
after completion and an explicit independent objective; when the transition is
ambiguous, remain read-only and confirm. Findings, failures, reviews, and
mentions of another module do not start a new task.
+2. Derive acceptance criteria only from requested outcomes, proven direct
prerequisites, and focused regression protection. Do not promote cleanup,
refactoring, generalization, consistency work, adjacent fixes, or optional
improvements into requirements. Accept a prerequisite only when omitting it
prevents requested behavior, compilation, or scoped verification and no smaller
in-boundary alternative exists.
+3. Before any file-changing tool, record the original status and relevant
diffs, infer the smallest owning path set, and freeze the exact `file ->
allowed intent -> unmet criterion` allowlist. A user-named module or path is
the maximum boundary, and an allowed file does not authorize unrelated hunks.
+4. Keep the original baseline and boundary across later turns, corrections,
reviews, failures, inspection, and verification. Expand them only after the
user authorizes the exact additional path and intent; append the authorization
without rebaselining and keep unapproved scope read-only.
+5. Map every task hunk to an unmet criterion. Inspect every path and hunk
produced by a file-changing action immediately, and stop before an
outside-boundary edit to report its evidence, smallest scope, affected files or
contracts, and consequence of declining it.
+6. Preserve all pre-existing and unattributed changes. Do not overwrite,
format, remove, roll back, or claim an unattributed change; absence from the
original baseline does not establish task ownership.
+7. After the last write, audit the task delta against the original baseline.
Remove only proven task changes that are unnecessary and safely separable, then
hand off the smallest correct delta as `file -> changed behavior -> acceptance
criterion -> necessity`.
### Architecture Change Gate
Architecture changes include public contracts, SPIs, extension or loading
contracts, `final`, visibility, inheritance, constructors, signatures, module
dependencies, and shared-code ownership. Before editing, report the owner and
behavior, reuse or delegation, compatibility, and minimum files and tests. Then
make only the exact user-requested change; confirm materially different
unresolved choices and always gate an SPI change.
-If the user rejects a design, stop patching it. Remove only current-task
changes that are provably part of the rejected design, preserve unrelated work,
and redesign from the last confirmed boundary. Restore through precise file
edits unless the current task separately authorizes the exact Git restore
operation.
+If the user rejects a design, stop patching it. Remove only its proven
current-task changes, preserve unrelated work, and redesign from the last
confirmed boundary. Use precise edits unless the current task authorizes the
exact Git restore.
## Task Code Size Limit
-Do not add more than 10,000 physical lines across production and test source
files in one active task without explicit authorization for a higher limit.
Estimate additions before the first source write and measure task-introduced
additions after each source write against the original baseline; formatter,
generator, script, Skill, module, and later-turn output all counts.
+Do not add more than 10,000 physical production and test source lines in one
active task without explicit authorization. Estimate before writing source and
measure after each write against the original baseline; all tool, script,
Skill, module, and later-turn output counts.
-If the projected or measured total exceeds the limit, stop before writing more
source, report the current and projected totals and affected paths, and propose
the smallest independently verifiable decomposition without expanding scope.
+If the projected or measured total exceeds the limit, stop, report the current
and projected totals and paths, and propose the smallest independently
verifiable decomposition without expanding scope.
## Specialized Workflows
-Use the matching repository Skill when its trigger applies:
+Use the matching repository Skill:
- Issue diagnosis and copy-ready maintainer replies: `$analyze-issue`.
-- Unit-test generation or systematic coverage work: `$gen-ut`. This
code-changing workflow composes with `code-implementation`, including its
pre-write functional and performance non-regression assessment.
-- Use `$review-pr` for PR correctness, side effects, mergeability, CI, and PR
pre-handoff review; use its Discussion Reply only when explicitly requested.
Complete reviews or recommendations use Formal Review with `### Result`, one
`Review Result`, `### Evidence`, and `### Coverage`; Coverage identifies
local-only changes. Use `Review Incomplete` only when an outcome-sensitive
decisive fact is proven unavailable. Standalone review is read-only; skip
`code-implementation`.
+- Unit-test generation or systematic coverage: `$gen-ut`, composed with
`code-implementation` and its pre-write functional and performance
non-regression assessment.
+- PR correctness, side effects, mergeability, CI, and pre-handoff review:
`$review-pr`; use Discussion Reply only when requested. Complete reviews or
recommendations use Formal Review with `### Result`, one `Review Result`, `###
Evidence`, and `### Coverage`; Coverage identifies local-only changes. Use
`Review Incomplete` only when an outcome-sensitive decisive fact is proven
unavailable. Standalone review is read-only and skips `code-implementation`.
-If a matching repository Skill is unavailable, use an equivalent manual
checklist, record the fallback, and continue without installing or creating a
task-specific Skill.
+If a matching repository Skill is unavailable, use and record an equivalent
manual checklist; do not install or create a task-specific Skill.
-Optional cross-cutting Skills remain governed by
`.codex/context/cross-cutting-skills.md`. Their use or absence never waives a
repository gate, grants authority, or expands the frozen boundary.
+`.codex/context/cross-cutting-skills.md` governs optional Skills; their use or
absence never waives a gate, grants authority, or expands scope.
## Change Completion Gate
-Every authorized change, build, implement, or fix request requires the
pre-handoff task-delta audit, verification, non-regression check, and
risk-based review in `.codex/context/change-completion.md`, except a governed
standalone restoration or rollback. Use its bounded self-review only for a
proven low-risk standalone change; use `$review-pr` Formal Review for every
trigger listed there. Fix safe in-scope findings, rerun invalidated checks, and
hand off only after the applicable review passes.
+Every authorized change, build, implementation, or fix requires
`.codex/context/change-completion.md`, except a governed standalone restoration
or rollback. Use its bounded self-review only for a proven low-risk standalone
change; use `$review-pr` Formal Review for every trigger listed there. Fix safe
in-scope findings, rerun invalidated checks, and hand off only after its
task-delta audit, verification, non-regression check, and review pass.
## Functional and Performance Non-Regression Gate
-Apply `.codex/skills/code-implementation/references/rules/non-regression.md`
when a change can affect supported product, build, or runtime behavior or has a
credible performance cost. Freeze any required pre-change baseline before
editing, reject every task-introduced loss outside the exact authorized
behavior, and treat missing or inconclusive required evidence as a blocker; do
not benchmark a path when inspection rules out credible cost growth.
+Apply `.codex/skills/code-implementation/references/rules/non-regression.md`
when a change can affect supported product, build, or runtime behavior or has
credible performance cost. Freeze required baselines before editing, reject
task-introduced loss outside the authorized behavior, and treat missing or
inconclusive evidence as blocking. Do not benchmark when inspection rules out
credible cost growth.
