Add release notes

.agents/skills/issue-spec-apply/SKILL.md

@@ -1,35 +0,0 @@
----
-name: issue-spec-apply
-description: Implement PROCESS comments for an issue-spec change and keep PR traceability synchronized.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Apply
-
-Use when the user asks for /issue-spec:apply, issue-spec apply, or implementing PROCESS/TASK scopes from an issue-spec change.
-
-## Steps
-
-1. Read proposal/design/implement issue context and list typed comments with issue-spec comment list --json.
-2. Confirm issue-spec auth status --json includes the expected GitHub backend. Local gh-authenticated sessions can use the native gh backend; keep ISSUE_SPEC_TOKEN="$(gh auth token)" only as an older-version or forced-rest compatibility path.
-3. Create or update PROCESS comments with owner agent, scope, dependencies, write ownership, and status.
-4. Split non-trivial work into independent worker PROCESS nodes when file/module ownership does not overlap; execute independent workers in parallel when available.
-5. Add dedicated review PROCESS nodes for non-trivial changes. Review PROCESS nodes should own review scopes such as CLI/API behavior, workflow docs, tests, compatibility, or security-sensitive surfaces.
-6. Link each PROCESS to its TASK comments with issue-spec link.
-7. Implement the code changes for one PROCESS scope at a time, or integrate completed worker outputs by dependency order.
-8. Link every worker and review PROCESS to the PR with issue-spec pr link-process.
-9. Add PR rationale comments on key changed lines with issue-spec pr rationale, each linked to a SPEC comment.
-10. Mark PROCESS comments done only after implementation/review work and focused verification evidence exist.
-
-## Coordinator DAG Execution
-
-1. Build the ready set from PROCESS nodes whose dependencies are done.
-2. Keep immediate blocking work local when the next step depends on it.
-3. Spawn or assign independent worker agents only when their write ownership is disjoint.
-4. Spawn or assign independent review agents only when their review scopes are disjoint.
-5. Integrate completed outputs by dependency order and update PROCESS evidence before marking done.

.agents/skills/issue-spec-archive/SKILL.md

@@ -1,24 +0,0 @@
----
-name: issue-spec-archive
-description: Create the post-merge durable spec archive PR for an issue-spec change.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Archive
-
-Use when the user asks for /issue-spec:archive, issue-spec archive, or creating the post-merge durable spec PR.
-
-## Steps
-
-1. Confirm the implementation PR is merged.
-2. Create the durable spec PR:
-
-       issue-spec archive durable-spec --repo higress-group/higress --proposal <issue> --capability <capability> --create-pr --branch issue-spec/durable-spec-<capability> --json
-
-3. Review the durable spec PR for long-lived behavior only. Do not copy process records, review findings, or verification logs into durable specs.
-4. After durable spec PR merge, keep proposal/design/implement issues as audit history unless the project policy says to close them.

.agents/skills/issue-spec-github/SKILL.md

@@ -1,58 +0,0 @@
----
-name: issue-spec-github
-description: Use GitHub CLI for GitHub issues, pull requests, CI runs, and API queries that issue-spec does not wrap.
-license: MIT
-compatibility: Requires GitHub CLI (gh).
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# GitHub CLI
-
-Use the `gh` CLI to interact with GitHub repositories, issues, pull requests, CI, and API endpoints.
-
-## When To Use
-
-- Checking PR status, reviews, mergeability, or CI checks.
-- Creating, viewing, updating, closing, or commenting on GitHub issues.
-- Listing or inspecting pull requests, workflow runs, releases, labels, or repository metadata.
-- Calling GitHub API endpoints with `gh api` when issue-spec does not provide a dedicated command.
-
-## When Not To Use
-
-- Local git operations such as commit, branch, fetch, merge, or push. Use `git` directly.
-- Non-GitHub repositories. Use the matching provider CLI instead.
-- Complex code review across local diffs. Read the repository files directly and use issue-spec review commands for traceable findings.
-
-## Setup
-
-```bash
-gh auth login
-gh auth status
-```
-
-## Common Commands
-
-```bash
-gh issue list --repo owner/repo --state open
-gh issue view 42 --repo owner/repo --json number,title,state,url,body
-gh issue comment 42 --repo owner/repo --body "Comment body"
-
-gh pr list --repo owner/repo
-gh pr view 17 --repo owner/repo --json number,title,state,headRefName,baseRefName,url
-gh pr checks 17 --repo owner/repo
-
-gh run list --repo owner/repo --limit 10
-gh run view <run-id> --repo owner/repo --log-failed
-
-gh api repos/owner/repo/labels --jq '.[].name'
-```
-
-## Notes
-
-- Always pass `--repo owner/repo` when the current directory is not definitely inside the target repository.
-- Use GitHub URLs directly when convenient, for example `gh pr view https://github.com/owner/repo/pull/17`.
-- Prefer structured output with `--json` and `--jq` when another command or agent step consumes the result.
-- issue-spec owns the proposal, design, implement, typed comment, review, verify, and archive workflow state. Use `gh` for adjacent GitHub operations that are outside issue-spec's command surface.

.agents/skills/issue-spec-propose/SKILL.md

@@ -1,37 +0,0 @@
----
-name: issue-spec-propose
-description: Create or continue proposal, SPEC, QUESTION, design, and TASK artifacts for an issue-spec change.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Propose
-
-Use when the user asks for /issue-spec:propose, issue-spec propose, creating a change proposal, drafting SPEC comments, or preparing design/tasks after questions converge.
-
-## Steps
-
-1. Create the proposal issue:
-
-       issue-spec issue create proposal --repo higress-group/higress --change <change-name> --body-file <proposal.md>
-
-2. If the proposal body needs revision after discussion, update it in place:
-
-       issue-spec issue update --repo higress-group/higress --issue <proposal-issue> --body-file <proposal.md> --summary "<what changed>"
-
-3. Add SPEC comments with issue-spec comment upsert --type SPEC. SPEC comments must use MUST/SHALL and WHEN/THEN scenarios.
-4. Add QUESTION comments for unresolved behavior with issue-spec question create and resolve blocking questions before design.
-5. Create the design issue after SPEC/QUESTION convergence:
-
-       issue-spec issue create design --repo higress-group/higress --change <change-name> --proposal <proposal-issue-or-url> --body-file <design.md>
-
-6. Add TASK comments with issue-spec comment upsert --type TASK and link every TASK to covered SPEC comments with issue-spec link.
-7. Create the implement issue once tasks are ready:
-
-       issue-spec issue create implement --repo higress-group/higress --change <change-name> --proposal <proposal-issue-or-url> --design <design-issue-or-url> --body-file <implement.md>
-
-8. Run issue-spec verify-links and fix missing backlinks before implementation.

.agents/skills/issue-spec-review/SKILL.md

@@ -1,32 +0,0 @@
----
-name: issue-spec-review
-description: Review an issue-spec implementation PR, create PR line findings, reply after fixes, and sync REVIEW comments.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Review
-
-Use when the user asks for /issue-spec:review, issue-spec review, or a PR review gate for an issue-spec implementation.
-
-## Steps
-
-1. Run issue-spec review sync --repo higress-group/higress --pr <number> --implement <issue> --id REVIEW-<n> --json to capture current rationale comments, findings, and checks.
-2. For non-trivial PRs, spawn or assign dedicated review agents as review PROCESS owners. Multiple review agents can run in parallel when their review scopes are independent.
-3. Give each review agent a concrete scope and expected output: actionable findings only, severity, file/line, linked SPEC, owner PROCESS, and suggested fix.
-4. Create actionable PR line findings with issue-spec review finding. Use P0/P1 for blockers and P2 for non-blocking follow-up.
-5. Assign every finding to a PROCESS owner. If no findings are found, record that result in REVIEW or VERIFY evidence.
-6. After the worker fixes a finding, reply to the original thread with issue-spec review reply --status resolved.
-7. Re-run review sync. P0/P1 findings must be resolved before final verify/archive.
-
-## Review DAG Policy
-
-1. Every non-trivial PR should have at least one dedicated review PROCESS node before final verify.
-2. Use multiple review agents in parallel when scopes are independent, for example CLI/API behavior, workflow docs, tests, compatibility, or security-sensitive surfaces.
-3. A review agent reports findings only; the coordinator converts actionable line findings into issue-spec review finding comments.
-4. P0/P1 findings block final verify until the owner PROCESS fixes them and issue-spec review reply records the resolution on the original thread.
-5. If a review agent finds no issues, record that result in REVIEW or VERIFY evidence before marking the review PROCESS done.

.agents/skills/issue-spec-verify/SKILL.md

@@ -1,28 +0,0 @@
----
-name: issue-spec-verify
-description: Run final issue-spec verification across traceability, questions, review findings, PR rationale, PR checks, and durable spec draft.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Verify
-
-Use when the user asks for /issue-spec:verify, issue-spec verify, or final readiness evidence before merge/archive.
-
-## Steps
-
-1. Run focused project tests and record evidence in VERIFY comments.
-2. Run issue-spec verify-links --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --json.
-3. Render a durable spec draft:
-
-       issue-spec archive durable-spec --repo higress-group/higress --proposal <issue> --capability <capability> --output /tmp/<capability>-spec.md --json
-
-4. Run final verify:
-
-       issue-spec verify --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --pr <pr> --durable-spec /tmp/<capability>-spec.md --json
-
-5. Final verify must fail if blocking questions, missing links, missing PROCESS rationale, open P0/P1 findings, failed or pending PR checks, or durable spec omissions exist.

.agents/skills/issue-spec-workflow/SKILL.md

