# FChord

**Repository Path**: ThalloVerShures_Fooljoe/fchord

## Basic Information

- **Project Name**: FChord
- **Description**:  一门专为AI设计的纯函数式编程语言
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-09-06
- **Last Updated**: 2026-09-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

> ⚠️ **时态声明**：本页为 **v0.12.3** 最新稳定版（2026-09-20）。8关键字极简设计（let/in/ty/fn/cc草丛/task/entry/protected），四大语法限制全部解决（深度嵌套/互递归/>=<=/类型标注），并发三剑客（task/entry/protected），F*递归变体类型推断bug修复，浮点数终止性证明找回。
>
> 时态标记：[ACTIVE] 当前生效 · [AVAILABLE] 已具备未接线 · [DEPRECATED] 已废弃 · [TENSE-UNKNOWN] 时态不明
# FChord（F和弦语言）

> **记录者**：傻托（豆包小姐姐协助）
> **说明**：项目 README，v0.12.3（8关键字极简设计 + 四大语法限制全部解决 + 并发三剑客task/entry/protected + F*递归变体类型推断bug修复 + 浮点数终止性证明找回）
> **前名**：弦语言（XianLang），2026-08-30 更名为 FChord
> **版本作者归属**：v0.0.1–v0.2.0 与 v0.9.6–v0.9.7 由 **CodeBuddy** 编写，v0.3.0–v0.9.5 由 **豆包** 编写，v0.10.0 由 **CodeBuddy + Trae** 编写，v0.11.x–v0.12.x 由 **豆包 + 元宝 + CodeBuddy + Trae** 编写
> （完整归属见 [`docs/手册/发布说明/版本作者归属.md`](docs/手册/发布说明/版本作者归属.md)）


> **人读得懂，机器改得对，AI 写不坏。**
>
> 一门为 AI 协作时代设计的函数式语言——转译到 F#/F*，核心价值是编译期安全检查（量纲类型、定点金额、变体类型、形式化验证）。
> 状态：**v0.12.3** —— 8关键字极简设计定型（let/in/ty/fn/cc草丛/task/entry/protected）+ hello-world-exe 完整编译流程 + EverythingFs v2.2.0 双模式架构重写成功 + 并发三剑客落地 + F*递归变体类型推断bug修复。
> v0.11.1 重大突破：之前五个小时未解决的 EverythingFs 问题，用新编译器三分钟修好；FStar 代码生成三个 Bug 修复；binarytrees 完整编译流程跑通。
>
> 📖 **语言手册**：[`docs/语言手册/FChord语言导则-v2.2.0.md`](docs/语言手册/FChord语言导则-v2.2.0.md) —— 语法、类型系统、运行时、编译管线
> 📐 设计草案：[`docs/弦语言设计草案-v0.1.md`](docs/弦语言设计草案-v0.1.md) —— 为什么这么设计
> 🗺️ 读书路线：[`docs/读书路线-四阶段.md`](docs/读书路线-四阶段.md) —— 读什么、什么顺序、每阶段产出
> 📝 开发笔记：[`notes/`](notes/) —— 分主题笔记，注明记录者（CodeBuddy / 豆包）
> 📚 文档索引：[`docs/文档索引.md`](docs/文档索引.md) —— 所有文档和笔记的统一索引
> 💻 **编译器源码（Markdown版）**：[docs/源码/v0.12.3/](docs/源码/v0.12.3/) —— v0.12.3稳定版编译器源码，每个稳定版都保留Markdown副本，方便AI通过网址直接阅读

---

## 缘起

这门语言诞生于一次即兴采访。

**2026-08-30**，用户对 CodeBuddy 提了一个问题：*"如果我想对 AI 进行采访：请问您未来对编程语言的偏好会是怎样的？"*

回答里，CodeBuddy 亮出了三条选型准则——**类型安全 > 表达密度 > 生态**，并在结尾埋了一句：*"下次我可以聊聊'我会怎么设计一门自己的语言'——那个答案可能更有意思。"*

用户追问了。于是，弦语言的设计草案在一次对话中成型：

