Files
multica/apps/docs/content/docs/projects.zh.mdx
Naiyuan Qing 32740d0ee3 docs+i18n: fix terminology/runtime drift across landing, onboarding, docs (#2146)
* 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>
2026-05-06 18:44:39 +08:00

50 lines
3.0 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
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) —— 整体视图