项目入口协议（PEP）-定义一种开放的、跨语言、跨工具的项目声明、发现与执行标准。
以 .project 结尾的文件，来声明该文件所在的目录是一个逻辑项目。
.project文件 的唯一职责:
以最低成本、非中心化的方式，自由声明一个可被发现的逻辑项目，为上层中心化管理工具提供稳定、可扩展的读取入口。
.project文件 本质上是一个“锚点”。
通过统一的 CLI 工具可以扫描你的工作目录，它在项目名与物理路径之间建立N-1关系的索引，从而实现中心化管理。
.project 中定义shell类型和权限要求等语义化配置，确保每个项目可以以正确的方式进入。
在日常开发中，一台电脑可能有几十个项目散在各级文件夹。我们经常在不同的项目间，来回切换资源管理器、启动终端、执行指令，这相当繁琐。
## 即便是简单的一个项目，也具备基本的结构复杂度
Node.js 管理后台前端: D:/companyA/xxx/admin/frontend
Node.js 管理后台服务: D:/companyA/xxx/admin/user-service
Node.js 用户前端: D:/companyA/xxx/user/frontend
Node.js 用户后端: D:/companyA/xxx/user/backend
Node.js 支付沙盒项目: D:/companyA/xxx/payment/sandbox
vitepress 文档项目: D:/companyA/xxx/docs/
## 各种可能的散落
wasm 工具项目: D:/companyB/yyy/wasm/
Python 数据处理脚本: E:/scripts/data-pipeline
Go 微服务十几个: D:/legacy/go/order-service、......
React 实验项目: E:/experiments/openai-test
Markdown 知识管理十几个 E:/markdowns/... （博客、论文、工作、学习..）
并且，当项目多了之后，尤其是知识管理，容易因为忘记了存放位置而重新clone，造成多余的分叉副本。
这类“繁琐”不是技术上的复杂，而是一种认知负荷和操作步骤的反复叠加。
我们需要一个干净、快捷的进入目录的解决方案：
- 足够轻量！
- 足够灵活！
- 不需要心智成本！
.project 文件，即可借助简单的CLI或GUI工具被发现、管理，然后通过[项目名]或[序号]快捷进行进入操作：PEP协议（Project Entry Protocol）解决的是如何声明项目，以及如何规范基础配置，以避免不同实现之间的数据依赖冲突。。
在保持一致的文件命名和配置管理基础上，支持任何人、任何工具进行任意功能体验的设计和实现。
项目发现总是从用户配置的检索根目录开始，通过搜索.project 文件快速重建中心化索引。
1、协议不定义固定的扫描起点、深度、范围、忽略目标，由上层实现来选择体验策略。
2、对于 .开头 、node_modules 等在主流语义中默认是非业务入口的目录，强烈建议上层实现自动忽略或纳入忽略配置。
所有以 .project 结尾的文件，均被视为合法的项目声明文件。
项目名称的确定遵循以下规则：
1、若声明文件显式具名，则优先使用文件名作为项目名。
2、若未具名，则默认使用其所在文件夹的名称作为项目名。
3、允许同一个文件夹内部有多个声明文件，即支持同一个物理路径可以用不同的逻辑项目来管理进入操作。这意味着你可以借助多个具名.project文件组合来实现策略隔离。
D:/legacy/go/order-service
├── src/
├── order-service.dev.project # 开发环境声明
├── order-service.test.project # 测试环境声明
└── order-service.prod.project # 生产环境声明文件内容允许为空。如果配置，则必须统一遵循标准的 YAML 格式，且使用 UTF-8 编码，以确保跨上层实现的存储一致性。
# 示例配置
shell: powershell ## 优先以powershell启动
asAdmin: true ## 要求以管理员权限启动
commands: ## 别名配置最常用命令
start: npm run dev
build: ./scripts/build.sh
协议定义了四个基础配置，以解决最常用的终端进入需求以及能隔离冲突的扩展性需求。
-启动终端，进入项目目录
| 属性名 | 类型 | 声明的语义 |
|---|---|---|
shell |
String | 偏好的终端类型（如 wt, bash, powershell）。 |
asAdmin |
Boolean | 是否需要以管理员/Root权限执行，主要针对windows。 |
commands |
Map | 自定义命令映射表，如 start, test 等。 |
附注：启动用其他以路径为目标上下文的应用(比如typora、vscode、资源管理器)的功能，因不依赖配置，协议不做约束，均有上层自由实现。
-扩展槽
| 属性名 | 类型 | 说明 |
|---|---|---|
extensions |
map{string,map} |
上层扩展占位槽。 |
语义说明：
1、协议层永远不依赖其中任何字段，所有上层功能扩展必须放入此槽内。
2、extensions采用命名空间隔离，每个命名空间代表一个上层产品或能力单元，且更新操作时不应该破坏其他命名空间的原值。为降低空间冲突概率，建议使用带产品域名的空间命名规则。
本协议采用完全开放许可: MIT License
基于该协议，目前已做了上层工具实现：
1、快捷进入终端、或打开资源管理器
2、自动忽略.开头、$开头的文件夹，以及node_modules等多种主流语言的包管理目录、编译目录、缓存目录等
3、只扫描根目录下最多5层，性能极佳
4、高容错，如配置格式yaml解析非法，会按默认无配置处理，且有反馈体验
5、支持全局默认配置shell，可以尽可能避免项目级配置。优先级是项目级配置>全局默认配置>工具默认配置
6、最近进入的项目排序优先
提供可视化的操作体验：
1、进入git仓库，下载最新的release版本
2、选择对应的操作系统版本安装
1、纯本地工具，无任何外网请求
2、清爽简洁的体验、高容错、性能极佳、支持多国语言、多操作系统
3、但需要手动放置.project文件
4、内置了快捷键来打开最小化到托盘的窗口ctrl+alt+P
-windows快捷键：Ctrl+Alt+P
-mac快捷键：Command+Option+P
提供工程师习惯的终端操作体验：
1、全局安装：npm install -g dotproject
2、执行：project
1、推荐无参数project交互式命令，快速罗列项目，使用序号精准执行进入操作
2、支持按项目名定向进入项目
3、支持初始化声明、管理配置、打开资源管理器等基础指令
| flag | 说明 |
|---|---|
project --help |
显示完整帮助信息与示例说明。 |
| 子命令 | 说明 |
|---|---|
project init |
将当前目录声明为项目，交互式生成 .project 文件。 |
project root add|remove [path] |
管理项目搜索的根目录集合；未传 path 时默认使用当前目录。 |
project default [shell] |
设置或读取全局默认终端类型，用于统一项目启动环境，减少项目级配置。 |
project open <project> |
打开指定项目所在目录的文件资源管理器。 |
| 命令结构 | 类型 | 说明 |
|---|---|---|
project |
Interactive | 列出所有已缓存项目并进入交互模式，可通过[序号]精准选择并启动项目。 |
project <project> |
Launch | 启动指定项目的终端。 |
project <project> <commandName> |
Launch + Execute | 启动指定项目，并在新终端中执行项目内配置的命令，如 dev、start、test 等。 |