BitzOrcas.Cli 1.0.0-alpha.1

BitzOrcas.Cli (bitz)

BitzOrcas.Modern 企业级全生命周期开发者工具链与脚手架引擎
统一身份准入 · 稳态硬件防拔插锁 · 强类型客户端代理 · CQRS 垂直切片物化 · 双模设计工作台 · 全链路自愈诊断

---

1. 核心定位与架构概览

bitz（NuGet 包标识符 BitzOrcas.Cli）是面向 BitzOrcas.Modern 企业微内核与整洁架构体系设计的工业级全能开发者 CLI 工具。作为现代化工程体系的统一基石与全生命周期入口，它彻底解决了传统分布式团队面临的环境准入混乱、硬件锁误触漂移、端到端契约频繁漂移、CQRS 样板代码臃肿及依赖投毒等痛点。

核心能力全景：

• 统一身份准入与硬件锁保护 (bitz login / bitz lic sync / bitz status)：默认对接 LicenseHub /api/v1/auth/login 账号密码登录（密码经 RSA-OAEP-SHA256 密文传输，服务器时间戳免疫本机时钟偏差），支持 PAT 注入与 --sso 浏览器回环认证；底层智能穿透虚拟网卡与 USB 扩展坞芯片，锁定板载物理网卡生成稳态机器码，彻底根治工位拔插扩展坞造成的误锁机问题。首次审批通过后，bitz lic sync 复用本地会话即可滚动续租。
• 正交应用脚手架向导 (bitz new)：提供交互式 TUI 向导与 5 种场景驱动预设（企业单租户系统、多租户 SaaS 云、移动跨端小程序、官方门户与无头 API 资源服务）；坚持纯净白板原则（Clean by Default），杜绝 Starter 冗余代码污染。
• 确定性接线变异 (bitz add module / bitz remove module)：严格遵循确定性七点变异契约，在模块工程、宿主 Api 引用、Program 组合根、建库迁移、解决方案结构、单元测试及规范文件头等 7 处接线点原子写入/卸载。
• 集中包管理与供应链防投毒 (bitz add-package / bitz remove-package)：原生感知 CPM（Directory.Packages.props），并自动同步维护 nuget.config 中的 packageSourceMapping，物理级隔离公网 NuGet.org 与内部商业私有源。
• OpenAPI 强类型代理生成 (bitz generate-proxy)：一键将 OpenAPI 3.0 / 3.1 规范物化为 C# 强类型客户端 SDK（含 HttpClient、DTO、XML 注释、连接池与 DI 扩展）及 TypeScript 前端 SDK（camelCase 接口与枚举字典）。
• CQRS 垂直切片自动化物化 (bitz generate-slice)：基于微内核标准，一键输出统一聚合根（继承 TenantAggregateRoot）、领域事件、DTO、Command/Query 处理器、Minimal API 路由及 MCP Tool 智能体标记。
• 双模设计工作台 (bitz suite)：支持终端交互式 TUI 与本地微型 Web Studio（http://127.0.0.1:5200）双模式，实时 AST 语法树动态预览与一键落盘。
• 全链路体检与自愈诊断 (bitz doctor --fix)：包含 8 项底层环境探针（OS 架构、.NET 10 SDK、前端工具链、Docker、硬件稳定性、许可证期效与包源映射），--fix 自动自愈修复配置缺陷。

---

2. 全局安装与快速入门

2.1 全局工具安装

# 从官方 NuGet.org 安装全局工具
dotnet tool install -g BitzOrcas.Cli

# 若已安装历史版本，执行升级
dotnet tool update -g BitzOrcas.Cli

# EF Core persistence channel (SQL Server dialect migrations)
bitz new MyApp --preset enterprise-saas --orm efcore

# Custom composition
bitz new MyApp --preset custom --tenancy single --capabilities identity,auth --slice blank

# Playground sandbox + Vue admin frontend
bitz new MyApp --preset enterprise-saas --slice Order --sandbox true --frontend vue-admin --silent

# Portal preset with the Astro content site (`astro` is pinned to ^7.0.0)
bitz new MyPortal --preset portal --non-interactive

# Skip generated-output self-verification (offline / no commercial feed)
bitz new MyApp --preset enterprise-saas --non-interactive --skip-verify