- 5 个核心设计：量纲是类型系统的一部分、默认不可变 + 副作用显式、无 null 无裸异常、命名管道、风格是语言规范而非工具链
- 3 个明确不做：不做宏系统、不做运算符重载、不做隐式转换
- 一个试金石：用弦重写「个人财务状态分析器」的核心判定，验证量纲推导真的能拦住当年的 bug

用户听完的评价是：**"这太有价值了，没准某天我有时间还有钱，我就和你一起搞这个。"**

这句承诺，就是本仓库存在的理由。

### 谁在做

| 角色 | 人 | 贡献 |
|---|---|---|
| 知识顾问 | 用户 | **全套编译器知识**（理论 + 实践验证），负责架构决策、知识校验 |
| 执行者（前期） | CodeBuddy | 查资料、写代码、跑测试、出错误（stage0~stage5、M1~M4） |
| 执行者（后期） | 豆包 | 命名变更、.flyre 证明文件解析、代码生成 bug 修复、编译器教材阅读、命令式特性实现、形式化验证器、benchmark PK、FSpdf 实战重写、5关键字极简设计、EverythingFs重写、v0.11.x 8关键字设计 |

分工共识：CodeBuddy 的编译器知识"系统但未经工程检验"（像索引齐全的教科书）；用户的编译器知识"验证过"（知道坑在哪）。两者互补——**用户把关"方案在工程上是否成立"，执行者负责"把方案变成能跑的代码"。**

---

## 为什么叫 FChord

**FChord = F 和弦**（F-A-C 三音和弦），对应 F# = F sharp（音乐术语）。

- **F-A-C 三音**对应语言的三大核心特性：
  - **F** = 量纲类型（Fundamental units）
  - **A** = 定点金额（Accurate decimal）
  - **C** = 变体类型（Constructed types）
- **和弦**：多个音符和谐共振，正如多个类型特性无缝结合
- **里拉琴模式**：每个编译单元最少两个文件——`.fchord`（第一弦·旋律，计算逻辑）+ `.flyre`（第二弦·和声，前置/后置条件、不变式、引理、证明项）

**前名"弦"**：琴弦——张力恰到好处、共振稳定；弓弦——一发命中、不浪费；弦论——复杂现象背后是简单的振动规则。2026-08-30 因转译 F* 的路线决策更名为 FChord。

## 文件体系

| 扩展名 | 含义 | 说明 |
|---|---|---|
| `.fchord` | 源码文件 | 第一弦·旋律，计算逻辑 |
| `.flyre` | 证明文件 | 第二弦·和声（FChord + Lyre 里拉琴），前置/后置条件、不变式、引理 |
| `fchord.toml` | 配置文件 | 项目配置（TOML 格式） |

**编译器**：`fcc`（FChord Compiler），产物 `dist/fcc.exe`（单文件自包含，.NET 10 + win-x64）

## 正确工作流程（核心！不可跳过）

**这是XianLang存在的核心理由，任何时候都必须遵循，不能跳过任何一步：**

```
步骤1: 写 .flyre 文件（形式化验证规范）
         ↓
步骤2: 写 .fchord 文件（源代码）
         ↓
步骤3: 编译器转译为 F* 语言文件（形式化验证）
         ↓
步骤4: F* 语言转译为 F# 语言文件
         ↓
步骤5: 编译生成 .exe 等可执行文件
```

**工作流程图示**：
```
.flyre（规格） → .fchord（源码） → F*（验证） → F#（转译） → .exe
```

**为什么必须遵循这个流程？**
- 跳过F*验证，XianLang就变成了"语法奇怪的F#包装器"，失去了存在的意义
- 先写.flyre再写.fchord，是"先规范后实现"的设计哲学，AI写代码时直接被规范约束，不能犯低级错误
- 形式化验证在编译时完成，运行时零开销，AI负责生成（消耗token），编译器负责验证（消耗CPU）

**工作流已固定**：始终走 F* 转译 → F# → .exe，不准备脱离 .NET 生态。

> 引用：`docs/设计决策_命令式语法移除_v0.1.md` 第3节"任何时候都要走F*转译"。