@@ -1,53 +0,0 @@
----
-name: issue-spec-workflow
-description: Use issue-spec to run an issue-native OpenSpec-style workflow with GitHub issues, typed comments, PR review comments, final verification, and durable spec archive PRs.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Workflow
-
-Use this skill for issue-native OpenSpec work. Active change artifacts live in GitHub issues and issue comments; durable specs are repository files created after implementation merge.
-
-## Start
-
-1. Run issue-spec auth status --json and confirm the active auth source and GitHub backend.
-2. Run issue-spec status --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --json when issues already exist.
-3. For new work, create proposal, design, and implement issues with issue-spec issue create and pass --body-file with concrete markdown content.
-4. When an issue body changes, update it in place with issue-spec issue update --body-file and include --summary for the human-readable audit trail.
-5. Store requirements, tasks, process ownership, review, and verify evidence as typed comments.
-
-## GitHub Backend
-
-- Local agents may rely on native GitHub CLI support: when no ISSUE_SPEC_TOKEN, GH_TOKEN, GITHUB_TOKEN, keyring token, or issue-spec config token is present and gh auth status --active succeeds for the target host, issue-spec auto-selects the gh backend.
-- Explicit env or stored issue-spec tokens keep the rest backend under auto selection. Set ISSUE_SPEC_GITHUB_BACKEND=rest or ISSUE_SPEC_GITHUB_BACKEND=gh only when a workflow needs deterministic backend selection.
-- The gh backend proxies GitHub API operations through gh api and uses gh --hostname for Enterprise hosts. It does not replace local git commands.
-- ISSUE_SPEC_API_URL applies to the rest backend. Forced gh mode should be used only with hosts that gh can address.
-- Use ISSUE_SPEC_TOKEN="$(gh auth token)" only for older issue-spec versions or when deliberately forcing rest while sourcing the token from gh.
-
-## Rules
-
-- Create SPEC comments before design; each SPEC must be testable and include WHEN/THEN scenarios.
-- Do not leave active proposal/design/implement issue bodies as TBD placeholders.
-- Resolve blocking QUESTION comments before design/tasks, or explicitly record accepted assumptions.
-- Link SPEC <-> TASK and TASK <-> PROCESS with issue-spec link.
-- Link every PROCESS to the implementation PR with issue-spec pr link-process.
-- For non-trivial changes, include review PROCESS nodes in the DAG; review agents are scheduled like worker agents and can run in parallel when their review scopes are independent.
-- Small changes may stay coordinator-only, but record the serial execution decision in the implement or VERIFY evidence.
-- Before human review, add PR rationale comments with issue-spec pr rationale for every active PROCESS.
-- Use issue-spec review finding for PR line findings and issue-spec review reply to close the original thread.
-- Run issue-spec review sync and issue-spec verify before declaring ready.
-- After the implementation PR merges, create the separate durable spec PR with issue-spec archive durable-spec --create-pr.
-
-## Coordinator DAG Execution
-
-1. Treat PROCESS comments as DAG nodes with explicit owner, dependencies, write or review scope, PR link, and evidence.
-2. Select ready PROCESS nodes whose dependencies are done and whose scopes do not overlap.
-3. Dispatch independent worker PROCESS nodes in parallel when their file/module ownership is disjoint.
-4. Dispatch independent review PROCESS nodes in parallel for non-trivial PRs after PR rationale exists.
-5. Integrate completed worker outputs by dependency order; route P0/P1 review findings back to the owner PROCESS.
-6. Mark PROCESS nodes done only after their implementation or review evidence is recorded and blocking findings are resolved.

.claude/commands/issue-spec/apply.md

@@ -1,31 +0,0 @@
----
-name: "Issue Spec: Apply"
-description: "Implement PROCESS comments for an issue-spec change and keep PR traceability synchronized."
-category: "Workflow"
-tags: ["workflow", "issue-spec"]
----
-
-# Issue Spec Apply
-
-Use when the user asks for /issue-spec:apply, issue-spec apply, or implementing PROCESS/TASK scopes from an issue-spec change.
-
-## Steps
-
-1. Read proposal/design/implement issue context and list typed comments with issue-spec comment list --json.
-2. Confirm issue-spec auth status --json includes the expected GitHub backend. Local gh-authenticated sessions can use the native gh backend; keep ISSUE_SPEC_TOKEN="$(gh auth token)" only as an older-version or forced-rest compatibility path.
-3. Create or update PROCESS comments with owner agent, scope, dependencies, write ownership, and status.
-4. Split non-trivial work into independent worker PROCESS nodes when file/module ownership does not overlap; execute independent workers in parallel when available.
-5. Add dedicated review PROCESS nodes for non-trivial changes. Review PROCESS nodes should own review scopes such as CLI/API behavior, workflow docs, tests, compatibility, or security-sensitive surfaces.
-6. Link each PROCESS to its TASK comments with issue-spec link.
-7. Implement the code changes for one PROCESS scope at a time, or integrate completed worker outputs by dependency order.
-8. Link every worker and review PROCESS to the PR with issue-spec pr link-process.
-9. Add PR rationale comments on key changed lines with issue-spec pr rationale, each linked to a SPEC comment.
-10. Mark PROCESS comments done only after implementation/review work and focused verification evidence exist.
-
-## Coordinator DAG Execution
-
-1. Build the ready set from PROCESS nodes whose dependencies are done.
-2. Keep immediate blocking work local when the next step depends on it.
-3. Spawn or assign independent worker agents only when their write ownership is disjoint.
-4. Spawn or assign independent review agents only when their review scopes are disjoint.
-5. Integrate completed outputs by dependency order and update PROCESS evidence before marking done.

.claude/commands/issue-spec/archive.md

@@ -1,20 +0,0 @@
----
-name: "Issue Spec: Archive"
-description: "Create the post-merge durable spec archive PR for an issue-spec change."
-category: "Workflow"
-tags: ["workflow", "issue-spec"]
----
-
-# Issue Spec Archive
-
-Use when the user asks for /issue-spec:archive, issue-spec archive, or creating the post-merge durable spec PR.
-
-## Steps
-
-1. Confirm the implementation PR is merged.
-2. Create the durable spec PR:
-
-       issue-spec archive durable-spec --repo higress-group/higress --proposal <issue> --capability <capability> --create-pr --branch issue-spec/durable-spec-<capability> --json
-
-3. Review the durable spec PR for long-lived behavior only. Do not copy process records, review findings, or verification logs into durable specs.
-4. After durable spec PR merge, keep proposal/design/implement issues as audit history unless the project policy says to close them.

.claude/commands/issue-spec/propose.md

@@ -1,33 +0,0 @@
----
-name: "Issue Spec: Propose"
-description: "Create or continue proposal, SPEC, QUESTION, design, and TASK artifacts for an issue-spec change."
-category: "Workflow"
-tags: ["workflow", "issue-spec"]
----
-
-# Issue Spec Propose
-
-Use when the user asks for /issue-spec:propose, issue-spec propose, creating a change proposal, drafting SPEC comments, or preparing design/tasks after questions converge.
-
-## Steps
-
-1. Create the proposal issue:
-
-       issue-spec issue create proposal --repo higress-group/higress --change <change-name> --body-file <proposal.md>
-
-2. If the proposal body needs revision after discussion, update it in place:
-
-       issue-spec issue update --repo higress-group/higress --issue <proposal-issue> --body-file <proposal.md> --summary "<what changed>"
-
-3. Add SPEC comments with issue-spec comment upsert --type SPEC. SPEC comments must use MUST/SHALL and WHEN/THEN scenarios.
-4. Add QUESTION comments for unresolved behavior with issue-spec question create and resolve blocking questions before design.
-5. Create the design issue after SPEC/QUESTION convergence:
-
-       issue-spec issue create design --repo higress-group/higress --change <change-name> --proposal <proposal-issue-or-url> --body-file <design.md>
-
-6. Add TASK comments with issue-spec comment upsert --type TASK and link every TASK to covered SPEC comments with issue-spec link.
-7. Create the implement issue once tasks are ready:
-
-       issue-spec issue create implement --repo higress-group/higress --change <change-name> --proposal <proposal-issue-or-url> --design <design-issue-or-url> --body-file <implement.md>
-
-8. Run issue-spec verify-links and fix missing backlinks before implementation.

.claude/commands/issue-spec/review.md

@@ -1,28 +0,0 @@
----
-name: "Issue Spec: Review"
-description: "Review an issue-spec implementation PR, create PR line findings, reply after fixes, and sync REVIEW comments."
-category: "Workflow"
-tags: ["workflow", "issue-spec"]
----
-
-# Issue Spec Review
-
-Use when the user asks for /issue-spec:review, issue-spec review, or a PR review gate for an issue-spec implementation.
-
-## Steps
-
-1. Run issue-spec review sync --repo higress-group/higress --pr <number> --implement <issue> --id REVIEW-<n> --json to capture current rationale comments, findings, and checks.
-2. For non-trivial PRs, spawn or assign dedicated review agents as review PROCESS owners. Multiple review agents can run in parallel when their review scopes are independent.
-3. Give each review agent a concrete scope and expected output: actionable findings only, severity, file/line, linked SPEC, owner PROCESS, and suggested fix.
-4. Create actionable PR line findings with issue-spec review finding. Use P0/P1 for blockers and P2 for non-blocking follow-up.
-5. Assign every finding to a PROCESS owner. If no findings are found, record that result in REVIEW or VERIFY evidence.
-6. After the worker fixes a finding, reply to the original thread with issue-spec review reply --status resolved.
-7. Re-run review sync. P0/P1 findings must be resolved before final verify/archive.
-
-## Review DAG Policy
-
-1. Every non-trivial PR should have at least one dedicated review PROCESS node before final verify.
-2. Use multiple review agents in parallel when scopes are independent, for example CLI/API behavior, workflow docs, tests, compatibility, or security-sensitive surfaces.
-3. A review agent reports findings only; the coordinator converts actionable line findings into issue-spec review finding comments.
-4. P0/P1 findings block final verify until the owner PROCESS fixes them and issue-spec review reply records the resolution on the original thread.
-5. If a review agent finds no issues, record that result in REVIEW or VERIFY evidence before marking the review PROCESS done.

.claude/commands/issue-spec/verify.md

@@ -1,24 +0,0 @@
----
-name: "Issue Spec: Verify"
-description: "Run final issue-spec verification across traceability, questions, review findings, PR rationale, PR checks, and durable spec draft."
-category: "Workflow"
-tags: ["workflow", "issue-spec"]
----
-
-# Issue Spec Verify
-
-Use when the user asks for /issue-spec:verify, issue-spec verify, or final readiness evidence before merge/archive.
-
-## Steps
-
-1. Run focused project tests and record evidence in VERIFY comments.
-2. Run issue-spec verify-links --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --json.
-3. Render a durable spec draft:
-
-       issue-spec archive durable-spec --repo higress-group/higress --proposal <issue> --capability <capability> --output /tmp/<capability>-spec.md --json
-
-4. Run final verify:
-
-       issue-spec verify --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --pr <pr> --durable-spec /tmp/<capability>-spec.md --json
-
-5. Final verify must fail if blocking questions, missing links, missing PROCESS rationale, open P0/P1 findings, failed or pending PR checks, or durable spec omissions exist.

.claude/skills/issue-spec-apply/SKILL.md