# Mutate an existing bitz-generated solution (deterministic seven-point wiring)
bitz add module Billing --project ./MyApp
bitz remove module DevSandbox --project ./MyApp

# Diagnostics and environment check
bitz doctor

# Version info
bitz version

AI intent-driven modeling (bitz ask)

bitz ask converts a natural-language requirement into a validated entity model and scaffolds the CQRS vertical slice after an interactive preview. It works with any OpenAI-compatible Chat Completions endpoint:

export BITZ_AI__ENDPOINT=https://api.deepseek.com/v1/chat/completions
export BITZ_AI__APIKEY=sk-...
export BITZ_AI__MODEL=deepseek-chat

# Local Ollama needs no API key:
#   BITZ_AI__ENDPOINT=http://localhost:11434/v1/chat/completions
#   BITZ_AI__MODEL=qwen2.5:7b

bitz ask "创建一个员工考勤打卡实体，包含工号、打卡时间、打卡地点与迟到状态"
bitz codegen --prompt "设计工单流转聚合根" --dry-run   # same inference core

Endpoint settings may also live in appsettings.local.json under Ai:Inference. The API key is only used for the request header and never logged.

Stability knobs (transient failures such as HTTP 429/408/5xx and network errors are retried with exponential backoff; 429 honors the server Retry-After header):

export BITZ_AI__MAXATTEMPTS=3       # total attempts incl. the first (1-6)
export BITZ_AI__TIMEOUTSECONDS=180  # per-attempt timeout (5-600); timeouts are not retried

Retry traces surface in bitz ask preview notes and the Studio AI copilot chat.

