<user>
https://github.com/LeoLoudWarden/micalang 这是我刚发的项目，我现在有点担心，你以一个外人的视角看一下这个理念成不成立，有没有硬伤。以及主观上说会不会遭受质疑。还有会不会无人问津（这个倒没有前面的可能性严重了，真凉了我也无所谓了）。
</user>


<ai>
看完了。仓库本体（README、design.md、security.md、language-reference.md）加 GitHub API 元数据都核过，先例也查了一圈。按你问的三件事分述，每条判定给出依据档位。

---

## 一、理念成不成立：成立，但有三个待补的洞

**核心理念（零能力默认 + 任意嵌套 + 逐层授予 + 祖先计费配额）在概念上是自洽的，且有历史验证**——这不是我客气话，见下面的先例部分。文档质量在 0.1.0 项目里属于异常高的一档：design.md 明确区分"设计目标 vs 原型现状"、主动承认"cheap 是未实测的方向而非事实"、security.md 把不保证的事项逐条列出——这些恰恰是多数同类项目死掉的地方，你都处理了。

硬伤候选按严重度排：

**1.（最实际）"Python 子集"是双刃剑，而当前语言面恰好卡在 LLM 场景最疼的位置。** 你宣称的头号驱动场景是"执行 LLM 生成的脚本"，但模型写 Python 的肌肉记忆是 `text.split()`、`", ".join(xs)`、f-string、切片——Mica 全部在编译期拒绝（language-reference 第 6、8 节：无任何方法、无切片、无 f-string、无闭包、无 *args）。**外观越像 Python，near-miss 的挫败率越高**：模型生成的代码看着完全合法、一跑就 `type_error`。这不是"功能以后再加"的问题，是"语言的视觉形态在主动诱导非法输入"。Roadmap 里 list/dict/str 方法排第一，方向对，但在补上之前，LLM 场景的卖点是打折的。

**2.（已声明但仍是结构性天花板）"cheap"这个立身主张目前零实测。** design.md 第 2 节的整个论证——用户态虚拟化比进程/容器/WASM 便宜——落到执行层面，Python 写的解释器每条指令的开销是宿主 Python 的几十上百倍。对"LLM 工具调用"场景这可能无所谓（脚本短），但"像建 Lua 子表一样便宜"是量化主张，README 和 design 都没有一个数字。Roadmap 里有 benchmark，但在 benchmark 落地前，所有成本论证都是结构论证而非实证。这是"存疑"档，不是"证伪"档。

**3.（小但真实）无任何并发/异步故事。** LLM 场景的典型形态是成百上千脚本并发执行，而架构是单 dispatch loop + 阻塞式 `run()`。0.1.0 可以没有，但 design.md 完全没提这个方向，而它是你引用的成本类比（进程→线程→协程）的自然延伸——你自己用并发演化史论证轻量化的正当性，读者会追问"那 Mica VM 的协程在哪"。

## 二、会不会遭受质疑：会，主要质疑点可枚举

**质疑 1（最锋利）：先例覆盖不全，漏掉了最近的那个祖先。** design.md 的"为什么不用 WASM/gVisor/Starlark"段落防住了常规问题，但漏了 **Tcl Safe-Tcl**——1992 年 Borenstein/Rose 原型就实现了"安全解释器 + alias 机制向上层请求受控能力"，Tcl 7.5（约 1995）起 `interp create -safe` 就是语言内建，slave 可以再建 slave 形成任意层级，alias 就是你的 FFI 能力授予。懂行的人会直接说："你说的'没有任何方案落在语言自身域内'是错的，Tcl 三十年前就坐在那个点上，连嵌套带能力授予。" **但注意这个质疑的真正解法不是防守而是反攻**：Safe-Tcl 恰恰证明理念成立——它的已知弱点是 DoS 防护（Safe-Tcl 论文专门有 Denial-of-Service 一节承认资源管制薄弱），而你的祖先计费配额正是补这个的。写一篇 prior-art 对比，把 Tcl 列为第一先例并讲清差异点（配额树、step/snapshot/terminate、纯数据深拷贝边界），质疑 1 就从致命伤变成你的论证素材。历史死因也清楚：Tcl 输了市场，不是这个机制输了。