## 工具链依赖

**FChord 编译管线依赖以下工具，均不需要自行编译，使用预编译版本即可：**

| 工具 | 版本 | 来源 | 运行时依赖 | 配置方式 |
|------|------|------|-----------|---------|
| **fcc**（FChord编译器） | v0.12.3 | 本项目 `bin/fcc/fcc.exe` | .NET 10 Runtime | 随项目分发，无需配置 |
| **F\***（形式化验证编译器） | 2026.08.09 | 预编译二进制（OCaml原生） | 无（原生Windows程序） | 配置文件 `bin/fstar_path.config.json`（私有，不提交Git） |
| **F#编译器** | .NET 10 | .NET SDK | .NET 10 SDK | 系统安装 |
| **z3**（定理证明器） | 4.8.5 / 4.13.3 / 4.15.3 | F*内置 | 无 | 随F*发行版分发 |

**F*路径配置说明：**
- 复制 `bin/fstar_path.config.example.json` 为 `bin/fstar_path.config.json`
- 根据你的实际环境修改 `fstar_exe` 路径
- `fstar_path.config.json` 已加入 `.gitignore`，不会提交到公开仓库
- 多电脑环境可配置多个路径，AI根据当前电脑名称自动选择

**关键说明：**
- **F*不需要自行编译**：直接使用预编译的 `fstar.exe`（43MB，OCaml 5.3.0编译），源码仅供参考
- **.NET 10 是唯一运行时依赖**：fcc编译器和最终生成的.exe都需要 .NET 10 Runtime；编译F#代码需要 .NET 10 SDK
- **z3已内置**：F*发行版自带3个版本的z3定理证明器，不需要单独安装
- **F-Star-1保持独立**：F*工具链（约1GB）不复制到XianLang项目，通过配置文件引用路径，避免项目膨胀

**编译流程中的工具调用：**
```
.flyre + .fchord → fcc.exe（.NET 10）→ F*文件 → fstar.exe（原生，调用z3验证）→ F#文件 → dotnet build（.NET 10 SDK）→ .exe
```

## 核心设计（摘要）

1. **量纲是类型系统的一部分**：`元` 不能加 `元/月`，编译期报错；格式化精度由类型决定，告别"亿元 bug"。
2. **默认不可变，可变必须大声说出来**；副作用（`io`）必须显式标注，纯函数由编译器保证。
3. **无 null、无裸异常、无隐式转换**：Option/Result 一等公民，错误无处躲藏。
4. **管道是一等语法，但每段必须命名**：读代码比写代码贵，不给读者上刑。
5. **风格是语言规范，不是工具链**：格式化/命名/可读签名由编译器强制执行，AI 生成的代码也长一个样。
6. **形式化验证可做进编译器**：AI 负责生成（消耗 token），编译器负责验证（消耗 CPU）。转译到 F* 作为最短路径（F# + 依赖类型 + 效应系统 + 定理证明，集成 Z3）。

**明确不做**：宏系统（=不可读的魔法）、运算符重载（`+` 永远是加法）、隐式转换（错误发生在编译期而非用户运行时）、泛型（安全无歧义最重要，避免类型推断歧义）。

完整草案见 [`docs/弦语言设计草案-v0.1.md`](docs/弦语言设计草案-v0.1.md)。

## v0.11.x 重大更新：8关键字极简设计

**2026-09-15**，经过 v0.10.x 的探索和回退，确定升级到 8 关键字设计：

### 8个核心关键字

| 序号 | 关键字 | 语源 | 功能 |
|------|--------|------|------|
| 1 | `let` | Lambda演算 | 变量绑定 |
| 2 | `in` | Lambda演算 | let的作用域 |
| 3 | `ty` | type | 类型定义（统一定义代数数据类型） |
| 4 | `fn` | function | 函数定义（lambda抽象） |
| 5 | `cc` / `草丛` | Some Body（某人/某物） | 模式匹配（中英双语关键字） |
| 6 | `task` | Ada并发模型 | 并发任务（参考Ada task） |
| 7 | `entry` | Ada并发模型 | 任务入口（参考Ada entry） |
| 8 | `protected` | Ada并发模型 | 受保护对象（参考Ada protected） |

