docs: clarify internal architecture terminology

[kayx23]

Summary

PR #894 aligned public and maintainer-facing AISIX terminology where the intended meaning was clear. A smaller set of internal implementation comments and test descriptions still uses historical terms whose architectural meaning must be confirmed before they are renamed.

This issue tracks that remaining AISIX repository work. It does not request runtime behavior changes.

Current findings

The following terms remain on main:

• “Self-hosted CP” in crates/aisix-proxy/src/auth.rs and crates/aisix-core/src/models/apikey.rs
• “v3 self-hosted CP wire” in tests/e2e/src/cases/smoke.test.ts
• “self-hosted etcd mode/deployments” and “aisix.cloud tenant” in crates/aisix-core/src/config.rs
• “standalone gateway” in crates/aisix-core/src/models/mod.rs and tests/e2e/src/cases/admin-disabled-e2e.test.ts

These phrases may refer to different concepts: an open-source gateway running without a control plane, an open-source multi-replica deployment backed directly by etcd, or a managed-mode gateway connected to AISIX Cloud. Replacing them mechanically could make the comments less accurate.

Required engineering decisions

• Confirm what “self-hosted CP” means in the API-key hashing comments.
• Confirm whether “self-hosted etcd mode” specifically means an open-source deployment that writes resources directly to etcd.
• Confirm whether aisix.cloud tenant means any managed-mode AISIX gateway or a narrower deployment context.
• Confirm whether each “standalone gateway” reference describes the product or the runtime state of a gateway running without a control plane.

Acceptance criteria

• Each affected comment or test description identifies the actual component or runtime behavior instead of using an ambiguous product label.
• AISIX Cloud remains the commercial product umbrella; Hybrid Cloud and On-Premises remain its control-plane deployment options.
• Data plane is used only for an AISIX gateway's role within AISIX Cloud architecture.
• Valid descriptions of self-hosted upstream models or services remain unchanged.
• Public comments are self-contained and do not depend on inaccessible repository links or private issue context.
• No runtime behavior, compatibility identifier, configuration key, or test behavior changes as part of this terminology cleanup.

Reference

• docs: align AISIX product terminology #894 — completed the source-backed terminology changes whose meaning did not require additional engineering interpretation.

[coderabbitai]

🔗 Related PRs

#843 - docs: bring the README in line with what the gateway actually ships [merged]
#872 - feat(config): lenient etcd parsing with tri-state compatibility reporting [merged]
#875 - feat(mcp): single-server endpoint /mcp/{server} with original tool names [merged]
#894 - docs: align AISIX product terminology [open]
#896 - revert: mid-stream fallback (#882) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!