**质疑 2："为什么不用 starlark-pyo3？"** starlark-pyo3 提供"sandboxed、Python 语法、嵌入 Python 宿主"，形态和 Mica-PY 几乎完全重合，背后是 Google/Bazel 的实战史。这是 Python 生态用户的第一反应问题。你的真实差异在嵌套 VM + 配额 + 单步/快照调试接口——但 README 一个字没提。不写清楚，这个问题会被问一百遍。

**质疑 3："Python 进程内沙箱也配叫安全边界？"** 历史阴影是真实的（RestrictedPython、pysandbox 均被废弃），但你编译到自有指令流、不经 exec/eval 的架构绕开了它们失败的根因（试图在 CPython 对象模型上贴封条）。README 的 security note 和 security.md 第 3 节的诚实声明能挡住认真读文档的人；挡不住的是评论区只看标题的人。这一档属于"会有噪音但打不穿"。

**质疑 4：名字。** README 披露了 Windows Mica、PyPI MICA、inactive Rust Mica——但漏了一个看起来**活跃**的：mica-dev.com 上有个 Mica 语言，2026 年 9 月还在发 7.5.0。这个我只看了搜索结果摘要，未深入核实，标"存疑"，建议你亲自查一下。如果属实，"Mica"作为语言名是双重撞车，好在仓库/包名是 `micalang`，影响可控。

**质疑 5：AI 辅助开发标签。** 主动披露是对的策略（藏着掖着被扒出来才是灾难），且有 198 测试 + CI + 对抗审查记录做对冲。仍会有"vibe-coded"的一眼 dismissal，这属于时代噪音，无法消除也不需要消除。

## 三、会不会无人问津：大概率会，但和项目质量无关

新语言/运行时项目的关注分发几乎只有几条窄道（HN、Reddit r/ProgrammingLanguages、中文侧 V2EX/即刻），0 star、无 benchmark、"又一个小众语言"的默认结局就是沉没。现在仓库 0 star 0 fork，创建于今天。你说凉了无所谓，那就只给一条最高杠杆建议：**把"LLM 生成代码的执行沙箱"做成一个可复现的对比 demo**（Mica vs subprocess vs starlark-pyo3，同样的恶意/失控脚本各跑一遍），英文写出来——这比任何理念阐述都有传播力。另外架构文档和 build journal 目前中文-only，英文受众点开 docs 看到一半中文会直接流失，README 里说 English versions are planned，这个优先级值得提高。

---

**总结判定**：理念成立（有 Safe-Tcl 三十年先例背书，且你的配额树补的是它的已知死因）；无致命硬伤，但"语言面 near-miss"和"cheap 无实测"是两个必须在被质疑前自己先补的实质缺口；质疑一定会来，主要集中在先例覆盖和 Python 沙箱历史阴影，两者都有现成答案，前提是写进文档而不是等评论区教。
</ai>


<user>
Safe-Tcl 这个你看怎么补
</user>


<ai>
证据补齐了，而且比我预想的更有利：Safe-Tcl 的原始论文（Levy/Demailly/Ousterhout/Welch, USENIX 1998）里有一段可直接引用的"认罪书"，Tcl 后续的补丁史也恰好把 Mica 的差异点衬托得很干净。先说修复策略，再给可直接粘贴的文本。

## 修补策略：不是"补一段引用"，而是改一句话 + 加一节

**第一步，必须先改 design.md §2 里那句会被抓住的话。**

现在这句：

> none sits at the point of "the language's own domain"

对 Tcl 是假的。Tcl 的 `interp create -safe` 自 1996 年 4 月的 Tcl 7.5 起就是语言内建，safe interp 可以再生 safe interp 形成层级，alias 机制就是你的 FFI 能力授予。这句话留着，懂行的人引用它就能否定整个 design.md 的可信度——不是因为理念错了，而是因为**你没查过自己的祖先**。

**第二步，把 Safe-Tcl 从"威胁"改写成"论据"。** 关键史实链条：