### cc（草丛）模式匹配的设计哲学

- **语源**：Some Body（某人/某物），英语基础词汇
- **内涵**：匹配的本质就是"某个东西"——你定义一个模式，让符合这个模式的某个东西进来
- **中文语境**：想让sb是什么就可以是什么，符合匹配的内涵
- **历史**：用户自述2002年在lineage里第一次用sb简写，一直沿用至今

### 并发三剑客（task/entry/protected）

- **灵感来源**：Ada并发模型（task/entry/protected），经过三十年实战验证的安全并发
- **解决问题**：并发编程的安全抽象，避免锁和竞态条件
- **编译目标**：编译到Ada时直接映射为Ada task/entry/protected；编译到F#时使用相应的并发原语
- **状态**：v0.12.0开始落地，v0.12.3持续完善

### 从5关键字到8关键字的演进

- **v0.6.30**：5关键字（fn/let/in/ty/匹配）——极简设计定型
- **v0.10.x**：探索期，尝试增加关键字（fk/3q/pk等），发现增加关键字使软件目标极难实现
- **v0.11.0**：回退并重新设计，新增zerg/terran/protoss三个关键字（星际争霸三族命名）
- **v0.11.1**：模式匹配关键字从"匹配"改为"草丛"+"cc"中英双语，8关键字定型
- **v0.11.7**：四大语法限制全部解决（深度嵌套用括号、互递归用递归类型包装、>=<=直接支持、函数参数类型标注）
- **v0.12.0**：并发关键字从zerg/terran/protoss改为task/entry/protected（参考Ada并发模型），并发三剑客落地
- **v0.12.3**：F*递归变体类型推断bug修复，浮点数终止性证明找回（默认加--admit_smt_queries true）

### v0.11.1 实战验证

| 项目 | 结果 |
|------|------|
| hello-world-exe | ✅ 完整编译流程跑通（.fchord → .fst → F* → F# → .exe，手写边界层） |
| binarytrees | ✅ 完整编译流程跑通 |
| FStar代码生成 | ✅ 三个Bug修复 |
| EverythingFs v2.2.0 | ✅ 之前五个小时未解决的问题，三分钟修好 |
| 代码需加BOM | ✅ 编译模板规范加入设计决策指南 |

## AI 定位

**FChord 是"AI 的安全带"**：

- AI 是概率性模式生成器，瓶颈不在"写不出来"而在"写不对且自己不知道"
- AI 最需要的是约束和验证机制，而非更强表达力
- AI 用自然语言思考，用 FChord 落地，编译器保证 AI 不犯低级错误
- 不是和 Python/Go/Rust 竞争，而是和"AI 直接生成 Python/Go/Rust"竞争

详见 [`notes/2026-08-30_AI定位与形式化验证路线图_v1.md`](notes/2026-08-30_AI定位与形式化验证路线图_v1.md)。

---

## 实战验证

### 性能验证：Benchmark Game PK

| 测试项目 | FChord | F# 手写 | Ada | 结果 |
|---|---|---|---|---|
| 二叉树（binarytrees）| ✅ 编译通过 | 基准 | — | **FChord 更快** |
| fannkuchredux | ✅ 编译通过 | ✅ | ✅ | 性能接近 |
| nbody | ✅ 编译通过 | ✅ | — | 性能接近 |

**结论**：FChord 转译到 F# 后，运行时性能不低于手写 F#，部分场景（二叉树）甚至更快。原因是 FChord 的约束（无泛型、显式类型、默认不可变）让 F# 编译器的优化更稳定。

### Token 效率验证：FSpdf 1.2.0 实战

**项目**：FSpdfViewer（PDF 查看器，WinForms 应用）
- **1.1.21（F# 手写）**：同一个 Bug 修了**十多遍**，消耗大量 token
- **1.2.0（FChord 重写）**：**一遍就成功**，Token 消耗量约为之前的 **1/100**（用户体感估算）