@@ -1,35 +0,0 @@
----
-name: issue-spec-apply
-description: Implement PROCESS comments for an issue-spec change and keep PR traceability synchronized.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Apply
-
-Use when the user asks for /issue-spec:apply, issue-spec apply, or implementing PROCESS/TASK scopes from an issue-spec change.
-
-## Steps
-
-1. Read proposal/design/implement issue context and list typed comments with issue-spec comment list --json.
-2. Confirm issue-spec auth status --json includes the expected GitHub backend. Local gh-authenticated sessions can use the native gh backend; keep ISSUE_SPEC_TOKEN="$(gh auth token)" only as an older-version or forced-rest compatibility path.
-3. Create or update PROCESS comments with owner agent, scope, dependencies, write ownership, and status.
-4. Split non-trivial work into independent worker PROCESS nodes when file/module ownership does not overlap; execute independent workers in parallel when available.
-5. Add dedicated review PROCESS nodes for non-trivial changes. Review PROCESS nodes should own review scopes such as CLI/API behavior, workflow docs, tests, compatibility, or security-sensitive surfaces.
-6. Link each PROCESS to its TASK comments with issue-spec link.
-7. Implement the code changes for one PROCESS scope at a time, or integrate completed worker outputs by dependency order.
-8. Link every worker and review PROCESS to the PR with issue-spec pr link-process.
-9. Add PR rationale comments on key changed lines with issue-spec pr rationale, each linked to a SPEC comment.
-10. Mark PROCESS comments done only after implementation/review work and focused verification evidence exist.
-
-## Coordinator DAG Execution
-
-1. Build the ready set from PROCESS nodes whose dependencies are done.
-2. Keep immediate blocking work local when the next step depends on it.
-3. Spawn or assign independent worker agents only when their write ownership is disjoint.
-4. Spawn or assign independent review agents only when their review scopes are disjoint.
-5. Integrate completed outputs by dependency order and update PROCESS evidence before marking done.

.claude/skills/issue-spec-archive/SKILL.md

@@ -1,24 +0,0 @@
----
-name: issue-spec-archive
-description: Create the post-merge durable spec archive PR for an issue-spec change.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Archive
-
-Use when the user asks for /issue-spec:archive, issue-spec archive, or creating the post-merge durable spec PR.
-
-## Steps
-
-1. Confirm the implementation PR is merged.
-2. Create the durable spec PR:
-
-       issue-spec archive durable-spec --repo higress-group/higress --proposal <issue> --capability <capability> --create-pr --branch issue-spec/durable-spec-<capability> --json
-
-3. Review the durable spec PR for long-lived behavior only. Do not copy process records, review findings, or verification logs into durable specs.
-4. After durable spec PR merge, keep proposal/design/implement issues as audit history unless the project policy says to close them.

.claude/skills/issue-spec-github/SKILL.md

@@ -1,58 +0,0 @@
----
-name: issue-spec-github
-description: Use GitHub CLI for GitHub issues, pull requests, CI runs, and API queries that issue-spec does not wrap.
-license: MIT
-compatibility: Requires GitHub CLI (gh).
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# GitHub CLI
-
-Use the `gh` CLI to interact with GitHub repositories, issues, pull requests, CI, and API endpoints.
-
-## When To Use
-
-- Checking PR status, reviews, mergeability, or CI checks.
-- Creating, viewing, updating, closing, or commenting on GitHub issues.
-- Listing or inspecting pull requests, workflow runs, releases, labels, or repository metadata.
-- Calling GitHub API endpoints with `gh api` when issue-spec does not provide a dedicated command.
-
-## When Not To Use
-
-- Local git operations such as commit, branch, fetch, merge, or push. Use `git` directly.
-- Non-GitHub repositories. Use the matching provider CLI instead.
-- Complex code review across local diffs. Read the repository files directly and use issue-spec review commands for traceable findings.
-
-## Setup
-
-```bash
-gh auth login
-gh auth status
-```
-
-## Common Commands
-
-```bash
-gh issue list --repo owner/repo --state open
-gh issue view 42 --repo owner/repo --json number,title,state,url,body
-gh issue comment 42 --repo owner/repo --body "Comment body"
-
-gh pr list --repo owner/repo
-gh pr view 17 --repo owner/repo --json number,title,state,headRefName,baseRefName,url
-gh pr checks 17 --repo owner/repo
-
-gh run list --repo owner/repo --limit 10
-gh run view <run-id> --repo owner/repo --log-failed
-
-gh api repos/owner/repo/labels --jq '.[].name'
-```
-
-## Notes
-
-- Always pass `--repo owner/repo` when the current directory is not definitely inside the target repository.
-- Use GitHub URLs directly when convenient, for example `gh pr view https://github.com/owner/repo/pull/17`.
-- Prefer structured output with `--json` and `--jq` when another command or agent step consumes the result.
-- issue-spec owns the proposal, design, implement, typed comment, review, verify, and archive workflow state. Use `gh` for adjacent GitHub operations that are outside issue-spec's command surface.

.claude/skills/issue-spec-propose/SKILL.md

@@ -1,37 +0,0 @@
----
-name: issue-spec-propose
-description: Create or continue proposal, SPEC, QUESTION, design, and TASK artifacts for an issue-spec change.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Propose
-
-Use when the user asks for /issue-spec:propose, issue-spec propose, creating a change proposal, drafting SPEC comments, or preparing design/tasks after questions converge.
-
-## Steps
-
-1. Create the proposal issue:
-
-       issue-spec issue create proposal --repo higress-group/higress --change <change-name> --body-file <proposal.md>
-
-2. If the proposal body needs revision after discussion, update it in place:
-
-       issue-spec issue update --repo higress-group/higress --issue <proposal-issue> --body-file <proposal.md> --summary "<what changed>"
-
-3. Add SPEC comments with issue-spec comment upsert --type SPEC. SPEC comments must use MUST/SHALL and WHEN/THEN scenarios.
-4. Add QUESTION comments for unresolved behavior with issue-spec question create and resolve blocking questions before design.
-5. Create the design issue after SPEC/QUESTION convergence:
-
-       issue-spec issue create design --repo higress-group/higress --change <change-name> --proposal <proposal-issue-or-url> --body-file <design.md>
-
-6. Add TASK comments with issue-spec comment upsert --type TASK and link every TASK to covered SPEC comments with issue-spec link.
-7. Create the implement issue once tasks are ready:
-
-       issue-spec issue create implement --repo higress-group/higress --change <change-name> --proposal <proposal-issue-or-url> --design <design-issue-or-url> --body-file <implement.md>
-
-8. Run issue-spec verify-links and fix missing backlinks before implementation.

.claude/skills/issue-spec-review/SKILL.md

@@ -1,32 +0,0 @@
----
-name: issue-spec-review
-description: Review an issue-spec implementation PR, create PR line findings, reply after fixes, and sync REVIEW comments.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Review
-
-Use when the user asks for /issue-spec:review, issue-spec review, or a PR review gate for an issue-spec implementation.
-
-## Steps
-
-1. Run issue-spec review sync --repo higress-group/higress --pr <number> --implement <issue> --id REVIEW-<n> --json to capture current rationale comments, findings, and checks.
-2. For non-trivial PRs, spawn or assign dedicated review agents as review PROCESS owners. Multiple review agents can run in parallel when their review scopes are independent.
-3. Give each review agent a concrete scope and expected output: actionable findings only, severity, file/line, linked SPEC, owner PROCESS, and suggested fix.
-4. Create actionable PR line findings with issue-spec review finding. Use P0/P1 for blockers and P2 for non-blocking follow-up.
-5. Assign every finding to a PROCESS owner. If no findings are found, record that result in REVIEW or VERIFY evidence.
-6. After the worker fixes a finding, reply to the original thread with issue-spec review reply --status resolved.
-7. Re-run review sync. P0/P1 findings must be resolved before final verify/archive.
-
-## Review DAG Policy
-
-1. Every non-trivial PR should have at least one dedicated review PROCESS node before final verify.
-2. Use multiple review agents in parallel when scopes are independent, for example CLI/API behavior, workflow docs, tests, compatibility, or security-sensitive surfaces.
-3. A review agent reports findings only; the coordinator converts actionable line findings into issue-spec review finding comments.
-4. P0/P1 findings block final verify until the owner PROCESS fixes them and issue-spec review reply records the resolution on the original thread.
-5. If a review agent finds no issues, record that result in REVIEW or VERIFY evidence before marking the review PROCESS done.

.claude/skills/issue-spec-verify/SKILL.md

@@ -1,28 +0,0 @@
----
-name: issue-spec-verify
-description: Run final issue-spec verification across traceability, questions, review findings, PR rationale, PR checks, and durable spec draft.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Verify
-
-Use when the user asks for /issue-spec:verify, issue-spec verify, or final readiness evidence before merge/archive.
-
-## Steps
-
-1. Run focused project tests and record evidence in VERIFY comments.
-2. Run issue-spec verify-links --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --json.
-3. Render a durable spec draft:
-
-       issue-spec archive durable-spec --repo higress-group/higress --proposal <issue> --capability <capability> --output /tmp/<capability>-spec.md --json
-
-4. Run final verify:
-
-       issue-spec verify --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --pr <pr> --durable-spec /tmp/<capability>-spec.md --json
-
-5. Final verify must fail if blocking questions, missing links, missing PROCESS rationale, open P0/P1 findings, failed or pending PR checks, or durable spec omissions exist.

.claude/skills/issue-spec-workflow/SKILL.md

@@ -1,53 +0,0 @@
----
-name: issue-spec-workflow
-description: Use issue-spec to run an issue-native OpenSpec-style workflow with GitHub issues, typed comments, PR review comments, final verification, and durable spec archive PRs.
-license: MIT
-compatibility: Requires issue-spec CLI.
-metadata:
-  author: issue-spec
-  version: "1.0"
-  generatedBy: "issue-spec"
----
-
-# Issue Spec Workflow
-
-Use this skill for issue-native OpenSpec work. Active change artifacts live in GitHub issues and issue comments; durable specs are repository files created after implementation merge.
-
-## Start
-
-1. Run issue-spec auth status --json and confirm the active auth source and GitHub backend.
-2. Run issue-spec status --repo higress-group/higress --proposal <issue> --design <issue> --implement <issue> --json when issues already exist.
-3. For new work, create proposal, design, and implement issues with issue-spec issue create and pass --body-file with concrete markdown content.
-4. When an issue body changes, update it in place with issue-spec issue update --body-file and include --summary for the human-readable audit trail.
-5. Store requirements, tasks, process ownership, review, and verify evidence as typed comments.
-
-## GitHub Backend
-
-- Local agents may rely on native GitHub CLI support: when no ISSUE_SPEC_TOKEN, GH_TOKEN, GITHUB_TOKEN, keyring token, or issue-spec config token is present and gh auth status --active succeeds for the target host, issue-spec auto-selects the gh backend.
-- Explicit env or stored issue-spec tokens keep the rest backend under auto selection. Set ISSUE_SPEC_GITHUB_BACKEND=rest or ISSUE_SPEC_GITHUB_BACKEND=gh only when a workflow needs deterministic backend selection.
-- The gh backend proxies GitHub API operations through gh api and uses gh --hostname for Enterprise hosts. It does not replace local git commands.
-- ISSUE_SPEC_API_URL applies to the rest backend. Forced gh mode should be used only with hosts that gh can address.
-- Use ISSUE_SPEC_TOKEN="$(gh auth token)" only for older issue-spec versions or when deliberately forcing rest while sourcing the token from gh.
-
-## Rules
-
-- Create SPEC comments before design; each SPEC must be testable and include WHEN/THEN scenarios.
-- Do not leave active proposal/design/implement issue bodies as TBD placeholders.
-- Resolve blocking QUESTION comments before design/tasks, or explicitly record accepted assumptions.
-- Link SPEC <-> TASK and TASK <-> PROCESS with issue-spec link.
-- Link every PROCESS to the implementation PR with issue-spec pr link-process.
-- For non-trivial changes, include review PROCESS nodes in the DAG; review agents are scheduled like worker agents and can run in parallel when their review scopes are independent.
-- Small changes may stay coordinator-only, but record the serial execution decision in the implement or VERIFY evidence.
-- Before human review, add PR rationale comments with issue-spec pr rationale for every active PROCESS.
-- Use issue-spec review finding for PR line findings and issue-spec review reply to close the original thread.
-- Run issue-spec review sync and issue-spec verify before declaring ready.
-- After the implementation PR merges, create the separate durable spec PR with issue-spec archive durable-spec --create-pr.
-
-## Coordinator DAG Execution
-
-1. Treat PROCESS comments as DAG nodes with explicit owner, dependencies, write or review scope, PR link, and evidence.
-2. Select ready PROCESS nodes whose dependencies are done and whose scopes do not overlap.
-3. Dispatch independent worker PROCESS nodes in parallel when their file/module ownership is disjoint.
-4. Dispatch independent review PROCESS nodes in parallel for non-trivial PRs after PR rationale exists.
-5. Integrate completed worker outputs by dependency order; route P0/P1 review findings back to the owner PROCESS.
-6. Mark PROCESS nodes done only after their implementation or review evidence is recorded and blocking findings are resolved.