- Safe-Tcl 为"active email"而生——代码通过信道送达、在本地执行。这和 LLM 工具调用是**同一个问题形状**：代码通过信道（模型输出）送达、在本地执行。三十年前的场景消失了，问题形状在 LLM 时代以百万倍规模回来了。这句话本身就是 design.md §4（LLM 关系）最好的开场。
- 1998 年论文明确承认 DoS 没解决："Safe-Tcl currently does not prevent most denial-of-service attacks. We will address this in the future with a combination of resource controls and a kill-key"。
- 这个"future"迟到了十年：Tcl 8.5 才经 TIP 143 引入 `interp limit`，且只有 time 和 command count 两种、**按单个解释器计**——TIP 143 的 rationale 原话是"it is trivial for scripts running in even safe Tcl interpreters to conduct a denial-of-service attack"。

于是 Mica 的真实定位一句话就能说清：**Safe-Tcl 验证了机制，Mica 补上它至死未补的那半——配额树（只紧不松 + 子孙消耗计入全部祖先）和把子 VM 当可检查对象（step/snapshot/terminate）**。这不是防御姿态，是"站在显式承认缺口的巨人肩膀上"。

## 可直接粘贴的文本

**A. design.md §2 替换段**（换掉现有 "You might ask: why not WASM runtimes..." 那一整段）：

```markdown
You might ask: hasn't this been done? The honest answer is: yes, once, almost
exactly — and the precedent is the strongest evidence that the idea is sound.

Tcl has had safe interpreters as a language built-in since Tcl 7.5 (1996),
descending from Borenstein and Rose's 1992 Safe-Tcl prototype built for "active
email" — code arriving over a channel to be executed locally, the exact problem
shape that LLM tool calls recreate today. A safe interpreter starts with unsafe
commands disabled; the master grants mediated capabilities back through aliases;
safe interpreters can create their own children, forming a hierarchy. Isolation
as a first-class, nestable language operation with explicit capability granting
is, therefore, a thirty-year-old validated mechanism — not a new speculation.

But Safe-Tcl stopped halfway, and said so itself: the 1998 security-model paper
(Levy, Demailly, Ousterhout, Welch) admits "Safe-Tcl currently does not prevent
most denial-of-service attacks", promising future "resource controls and a
kill-key". Tcl only gained per-interpreter resource limits in 8.5 (TIP 143), and
only two kinds — wall-clock time and command count, per interpreter, with no
memory/output accounting and no charging of a child's consumption to its
ancestors. The kill-key arrived even later (`interp cancel`, 8.6). Safe-Tcl also
died with its host language: the mechanism lost nothing — Tcl lost the market.

Mica's position in this lineage is precise: keep the validated core (zero
capabilities by default, explicit granting, recursive nesting), and supply the
missing half — a quota tree (instructions, memory, output, files, children,
depth; tighten-only; a child's consumption charged to all ancestors) and the
child VM as an inspectable object (statement/instruction stepping, state
snapshots, termination). WASM runtimes, microVM sandboxes, gVisor, and Starlark
each solve adjacent points on the cost spectrum, but none of them makes "creating
an isolated world" a statement-level capability of the language itself with
resource governance built into the nesting relation.
```

**B. 新增 `docs/prior-art.md`**（中英都要，或至少英文——理由见最后）：

```markdown
# Prior art and related work

Mica does not claim the idea of in-language isolation is new. It claims the
idea was proven once, abandoned unfinished for historical reasons, and is now
worth completing.

| | Safe-Tcl (1992/1996) | Starlark | WASM runtimes | Mica |
|---|---|---|---|---|
| Isolation is a language-level statement | yes (`interp create -safe`) | no (embedding API) | no (external runtime) | yes (`VM(...)`) |
| Recursive nesting of isolated worlds | yes | no | host-mediated | yes |
| Capability granting to children | yes (aliases) | partial (globals injection) | yes (host imports) | yes (FFI, pure-data both ways) |
| Resource quotas | none until Tcl 8.5; then time + command count only, per-interp | none (host times out) | fuel/memory (engine-specific) | instruction/memory/output/file/children/depth, tighten-only, charged to all ancestors |
| Parent-side introspection | none (cancel only, 8.6) | none | engine-specific | step / step_instruction / snapshot / terminate |
| Deterministic-ish, hermetic | no | yes (core goal) | yes | no (I/O and files by design) |

What Mica takes from Safe-Tcl: the padded-cell model, zero-default capabilities,
granting as the only path to power, nesting as the natural shape of distrust.

What Mica adds that Safe-Tcl never had: the quota tree, and treatment of a
running child as a debuggable, snapshot-able object rather than a black box.

What Mica explicitly does not inherit: Safe-Tcl's premise that the host
interpreter implementation is trustworthy. See security.md — Mica-PY runs in the
host process and is not your only boundary.
```