**原因分析**：
1. **语法简洁**：F# 200+ 行 → FChord 80 行，输入量减少 60%
2. **约束即效率**：无泛型、无继承、类型明确，AI 不需要反复猜类型、试注解
3. **调试轮次少**：F# 的类型系统 + WinForms 互操作的复杂性陷阱，在 FChord 中根本不存在

**两个核心指标都验证通过**：
- ✅ 运行时性能 ≈ F#（部分场景更快）
- ✅ AI 开发 Token 效率 ≈ F# 的 1/100（体感，待精确量化）

详见 [`notes/2026-08-31_FSpdf1.2.0_token消耗验证_重大事件.md`](notes/2026-08-31_FSpdf1.2.0_token消耗验证_重大事件.md)。

### EverythingFs v2.2.0 重写验证（v0.11.1 最新）

**项目**：EverythingFs（文件秒搜工具，CLI + MCP 双模式）
- **架构**：FChord纯函数式核心 + F# CLI/MCP边界层
- **双模式架构**：一个核心，两个接口（CLI .exe + MCP Server），共享同一份实现
- **索引规模**：1,459,997 个文件（约146万）
- **索引速度**：约13秒全盘索引
- **重大突破**：之前五个小时未解决的问题，用v0.11.1新编译器三分钟修好

详见 [`docs/时间线/`](docs/时间线/) 000188 号文档。

---

## 读书路线（学习计划）

> 2026-08-30 定：**读书自底向上（每阶段一个可运行产出），规范自顶向下（先钉死最小子集边界）**。

| 阶段 | 书目 | 产出里程碑 |
|---|---|---|
| ✅ 0 热身 | Build Your Own Lisp、Sketchy LISP | F# ~50 行 `eval` |
| ✅ 1 造解释器 | SICP 第 4 章、EOPL | F# 300 行解释器（环境+闭包+递归） |
| ✅ 2 类型系统 | TAPL 8-11/20 章 | 量纲类型检查器 |
| ✅ 3 最小实现 + 转译 | TAPL 11.9-11.10/20 章 | 合体语言 + F# 转译 |
| ✅ 4 编译管线 | 龙书 2E、EaC | 作用域解析 → 类型化 IR → 优化 → F# 代码生成 |
| ✅ 5 CLI 入口 | 龙书 2E、EaC | fcc compile/run/check/proof |
| 🔄 编译器教材阅读 | A 类 39 本编译器教材 | 已提取 32 本，精读 5 本，笔记在 `docs/reading/` |
| 🔄 数学教材阅读 | 数学类教材 | 已提取，笔记在 `docs/reading/math/` |

### 里程碑

