mirror of
https://github.com/multica-ai/multica.git
synced 2026-08-01 01:16:17 +02:00
* fix(landing): align ZH copy with conventions and update tool list to 11 - Replace "Agent" with "智能体" in ZH marketing copy (lines 1-275) per conventions.zh.mdx — landing was the only surface still using "Agent" while UI, docs, and locales already use "智能体". Changelog-section technical names (Agent SDK / Agent runtime / Cursor Agent) preserved. - Replace the 4-tool list (Claude Code / Codex / OpenClaw / OpenCode) with the actual 11 supported tools across hero card, how-it-works step, and FAQ — this matches daemon-runtimes.mdx and the file's own changelog entries that already record the rollout of Cursor, Copilot, Gemini, Hermes, Kimi, Kiro CLI, and Pi. - Drop the "plug in and go" line; replace with an honest sentence about multica setup walking through OAuth + daemon start. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(i18n): correct daemon/runtime drift across modals, onboarding, docs - modals/zh-Hans: 4 places used "daemon" untranslated; conventions.zh.mdx rules Daemon -> 守护进程. Aligned. - onboarding/zh-Hans: line "把任务交给它们" was the only spot using "任务" for the task entity; rest of the file already uses lowercase "task" per conventions. Aligned. - onboarding (en + zh-Hans) runtime_aside.what_suffix: said runtime IS a background process. daemon-runtimes.mdx defines runtime = daemon × one AI coding tool (one machine + N tools = N runtimes). Replaced with the correct definition so new users form the right mental model on first contact. - onboarding (en + zh-Hans) step_platform headline+lede: said "Connect a runtime" but the next options are "install desktop / CLI / cloud waitlist" — those install a runtime source, not connect to one. Reworded. - onboarding/zh-Hans: 4 places used "AI 编码工具"; docs use "AI 编程工具" consistently. Unified on the docs term. - daemon-runtimes (en + zh): added cross-link to /desktop-app for users deciding between desktop daemon and CLI daemon. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): localize starter-content (Getting Started project) The Getting Started project + welcome issue + 10 sub-issues that land in the workspace at the end of onboarding were hardcoded English. Chinese users finished a Chinese onboarding flow and arrived to an all-English workspace; the welcome issue's prompt to the agent was also English, so the agent's first reply tended to be English regardless of what templates the user picked. This commit adds Chinese parity, fixes the runtime definition error that was the source of similar drift in onboarding.json, and removes a few hardcoded UI specifics that would silently rot. Architecture: - Long-form markdown (~600 lines per language) lives in TS sibling files: starter-content-content-en.ts and starter-content-content-zh.ts. JSON locales were considered, but multi-paragraph markdown becomes unreadable single-line escape soup in JSON; keeping it in TS lets reviewers see the rendered shape and catch markdown regressions in code review. - starter-content-templates.ts is now a thin orchestrator: imports both content files, exports buildImportPayload({ ..., locale }), picks the right one at runtime. - StarterContentPrompt resolves locale from i18n.language (with a small startsWith("zh") helper so "zh-Hans-CN" or future variants still hit the ZH content). Content fixes (apply to both EN and ZH): - "A runtime is a small background process" was wrong (runtime = daemon × one AI coding tool, per docs). Replaced with the correct definition so the welcome agent doesn't seed an incorrect mental model. - Removed hardcoded "tabs at the top: 6 tabs" / "(third row)" / "6 templates" lists — those rot the moment product UI changes. Replaced with descriptions that don't depend on exact counts/positions. Conventions adherence (ZH): - agent → 智能体, daemon → 守护进程, runtime → 运行时, workspace → 工作区 - task / issue / skill stay lowercase English (per conventions.zh.mdx) - Product UI labels (Properties, Assignee, Status, Activity, Live card, Inbox, Members, Settings, Runtimes, Configure, Repositories, Instructions, Tasks, Skills, Autopilot, etc.) stay English so the doc text matches what the user sees on screen. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(conventions): formalize mixed-rule for task / issue / skill in CN The prior rule said issue/skill/task always render as lowercase English in Chinese text. That worked for UI strings but never matched what the sister docs actually do — tasks.zh.mdx is built around "执行任务", issues.zh.mdx titles "Issue 与 project", skills.zh.mdx titles "Skills". Three docs, three patterns, all sensible in their own context, none matching the old rule. Conventions also explicitly cited the docs as the voice standard, so the rule was internally inconsistent. This commit promotes the de facto pattern to a written rule: - UI strings, state names, code references → lowercase English ("排队中的 task", "创建子 issue", "为智能体注入 skill") - Doc titles / section headings → Title-case English OR Chinese term ("Issue 与 project", "Skills", "执行任务") - Doc prose where the entity is the running subject → Chinese term, with English in parentheses on first mention ("**执行任务**(task)是智能体每一次工作的单位") - API / DB fields → always task / issue / skill (`task_id`, etc.) Provides the term mapping (task ↔ 执行任务) explicitly so future translation PRs don't have to rediscover it. No code or other doc changes — tasks.zh.mdx already follows this pattern; this commit just formalizes it. Other ZH locale strings remain lowercase per the UI rule (which the locale audit + PR #2139 verified). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: add Projects page (en + zh) and Autopilot failure visibility note The audit found that 'projects' was the most prominently missing docs page — it appears as a sidebar nav item in onboarding's workspace preview, but users clicking through to docs found nothing on the topic. The other locale-but-no-doc pages (my-issues, labels, settings) are listed as follow-ups; this PR ships the highest-impact one. Also adds a missing piece in tasks.{mdx,zh.mdx}: the Autopilot no-auto-retry callout explained the *why* but never the *how do I notice* — added a sentence pointing users at Inbox + the issue status revert + the Autopilot page's run history. projects.mdx covers: - What a project is (container for related issues) - Fields: name, icon, description, lead, status, priority, progress - Project-issue many-to-one relationship + how progress is computed - Pinning to sidebar (personal preference) - Resources section (GitHub repos passed to daemon) - Delete behavior (issues unlinked, not deleted) - Lead can be a member or an agent Both pages registered in meta.json / meta.zh.json under "Workspace & team" group, between issues and comments. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(pr-template): add drift-prevention checkboxes for runtime/CN copy Two failure modes the docs+onboarding audit found, both caused by adding-a-thing without remembering all the places that thing surfaces: 1. New runtime / coding tool / UI tab gets recorded in changelog but not in landing FAQ ("Multica supports 4 tools" while changelog shows the 11th was added) or starter-content tutorial ("6 tabs at the top: Instructions / Skills / Tasks / Environment / Custom Args / Settings" stays frozen the moment a tab is added or renamed). 2. Chinese copy added without checking the canonical glossary — "Agent" survived in landing/zh.ts long after product UI standardized on "智能体" because nobody routed landing through the conventions review. Adding two checklist items to the PR template so authors see the specific paths to update at PR-creation time, before the drift ships. This is the final batch (5 / 5) from the audit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
50 lines
3.0 KiB
Plaintext
50 lines
3.0 KiB
Plaintext
---
|
||
title: 项目
|
||
description: 把相关的 issue 归为一组当成一个单元来跟进 —— 有优先级、状态、进度和负责人。
|
||
---
|
||
|
||
import { Callout } from "fumadocs-ui/components/callout";
|
||
|
||
Multica 里的**项目**(project)是相关 [issue](/issues) 的容器。当一摊工作比单个 issue 大、又比整个工作区小的时候用它 —— 一次发布、一次迁移、一个分多块做的功能、一个会拆出多个线索的调研。
|
||
|
||
每个项目有名字、图标、描述、**负责人**(lead,可以是成员,也可以是 [智能体](/agents))、**状态**(`planned` / `in_progress` / `paused` / `completed` / `cancelled`)、**优先级**(`urgent` / `high` / `medium` / `low` / `none`),以及一个根据关联 issue 状态自动算出来的**进度**百分比。
|
||
|
||
## 项目和 issue 的关系
|
||
|
||
项目和 issue 是独立对象,多对一关系:一个 issue **最多属于一个**项目;一个项目可以容纳**任意多个** issue。关联和解除关联随时可逆 —— 在看板视图里拖动,或者在 issue 右侧 properties 面板用项目选择器。
|
||
|
||
项目的进度条是按关联 issue 状态自动算出来的 —— 越多 issue 到 `done`,进度条越满。`cancelled` 的 issue 不计入分母;`backlog` 的 issue 计入分母但不计入分子。
|
||
|
||
## pin 到侧边栏
|
||
|
||
点项目右上角的 pin 图标,可以把这个项目加到侧边栏的固定区。pin 过的项目无论你在工作区哪里都一键可达;每个人独立 pin —— pin 是个人偏好。
|
||
|
||
侧边栏 **Workspace → Projects** 链接始终展示工作区里所有项目;pin 只是在这之上的个人快捷方式。
|
||
|
||
## 关联 resources
|
||
|
||
每个项目有一个 **Resources** 区,可以挂 GitHub 仓库。挂上之后,被分配到这个项目里 issue 的 [智能体](/agents) 在执行 task 时可以读写这些仓库 —— Multica 会把仓库 URL 作为上下文传给 [守护进程](/daemon-runtimes)。
|
||
|
||
Resources 是项目级别的;多个项目要共享同一个仓库,要分别挂上。
|
||
|
||
## 删除项目
|
||
|
||
删除项目**不会**删除它的 issue。关联的 issue 只是解除关联,回到工作区的扁平 issue 列表。这是刻意的 —— 即使项目本身的框架变了,里面的工作通常也不会是一次性的。
|
||
|
||
<Callout type="info">
|
||
如果你确实想把工作也删掉,先归档或删除 issue,再删除项目。
|
||
</Callout>
|
||
|
||
## 项目负责人
|
||
|
||
负责人是为这个项目负总责的人 —— 或者智能体。这是一个软信号,不是权限控制:工作区任何成员都可以编辑项目,不管谁是负责人。项目负责人可以是:
|
||
|
||
- 工作区里的成员(人)
|
||
- [智能体](/agents) —— 当项目里的工作大部分要交给智能体时合适(例如"每周 bug 巡检"由一个巡检智能体担任 lead)
|
||
|
||
## 下一步
|
||
|
||
- [Issues](/issues) —— 项目里装的工作单元
|
||
- [智能体担任项目负责人](/agents) —— 什么时候由智能体当 lead 合适
|
||
- [Multica 怎么运转](/how-multica-works) —— 整体视图
|