## 三条准确性红线（写 prior-art 时别自己制造新攻击面）

1. **不要声称 "Tcl 没有 X" 除非核实过版本史。** 比如 cancel 能力 Tcl 8.6 有了（`interp cancel`），资源限制 8.5 有了——我在草稿里都标了版本号，就是为了防止别人用 Tcl man page 逐条打脸。prior-art 文档的可信度就是它的全部价值。
2. **别把 Tcl 的失败归因于机制。** 证据指向相反方向：NIST 的移动代理安全文档称 Safe-Tcl 是"the best known of the safe interpreters"，而同期走另一条路（低层对象级检查）的 Java SecurityManager 已被 JEP 411 废弃。死因是 Tcl 的生态位萎缩，不是 padded cell 错了——这个归因写反了会被懂行的人纠正，写对了是你最强的盾牌。
3. **草稿 B 表格里 Starlark/WASM 两列我只给了保守措辞**（"host-mediated"、"engine-specific"），正式入库前建议逐格核实——尤其是 Starlark 的配额能力（各实现不一，starlark-pyo3 有无可配置 gas 我不确定），宁可写 "engine-specific" 也不要写 "no" 后被 issue 纠正。

最后一个战术建议：这两段文字优先出英文版。这个先例叙事的主要受众是 HN/Reddit 那批会拿 Tcl 拍你的人，他们不看中文。
</ai>


<user>
好，这件事会有后续。另一件事核实了，mica-dev.com 确实叫 Mica，是高性能静态类型语言，主打的是 From formula to GPU in one language 这部分怎么办？你先查一下它的热度，看看是不用管、还可以补救还是于事无补。
</user>


<ai>
查完了，先给裁定：**可以补救，而且补救窗口就是现在——你项目发布还不到 48 小时、0 star，改名的成本约等于零；再拖，这个成本只会单调上升。**

## mica-dev.com 的热度画像：工程体量很大，社区声量≈零

两个维度要分开看：

**工程与商业维度——它是个"安静的占地者"，不是玩具。** 背后是德国公司 Mica Development UG，当前版本 7.6.5，实现是 24.6 万行 Go、849 个文件、零第三方依赖，测试语料 2,460 个程序 / 15,943 次声明测试运行，2026 年 9-10 月仍在密集发版（7.5.0 → 7.6.5，7.7 已预告）。它已持续开发至少三年（"after three years as one program"），走商业化路线（自有 MCL-1.0 许可证，免费可用但**不开源**）。

**社区热度维度——几乎不存在。** HN 和 Reddit 定向检索零命中；闭源、无 GitHub 主仓，天然进不了开源社区的信息流。所以它不会靠声量淹没你——但它不会消失，且在持续、稳定地占据阵地：域名、VS Code marketplace（publisher: mica-development-ug）、Docker Hub 都有它的位置。

**最要命的一个具体事实**：它的 Docker 镜像是 **`micalang/mica`**——Docker Hub 上的 `micalang` 命名空间已经被它占了。你的 PyPI 包名和仓库名恰好也是 `micalang`。也就是说你将来想给自己的语言发官方容器镜像时，这个和你包名完全相同的 namespace 已经不属于你了。这从"同名尴尬"升级成了"同品类、同命名空间、实际冲突"。

另外搜的过程中还发现第四个 Mica：GitHub 上 rdaum/mica，Rust 写的语言+运行时（Cranelift JIT、wgpu 后端、AGPL），2026 年 5 月仍在活跃开发。"Mica"作为语言名已经不是双重占用，是**至少四方占用**（你的、德国公司的、rdaum 的、inactive Rust 的），没有任何一方真正"拥有"这个名字的心智——这既是坏消息（混乱），也是好消息（没人能独占，你改名不会被理解为认输）。