.issue-spec/config.json

@@ -1,4 +0,0 @@
-{
-  "hostname": "github.com",
-  "repo": "higress-group/higress"
-}

.licenserc.yaml

@@ -36,9 +36,7 @@ header:
     - 'pkg/ingress/kube/gateway/istio/testdata'
     - 'release-notes/**'
     - '.cursor/**'
-    - '.claude/**'
-    - '.agents/**'
-    - '.issue-spec/**'
+    - '.claude/**'    
 
   comment: on-failure
 dependency:

AGENTS.md

@@ -1,156 +0,0 @@
-# AGENTS.md
-
-Guidance for AI agents working in this repository.
-
-Higress is a cloud-native API gateway built on Istio and Envoy. The control
-plane extends Istio/pilot (Go); the data plane is Envoy extended with WASM
-plugins (Go/Rust/C++/AssemblyScript) and a Go-based `golang-filter`. It supports
-Ingress/Gateway API and ships a rich plugin ecosystem (including AI gateway
-plugins).
-
-## Repository layout
-
-Top-level directories (all paths relative to repo root):
-
-- `cmd/higress/` — main entrypoint (`main.go`) for the Higress controller binary.
-- `pkg/` — core Go control-plane packages: `bootstrap/`, `cert/`, `cmd/`,
-  `common/`, `config/`, `ingress/` (Ingress/Gateway config translation),
-  `kube/`.
-- `api/` — protobuf/CRD API definitions; Higress CRDs live in
-  `api/extensions/v1alpha1` (e.g. the `WasmPlugin` type). Generated with
-  `make gen-api` / `make gen-client` (see `api/gen.sh`, `buf.*`).
-- `client/` — generated Go clientset for Higress CRDs.
-- `istio/` — git submodules of higress-group forks of Istio (`api`, `istio`,
-  `client-go`, `pkg`, `proxy`); see `.gitmodules`. Pulled via `make submodule`
-  (part of `prebuild`).
-- `envoy/` — Envoy + `go-control-plane` submodules (higress-group forks).
-- `external/` — vendored/external mirror dirs used during build (istio, envoy,
-  proxy, etc.).
-- `plugins/` — all data-plane plugins (see "Plugins" below).
-- `registry/` — service-discovery registry integrations (nacos, consul, eureka,
-  zookeeper, direct, mcp, ...).
-- `hgctl/` — the `hgctl` CLI (separate Go module) for managing Higress.
-- `helm/` — Helm charts: `helm/core` (the dev/install chart) and `helm/higress`.
-- `test/` — `test/e2e/` (conformance/e2e, see "Build & test") and
-  `test/gateway/`.
-- `tools/` — build/CI scripting: `tools/hack/` (build scripts), `tools/bin/`,
-  `tools/linter/`, `*.mk`.
-- `samples/` — example manifests (gateway-api, hello-world, wasmplugin, ...).
-- `docker/`, `docs/`, `release-notes/` — packaging, docs, and release notes.
-- `Makefile` — istio common-files wrapper (supports `BUILD_WITH_CONTAINER`);
-  real targets live in `Makefile.core.mk` (+ `Makefile.overrides.mk`).
-
-## Plugins
-
-All plugins live under `plugins/`. See `plugins/README.md` for the contributor
-overview. Prebuilt plugin images are published to
-`higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins`.
-
-### plugins/wasm-go/ (primary WASM plugin framework, Go)
-
-- `extensions/<name>/` — one directory per plugin (~59 plugins, many `ai-*`).
-  Each plugin is its own Go module: `main.go`, `go.mod`/`go.sum`, `VERSION`,
-  `README.md`(+`README_EN.md`), often `config/`, `util/`, `main_test.go`.
-  Optional `.buildrc` sets `EXTRA_TAGS`; optional `prepare.sh`/`prepare.sh`.
-  `plugin.wasm` is a build artifact and is **not** committed.
-- Shared SDK: plugins depend on external modules
-  `github.com/higress-group/wasm-go` and
-  `github.com/higress-group/proxy-wasm-go-sdk` (NOT an in-repo SDK dir).
-  In-repo, `plugins/wasm-go/pkg/mcp/` provides MCP helpers and
-  `plugins/wasm-go/mcp-servers/` holds MCP server plugins.
-- `examples/` — minimal reference plugins (custom-log, custom-span-attribute,
-  test-foreign-function).
-- Build: `plugins/wasm-go/Makefile`. `PLUGIN_NAME=<name> make build` builds a
-  wasm file (output to `extensions/<name>/plugin.wasm`) + image via
-  `Dockerfile`/`DockerfileBuilder` (uses a `wasm-go-builder` image, Go 1.24,
-  TinyGo optional). `make build-push` pushes the image; `make local-build`
-  builds locally with `GOOS=wasip1 GOARCH=wasm go build -buildmode=c-shared`.
-- Conventions: `VERSION` is the image tag; the CI/e2e batch builder
-  (`tools/hack/build-wasm-plugins.sh`) only compiles a wasm-go plugin whose
-  `VERSION` ends in `-alpha` (see the section at the bottom of this file).
-
-### plugins/wasm-rust/ (Rust WASM plugins)
-
-- Workspace-style: root `Cargo.toml`/`Cargo.lock`, shared `src/`,
-  `extensions/<name>/` per plugin (e.g. `ai-data-masking`, `ai-intent`,
-  `request-block`, `say-hello`, `demo-wasm`), `example/`.
-- Build via `plugins/wasm-rust/Makefile` (`PLUGIN_NAME=<name> make build`, plus
-  `lint`/`test`); the batch builder runs it when `PLUGIN_TYPE=RUST`.
-
-### plugins/wasm-cpp/ (C++ WASM plugins, Bazel)
-
-- Bazel project: `WORKSPACE`, `BUILD`, `bazel/`, `common/`, `scripts/`,
-  `extensions/<name>/` (e.g. `basic_auth`, `jwt_auth`, `key_rate_limit`,
-  `model_router`, ...). Build via `plugins/wasm-cpp/Makefile`
-  (`PLUGIN_NAME=<name> make build`), invoked with `PLUGIN_TYPE=CPP`.
-
-### plugins/wasm-assemblyscript/ (AssemblyScript WASM plugins)
-
-- Node/AssemblyScript project: `asconfig.json`, `package.json`, `assembly/`,
-  `extensions/`.
-
-### plugins/golang-filter/ (Envoy Go HTTP filter, NOT WASM)
-
-- A native Envoy Golang HTTP filter (`main.go`, `mcp-server/`, `mcp-session/`);
-  compiled as a shared object (`.so`) independent of Envoy — no Envoy rebuild
-  needed. Requires Higress >= 2.1.0. Plugins register in `main.go`'s `init()`
-  via `RegisterHttpFilterFactoryAndConfigParser`. See
-  `plugins/golang-filter/README.md`.
-- Build: `plugins/golang-filter/Makefile` (docker build, outputs
-  `golang-filter_<arch>.so`). Wired into the gateway image build via
-  `Makefile.core.mk` targets `build-golang-filter[-amd64|-arm64]`.
-
-### How plugins are loaded
-
-`WasmPlugin` CRDs (`extensions.higress.io/v1alpha1`) reference a plugin by
-`url:` — either `oci://.../plugins/<name>:<version>` (image) or
-`file:///opt/plugins/.../plugin.wasm` (local mount used in e2e). The dev install
-`make install-dev-wasmplugin` sets Helm `global.volumeWasmPlugins=true` to mount
-locally built wasm files into the gateway.
-
-## Build & test
-
-Run targets from the repo root; `Makefile` delegates to `Makefile.core.mk`.
-Common ones:
-
-- `make build` / `make build-linux` — build the Higress controller binary
-  (`prebuild` first fetches submodules).
-- `make build-hgctl` — build the `hgctl` CLI.
-- `make build-gateway` / `make build-istio` / `make build-envoy` — data-plane
-  and control-plane images (gateway pulls in the golang-filter).
-- `make build-wasmplugins` — runs `tools/hack/build-wasm-plugins.sh` to batch
-  build WASM plugins (respects `PLUGIN_TYPE` / `PLUGIN_NAME`; Go plugins require
-  a `-alpha` VERSION).
-- `make gen-api` / `make gen-client` — regenerate API/client code.
-
-### Conformance / e2e tests (`test/e2e/`)
-
-- Entrypoint `test/e2e/e2e_test.go`, run with build tag `conformance` and
-  `--test-area` / `--execute-tests` flags.
-- Cases live in `test/e2e/conformance/tests/` as **paired `<name>.go` +
-  `<name>.yaml`** files (~68 cases; WASM cases are prefixed by language, e.g.
-  `go-wasm-*`, `cpp-wasm-*`). Support code: `conformance/base/`,
-  `conformance/utils/`, `conformance/embed.go`.
-- Key Make targets (each spins up a kind cluster):
-  - `make higress-conformance-test` — Ingress/Gateway conformance.
-  - `make higress-wasmplugin-test` — WASM plugin e2e (uses
-    `install-dev-wasmplugin`, which builds plugins and mounts them).
-  - `*-prepare` / `*-skip-docker-build` / `*-clean` variants exist for
-    iterating; `run-higress-e2e-test[-wasmplugin]` runs `go test` against an
-    already-prepared cluster (filter with `TEST_SHORTNAME`).
-- For the specifics of authoring a wasm-go e2e test, see the section below.
-
-## Writing e2e conformance tests with wasm-go plugins
-
-When adding an e2e conformance test that ships its own wasm-go plugin under
-`plugins/wasm-go/extensions/<name>/`:
-
-- The plugin's `VERSION` file **must end in `-alpha`** (e.g. `1.0.0-alpha`).
-  CI's `tools/hack/build-wasm-plugins.sh` only compiles a wasm-go plugin when
-  its version ends in `-alpha`; otherwise it silently skips it.
-- `plugin.wasm` is a build artifact and is **not** committed. If the plugin
-  isn't built, the `file:///opt/plugins/.../plugin.wasm` URL in the test's
-  `WasmPlugin` manifest resolves to a missing file, envoy rejects the wasm
-  config and fails closed, and every request on that route returns HTTP 500.
-  Locally this can be masked because a previously built `plugin.wasm` still
-  exists on disk — so a test can pass locally yet 500 in CI.