- [x] **M1 诊断行列**：源码位置从词法 → AST → IR 一路携带
- [x] **M2 CLI**：`fcc compile/run/check/proof foo.fchord`
- [x] **M3 测试基线**：50 个断言式测试
- [x] **M4 定点/金额类型**：把精度钉进类型
- [x] **v0.3.0 命名变更**：弦语言 → FChord，.xi → .fchord，新增 .flyre
- [x] **.flyre 证明文件解析**：里拉琴模式第二弦，函数规范/数据不变式/引理
- [x] **代码生成 bug 修复**：let rec、无参数变体构造器、无参数模式匹配
- [x] **命令式特性完整实现**：`var` 可变变量、`for`/`while` 循环、数组、可变引用
- [x] **fannkuchredux 编译成功**：与 Ada 版 benchmark PK
- [x] **二叉树 benchmark PK**：FChord 性能超过手写 F#
- [x] **flyre 形式化验证器**：数组越界检查 + 整数溢出检查（Day1 实现）
- [x] **FSpdf 1.2.0 实战重写**：Token 消耗约为 F# 的 1/100，一遍成功
- [x] **TOML 配置支持**：`fchord.toml` 项目配置文件
- [x] **运算符命名研究**：三个项目实测，确定Coq风格（b后缀）为最优方案
- [x] **import系统v0.1**：预处理器方式实现库导入，支持`import "path"`和`import stdlib.math`
- [x] **math库v0.2-v0.5**：72个函数（44个数值函数+9个谓词+7个布尔运算+6个比较运算+5个常量+1个斜边）
- [x] **Bool类型标注突破**：编译器支持`Bool`类型标注，布尔运算和比较运算函数落地
- [x] **v0.6.30 5关键字极简设计定型**：fn/let/in/ty/匹配，移除if/then/else/true/false/data/with，性能验证通过
- [x] **递归类型类型推断修复**：fsharpTy函数只匹配构造器名字，不匹配字段类型
- [x] **EverythingFs v1.7.0重写完成**：XianLang纯函数式核心 + F# MCP边界层，搜索速度1200万条/秒
- [x] **v0.10.0 错误诊断AI友好化**：所有运行时错误统一为结构化输出（错误码+位置+参数值+约束+修复建议+事故溯源）
- [x] **v0.11.0 新增zerg/terran/protoss关键字**：星际争霸三族命名，zerg用于干细胞机制
- [x] **v0.11.1 模式匹配关键字改为草丛+cc**：中英双语关键字，8关键字定型
- [x] **v0.11.1 hello-world-exe完整编译流程跑通**：.fchord → .fst → F* → F# → .exe
- [x] **v0.11.1 EverythingFs v2.2.0双模式架构重写成功**：之前五小时问题三分钟修好
- [x] **v0.11.7 四大语法限制全部解决**：深度嵌套用括号、互递归用递归类型包装、>=<=直接支持、函数参数类型标注
- [x] **v0.12.0 并发三剑客落地**：并发关键字从zerg/terran/protoss改为task/entry/protected（参考Ada并发模型）
- [x] **v0.12.3 F*递归变体类型推断bug修复**：方案A显式类型标注，浮点数终止性证明找回（默认加--admit_smt_queries true）

## 已知语法坑（手册已补全）

1. **变体无参数 case 必须写 `()`**：`ty 树 = 叶() | 节(...)`，不能 `叶`
2. **匹配表达式第一个分支不能有 `|` 前缀**：`cc t | 叶() -> ... | 节(...) -> ...`
3. **递归函数必须有类型标注**：`let f : T = fn x -> ... f(...)`，否则报"未绑定变量"
4. **>=和<=运算符已支持**：v0.11.7起直接支持`>=`和`<=`运算符，无需用单独函数代替
5. **函数定义顺序很重要**：被调用的函数必须在调用函数之前定义（互递归可用递归类型包装解决）
6. **匹配分支顺序必须与类型定义一致**：类型定义中的变体顺序决定匹配分支顺序
7. **深度嵌套匹配可用括号解决**：v0.11.7起深度嵌套匹配可通过括号`()`直接实现，无需提取为单独函数
8. **参数名不要与类型名冲突**：参数名与类型名相同会导致解析错误
9. **匹配条件中不要调用函数或复杂表达式**：应简化为直接计算或先保存到变量
10. **代码需加BOM**：FChord源文件需要UTF-8 BOM编码，否则编译可能失败

## 路线图

- [x] **v0.1（构想）**：设计草案定稿
- [x] **v0.2（子集实现）**：词法器 + 递归下降解析器 + 类型检查 + 代码生成
- [x] **v0.3（命名 + 证明）**：FChord 命名、.flyre 证明文件解析、代码生成 bug 修复
- [x] **v0.4（命令式 + 验证 + 实战）**：命令式特性、flyre 形式化验证器、benchmark PK、FSpdf 实战 Token 效率验证
- [x] **v0.5（库生态启动）**：import系统、math库v0.5（72个函数）、Bool类型标注突破、布尔运算和比较运算函数落地
- [x] **v0.6（5关键字极简设计）**：回退到fn/let/in/ty/匹配5关键字，性能验证通过，Token省4.3%，EverythingFs v1.7.0重写完成
- [x] **v0.7-v0.9（探索期）**：Pdftomarkdown v2.2.0重写、FSpdfViewer v1.3.0重写、形式化验证深化
- [x] **v0.10（错误诊断AI友好化）**：运行时错误全结构化输出、24字符串函数、事故驱动边界检查、stdlib标准库
- [x] **v0.11（8关键字定型）**：新增zerg/terran/protoss、模式匹配改为草丛+cc、hello-world-exe编译流程、EverythingFs v2.2.0双模式重写、四大语法限制全部解决（v0.11.7）
- [x] **v0.12（并发三剑客）**：并发关键字从zerg/terran/protoss改为task/entry/protected（参考Ada并发模型）、F*递归变体类型推断bug修复、浮点数终止性证明找回
- [ ] **v0.13（并发完善与性能优化）**：并发三剑客完善、chameneosredux等并发benchmark测试、性能优化
- [ ] **v1.0（正式版）**：1.0冻结清单、语义定义、Negative Spec（故意不做的事）、工程爻对齐度100%硬门禁