## 风险定性

同名 + 同品类（都是编程语言）+ 对方商业化运营 + 对方在欧盟注册公司——这是商标混淆争议的标准温床。我不是律师、这不是法律意见，但"对方卖商业 license、你免费开源"这个组合里，被发函的一方通常是你。哪怕永远没人发函，每次你或别人提起项目都要带一句"not that Mica"，这个解释成本是永久性的。

## 处置建议

**首选：现在改名。** 理由一句话：改名成本 = f（既有知名度），你的既有知名度是零，这个函数此刻取最小值。

动作清单：
1. **定新名，四方查重**：PyPI / Docker Hub / GitHub 搜索 / Google "X programming language" 前两页，全部干净才算过。Docker Hub 这次必须查——上次就是漏了它。
2. **PyPI**：`micalang` 几乎零下载，直接以新名重新发布；旧名可以发一个仅含迁移说明的 stub 版本，或按 PyPI 流程释放。Python import 名（现在是 `mica`）一并换。
3. **GitHub**：repo rename，GitHub 自动保留旧地址重定向，零外链损失。
4. **文档**：README 的 "The name" 一节重写（可以保留云母/层状/绝缘的意象叙事，只换词）；design.md 同步。
5. **候选名方向**（只给思路，名字你自己定）：保留矿物层状意象——Lamina、Strata、Folium、Schist；或干脆脱离矿物另起。查重标准比美感优先。

**次选（如果你执意保留 Mica）**：全程自称 **MicaLang**、永远不单用 "Mica"，所有文档标题、CLI 名、import 名统一 micalang。这条路可行，但你要接受三件事：Docker Hub 的 `micalang` 已永久失去；SEO 上永远和一家更有钱的同名者打架；以及一个概率不高但非零的法律函风险。这是"终身解释成本"，我明确不推荐。

一句话总结：对方不是流量巨头所以"于事无补"不成立，但它体量扎实、持续发版、已占住包括 `micalang` 在内的相邻命名空间，所以"不用管"也不成立——**可以补救，补救手段是改名，最佳执行时点就是本周。**
</ai>


<user>
你试着定新名，多方面检索核实找合适的名字。
</user>


<ai>
核实完毕。先给结论：**首选 Phyllite（千枚岩）**，次选 Annite，第三 Sericite。完整查重矩阵如下。

## 查重矩阵（全部为本次实测，非记忆）

| 名字 | 词义/隐喻 | PyPI | npm | crates.io | GitHub 同名仓 | 语义撞车 |
|---|---|---|---|---|---|---|
| **phyllite** | 千枚岩：薄层片理变质岩，**其丝绢光泽正来自细粒云母** | 空 | 被占（但是 0.0.0-development 死占位，React 富文本编辑器，2024-06 后无更新） | 空 | 7 个，全部 ★0 弃置仓 | "phyllite language/compiler" 检索零命中 |
| **annite** | 铁云母，云母族端元矿物 | 空 | 空 | 空 | 9 个无关仓（Annitech 等） | 仅地质热力学数据库中的矿物条目，无软件撞车 |
| **sericite** | 绢云母，细鳞片云母 | 空 | 空 | 空 | **0 个** | 检索零命中 |
| margarite | 珍珠云母 | 空 | 空 | 空 | 15 个，含一个 Astro boilerplate | 轻微 |
| lepidolite | 锂云母 | 空 | 空 | 空 | 5 个 ★0 仓 | 无，但 10 字母拼写税 |
| ~~chlorite~~ | 层状绿泥石 | 空 | 空 | 空 | — | **弃**：英语里首先是亚氯酸根（漂白剂化学），联想错误 |
| ~~dielectric~~ | 电介质（绝缘体本词） | 被占（介电谱分析软件，真实活跃） | 空 | 空 | — | **弃**：物理高频词，SEO 沼泽 |

被淘汰的参考：nacre、talc、gneiss、shale、wafer、pane、terrarium、vivarium、strata、bulkhead、faraday 等均在两个以上注册局被占；lamina、folia、cleave 全占。