Streaming (typing-effect output including the model's reasoning process for reasoning-style models such as DeepSeek-R1 / QwQ) is a toggleable setting:

export BITZ_AI__STREAM=true   # default on/off for `bitz ask`
bitz ask "..." --stream       # force on for one run (--no-stream to force off)

In the Studio copilot drawer the "流式思考" checkbox controls it per session; the backend exposes POST /api/suite/ai/infer-stream (SSE) emitting delta (reasoning/content) frames followed by a final result frame. Deltas already emitted are never replayed — a stream that fails mid-way reports a structured failure instead of retrying.

Database & schema operations (bitz db / bitz schema)

bitz db backup / restore / export and bitz schema sync / diff / validate-seed operate on the product repository: bitz schema reads the compile-time entity manifest closure held by BitzOrcas.SchemaMaintenance (located automatically inside this repo, or via BITZ_SCHEMA_TOOL).

Consumer solutions are different by design. A generated consumer host already ships its own schema operations channel:

dotnet run --project src/YourName.Api -- --migrate-schema plan|status|apply

Use that for consumer drift detection and safe DDL application — bitz schema is not wired to consumer manifests. Database credentials for both channels come from workspace configuration files only (ConnectionStrings / SqlSugar sections); passwords are always masked in output.

MCP server (bitz mcp serve)

bitz mcp serve runs the CLI itself as a Model Context Protocol (2024-11-05) server over Stdio JSON-RPC 2.0 and exposes four tools: bitz_scaffold_slice (default preview-only; pass write: true to persist), bitz_list_modules, bitz_reverse_db (reads the connection only from the workspace configuration and masks secrets), and bitz_check_doctor.

Cursor — .cursor/mcp.json:

{
  "mcpServers": {
    "bitz": { "command": "dotnet", "args": ["/path/to/BitzOrcas.Cli.dll", "mcp", "serve"] }
  }
}

Claude Desktop — claude_desktop_config.json (Developer Settings):

{
  "mcpServers": {
    "bitz": { "command": "dotnet", "args": ["/path/to/BitzOrcas.Cli.dll", "mcp", "serve"] }
  }
}

Antigravity / generic MCP clients — point the stdio command at bitz mcp serve (use command: "bitz" with args: ["mcp", "serve"] after dotnet tool install --global BitzOrcas.Cli).

Contract anchors

The templates and the generated READMEs share one vocabulary with the platform knowledge base sections PRD/10-底座Platform支撑/A9-CLI快速初始化预设.md (FR3 frontend deepening, FR4 Taro overlay, FR5 generated-output self-verification, FR6 documentation) and PRD/10-底座Platform支撑/A9 §5 GAP-C6 (zero built-in credentials) / GAP-C8 (explicit frontend build sanitization). Contract baselines for generated hosts stay in docs/architecture/00-governance/0014-bitz-cli-scaffolding-ledger.md.

Generated-output self-verification

bitz new verifies what it just produced: dotnet build on the generated solution, then npm install plus the strongest frontend script that can run at generation time inside the generated frontend/. A failed verification keeps the generated files and exits with code 3, so scripts can tell "nothing was generated" (exit 1/2) apart from "generated, but did not build".

The frontend step is chosen from the generated package.json, not hardcoded per frontend:

Frontend	Script run	Why
react-admin / vue-admin	npm run build	fully offline (Vite build, no backend calls)
astro-site	npm run verify (astro sync)	its production npm run build renders content pages from the public read contract, which cannot exist at generation time
taro-mobile	none (stops at npm install)	there is no build script until taro init has run

Skipping the portal's npm run build does not weaken the "never publish a silently empty site" guarantee: the template still throws at build time when the public read contract is unreachable, and npm run verify never renders pages. Only when that build runs changes. Every skipped or downgraded step is printed as an explicit ⓘ notice, and the generated portal README states that content-page renderability must be verified in CI/deploy with PUBLIC_API_BASE_URL set.

Failure output names the step that failed and classifies its cause: missing commercial feed (BITZFEED001), package not delivered to the feed (NU1101/NU1102), missing PackageVersion row (NU1010), unavailable feed credentials (NU1301/401/403), unreachable package source (ENOTFOUND/EAI_AGAIN/ETIMEDOUT/ECONNREFUSED), or a generated-code compile error (error CS). The --skip-verify hint is printed only for environment-caused failures; template defects explicitly tell the reader that skipping would only hide the defect until the consumer's first compile.

Offline environments and environments without BITZORCAS_COMMERCIAL_FEED_URL must pass --skip-verify. Programmatic callers (ProjectScaffolder.Execute from tests or tooling) default to WizardOptions.VerifyGeneratedOutput = false so contract tests never shell out to a build.

Demo credentials

Templates ship zero built-in credentials. bitz new generates a project-level random demo password in the same shape as scripts/local/bootstrap.sh (Bitz! + 36 hex characters + Aa1) and persists it, owner-only (0600) and git-ignored, to .bitzorcas/demo-credentials in the generated project. The generated host reads it back through DemoCredentialFile during configuration composition, and --seed-only consumes it for the privileged super admin (tenant 1000001 / admin). Login pages and READMs only point at that file; no plaintext is ever printed or written into a template.

Explicit configuration always wins over the local file, in this order: Identity:SuperAdmin:Password > Parameters:demo-user-password > USER__ADMIN__PASSWORD > .bitzorcas/demo-credentials.

Frontend selection

--frontend is a set, not a single value: real projects routinely need a content site and an admin console, and mini-program projects need the admin console too. Comma-separated values compose, and the historical single-value spelling is just the one-element set:

bitz new MyApp --preset portal --frontend astro-site,react-admin
bitz new MyApp --preset enterprise-saas --frontend vue-admin
bitz new MyApp --frontend none          # pure backend: no Node project emitted at all

The admin console is always included. Any non-empty selection is normalized to contain react-admin or vue-admin, because a generated "full-stack" project without a management surface is not a deliverable state. none means pure backend and cannot be combined with other shapes; react-admin,vue-admin is rejected at parse time because both write the same app directory.

Preset defaults are sets for the same reason: portal → website + app, mini-program → app + app-mobile, enterprise-saas / multi-tenant-cloud / headless-api → app. An explicit --frontend replaces the preset default rather than merging into it, so a shape a preset would add can still be dropped deliberately.

Generated layout mirrors the product frontend repository:

frontend/
  package.json          # workspace root: declares apps/* and aggregate scripts
  apps/website/         # Astro content site
  apps/app/             # admin console (React or Vue)
  apps/app-mobile/      # Taro mini-program / cross-platform bootstrap

One workspace root collects every app, so a single npm install under frontend/ covers all of them; independent roots would duplicate the toolchain and let each app drift onto its own builder version. The @bitz/platform-sdk opt-in stays an explicit peerDependencies reference per app — the templates never add it implicitly.

Migration note: frontend multi-select

• Layout moved from frontend/ (one app, files at the workspace root) to frontend/apps/<shape>/, and the workspace root now owns frontend/package.json with workspaces: ["apps/*"]. Already-generated projects keep working unchanged; only newly generated ones use this layout.
• --preset portal now yields website + app (previously the Astro site only) and --preset headless-api now yields app (previously no frontend), because the admin console is always included. Pass an explicit --frontend to reproduce the old composition.
• --frontend none, or omitting both --frontend and --preset, still emit no frontend, so the scripted CI baseline does not start producing Node projects by accident.

Frontend build sanitization

Every generated frontend declares production sanitization explicitly instead of relying on builder defaults: sourcemap: false plus drop_console / drop_debugger equivalents.

Frontend	Builder	Declaration
react-admin / vue-admin	Vite 5	build.sourcemap: false + esbuild.drop: ['console', 'debugger'] under command === 'build'
astro-site	Astro 7 (^7.0.0)	vite.build.sourcemap: false + a build-only Vite plugin calling transformWithEsbuild(..., { drop: ['console', 'debugger'] })
taro-mobile	Taro overlay	mini/h5 webpackChain disabling devtool + Taro terser compress.drop_console / compress.drop_debugger

Astro config is a plain object on purpose: Astro's defineConfig does not accept the Vite-style function form, and a returned function is silently ignored — sanitization would look configured while nothing is emitted.

Central package management

Generated solutions use central package management, so every emitted PackageReference needs a matching PackageVersion row in the generated Directory.Packages.props; otherwise restore fails with NU1010 before NuGet even looks at a feed. Because the version list is a literal in SolutionScaffolder.GenerateDirectoryPackagesProps, a new capability branch can silently add a reference without a version row — exactly how the Website and standalone-RiskControl branches broke.

Generated_Projects_Should_Declare_PackageVersion_For_Every_PackageReference guards this generally: it scaffolds sixteen preset/capability/ORM/topology combinations and asserts every PackageReference in every generated .csproj (host, job host, modules, sandbox, tests) has a matching PackageVersion and never carries an inline Version. It reports the offending package id and file, so the next such omission fails with the exact fix instead of an opaque restore error.

Website capability packages

--preset portal / --capabilities website emit references to the four BitzOrcas.Platform.Website.* packages plus the BitzOrcas.Profile.Portal aggregate. All eight packages in that closure are registered visibility: commercial with signingRequired: true in the 0010 catalog, and every one of them sets IsPackable, so they are all reachable from the commercial feed. This is a machine-checked invariant, not a convention: read-commercial-package-catalog.py --validate now fails closed when a commercial entry has no packable source project, which is exactly how the three adapters that used to be declared commercial but never packed were found.

Golden_Build_Website_Portal_Project_Should_Compile is the acceptance gate for the channel. scripts/build/test-golden-cli-gate.sh arms BITZ_CLI_GOLDEN_BUILD itself, and whenever a commercial feed is available it arms BITZ_CLI_GOLDEN_WEBSITE_BUILD as well — after asserting the feed really carries all eight closure packages, naming the missing ones otherwise. With no feed at all the gate exits 2 and prints an explicit "not exercised" banner; it never reports a silent pass.

Golden path of a generated project

验证安装是否成功

bitz --version

> **跨平台 PATH 配置说明**：
> - **macOS / Linux**：确保 `~/.dotnet/tools` 已加入用户 PATH。可在 `~/.zshrc` 或 `~/.bashrc` 中追加：
>   ```bash
>   export PATH="$PATH:$HOME/.dotnet/tools"
>   ```
> - **Windows**：系统通常会在安装 .NET SDK 时自动将 `%USERPROFILE%\.dotnet\tools` 加入用户环境变量。

---

## 3. 开发者五分钟黄金实践路线

### 步骤 1：工位统一身份准入与设备激活 (`bitz login`)

```bash
# 对接内网授权中心（LicenseHub），交互输入账号密码（默认认证模式）
bitz login --server http://192.168.1.172:8030

# 脚本化一键准入（凭据也可经环境变量 BITZ_USERNAME / BITZ_PASSWORD 注入）
bitz login --server http://192.168.1.172:8030 --username alice --password 'secret'

# CI/CD 或无头终端：直接注入个人访问令牌 (PAT)
bitz login --token pat_sec_xxx

# 生产部署接入 Keycloak 统一身份时使用浏览器 SSO（可选 codeup / wecom / saas）
bitz login --sso --provider wecom

CLI 自动采集板载主物理硬件指纹，将准入数字证书安全持久化至 ~/.bitz/bitz-dev.lic。若设备尚待管理员审批，会话仍会保存，审批通过后直接执行续租即可。

步骤 2：查看工位健康与授权状态 (bitz status)

bitz status

展示当前机器硬件特征、证书绑定状态、100% 匹配度、准入认证源，以及软期限（建议联网续期）与硬期限（编译期防篡改锁机）倒计时。

步骤 2.1：日常租约滚动续租 (bitz lic sync)

bitz lic sync

复用 bitz login 保存的本地会话（~/.bitz/auth.json）向授权中心提交机器码并拉取续签凭据，无需重新认证；软期限告警或硬期限临近时在联网环境执行一次即可。

步骤 3：创建全新微内核工程 (bitz new)

# 交互式向导模式（推荐新手使用）
bitz new LicenseHub

# 或通过场景驱动预设免交互快速生成
bitz new DemoSaaS --preset enterprise-saas --orm sqlsugar --non-interactive

# 生成带有 React 前端与切片的复杂 SaaS 平台
bitz new CloudApp --preset multi-tenant-cloud --frontend react-admin --non-interactive

Seeding provisions the privileged super admin (tenant 1000001 / admin) with the randomly generated password stored in .bitzorcas/demo-credentials; demo accounts are only created when USER__<NAME>__PASSWORD environment variables are set (fail-closed password injection, see the generated project README). The generated host currently ships seed + JWT composition only — the interactive HTTP login endpoint group is on the scaffolding roadmap (ledger 0014), so HTTP login acceptance still runs against the platform host.

步骤 4：生成工程的编译与启动黄金路径

cd DemoSaaS

# 1. 应用数据库架构迁移
dotnet run --project src/Hosts/DemoSaaS.Api/DemoSaaS.Api.csproj -- --migrate-schema apply

# 2. 安全初始化数据种子（参见下文安全规范）
dotnet run --project src/Hosts/DemoSaaS.Api/DemoSaaS.Api.csproj -- --seed-only

# 3. 启动后端 API 服务
dotnet run --project src/Hosts/DemoSaaS.Api/DemoSaaS.Api.csproj

---

4. 严谨的安全与凭据管理规范 (Security Policy)

4.1 种子账户与口令注入机制

1. 开发与测试环境（Development / Staging）：

   • 系统种子步骤（BuiltinIdentitySuperAdminSeedStep）默认仅作为受控沙箱使用；
   • 开发者如需设置超级管理员账户初始口令，必须通过环境变量或受控本地配置注入：

     # 通过环境变量动态注入超级管理员口令（推荐）
     export BITZ_SUPERADMIN_PASSWORD="YourSecurePassword@2026"
     dotnet run --project src/Hosts/DemoSaaS.Api/... -- --seed-only
     

   • 业务演示账号（Demo Accounts）遵循 Fail-Closed 原则：未显式配置 USER__<NAME>__PASSWORD 环境变量时，系统绝不预设假口令，确保开发沙箱与外部公网物理隔离。

2. 生产环境（Production）：

   • 生产环境启动时，--seed-only 处于严格阻断模式，严禁自动执行未经审计的演示种子数据注入；
   • 敏感凭据必须通过企业级 KMS、Azure Key Vault、HashiCorp Vault 或 Kubernetes Secret 密文卷动态注入；
   • 系统全面启用首次登录强制修改口令与两步认证（2FA / Step-up Authentication）策略。

---

5. 全量常用命令速查手册

5.1 身份准入与硬件维护

命令	说明与典型示例
bitz login	设备统一准入与硬件锁激活（默认账号密码登录，交互输入；--server 指向内网授权中心）
bitz login --token <pat>	使用个人访问令牌 (PAT) 一键准入（CI/CD 与自动化流水线首选）
bitz login --sso --provider wecom	切换至浏览器 SSO / 企业微信扫码认证通道（面向接入统一身份网关的部署）
bitz lic sync	复用本地登录会话向授权中心滚动续租开发凭据（免重新登录）
bitz lic buildagent issue	向授权中心现签 CI/CD 流水线短期构建凭据（≤168 小时，落盘 ~/.bitz/bitz-dev.lic）
bitz lic buildagent revoke --credential-id <id>	吊销指定 BuildAgent 凭据（进入服务端审计）
bitz status	检查本机硬件匹配度、证书有效性及软硬期限
bitz logout	注销当前工位凭据并清理本地敏感令牌缓存

5.2 工程生成与架构管理

命令	说明与典型示例
bitz new <AppName>	启动交互式终端脚手架向导
bitz new <AppName> --preset <preset>	根据场景预设免交互构建（enterprise-saas, multi-tenant-cloud, portal 等）
bitz add module <Name>	向当前解决方案遵循 7 点契约安全挂载新业务模块
bitz remove module <Name>	原子性卸载业务模块并安全回退所有依赖接线
bitz add-package <PackageId>	在集中式 CPM（Directory.Packages.props）中声明依赖并维护包源映射
bitz remove-package <PackageId>	从集中式包管理与所有引用项目中彻底移除指定依赖

5.3 代码生成与可视化建模

命令	说明与典型示例
bitz generate-proxy csharp --spec <url>	解析 OpenAPI 生成包含 DI 扩展的强类型 C# HttpClient SDK
bitz generate-proxy ts --spec <url>	解析 OpenAPI 生成适配 Axios/Fetch 的 TypeScript 前端 SDK
bitz generate-slice <Entity> --module <Mod>	全自动生成统一聚合根、CQRS 读写切片、Minimal API 与 MCP Tool
bitz suite	启动终端 TUI 交互式代码切片建模向导
bitz suite --web --port 5200	启动本地微型 Web Studio 设计器（深色拟态极客界面）

5.4 运维体检、清理与自愈

命令	说明与典型示例
bitz doctor	执行全链路 8 项深度环境探测（OS、SDK、工具链、硬件锁等）
bitz doctor --fix	一键自愈修复配置缺陷并自动补齐 packageSourceMapping 防投毒规则
bitz clean	递归深度清理全仓 bin/、obj/、Roslyn 源生成器缓存并统计释放空间
bitz install-libs	自动探测并恢复前端工程依赖（pnpm / yarn / npm 自动适配）
bitz update	检查并自动升级 BitzOrcas 框架核心包版本

---

6. 供应链投毒防御（Package Source Mapping）

在混合了公共 NuGet.org 与企业内部私有制品仓库的开发环境中，为杜绝依赖混淆（Dependency Confusion）攻击，工程根目录下的 nuget.config 必须启用命名空间映射。bitz doctor --fix 可全自动生成如下安全规则：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="BitzOrcasCommercial" value="%BITZORCAS_COMMERCIAL_FEED_URL%" />
  </packageSources>

  <packageSourceMapping>
    
    <packageSource key="nuget.org">
      <package pattern="*" />
      <package pattern="BitzOrcas.Cli" />
      <package pattern="Microsoft.*" />
      <package pattern="System.*" />
    </packageSource>

    
    <packageSource key="BitzOrcasCommercial">
      <package pattern="BitzOrcas.*" />
      <package pattern="LicenseHub.*" />
      <package pattern="Bitzsoft.Licensing.*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

---

7. 退出码规范（Exit Code Contract）

CLI 在持续集成（CI/CD）流水线中严格遵循 Fail-Fast 原则：

• 0 (Success)：命令顺利执行完毕；bitz doctor 恒退出 0（检测报告供判读，不阻断自动化流水线）。
• 1 (Refusal / Security Block)：业务逻辑或安全检查被阻断（例如：模块已存在、工程缺少接线锚点、准入握手被服务端拒绝、机器码硬期限超期锁机）。
• 2 (Argument / Syntax Error)：输入了未知的命令行参数、缺少必填参数、枚举取值非法（例如指定了未受支持的持久化方言）。

---

8. 开源许可与支持

• 开源协议：本项目基于 Apache License 2.0 协议发布。
• 官方文档：请查阅组织内部知识库与微内核架构开发手册。
• 问题反馈：如在使用过程中遇到任何异常或有功能建议，欢迎在组织内部平台提 Issue 或联系架构委员会。