Makefile.core.mk

@@ -151,7 +151,7 @@ docker-buildx-push: clean-env docker.higress-buildx
 export PARENT_GIT_TAG:=$(shell cat VERSION)
 export PARENT_GIT_REVISION:=$(TAG)
 
-export ENVOY_PACKAGE_URL_PATTERN?=https://github.com/higress-group/proxy/releases/download/v2.2.4-rc.2-test-cpp-host/envoy-symbol-ARCH.tar.gz
+export ENVOY_PACKAGE_URL_PATTERN?=https://github.com/higress-group/proxy/releases/download/v2.2.3/envoy-symbol-ARCH.tar.gz
 
 build-envoy: prebuild
 	./tools/hack/build-envoy.sh
@@ -205,7 +205,7 @@ install: pre-install
 	helm install higress helm/higress -n higress-system --create-namespace --set 'global.local=true'
 
 HIGRESS_LATEST_IMAGE_TAG ?= latest
-ENVOY_LATEST_IMAGE_TAG ?= 481184afc44176eb23d64e0011dc3ea1ae6a410c
+ENVOY_LATEST_IMAGE_TAG ?= fcc50202f47e27f6b8391a4bd9bbc0a9127d89d7
 ISTIO_LATEST_IMAGE_TAG ?= de2c9628294f51b13c4a70b3a862b4372890797a
 
 install-dev: pre-install

plugins/wasm-go/extensions/test-redis-inject-spin/VERSION

@@ -1 +0,0 @@
-1.0.0-alpha

plugins/wasm-go/extensions/test-redis-inject-spin/go.mod

@@ -1,20 +0,0 @@
-module github.com/alibaba/higress/plugins/wasm-go/extensions/test-redis-inject-spin
-
-go 1.24.1
-
-toolchain go1.24.4
-
-require (
-	github.com/higress-group/proxy-wasm-go-sdk v0.0.0-20251103120604-77e9cce339d2
-	github.com/higress-group/wasm-go v1.0.10-0.20260120033417-1c84f010156d
-	github.com/tidwall/gjson v1.18.0
-	github.com/tidwall/resp v0.1.1
-	google.golang.org/protobuf v1.36.6
-)
-
-require (
-	github.com/google/uuid v1.6.0 // indirect
-	github.com/tidwall/match v1.1.1 // indirect
-	github.com/tidwall/pretty v1.2.1 // indirect
-	github.com/tidwall/sjson v1.2.5 // indirect
-)

plugins/wasm-go/extensions/test-redis-inject-spin/go.sum

@@ -1,32 +0,0 @@
-github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
-github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
-github.com/google/go-cmp v0.5.5 h1:Khx7svrCpmxxtHBq5j2mp/xVjsi8hQMfNLvJFAlrGgU=
-github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
-github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=
-github.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
-github.com/higress-group/proxy-wasm-go-sdk v0.0.0-20251103120604-77e9cce339d2 h1:NY33OrWCJJ+DFiLc+lsBY4Ywor2Ik61ssk6qkGF8Ypo=
-github.com/higress-group/proxy-wasm-go-sdk v0.0.0-20251103120604-77e9cce339d2/go.mod h1:tRI2LfMudSkKHhyv1uex3BWzcice2s/l8Ah8axporfA=
-github.com/higress-group/wasm-go v1.0.10-0.20260120033417-1c84f010156d h1:LgYbzEBtg0+LEqoebQeMVgAB6H5SgqG+KN+gBhNfKbM=
-github.com/higress-group/wasm-go v1.0.10-0.20260120033417-1c84f010156d/go.mod h1:uKVYICbRaxTlKqdm8E0dpjbysxM8uCPb9LV26hF3Km8=
-github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
-github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
-github.com/stretchr/testify v1.9.0 h1:HtqpIVDClZ4nwg75+f6Lvsy/wHu+3BoSGCbBAcpTsTg=
-github.com/stretchr/testify v1.9.0/go.mod h1:r2ic/lqez/lEtzL7wO/rwa5dbSLXVDPFyf8C91i36aY=
-github.com/tidwall/gjson v1.14.2/go.mod h1:/wbyibRr2FHMks5tjHJ5F8dMZh3AcwJEMf5vlfC0lxk=
-github.com/tidwall/gjson v1.18.0 h1:FIDeeyB800efLX89e5a8Y0BNH+LOngJyGrIWxG2FKQY=
-github.com/tidwall/gjson v1.18.0/go.mod h1:/wbyibRr2FHMks5tjHJ5F8dMZh3AcwJEMf5vlfC0lxk=
-github.com/tidwall/match v1.1.1 h1:+Ho715JplO36QYgwN9PGYNhgZvoUSc9X2c80KVTi+GA=
-github.com/tidwall/match v1.1.1/go.mod h1:eRSPERbgtNPcGhD8UCthc6PmLEQXEWd3PRB5JTxsfmM=
-github.com/tidwall/pretty v1.2.0/go.mod h1:ITEVvHYasfjBbM0u2Pg8T2nJnzm8xPwvNhhsoaGGjNU=
-github.com/tidwall/pretty v1.2.1 h1:qjsOFOWWQl+N3RsoF5/ssm1pHmJJwhjlSbZ51I6wMl4=
-github.com/tidwall/pretty v1.2.1/go.mod h1:ITEVvHYasfjBbM0u2Pg8T2nJnzm8xPwvNhhsoaGGjNU=
-github.com/tidwall/resp v0.1.1 h1:Ly20wkhqKTmDUPlyM1S7pWo5kk0tDu8OoC/vFArXmwE=
-github.com/tidwall/resp v0.1.1/go.mod h1:3/FrruOBAxPTPtundW0VXgmsQ4ZBA0Aw714lVYgwFa0=
-github.com/tidwall/sjson v1.2.5 h1:kLy8mja+1c9jlljvWTlSazM7cKDRfJuR/bOJhcY5NcY=
-github.com/tidwall/sjson v1.2.5/go.mod h1:Fvgq9kS/6ociJEDnK0Fk1cpYF4FIW6ZF7LAe+6jwd28=
-golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543 h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
-golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
-google.golang.org/protobuf v1.36.6 h1:z1NpPI8ku2WgiWnf+t9wTPsn6eP1L7ksHUlkfLvd9xY=
-google.golang.org/protobuf v1.36.6/go.mod h1:jduwjTPXsFjZGTmRluh+L6NjiWu7pchiJ2/5YcXBHnY=
-gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=
-gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=

plugins/wasm-go/extensions/test-redis-inject-spin/main.go

@@ -1,119 +0,0 @@
-// Repro plugin for higress issue #4034: worker CPU spin in
-// WasmBase::doAfterVmCallActions when a deferred async callback synchronously
-// calls injectEncodedDataToFilterChain (nesting SaveRestoreContext) so that the
-// after-vm-call action re-queues itself forever.
-//
-// Repro shape (dead-Redis only, self-contained — no external HTTP dependency):
-//   1. In the response-header phase, pause the response.
-//   2. Fire N Redis commands against an UNREACHABLE redis cluster.
-//   3. Each failure callback (onRedisCallFailure) synchronously calls the
-//      inject_encoded_data_to_filter_chain foreign function. Because sibling
-//      failure callbacks are still queued as after-vm-call actions, the nested
-//      SaveRestoreContext leaves current_context_ != nullptr and the deferred
-//      action re-queues itself -> CPU spin on the pre-fix host.
-//
-// With the Layer A drain-to-local fix in place, the drain terminates over a
-// snapshot and worker CPU stays bounded.
-package main
-
-import (
-	"github.com/higress-group/proxy-wasm-go-sdk/proxywasm"
-	"github.com/higress-group/proxy-wasm-go-sdk/proxywasm/types"
-	"github.com/higress-group/wasm-go/pkg/log"
-	pb "github.com/higress-group/wasm-go/pkg/protos"
-	"github.com/higress-group/wasm-go/pkg/wrapper"
-	"github.com/tidwall/gjson"
-	"github.com/tidwall/resp"
-	"google.golang.org/protobuf/proto"
-)
-
-func main() {}
-
-type Config struct {
-	redisClient *wrapper.RedisClusterClient[wrapper.FQDNCluster]
-	redisKey    string
-	injectBody  string
-	injectCount int
-}
-
-func init() {
-	wrapper.SetCtx(
-		"test-redis-inject-spin",
-		wrapper.ParseConfig(parseConfig),
-		wrapper.ProcessResponseHeaders(onHttpResponseHeaders),
-	)
-}
-
-func parseConfig(json gjson.Result, config *Config) error {
-	serviceName := json.Get("service_name").String()
-	if serviceName == "" {
-		serviceName = "dead-redis.dead-redis.svc.cluster.local"
-	}
-	servicePort := json.Get("service_port").Int()
-	if servicePort == 0 {
-		servicePort = 6379
-	}
-	config.redisKey = json.Get("redis_key").String()
-	if config.redisKey == "" {
-		config.redisKey = "higress-4034-key"
-	}
-	config.injectBody = json.Get("inject_body").String()
-	if config.injectBody == "" {
-		config.injectBody = "injected-by-4034-repro\n"
-	}
-	config.injectCount = int(json.Get("inject_count").Int())
-	if config.injectCount == 0 {
-		config.injectCount = 16
-	}
-
-	config.redisClient = wrapper.NewRedisClusterClient(wrapper.FQDNCluster{
-		FQDN: serviceName,
-		Port: servicePort,
-	})
-	// Init never returns error for an unreachable host; commands' callbacks will
-	// fire with an error value, which is exactly the #4034 trigger path.
-	return config.redisClient.Init("", "", 1000)
-}
-
-func onHttpResponseHeaders(ctx wrapper.HttpContext, config Config) types.Action {
-	proxywasm.RemoveHttpResponseHeader("content-length")
-	ctx.DontReadResponseBody()
-
-	inject := func() {
-		d := &pb.InjectEncodedDataToFilterChainArguments{
-			Body:      config.injectBody,
-			Endstream: true,
-		}
-		s, err := proto.Marshal(d)
-		if err != nil {
-			log.Errorf("marshal inject args failed: %+v", err)
-			return
-		}
-		if _, err := proxywasm.CallForeignFunction("inject_encoded_data_to_filter_chain_on_header", s); err != nil {
-			log.Errorf("call inject_encoded_data_to_filter_chain_on_header failed: %+v", err)
-		}
-	}
-
-	scheduled := 0
-	for i := 0; i < config.injectCount; i++ {
-		err := config.redisClient.Get(config.redisKey, func(response resp.Value) {
-			// Fires on redis-unreachable failure; synchronously inject to nest
-			// SaveRestoreContext while sibling callbacks are still queued.
-			if response.Error() != nil {
-				log.Debugf("redis get failed as expected: %v", response.Error())
-			}
-			inject()
-		})
-		if err != nil {
-			log.Errorf("redis Get dispatch failed: %+v", err)
-			continue
-		}
-		scheduled++
-	}
-
-	if scheduled == 0 {
-		// Nothing dispatched (e.g. cluster missing) — don't hang the response.
-		return types.ActionContinue
-	}
-	return types.ActionPause
-}

