Architecture: decouple project identity from config — config should not store project identifiers

[zhangweijian97]

---

English

Problem

The projects array in devos.config.ts mixes two fundamentally different concerns:

1. Project registration data — id, name, workspacePath: which projects exist, their identity. This is operational data that changes over time as projects are added/removed.

2. Per-project config preferences — model choices, agent type, skills paths. This is true configuration that rarely changes.

Currently, these are interleaved in a single file. This creates a concrete problem: the id field is a per-user, per-machine value (determined by the local DB at onboard time), but devos.config.ts is committed to the repo. Every new user clones the repo and gets the wrong id — a UUID that belongs to the original author's local database.

This also means:

• The config file acts as a poor man's database for project identity, duplicating what Server's projects table already stores.
• The projects array is inherently dynamic (projects come and go), which makes it awkward as a static config entry.
• There's no clean separation between "what projects am I managing" (data) and "how do I develop each project" (config).

Suggested direction

A cleaner architecture would be three layers:

1. Global defaults (~/.devos/config or similar): default model, agent, skills — applied to all projects unless overridden.
2. Per-project overrides (stored in the project directory or DB): only the differences from global defaults.
3. Project registry (Server DB projects table): project identity (id, name, workspacePath) — this is data, not config. The Server already has this.

The config file should only contain true configuration preferences. Project identity and discovery should flow from the database (or be inferred from cwd context), not from a static declaration in a config file that gets committed to git.

Additional note

devos.config.ts should not be committed to version control. A devos.config.example.ts or a generated config at onboard time would be more appropriate.

---

中文

问题

devos.config.ts 中的 projects 数组混淆了两个本质不同的关注点：

1. 项目注册数据 — id、name、workspacePath：当前在管理哪些项目，它们的身份信息。这是会随时间变化的操作数据。

2. 项目级配置偏好 — 模型选择、agent 类型、skills 路径。这是真正的配置，很少变化。

目前这两者混在同一个文件中。这导致一个具体问题：id 字段是每个用户、每台机器独有的值（onboard 时由本地数据库生成），但 devos.config.ts 被提交到了 repo。每个新用户 clone 下来拿到的都是原作者的 UUID，跟自己的本地数据库对不上。

这也意味着：

• config 文件实际上在充当一个简陋的项目数据库，而 Server 的 projects 表已经存了同样的信息。
• projects 数组本身是动态的（项目会增减），放在静态配置文件里很别扭。
• "我在管理哪些项目"（数据）和"每个项目怎么开发"（配置）之间没有清晰的边界。

建议方向

更干净的架构应该是三层分离：

1. 全局默认配置（~/.devos/config 之类）：默认模型、agent、skills —— 除非被覆盖，否则对所有项目生效。
2. 项目级覆盖（存在项目目录或数据库中）：只写跟全局默认不同的部分。
3. 项目注册信息（Server DB projects 表）：项目身份（id、name、workspacePath）—— 这是数据，不是配置。Server 端已经有了。

配置文件应该只包含真正的配置偏好。项目身份和发现应该从数据库获取（或从 cwd 上下文推断），而不是从提交到 git 的静态配置中声明。

补充

devos.config.ts 不应该提交到版本控制中。提供 devos.config.example.ts 或在 onboard 时生成更合适。