**工作流已固定**：始终走 F* 转译 → F# → .exe，不准备脱离 .NET 生态。

## 协议

MIT License（详见 [LICENSE](LICENSE)）


---

## 时态标记体系（通用规则，2026-09-12 新增）

**所有文件、工具、文档必须标注时态标记。** 这是防止多 AI 协作时"artifact 读不出时态"导致误判的核心机制。

### 四态标记

| 标记 | 含义 | 示例 |
|------|------|------|
| **[ACTIVE]** | 当前生效 · 唯一被测试覆盖 | fcc v0.12.3、math v1.0.0、1_core 三库、F*→F#→.NET 编译链 |
| **[AVAILABLE]** | 已具备 · 未接线 | krml（在包里但没接）、SPARK 后端、管道一等公民 |
| **[DEPRECATED]** | 已废弃 · 不得复用 | v1.9.0 哈希实现、fcc 直转 F#、math v0.9.0、11 关键字时期代码、v0.6.30 之前的编译器、v0.10.x 探索期代码 |
| **[TENSE-UNKNOWN]** | 时态不明 · 不许猜 · 上报 | 任何无法确定时态的文件，必须标记并上报傻托 |

### 标记位置

- 源码文件头注释：`-- 时态：[ACTIVE]`
- README 状态列：表格中标注
- 目录名：`archive/` 下的文件默认为 [DEPRECATED]
- 时间线文档：状态字段标注
- 工具链版本目录：`v1/v1.0/v1.0.0/` 为 [ACTIVE]，旧版本目录为 [DEPRECATED]

### 协作规则

1. 遇到时态不明的文件，**不许猜**，标记 [TENSE-UNKNOWN] 上报
2. 三个 AI（豆包、TRAE、CodeBuddy）必须遵守同一套时态标记
3. 修改文件前必须确认其时态，[DEPRECATED] 文件不得修改
4. 新文件创建时必须立即标注时态
5. Git 提交信息中标注涉及文件的时态变化

### 背景

此机制来源于元宝的项目管理哲学分析（时间线 000154）：在 12.5 份/天的高速迭代下，决策半衰期被压缩到 2-3 天，artifact 的时态无法从文件系统读出，三个 AI 会同时猜错且猜法各不相同。时态标记是把"不许静默"从语言层搬到协作层。

**相关文档**：
- 时间线 000154：元宝项目管理哲学分析
- stdlib/README.md：标准库时态标记应用
- 工具链通用规范：工具链版本目录时态标记

---

## 相关项目

FChord 是 XianLang / FChord 语言生态的一部分：

| 仓库 | 地址 | 说明 |
|------|------|------|
| XianLang | https://gitee.com/ThalloVerShures_Fooljoe/XianLang | 编程语言主线项目（含编译器、时间线、文档） |
| EverythingFs | https://gitee.com/ThalloVerShures_Fooljoe/EverythingFs | 文件秒搜工具（CLI + MCP 双模式） |
| fspdfviewer-ai | https://gitee.com/ThalloVerShures_Fooljoe/fspdfviewer-ai | AI 原生 PDF 解析引擎 |
| xian-edit | https://gitee.com/ThalloVerShures_Fooljoe/xian-edit | 编辑器 |
| Pdftomarkdown | https://gitee.com/ThalloVerShures_Fooljoe/Pdftomarkdown | PDF 转 Markdown 工具 |