mirror of
https://gh-proxy.org/https://github.com/klinsmaya/multica.git
synced 2026-11-11 02:46:45 +08:00
苗大
e13a902f59
* chore(docs): upgrade to Fumadocs 16 and Next.js 16 Fumadocs UI 16 requires Next.js 16, so the docs app moves to Next 16 alongside it (apps/web is already on 16). - fumadocs-core/ui 15 -> 16, fumadocs-mdx 12 -> 15 - import collections from .source/server and RootProvider from fumadocs-ui/provider/next - migrate UI translation keys to the v16 message ids - rename middleware.ts to proxy.ts per the Next 16 convention - declare the status, diff and overlay color slots v16 moved out of preset.css - keep heading anchors, now rendered as a[data-card], out of the card styles - drop the language select v16 adds to the sidebar footer; the docs settings menu already switches language * feat(docs): add a kit for click-through product demos Docs pages can embed small demos that imitate the product and walk the reader through one action. The kit holds the shared frame (title, replay, live caption), the coach mark that rings the next control with a localized "Click" and an arrow, and timeline pieces for runs, comments and steps. Demos start when scrolled into view, take their scenario copy per locale, and isolate their stacking so they stay under the page header. tw-animate-css provides the enter animations, as in apps/web. * fix(docs): consistent Steps, Tabs and Accordion styling - a Steps item is at least as tall as its number badge, so one-line steps don't stack their badges - accordion headers (not-prose h3) skip the editorial heading styles - hide the copy-link button Fumadocs adds beside accordion titles; the ids stay so links still open an entry - tab bars end in a hairline that carries the active underline without overflowing the scrolling bar, and a lone code block in a tab keeps its inset and border, so every tab group looks the same * docs: interactive getting-started pages - concepts: clickable map of the core objects and their relations - how-multica-works: step-through of one run from issue to result - triggering-agents: pick a goal, get the way to start an agent, including issue wakeups - cloud-quickstart and tutorial use Steps; agent creation, the runtimes entry and the sidebar paths match the current product Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive workspace, issue and project pages - demos for member roles, issue statuses, project progress, workflow handoffs, creating an issue with an agent, deliverable versions and local directory modes - new Analytics page with a demo of the usage and errors tabs: cost estimates, runtime usage, custom prices and per-issue spend - issues: custom properties, display settings and saved views, peek, bulk edits and duplicates - project progress counts the done and closed categories; status category names, the workflow return label and share links follow the product; agent moves trigger handoffs too - project-resources: modes as Tabs, worktree details as Accordions Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive agent pages - demos for agent Access, creating an agent, adding a skill and a squad run led by its leader - agents-create describes the current runtime -> configure -> done flow instead of the removed start-blank / build-with-AI choice, and covers workspace-shared MCP servers - squads: notified members, a three-column re-trigger table, and the sections the ja/ko pages were missing Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive everyday-collaboration pages - demos for steering a running agent, mentioning an agent, assigning an issue, resolving a thread, running a quick action, chat, the chat message queue and the inbox - mentioning-agents documents steering and the per-recipient delivery options; follow-ups no longer always wait for the run to end - comments: sub-issues created from a thread, the thread minimap and edit-conflict comparison - chat: the floating window, draft restore and the message queue - new page for search, keyboard shortcuts and preferences - quick actions: the sidebar list is not filtered by invoke permission Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive runtime and automation pages - demos for a failed run and its retry, a run waiting on an offline computer, an autopilot run, an issue wakeup and picking a coding tool - new Issue wakeups page: event, time and periodic conditions, check-ins, limits, the child_done system rule and its workspace default, and the `multica issue wakeup` commands - daemon-runtimes: start at login, local MCP merging, cleanup and retention, Codex memory defaults, and sharing a runtime with specific members - runs on an offline runtime fail only after the reconnect grace (default 3h); the execution log lists the latest three past runs - providers and the install guide add ZeroClaw and the model-selection column; install-agent-runtime uses Steps, Tabs and per-tool Accordions - the event-filter heading keeps the anchor the product links to Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive integration and app pages - demos for talking to a channel bot, a merged PR completing its issue and per-workspace desktop tabs - the bot guides share one Steps-based layout with their old anchors - Lark and Telegram attach recent group messages as read-only context - desktop-app: pinned tabs - fix stale French GitHub and mobile self-hosting sections, and the compressed ja/ko Telegram pages Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: restructure self-hosting and reference pages - self-host-quickstart and troubleshooting use Steps, Tabs and Accordions with ASCII ids so links open the right entry; code-block tabs become Tabs like everywhere else - environment-variables adds the GC, log rotation and per-tool path/model settings and drops the unused MULTICA_KEEP_ENV_AFTER_TASK - cli adds issue timeline, issue wakeup, daemon autostart and the commonly used flags - fix a corrupted link, flattened code indentation and dead anchors - translations no longer call GitHub issues "tasks" Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * feat(docs): show the search bar with compact results The site already served a per-locale search index from /api/search (with character-level tokenizers for zh and ja), but the layout hid Fumadocs's search toggle, leaving ⌘K as the only, undiscoverable way in. The toggle is back: a search bar atop the sidebar on desktop and an icon in the mobile header. Fumadocs's default dialog renders every matching paragraph, table and row in full, which buries the page titles. Like DocSearch and Pagefind, results now show the page and section titles plus at most three matches per page, each a two-line excerpt around the match; table rows become one line with their cells joined. The index and ranking are unchanged.
80 lines
4.2 KiB
Plaintext
80 lines
4.2 KiB
Plaintext
---
|
||
title: Projects
|
||
description: Organize related issues with projects and give them a shared goal, plan, and execution context.
|
||
---
|
||
|
||
import { Callout } from "fumadocs-ui/components/callout";
|
||
import { ProjectDemo } from "@/components/demos/project-demo";
|
||
|
||
Projects organize work that takes multiple [issues](/issues) to finish — a product launch, a migration, or a feature delivered in stages.
|
||
|
||
Work that a single issue can describe does not need a project. Projects fit a group of work that shares a goal, needs its progress tracked together, or needs shared repositories and working directories.
|
||
|
||
## Parts of a project
|
||
|
||
| Part | Purpose |
|
||
|---|---|
|
||
| **Name, icon, and description** | Goal, scope, and long-lived requirements; the description enters the execution context of agents working inside the project. |
|
||
| **Status** | `planned`, `in_progress`, `paused`, `completed`, or `cancelled`. |
|
||
| **Priority** | `urgent`, `high`, `medium`, `low`, or `none`. |
|
||
| **Lead** | A member or an agent — who coordinates the project. |
|
||
| **Start and target dates** | The project's planned time range. |
|
||
| **Issues and progress** | The work in the project and how much of it is finished. |
|
||
| **Resources** | Linked GitHub repositories or local directories on specific computers. |
|
||
| **Workflow** | The steps its issues follow and who takes over at each step. |
|
||
|
||
## Projects and issues
|
||
|
||
A project can contain any number of issues; an issue belongs to at most one project. Create issues directly inside the project, or pick or change the project from the issue's properties.
|
||
|
||
Project progress is computed automatically from linked issues:
|
||
|
||
```text
|
||
progress = issues whose status is in the done or closed category ÷ all issues in the project
|
||
```
|
||
|
||
Among the built-in statuses that means `done` and `cancelled`; custom statuses in those two categories count as well. `cancelled` means that work has been closed out of the project's scope, so it counts toward progress.
|
||
|
||
Project status and issue status are independent: finishing every issue does not set the project to `completed`, and changing the project's status does not bulk-change its issues.
|
||
|
||
<ProjectDemo />
|
||
|
||
## Project description and execution context
|
||
|
||
When an agent runs an issue inside a project, the project's name and description are added to that run's context. Put what every related run needs to know in the description — the goal, technical boundaries, delivery conventions — and keep requirements for a single issue in that issue.
|
||
|
||
## Add resources
|
||
|
||
Project resources tell agents which code and working directories to use:
|
||
|
||
- **GitHub repositories**: provide a repo the runtime can check out, with an optional ref.
|
||
- **Local directories**: let the runtime on a specific computer work in an existing directory, whose contents the agent modifies directly.
|
||
|
||
See [Project resources](/project-resources) for how to choose and for the safety boundaries.
|
||
|
||
## Choose a workflow
|
||
|
||
Choose the project’s **Workflow** to set its board columns and who takes over at each step. For example, development can go to one agent, review to another, and acceptance to a team member. Projects without another choice use **Default**: every status is available and nothing is handed off automatically. See [Workflows](/workflows) for setup and switching an existing project.
|
||
|
||
## Project lead
|
||
|
||
The lead can be a member or an agent; a member who is the lead can also switch the project’s workflow. Making someone the lead does not assign issues to them or start any work. To hand a step to the lead, set that step's handler to **Project lead** in the workflow.
|
||
|
||
## Pin to the sidebar
|
||
|
||
A pinned project appears in your sidebar. Pinning is a personal preference and does not affect other members.
|
||
|
||
## Create, edit, and delete
|
||
|
||
Any workspace member can create and edit projects; only `owner` and `admin` can delete them.
|
||
|
||
<Callout type="warning">
|
||
Deleting a project does not delete its issues: they detach and stay in the workspace. The project's description, status, and resources are permanently deleted.
|
||
</Callout>
|
||
|
||
## Next steps
|
||
|
||
- [Project resources](/project-resources) — link GitHub repositories or local directories.
|
||
- [Issues](/issues) — create and organize the concrete work in a project.
|
||
- [Agents](/agents) — learn about agent identity, configuration, and Access.
|