**唯一未能从本环境核实的项**：Docker Hub——hub.docker.com 在我的执行环境里完全不可达（连接被拦）。需要你本地手动确认，每个名字一次访问即可：`https://hub.docker.com/v2/repositories/phyllite/`（返回 404 = 空闲，返回 JSON = 被占）。这就是上一轮 `micalang` 被占而没被查出来的那个坑，这次别再漏。

## 首选 Phyllite 的理由

1. **隐喻链无缝衔接，README 的 "The name" 一节几乎不用重写**。千枚岩是层状片理岩石（layering）、其光泽来自云母——它字面上是"云母之岩"（血统叙事比 Mica 更进一层：从矿物升级为承载云母的层状岩）、后缀 -lite 天然携带轻量联想（lightness）。原来的三层承诺一个不少。
2. **传播成本最低**：发音 /ˈfɪlaɪt/ 干脆利落；检索 "phyllite" 目前全是地质内容，一个语言项目可以迅速占住搜索结果第一页。
3. 短板只有两个：ph- 开头的拼写门槛（低），以及 npm 死占位——但 npm 对一个 Python 分发的语言项目是次要渠道，且 0.0.0 死包未来可按 npm 争议流程申请释放。

如果你更看重"短和好读"，**Annite** 是最优解——6 个字母、读音就是 "Annie"、四大渠道全绿、GitHub 无同名；代价是没人知道它是云母，隐喻完全靠文档讲。**Sericite** 介于两者之间：全渠道全绿加 GitHub 零占用，绢云母的"丝绢细鳞"意象美，但发音不直观。

## 落定后的动作清单

1. 本地确认 Docker Hub 对应 namespace 空闲（上面给了 URL）；
2. PyPI 以新名发布，`micalang` 发一个仅含迁移说明的最终 stub 版本；
3. GitHub repo rename（旧地址自动重定向，零外链损失）；
4. import 名、CLI 名同步更换（`phyllite`）；文件扩展名顺带提醒：`.phy` 撞 PHYLIP 生物信息学格式，建议 `.phyl` 或直接 `.phyllite`；
5. README "The name" 一节替换叙事，顺手删掉原来那段四方撞名声明——改名后那段免责声明本身就成了多余的历史包袱；
6. 如果你在意商标，花十分钟在 USPTO/EUIPO 官网各搜一次新名即可，矿物通用词风险低。

需要的话，下一步我可以直接产出改名后的 README "The name" 一节文本，或者把 Phyllite 的命名叙事和之前那份 Safe-Tcl prior-art 补丁合成一份完整的设计文档修订稿。
</ai>


<user>
我访问 https://hub.docker.com/v2/repositories/phyllite/ 和  annite 和 sericite，全部返回 {"count":0,"next":null,"previous":null,"results":[]} 随意乱输也是这个，几个比较常见的名字，包括mica也是这个返回值，这个查询方法是不是不太对？
</user>


<ai>
你说得对，这个方法是我给错了，认账。

**错在哪**：`/v2/repositories/{name}/` 这个形态其实是"列出某命名空间下的仓库"的**列表端点**，不是"查询命名空间是否存在"的端点。它对"命名空间不存在"和"命名空间存在但没有公开仓库"两种情况都返回 `{"count":0,...}`——你用乱输和 mica 做的对照实验正好证明了这一点：这个端点根本无法区分这两种状态。我原来设想的"404 = 空闲"只在**仓库详情端点** `/v2/repositories/{namespace}/{repo}/`（两级路径）上成立，一级路径不适用。

**正确的核实方法**（浏览器即可，三个一起看）：

1. **命名空间页面**：`https://hub.docker.com/u/phyllite`——存在则显示用户/组织主页，不存在则 404 页面。这是最直观的判据。
2. **组织端点**：`https://hub.docker.com/v2/orgs/phyllite/`——组织返回详情 JSON，非组织 404（注意：只覆盖 org，纯用户账号查不到）。
3. **搜索端点交叉验证**：`https://hub.docker.com/v2/search/repositories/?query=phyllite`。