plugins/wasm-go/extensions/transformer/main.go

@@ -39,7 +39,6 @@ func init() {
 		wrapper.ProcessRequestBodyBy(onHttpRequestBody),
 		wrapper.ProcessResponseHeadersBy(onHttpResponseHeaders),
 		wrapper.ProcessResponseBodyBy(onHttpResponseBody),
-		wrapper.WithRebuildMaxMemBytes[TransformerConfig](200*1024*1024),
 	)
 }
 
@@ -344,12 +343,11 @@ func onHttpRequestHeaders(ctx wrapper.HttpContext, config TransformerConfig, log
 	isValidRequestContent := isValidRequestContentType(contentType)
 	isBodyChange := config.reqTrans.IsBodyChange()
 	needBodyMapSource := config.reqTrans.NeedBodyMapSource()
-	hasRequestBody := ctx.HasRequestBody()
 
-	log.Debugf("contentType:%s, isValidRequestContent:%v, isBodyChange:%v, needBodyMapSource:%v, hasRequestBody:%v",
-		contentType, isValidRequestContent, isBodyChange, needBodyMapSource, hasRequestBody)
+	log.Debugf("contentType:%s, isValidRequestContent:%v, isBodyChange:%v, needBodyMapSource:%v",
+		contentType, isValidRequestContent, isBodyChange, needBodyMapSource)
 
-	if isBodyChange && isValidRequestContent && hasRequestBody {
+	if isBodyChange && isValidRequestContent {
 		delete(hs, "content-length")
 	}
 
@@ -363,7 +361,7 @@ func onHttpRequestHeaders(ctx wrapper.HttpContext, config TransformerConfig, log
 	ctx.SetContext("headers", hs)
 	ctx.SetContext("querys", qs)
 
-	if !hasRequestBody || !isValidRequestContent || (!isBodyChange && !needBodyMapSource) {
+	if !isValidRequestContent || (!isBodyChange && !needBodyMapSource) {
 		ctx.DontReadRequestBody()
 	} else if needBodyMapSource {
 		// we need do transform during body phase

plugins/wasm-go/extensions/transformer/main_test.go

@@ -424,43 +424,6 @@ func TestRequest_MapFromBody_DelaysHeaderTransform(t *testing.T) {
 	})
 }
 
-func TestRequest_MapFromBody_NoRequestBodyDoesNotPause(t *testing.T) {
-	test.RunTest(t, func(t *testing.T) {
-		host, status := test.NewTestHost(configJSON(map[string]any{
-			"reqRules": []map[string]any{
-				{
-					"operate":   "map",
-					"mapSource": "body",
-					"headers": []map[string]any{
-						{"fromKey": "user.id", "toKey": "X-User-Id"},
-					},
-				},
-				{
-					"operate": "add",
-					"headers": []map[string]any{
-						{"key": "X-Static", "value": "ok"},
-					},
-				},
-			},
-		}))
-		defer host.Reset()
-		require.Equal(t, types.OnPluginStartStatusOK, status)
-
-		action := host.CallOnHttpRequestHeaders([][2]string{
-			{":authority", "test.com"},
-			{":path", "/p"},
-			{":method", "POST"},
-			{"content-type", "application/json"},
-		}, test.WithEndOfStream(true))
-		require.Equal(t, types.ActionContinue, action, "request without body must not wait for body callback")
-
-		got := headersToMap(host.GetRequestHeaders())
-		require.Equal(t, []string{"ok"}, got["x-static"])
-		require.NotContains(t, got, "x-user-id")
-		host.CompleteHttp()
-	})
-}
-
 // --- regex template ---
 
 func TestRequest_Headers_AddWithHostPattern(t *testing.T) {

release-notes/2.2.3/README.md

@@ -0,0 +1,125 @@
+# Higress Console
+
+
+## 📋 Overview of This Release
+
+This release includes **18** updates, covering feature enhancements, bug fixes, and performance optimizations.
+
+### Distribution of Updates
+
+- **New Features**: 7
+- **Bug Fixes**: 9
+- **Documentation Updates**: 2
+
+---
+
+## 📝 Complete Change Log
+
+### 🚀 New Features (Features)
+
+- **Related PR**: [#621](https://github.com/higress-group/higress-console/pull/621) \
+  **Contributor**: @Thomas-Eliot \
+  **Change Log**: Enhanced MCP Server interaction capabilities: added support for automatic Host header rewriting for DNS backends; improved transport selection and full-path configuration in direct-routing scenarios; enhanced parsing of special characters (e.g., `@`) in DSNs for DB-to-MCP Server scenarios. \
+  **Feature Value**: Improves MCP Server configuration flexibility and compatibility, reduces user onboarding complexity, prevents integration issues caused by path-prefix confusion or DSN parsing failures, and strengthens multi-environment deployment stability and usability.
+
+- **Related PR**: [#608](https://github.com/higress-group/higress-console/pull/608) \
+  **Contributor**: @Libres-coder \
+  **Change Log**: Added plugin display capability to the AI Route Management page, enabling users to expand an AI route row to view enabled plugins and display an "Enabled" tag on the configuration page; involved core file modifications including `frontend/src/pages/ai/route.tsx` and `plugin/components/PluginList/index.tsx`, unifying plugin visualization capabilities between AI routes and standard routes. \
+  **Feature Value**: Enables users to intuitively view and verify enabled plugins directly from the AI route management interface, improving transparency and maintainability of AI service configurations; eliminates UX inconsistencies between legacy and new routing management, reduces learning curve, and enhances platform consistency and user confidence.
+
+- **Related PR**: [#604](https://github.com/higress-group/higress-console/pull/604) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Added support for regular-expression-based path rewriting via the `higress.io/rewrite-target` Kubernetes annotation; extended Kubernetes annotation constants; refactored the rewrite configuration population logic in `KubernetesModelConverter`; added corresponding unit test cases. \
+  **Feature Value**: Allows users to flexibly define path-rewriting rules using regular expressions, enhancing routing match accuracy and flexibility to meet complex business requirements for URL transformation, thereby reducing custom development effort.
+
+- **Related PR**: [#603](https://github.com/higress-group/higress-console/pull/603) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Defined the constant `STATIC_SERVICE_PORT = 80` in the static service source form component and displayed this fixed port in the UI, clearly informing users that static services use port 80 by default, thereby improving configuration transparency and consistency. \
+  **Feature Value**: Enables users to immediately recognize the default port (80) when configuring static service sources, preventing deployment failures due to port misinterpretation; enhances UI information completeness, lowers entry barriers for new users, and improves overall configuration experience and operational reliability.
+
+- **Related PR**: [#602](https://github.com/higress-group/higress-console/pull/602) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Added a search function to the upstream service selection component in AI route configuration; extended the input control logic of the `RouteForm` component to support real-time filtering and rapid target-service location, improving operational efficiency when navigating large service lists. \
+  **Feature Value**: Enables users to directly search for upstream services during AI route configuration, eliminating manual scrolling through long lists and significantly shortening configuration time—particularly beneficial in production environments with numerous microservices—thus enhancing configuration experience and accuracy for both operations and development teams.
+
+- **Related PR**: [#566](https://github.com/higress-group/higress-console/pull/566) \
+  **Contributor**: @OuterCyrex \
+  **Change Log**: Added support for the Qwen large language model (LLM) service, including customizable service endpoints, internet search toggle, and file ID upload functionality; added corresponding configuration options and internationalization support on both frontend and backend. \
+  **Feature Value**: Enables flexible integration of custom Qwen services via the Higress platform, enhancing AI capability extensibility; supports file ID uploads and internet-connected search, boosting practical AI inference capabilities and flexibility in real-world business scenarios.
+
+- **Related PR**: [#552](https://github.com/higress-group/higress-console/pull/552) \
+  **Contributor**: @lcfang \
+  **Change Log**: Added support for the `vport` (virtual port) attribute; extended the `ServiceSource` and `V1RegistryConfig` models; introduced the `VPort` class; integrated `vport` field mapping into Kubernetes model conversion logic, resolving routing failures caused by inconsistent service instance ports in service registries. \
+  **Feature Value**: Enables the MCPBridge to adapt to backend services with dynamically changing ports, improving gateway compatibility with service registries such as Eureka and Nacos; allows users to accommodate instance port changes without frequent route reconfiguration, enhancing system stability and operational efficiency.
+
+### 🐛 Bug Fixes (Bug Fixes)
+
+- **Related PR**: [#620](https://github.com/higress-group/higress-console/pull/620) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Fixed a typo in the `sortWasmPluginMatchRules` method, corrected variable names and conditional logic in the matching rule sorting algorithm to ensure Wasm plugin match rules are sorted correctly in the expected order, preventing logic errors or null pointer exceptions caused by naming inconsistencies. \
+  **Feature Value**: Enhances correctness and stability of Wasm plugin match rule sorting, preventing runtime exceptions or misordered rules caused by typos, ensuring users’ configured plugin matching policies are executed precisely, thus strengthening system reliability and maintainability.
+
+- **Related PR**: [#619](https://github.com/higress-group/higress-console/pull/619) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Fixed duplicate version information persistence when converting an `AiRoute` to a `ConfigMap`, removing the `version` field from the `data` JSON payload while retaining it solely in the `ConfigMap` metadata to prevent data redundancy and potential inconsistency. \
+  **Feature Value**: Improves accuracy and consistency of configuration management, prevents parsing errors or deployment anomalies caused by duplicated version fields, enhances system stability and operational reliability, delivering direct benefits to users leveraging `AiRoute` functionality.
+
+- **Related PR**: [#618](https://github.com/higress-group/higress-console/pull/618) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Refactored API authentication logic in `SystemController`, introducing an `AllowAnonymous` annotation mechanism to uniformly handle unauthenticated endpoints (e.g., health checks and login), eliminating pre-existing authorization bypass vulnerabilities and improving overall system security. \
+  **Feature Value**: Fixes a security vulnerability in `SystemController`, preventing unauthorized access to sensitive interfaces and safeguarding user data and system resources; strengthens compliance and trustworthiness for enterprise-grade applications.
+
+- **Related PR**: [#617](https://github.com/higress-group/higress-console/pull/617) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Fixed missing unique `key` attributes in frontend list rendering (triggering React warnings), resolved CSP policy blocking external image loading, corrected a type definition error for the `Consumer.name` field (changed from `boolean` to `string`), and adjusted list-element rendering logic on the route page. \
+  **Feature Value**: Improves frontend application stability and user experience, avoids console errors interfering with development debugging, ensures avatars and list content render correctly, and prevents runtime exceptions caused by type mismatches—enhancing system robustness and maintainability.
+
+- **Related PR**: [#614](https://github.com/higress-group/higress-console/pull/614) \
+  **Contributor**: @lc0138 \
+  **Change Log**: Fixed a type definition error for the `type` field of service origin in the `ServiceSource` class and added dictionary value validation logic to ensure only predefined, valid registry types are accepted, improving parameter validation accuracy and system robustness. \
+  **Feature Value**: Prevents service configuration parsing failures or runtime exceptions induced by invalid `type` values, enhances SDK stability and reliability, and provides users with clearer error messages and stronger type safety when configuring service origins.
+
+- **Related PR**: [#613](https://github.com/higress-group/higress-console/pull/613) \
+  **Contributor**: @lc0138 \
+  **Change Log**: Fixed a missing Content Security Policy (CSP) configuration issue in the frontend by adding a meta tag in `document.tsx` to declare the security policy, preventing XSS and other injection attacks and ensuring security context integrity during page loading. \
+  **Feature Value**: Strengthens frontend application security by effectively defending against common web attacks such as cross-site scripting (XSS) and malicious resource loading, protecting user data and interactions, meeting enterprise-grade security compliance requirements, and elevating overall system trustworthiness.
+
+- **Related PR**: [#612](https://github.com/higress-group/higress-console/pull/612) \
+  **Contributor**: @zhwaaaaaa \
+  **Change Log**: Added hop-to-hop header filtering logic to `DashboardServiceImpl`, filtering headers such as `transfer-encoding` per RFC 2616 to prevent reverse proxy forwarding of `transfer-encoding: chunked` headers from causing Grafana UI loading failures. \
+  **Feature Value**: Resolves Grafana console loading failures caused by reverse proxy passthrough of `transfer-encoding: chunked` headers, improving console stability and user experience and ensuring reliable rendering of monitoring dashboards.
+
+- **Related PR**: [#609](https://github.com/higress-group/higress-console/pull/609) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: Corrected a type error in the `Consumer` interface for the `name` field, updating its erroneous declaration from `boolean` to `string` to ensure alignment between frontend data structures and actual backend responses, preventing runtime type exceptions and TypeScript compilation errors. \
+  **Feature Value**: Resolving this type mismatch prevents frontend rendering anomalies, form submission failures, or logical misjudgments—improving application stability and developer experience, and ensuring correct operation of `Consumer`-related features (e.g., user information display and editing).
+
+- **Related PR**: [#605](https://github.com/higress-group/higress-console/pull/605) \
+  **Contributor**: @SaladDay \
+  **Change Log**: Corrected the frontend form validation regex for AI route names to support periods (`.`) and restrict names to lowercase letters only; synchronized updates to Chinese and English error message texts to ensure UI hints align precisely with actual validation logic. \
+  **Feature Value**: Enables users to legally use dot-delimited names (e.g., `api.v1`) when creating or editing AI routes, avoiding form submission failures caused by inconsistent validation rules; improves accuracy of UI feedback, enhancing configuration experience and troubleshooting efficiency.
+
+### 📚 Documentation Updates (Documentation)
+
+- **Related PR**: [#611](https://github.com/higress-group/higress-console/pull/611) \
+  **Contributor**: @qshuai \
+  **Change Log**: Corrected the Swagger API documentation summary description for the `@PostMapping` endpoint in `LlmProvidersController`, fixing the inaccurate description “Add a new route” to accurately reflect its actual functionality (i.e., LLM provider creation), thereby improving API documentation accuracy and readability. \
+  **Feature Value**: Enables developers to correctly understand the endpoint’s purpose (LLM provider creation) when using the console API documentation, preventing misuse due to misleading descriptions and improving API debugging and integration efficiency—enhancing overall developer experience.
+
+- **Related PR**: [#610](https://github.com/higress-group/higress-console/pull/610) \
+  **Contributor**: @heimanba \
+  **Change Log**: Updated frontend canary plugin documentation: changed `rewrite`, `backendVersion`, and `enabled` fields from required to optional; corrected the associated path for the `name` field in `rules` from `deploy.gray[].name` to `grayDeployments[].name`; synchronized updates to field descriptions and requirements in both Chinese and English `README`s and `spec.yaml`. \
+  **Feature Value**: Increases configuration flexibility and compatibility while lowering user onboarding barriers; avoids configuration errors caused by outdated documentation through standardized terminology and corrected paths, thereby enhancing the usability and maintainability of canary capabilities.
+
+---
+
+## 📊 Release Statistics
+
+- 🚀 New Features: 7  
+- 🐛 Bug Fixes: 9  
+- 📚 Documentation Updates: 2  
+
+**Total**: 18 changes  
+
+Thank you to all contributors for your hard work! 🎉
+

release-notes/2.2.3/README_ZH.md

@@ -0,0 +1,126 @@
+# Higress Console
+
+
+## 📋 本次发布概览
+
+本次发布包含 **18** 项更新，涵盖了功能增强、Bug修复、性能优化等多个方面。
+
+### 更新内容分布
+
+- **新功能**: 7项
+- **Bug修复**: 9项
+- **文档更新**: 2项
+
+---
+
+## 📝 完整变更日志
+
+### 🚀 新功能 (Features)
+
+- **Related PR**: [#621](https://github.com/higress-group/higress-console/pull/621) \
+  **Contributor**: @Thomas-Eliot \
+  **Change Log**: 优化MCP Server交互能力：支持DNS后端自动重写Host头；增强直连路由场景的transport选择与完整路径配置；改进DB到MCP Server场景的DSN特殊字符（如@）解析能力。 \
+  **Feature Value**: 提升MCP Server配置灵活性与兼容性，降低用户接入复杂度，避免因路径前缀混淆或DSN解析失败导致的集成问题，增强多环境部署稳定性与易用性。
+
+- **Related PR**: [#608](https://github.com/higress-group/higress-console/pull/608) \
+  **Contributor**: @Libres-coder \
+  **Change Log**: 为AI路由管理页面新增插件展示功能，支持展开AI路由行查看已启用插件，并在配置页显示'Enabled'标签；涉及frontend/src/pages/ai/route.tsx、plugin/components/PluginList/index.tsx等核心文件改造，统一了AI路由与普通路由的插件可视化能力。 \
+  **Feature Value**: 用户可在AI路由管理界面直观查看和确认已启用的插件，提升AI服务配置的透明度与可维护性；消除新旧路由管理体验差异，降低学习成本，增强平台一致性与操作信心。
+
+- **Related PR**: [#604](https://github.com/higress-group/higress-console/pull/604) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 新增对higress.io/rewrite-target注解的正则表达式路径重写支持，扩展了Kubernetes注解常量，重构了KubernetesModelConverter中的重写配置填充逻辑，并补充了对应的单元测试用例。 \
+  **Feature Value**: 用户可通过正则表达式灵活定义路径重写规则，提升路由匹配精度与灵活性，满足复杂业务场景下的URL转换需求，降低定制化开发成本。
+
+- **Related PR**: [#603](https://github.com/higress-group/higress-console/pull/603) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 在静态服务源表单组件中定义常量STATIC_SERVICE_PORT = 80，并在UI中展示该固定端口，使用户明确知晓静态服务默认使用80端口，提升配置透明度和一致性。 \
+  **Feature Value**: 用户在配置静态服务源时能直观看到默认端口80，避免因端口误解导致的部署失败；增强界面信息完整性，降低新手使用门槛，提升整体配置体验和运维可靠性。
+
+- **Related PR**: [#602](https://github.com/higress-group/higress-console/pull/602) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 在AI路由配置的上游服务选择组件中新增搜索功能，通过扩展RouteForm组件的输入控件逻辑，支持用户实时过滤和快速定位目标服务，提升复杂服务列表中的操作效率。 \
+  **Feature Value**: 用户在配置AI路由时可直接搜索上游服务，避免手动滚动查找，显著缩短配置时间，尤其适用于拥有大量微服务的生产环境，提升运维与开发人员的配置体验和准确性。
+
+- **Related PR**: [#566](https://github.com/higress-group/higress-console/pull/566) \
+  **Contributor**: @OuterCyrex \
+  **Change Log**: 新增通义千问（Qwen）大模型服务支持，包括自定义服务地址、互联网搜索开关、文件ID上传等功能，并在前后端增加对应配置项与国际化支持。 \
+  **Feature Value**: 用户可通过Higress平台灵活对接自定义Qwen服务，提升AI能力扩展性；支持文件ID上传与联网搜索，增强实际业务场景下的AI推理能力与灵活性。
+
+- **Related PR**: [#552](https://github.com/higress-group/higress-console/pull/552) \
+  **Contributor**: @lcfang \
+  **Change Log**: 新增vport虚拟端口属性支持，扩展ServiceSource和V1RegistryConfig模型，引入VPort类，并在Kubernetes模型转换逻辑中集成vport字段映射，解决注册中心服务实例端口不一致导致的路由失效问题。 \
+  **Feature Value**: 使MCPBridge能适配动态端口变化的服务后端，提升网关对Eureka/Nacos等注册中心的兼容性；用户无需频繁更新路由配置即可应对实例端口变更，增强系统稳定性与运维效率。
+
+### 🐛 Bug修复 (Bug Fixes)
+
+- **Related PR**: [#620](https://github.com/higress-group/higress-console/pull/620) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 修复了sortWasmPluginMatchRules方法中的拼写错误，修正了匹配规则排序逻辑中的变量名和条件判断，确保Wasm插件匹配规则按预期顺序正确排序，避免因命名错误导致的逻辑错误或空指针异常。 \
+  **Feature Value**: 提升了Wasm插件匹配规则排序的正确性与稳定性，防止因typos引发的运行时异常或规则误序，保障用户配置的插件匹配策略被准确执行，增强系统可靠性与可维护性。
+
+- **Related PR**: [#619](https://github.com/higress-group/higress-console/pull/619) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 修复了AiRoute转换为ConfigMap时重复保存版本信息的问题，从data JSON中移除version字段，仅保留在ConfigMap metadata中，避免数据冗余和潜在不一致。 \
+  **Feature Value**: 提升了配置管理的准确性和一致性，防止因版本信息重复导致的解析错误或部署异常，增强系统稳定性和运维可靠性，对使用AiRoute功能的用户有直接受益。
+
+- **Related PR**: [#618](https://github.com/higress-group/higress-console/pull/618) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 重构SystemController的API认证逻辑，引入AllowAnonymous注解机制，统一处理无需认证的健康检查和登录等端点，消除原有鉴权绕过漏洞，提升系统整体安全性。 \
+  **Feature Value**: 修复了SystemController中存在的安全漏洞，防止未授权访问敏感接口，保障用户数据和系统资源的安全性，增强企业级应用的合规性与可信度。
+
+- **Related PR**: [#617](https://github.com/higress-group/higress-console/pull/617) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 修复了前端列表渲染缺少唯一key导致的React警告、CSP策略阻止外部图片加载的问题，以及Consumer.name字段类型定义错误（由boolean改为string），同时修正了路由页面中列表元素的渲染逻辑。 \
+  **Feature Value**: 提升了前端应用的稳定性和用户体验，避免控制台错误干扰开发调试，确保头像和列表内容正确显示，防止因类型错误引发的运行时异常，增强系统健壮性与可维护性。
+
+- **Related PR**: [#614](https://github.com/higress-group/higress-console/pull/614) \
+  **Contributor**: @lc0138 \
+  **Change Log**: 修复ServiceSource类中服务来源type字段的类型定义错误，增加字典值校验逻辑，确保仅接受预定义的合法注册中心类型，提升参数校验的准确性和系统健壮性。 \
+  **Feature Value**: 避免因非法type值导致的服务配置解析失败或运行时异常，增强SDK的稳定性和可靠性，使用户在配置服务来源时获得更明确的错误提示和更强的类型安全保障。
+
+- **Related PR**: [#613](https://github.com/higress-group/higress-console/pull/613) \
+  **Contributor**: @lc0138 \
+  **Change Log**: 修复前端Content Security Policy（CSP）配置缺失问题，在document.tsx中新增meta标签以声明安全策略，防止XSS等注入攻击，提升页面加载时的安全上下文完整性。 \
+  **Feature Value**: 增强前端应用安全性，有效防御跨站脚本（XSS）和恶意资源加载等常见Web攻击，保障用户数据与交互安全，符合企业级安全合规要求，提升系统整体可信度。
+
+- **Related PR**: [#612](https://github.com/higress-group/higress-console/pull/612) \
+  **Contributor**: @zhwaaaaaa \
+  **Change Log**: 在DashboardServiceImpl中新增对hop-to-hop头部的忽略逻辑，依据RFC 2616规范过滤transfer-encoding等逐跳头部，防止反向代理转发chunked编码头导致Grafana页面异常。 \
+  **Feature Value**: 解决Grafana控制台因反向代理透传transfer-encoding: chunked头而无法正常加载的问题，提升控制台稳定性与用户体验，确保监控页面可靠展示。
+
+- **Related PR**: [#609](https://github.com/higress-group/higress-console/pull/609) \
+  **Contributor**: @CH3CHO \
+  **Change Log**: 修正了Consumer接口中name字段的类型错误，将原本错误声明为boolean的字段更正为string类型，确保前端数据结构与后端实际返回一致，避免运行时类型异常和TS编译错误。 \
+  **Feature Value**: 修复该类型错误可防止因字段类型不匹配导致的前端渲染异常、表单提交失败或逻辑判断错误，提升应用稳定性与开发体验，保障Consumer相关功能（如用户信息展示、编辑）正确运行。
+
+- **Related PR**: [#605](https://github.com/higress-group/higress-console/pull/605) \
+  **Contributor**: @SaladDay \
+  **Change Log**: 修正AI路由名称的前端表单验证正则表达式，使其支持点号（.）并限制为仅小写字母，同步更新中英文错误提示文本，确保界面提示与实际校验逻辑一致。 \
+  **Feature Value**: 用户在创建或编辑AI路由时可合法使用带点号的名称（如api.v1），避免因校验规则不一致导致的表单提交失败；提示信息更准确，提升配置体验和问题排查效率。
+
+### 📚 文档更新 (Documentation)
+
+- **Related PR**: [#611](https://github.com/higress-group/higress-console/pull/611) \
+  **Contributor**: @qshuai \
+  **Change Log**: 修复了LlmProvidersController中@PostMapping接口的Swagger API文档摘要描述，将错误的'Add a new route'更正为与实际功能匹配的描述，提升API文档准确性和可读性。 \
+  **Feature Value**: 使开发者在使用控制台API文档时能正确理解该接口功能（LLM提供者创建），避免因错误描述导致的误用，提升API调试和集成效率，改善整体开发体验。
+
+- **Related PR**: [#610](https://github.com/higress-group/higress-console/pull/610) \
+  **Contributor**: @heimanba \
+  **Change Log**: 更新前端灰度插件文档，将rewrite、backendVersion、enabled字段调整为非必填，并修正rules中name字段的关联路径从deploy.gray[].name改为grayDeployments[].name，同步更新中英文README和spec.yaml中的字段描述与要求。 \
+  **Feature Value**: 提升配置灵活性与兼容性，降低用户配置门槛；通过术语统一和路径修正，避免因文档过时导致的配置错误，增强灰度功能的易用性与可维护性。
+
+---
+
+## 📊 发布统计
+
+- 🚀 新功能: 7项
+- 🐛 Bug修复: 9项
+- 📚 文档更新: 2项
+
+**总计**: 18项更改
+
+感谢所有贡献者的辛勤付出！🎉
+
+

test/e2e/conformance/tests/go-wasm-test-redis-inject-spin.go

@@ -1,75 +0,0 @@
-// Copyright (c) 2026 Alibaba Group Holding Ltd.
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-//      http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-package tests
-
-import (
-	"testing"
-
-	"github.com/alibaba/higress/v2/test/e2e/conformance/utils/http"
-	"github.com/alibaba/higress/v2/test/e2e/conformance/utils/suite"
-)
-
-func init() {
-	Register(WasmPluginsRedisInjectSpin)
-}
-
-// WasmPluginsRedisInjectSpin reproduces issue #4034: a deferred async Redis
-// failure callback synchronously calls injectEncodedDataToFilterChain, which
-// (pre-fix) makes WasmBase::doAfterVmCallActions re-queue an action forever and
-// spins a worker at 100% CPU. Redis is pointed at an unroutable endpoint so the
-// failure callbacks fire under concurrency.
-//
-// With the Layer A drain-to-local fix in place, the after-vm-call drain
-// terminates over a snapshot, deferred callbacks complete, and the gateway keeps
-// serving requests. The test asserts the plugin route stays responsive (200)
-// rather than hanging — a spinning worker would fail this via timeout.
-var WasmPluginsRedisInjectSpin = suite.ConformanceTest{
-	ShortName:   "WasmPluginsRedisInjectSpin",
-	Description: "Reproduce #4034: redis-failure callback + inject must not spin the worker; gateway stays responsive.",
-	Manifests:   []string{"tests/go-wasm-test-redis-inject-spin.yaml"},
-	Features:    []suite.SupportedFeature{suite.WASMGoConformanceFeature},
-	Test: func(t *testing.T, suite *suite.ConformanceTestSuite) {
-		testcases := []http.Assertion{
-			{
-				Meta: http.AssertionMeta{
-					TargetBackend:   "infra-backend-v1",
-					TargetNamespace: "higress-conformance-infra",
-				},
-				Request: http.AssertionRequest{
-					ActualRequest: http.Request{
-						Host:             "redis-inject-spin.com",
-						Path:             "/",
-						UnfollowRedirect: true,
-					},
-				},
-				Response: http.AssertionResponse{
-					ExpectedResponse: http.Response{
-						StatusCode: 200,
-					},
-				},
-			},
-		}
-		t.Run("WasmPlugins redis-inject-spin (#4034 CPU spin repro)", func(t *testing.T) {
-			// Drive repeated requests: on the pre-fix host the deferred callback
-			// re-queues forever and a worker spins, so the route stops
-			// responding; on the fixed host every request completes.
-			for i := 0; i < 20; i++ {
-				for _, testcase := range testcases {
-					http.MakeRequestAndExpectEventuallyConsistentResponse(t, suite.RoundTripper, suite.TimeoutConfig, suite.GatewayAddress, testcase)
-				}
-			}
-		})
-	},
-}

test/e2e/conformance/tests/go-wasm-test-redis-inject-spin.yaml

@@ -1,75 +0,0 @@
-# Copyright (c) 2026 Alibaba Group Holding Ltd.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#      http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-# A "dead" Redis: the Service (with manual Endpoints) makes Higress create the
-# envoy cluster so RedisInit succeeds and commands dispatch, but the endpoint IP
-# is unroutable (240.0.0.1, class-E) so every connection fails -> the plugin's
-# redis-failure callbacks fire, which is the #4034 trigger.
-apiVersion: v1
-kind: Service
-metadata:
-  name: dead-redis
-  namespace: higress-conformance-infra
-spec:
-  ports:
-    - name: redis
-      port: 6379
-      protocol: TCP
-      targetPort: 6379
----
-apiVersion: v1
-kind: Endpoints
-metadata:
-  name: dead-redis
-  namespace: higress-conformance-infra
-subsets:
-  - addresses:
-      - ip: 240.0.0.1
-    ports:
-      - name: redis
-        port: 6379
-        protocol: TCP
----
-apiVersion: networking.k8s.io/v1
-kind: Ingress
-metadata:
-  name: redis-inject-spin
-  namespace: higress-conformance-infra
-spec:
-  ingressClassName: higress
-  rules:
-    - host: "redis-inject-spin.com"
-      http:
-        paths:
-          - pathType: Prefix
-            path: "/"
-            backend:
-              service:
-                name: infra-backend-v1
-                port:
-                  number: 8080
----
-apiVersion: extensions.higress.io/v1alpha1
-kind: WasmPlugin
-metadata:
-  name: test-redis-inject-spin
-  namespace: higress-system
-spec:
-  defaultConfig:
-    service_name: "dead-redis.higress-conformance-infra.svc.cluster.local"
-    service_port: 6379
-    redis_key: "higress-4034-key"
-    inject_body: "injected-by-4034-repro\n"
-    inject_count: 16
-  url: file:///opt/plugins/wasm-go/extensions/test-redis-inject-spin/plugin.wasm