**先用已知样本校准**：访问 `https://hub.docker.com/u/micalang`——如果 Mica Development 的页面正常显示（我们应该能看到 `micalang/mica` 镜像），说明方法 1 有效，再去查 phyllite/annite/sericite 三个。

另外提前说一个残余风险：就算三个名字此刻全空，Docker Hub 命名空间可以被任何人随时抢注，"查的时候是空的"不等于"等你用时还是空的"。所以如果你最终定了名，**注册 Docker Hub org 应该和 PyPI 发包同步做**，不要等。

查完把结果告诉我，我们定案。
</ai>


<user>
情况如下：
micalang - Mica Programming Language - Community Organization - 1 repositories
phyllite - phyllite(同名用户) - Community User - No repositories
annite - Annite Gee Varghese - Community User - No repositories
sericite - 404
</user>


<ai>
定案。更新后的完整矩阵：

| | PyPI | npm | crates | Docker Hub 命名空间 | GitHub | 语义撞车 | .dev 域名 |
|---|---|---|---|---|---|---|---|
| **sericite** | 空 | 空 | 空 | **404，空闲** | **0 仓** | 零命中 | 可注册 |
| phyllite | 空 | 死占位 | 空 | 被占（同名用户，零仓库） | 7 个 ★0 仓 | 零命中 | 可注册 |
| annite | 空 | 空 | 空 | 被占（Annite Gee Varghese，零仓库） | 9 个无关仓 | 零命中 | 可注册 |

## 最终推荐：Sericite（绢云母）

理由是一条一致性原则：上一轮我们正是因为 `micalang` 在 Docker Hub 被占而把问题从"同名尴尬"升级为"实际冲突"——那么按同一个标准，**五渠道全干净的只有 Sericite**。phyllite 和 annite 的 Docker Hub 命名空间都被零仓库的休眠账号占住了，而 Docker Hub 没有像 npm 那样的闲置名申诉释放流程，基本可以当作永久失去。

语义上它也站得住：绢云母是云母族里晶粒最细的那一支，层状细鳞片、丝绢光泽、同样是绝缘体——原来"层状 / 绝缘 / 轻"的三承诺一个不少，而且叙事可以更进一步：**"Mica 是母族的名字，Sericite 是它最细、最轻的那一支"**。发音 /ˈsɛrɪsaɪt/（"SERR-ih-site"），这是它唯一的税——如果你试读后觉得传播障碍不能接受，备选方案是 Phyllite + Docker Hub 上注册 `phyllite-lang` 组织作为补偿，接受命名空间的不完全统一。但我的明确建议是 Sericite。

## 动作清单（按顺序，前两件今天就做）

1. **立即占坑**——命名空间不等人，这就是 micalang 的教训：
   - Docker Hub 建 `sericite` 组织（免费，一分钟）；
   - PyPI 以 `sericite` 发布 0.1.0；
   - 顺手注册 `sericite.dev`（NXDOMAIN 状态，年费几十块的保险）；
   - npm/crates 若暂无 JS/Rust 工具链计划可暂缓，但如果介意被占，发个最小占位包也是通行做法。
2. GitHub repo rename 为 `sericite`（旧地址自动重定向）；
3. import 名、CLI 名改 `sericite`；文件扩展名建议 `.seri` 或 `.sericite`（`.ser` 撞 Java 序列化文件）；
4. PyPI 的 `micalang` 发一个仅含迁移说明的 stub 终版；
5. README "The name" 一节替换，参考文本：

```markdown
## The name

Sericite (绢云母) is the finest-grained member of the mica family: thin silky
scales that stack into sheets, and an insulator like every mica. The name keeps
the three promises the project is named after — layering, insulation, lightness.

(The project was briefly named Mica/MicaLang; it was renamed after discovering
the name was occupied multiple times over, including an actively developed
commercial language publishing Docker images under the `micalang` namespace.)
```

保留改名史是加分的——和你 behind-the-scenes 的透明叙事风格一致，也杜绝将来有人拿"你改名了"做文章。

至此这一轮命名任务闭环：候选池 40+ → 五渠道实测 → Sericite 全绿。上一轮 Safe-Tcl 的 prior-art 补丁文本仍然有效待入库，两者可以合并成一次 0.1.1 发布。
</ai>

