Get a team's status summary — team info + members + active tasks.

Hits /status (not the bare team row): the plain team endpoint carries no member or task fields, so callers asking "what is this team doing" got a row with nothing actionable in it.

Default response is a COMPACT projection (view="compact" + hint - trimmed, NOT missing fields). The upstream summary embeds the entire roster and every active task as full rows, which measured 170,331 chars on a real 173-member workflow team and 69,660 on a 51-member session team - both past the MCP result ceiling, i.e. the tool simply did not work on the teams that most needed it. Members and tasks are projected here, offline members fold into a count plus digest, and the API route and Dashboard JSON are untouched.

List teams — active ones by default, newest first.

Default response is a COMPACT projection (view="compact" + hint - trimmed, NOT missing fields): each row keeps id / name / status / kind / project_id / created_at. The unfiltered full-row list measured 148,173 chars across 316 teams on the real install, past the MCP result ceiling; teams accumulate one row per Workflow run and per CC session, so the list only ever grows.

Get a team panoramic briefing — understand full team status in one call.

Returns team info, member status, recent events, recent meetings, pending tasks, and action suggestions.

Default response is a COMPACT projection (view="compact" + hint - trimmed, NOT missing fields): the roster follows the same live-first / offline-digest split as agent_list, event payloads collapse to a one-line derived summary, and pending tasks use the task-wall row projection. Measured 20,521 chars on a 173-member workflow team before projection.

Close (complete) a team — sets team status to completed and marks all busy agents as offline.

Use this when the team's mission is fully done. Members are not deleted, but their status is set to offline automatically.

team_id is REQUIRED — closing a team is not reversible from the tool面, so it never falls back to auto-resolving "the active team".

Delete a team. team_id is REQUIRED — never auto-resolved.

Update an Agent's running status.

List a team's members - live roster first, offline history on request.

Default response is a COMPACT projection (view="compact" + hint - it is a trimmed view, NOT missing fields). Each member row keeps id / name / role / status / an 80-char current_task excerpt / last_active_at; system_prompt, config, the context watermark and the token ledger are omitted and come back with fields="all".

Offline members are folded into a count plus a short most-recent digest. An offline agent is a terminated process - it cannot be messaged and cannot be assigned work - and on the real 51-member session team those rows were 96.4% of the payload, which is what made this tool exceed the MCP result ceiling and fail outright. Nothing is deleted: the count is always reported and include_offline=True returns the full history.

List every Agent template CC can actually resolve.

Scans all three template sources with CC's own precedence — project-level <project>/.claude/agents/ > user-level ~/.claude/agents/ > the shipped plugin/agents/ — and de-duplicates by frontmatter name (the identity CC resolves), so the count matches what subagent_type will really accept. Each entry carries a source field.

Default response is a COMPACT projection (view="compact" + hint - trimmed, NOT missing fields): the full listing measured 32,480 chars, half of it because grouped repeats every row of templates verbatim. Compact keeps one projected row per template and reduces grouped to a name index.

Recommend Agent templates — and, for a known project type, a team shape.

Two layers in one answer:

1. recommendations — live template match against the installed template dirs (project > user > plugin), ranked by relevance.

2. team_composition — when task_type names a project type (web-app / api-service / data-pipeline / library / refactor / bugfix), a suggested role lineup with counts and the template to use for each. This is a static seed, not a live probe; it only suggests a shape.

Recommend whether to reuse an existing sub-agent for a follow-up task.

For follow-up work (bug re-fix, deeper research, same-domain iteration), resuming a prior sub-agent preserves its accumulated context. This tool ranks prior sub-agents by same-domain match, reads their P1 context watermark, infers reachability, and recommends one of three actions: reuse (SendMessage resumes it) / slim_then_reuse (self-summarize then spawn fresh with the summary) / spawn_new. It only recommends; the Leader decides.

Availability tiers: live (same session, reachable now) / resumable (same session, offline but transcript fresh) / cross-session (another session, needs claude --resume) / expired (past retention). Address candidates by NAME — SendMessage(to=...) takes a teammate name and keeps working after the agent completes; each candidate's resume_hint is a ready-to-run call (with the required summary). The raw agentId is the documented fallback for nameless rows or when a newer agent took the name.

Default response is a COMPACT projection (view="compact" + hint — trimmed, NOT missing fields): decision signals and call keys kept, full rationale and watermark detail via fields="all".

Dispatch an operational instruction to another ship (CC session) in the fleet.

The fleet down-channel drives an EXISTING idle session to run one turn via headless claude -p --resume (fleet-layer design §4). Use it to nudge an idle ship to advance a task or report its status - NOT to make strategic decisions on the user's behalf (the dispatched turn is constrained to operational work).

Safety gate (enforced server-side, no subprocess spawns until it passes):

• The target must be RESUMABLE: its transcript file still exists.

• The target must NOT be user-live: its file must be idle beyond a conservative guard (FLEET_DISPATCH_MIN_IDLE_SECONDS, > the 15min live window) so a dispatch never competes with someone typing in that session. A too-fresh target is refused with availability="live".

• Dispatches are deduped per-session, share the global wake concurrency limit and circuit breaker, and every one is ledgered in wake_sessions.

Get target_session_id from the fleet view / project summary (each ship's session_id). This tool RECOMMENDS nothing and DECIDES nothing strategic; it only relays an operational instruction to an idle ship.

Query Agent activity records for a team.

Returns recent activity log entries sorted by timestamp descending, including tool name, duration_ms, and an I/O summary.

Default response is a COMPACT projection (view="compact" + hint - trimmed, NOT missing fields): input/output summaries are excerpted because the raw output_summary often holds a whole command transcript (a 60-row window measured 43.9k chars, right at the MCP result ceiling). Full records via fields="all". The compact window is capped at 50 rows - narrow with agent_id rather than widening limit.

Create a team meeting and return a ready-to-use dispatch_plan for spawning participant Agents.

Supports two participant formats:

1. Legacy (strings): participants=["arch-lead", "backend-arch"] Returns dispatch_plan with empty launch_call + deprecation warning.

2. Structured (dicts): participants=[{"name": "arch-lead", "agent_template": "software-architect", "role": "负责评估架构方案", "context_files": ["docs/arch.md"], "expected_output": "三段式"}] Returns dispatch_plan with fully populated launch_call.params ready to paste into Agent tool.

Send a discussion message in a meeting.

Discussion rules:

• Round 1: Each participant presents their views

• Round 2+: Must read previous speakers' messages first, cite and respond to specific points

• Final round: Summarize consensus and disagreements

SECURITY: Set caller_agent_id to the actual agent making this call. If it differs from agent_id, the message is flagged as impersonation in the audit log. Leader sending on behalf of others should set caller_agent_id='team-lead'.

Read all discussion messages in a meeting.

Conclude a meeting, marking it as completed.

By default checks that all expected participants have spoken before concluding. Set force=True to override, but this will be recorded in the event log.

List available meeting templates and their round structures.

Returns: templates: All available templates with round structure details

List meetings for a team, optionally filtered by status.

Start a structured 4-round debate meeting between an Advocate and a Critic.

Debate structure:

• Round 1 (Advocate): Present proposal/position with evidence

• Round 2 (Critic): Challenge risks, flaws, and propose alternatives

• Round 3 (Advocate): Respond to challenges, revise proposal if needed

• Round 4 (Judge): Render verdict with action items

Start a debate-style code review for a specific file or change.

Creates a structured 4-round debate where:

• Advocate defends the current implementation

• Critic challenges the implementation and proposes improvements

• Judge synthesizes findings into consensus conclusions and action items

Update meeting fields (topic, participants, notes).

Use this to add conclusions/notes to a meeting or update its topic. To formally conclude a meeting (mark as concluded), use meeting_conclude instead.

Check which expected participants have spoken in the current round.

Use this after spawning all Agents via dispatch_plan to verify attendance before advancing to the next round or concluding the meeting.

Put a task on a team's wall. Nothing executes it — an Agent has to pick it up.

The name is historical: there was once a worker pool that would "run" the task. That pool is retired; this tool only creates the row. Dispatch is yours to do (Agent(...) / SendMessage), and the sub-agent then writes progress back with task_memo_add.

Priority and horizon drive the task wall's ordering, so set them here — the old docstring told callers to "set priority and horizon" while the signature had no such parameters, and any value passed was silently dropped (fixed 2026-07-27).

Create a new task in a project (not bound to a team).

Project-level tasks are attached directly to the project and visible on the project task wall. Suitable for planning-phase tasks not yet assigned to a team.

Query the current status of a task.

Update a task's fields (partial update — only provided fields are changed).

Get the task wall — project-scoped by default, team-scoped on request.

This is the single task-wall entry point (the team-only taskwall_view was folded in here 2026-07-27): pass team_id to narrow the wall to one team, leave it empty to get every team under the project plus the project-level tasks that belong to no team.

Default response is a COMPACT projection (marked by view="compact" + hint — it is a trimmed view, NOT missing fields): each task row keeps id/title/priority/status/score/assigned_to/tags + 80-char desc excerpt (plus result/depends_on/subtask_count when present). Full details of a single task: task_status(task_id) / task_memo_read(task_id).

Read all memo records for a task — read before picking up a task to understand historical progress.

Add a memo record to a task — for tracking progress, recording decisions, marking issues.

Get a task's execution timeline — plain, or with checkpoints + stats.

The separate task_replay tool was folded in here 2026-07-27: both answered "how did this task actually go", differing only in whether the answer carried the derived summary. include_stats=True is the old replay view.

Create a new project with a default Phase automatically created.

⚠️ IMPORTANT: Projects are automatically registered by the OS when a CC session starts. You should NOT manually create projects unless the auto-registered project is missing. The root_path MUST match the current CC session's working directory — do NOT create projects pointing to other directories.

List all projects in the system.

Returns: projects: List of all projects with id, name, description, root_path, etc.

Update a project's name, description, or root_path.

Delete a project.

Get a quick project summary: status (active/inactive), teams, top tasks.

Mark current cwd as dismissed for project registration — won't ask again.

Query team decision log — task assignments, approach selections, Agent scheduling decisions.

Return effectiveness statistics for Agent templates.

Aggregates activity records to compute success rate, average duration, and top failure reasons per template. Also shows how many failure alchemy lessons are associated with each template.

Use this to identify which Agent templates perform well and which need prompt improvement.

Report token usage together with how much of it can actually be accounted for.

Read-only. Every token number comes back alongside its denominator (dispatches_total) and its metric label, because a token count without those two is meaningless: this repo carries two orthogonal metrics that measure 5-25x apart, and sub-agent usage coverage is currently far below 100%. There is deliberately no total field — 95.6% of the four layers is cache_read, so a lone total is just a cache-read count in disguise.

Query cross-domain reference edges for an object (who references it / what it references).

Edges are extracted automatically (zero-LLM regex) from task memos and reports: wf_ runs, commit hashes, task UUIDs, [[memory]] links.

Trace the reference neighborhood of an object (undirected fanout, depth <= 2).

Answers questions like "which tasks/reports touched commit 9d8f020" or "what work is connected to run wf_cbad7348".

Search across all OS knowledge: task memos, reports, and tasks.

Three-arm RRF fusion (k=60): BM25 full-text (Chinese bigram native), knowledge-graph fanout (queries containing wf_/commit/uuid IDs pull in everything linked to them), and exact ID-prefix / title match.

Use this to recall past work: "归属铁律怎么修的", "wf_d01f207f", "stderr 盲区", commit hashes, etc.

Save a research/analysis report to the database.

Reports are stored in the database with project isolation — no filesystem permission needed. Reports appear on the Dashboard reports page automatically.

List saved reports, optionally filtered by author, topic, or type.

Returns reports for the current project context, sorted newest-first.

Read the full content of a saved report by ID.

Add a decision item to Leader Briefing for user review.

Use when Leader encounters decisions that require user input: project direction, architecture choices, budget/resource allocation.

Anything a sub-agent's completion report leaves "for the user to decide" belongs here — a decision parked in report prose is a decision the user never actually received.

List Leader Briefing items. Default shows pending items for user review.

Each item carries project_id and tags, so a long decision queue can be narrowed to one project and/or one topic.

Resolve a Leader Briefing item with user's decision.

Dismiss a Leader Briefing item (no action needed).

Analyze failed tasks, distill defense rules + training cases + improvement proposals (failure alchemy).

When a task permanently fails (exceeds retry limit), call this tool for deep failure analysis. Automatically generates three learning artifacts saved to team memory:

• Antibody: Defensive rule suggestions to prevent similar failures

• Vaccine: Structured failure case for new Agents to reference and learn from

• Catalyst: System improvement proposals to drive process optimization

Auto-diagnose why a task failed and suggest fixes.

Reads the task's execution trace (memos) to identify the failure point, compares with similar successful tasks in the same team, and returns actionable fix suggestions.

Use this when a task fails or gets stuck to quickly understand root cause without manually reading through all memo records.

Search the memory store in AI Team OS.

Add a direction-layer memory — the team's shared, cross-task standing preferences.

方向层 = 低频·高价值密度·跨任务长寿命的偏好/纠正/约束/设计意图。每个派出 的 agent 出生即注入方向层，"全中文""完成即汇报"这类偏好不再靠手抄进 prompt。

写入检验（软门槛）：这条能影响多少未来任务？只影响单个任务的 → 去 task_memo_add（情景层），不要写这里。

体量红线是单一轴：存储上限 = 注入预算。方向层按桶计字符配额—— global 1200 字 + 每个 project 1500 字 + user 300 字，一个会话实际继承 3000 字；单条仍 ≤ 400 字。存得下的一定传得到，写不进去的就是真的没位置： 超限时本工具返回该桶全部有效条目（id / kind / 字数 / 全文）+ 用量缺口， 要求当轮先 memory_invalidate（可用 content_match 子串定位）或 memory_reconcile_apply 腾出空间，再重试本次写入。 超长内容改写成「触发条件 + 指向权威文件」的指针条目（如 "涉及生产/集群/DB 时遵守只读铁律，详见 ~/.claude/CLAUDE.md"），正文外置。

写入侧安全扫描：方向层条目会进每个派出 agent 的 system prompt，因此不可见 Unicode、提示注入句式（覆盖既有指令 / 套取系统提示 / 伪造对话角色）、凭据 形态一律拒绝入库。

kind 四类（决定注入截断优先级 constraint>design>directive>preference）：

• constraint（禁令/护栏）：一句话、可机检、终身有效。 如 "所有输出使用中文"、"git 提交绝不自动加 agent 署名"。

• design（价值排序/设计意图）：缺显式指令时的取舍依据。 如 "技术决策偏向质量/简洁/健壮/长期可维护，不看重开发成本"。

• directive（方法论/工作方式）：回答"怎么干"。 如 "完成即按问题→根因→解法→验证汇报，不攒批次"。

• preference（格式偏好）：可选，如 "每句一行便于 diff"。

Invalidate a direction-layer memory — mark it invalid without deleting.

方向层偏好过时/被推翻时显式失效（Zep 失效语义：置 invalid_at 不删除， 保留可审计轨迹）。失效后不再进注入，也默认不出现在 memory_list。

两种定位方式，二选一：memory_id 精确定位，或 content_match 子串定位 （手里只有原文时免去先查一次 id——被配额顶回来的那一刻正是这种处境）。 子串必须唯一命中当前上下文的有效条目：命中 0 条或多条一律不动数据，多条时 返回候选让你给出更精确的子串。

List direction-layer memories — valid entries by default, grouped by kind.

返回当前上下文的方向层条目：global + user 全局条目 + 当前项目的 project 级条目，按 kind 优先级（constraint>design>directive>preference）+ 时间倒序。 这是双 hook 常驻注入的同一数据源；用它审阅"派出的 agent 会继承什么"。

按需整理·粗筛：返回情景层候选组 + 方向层清单 + 蒸馏素材 + 操作说明。

记忆整理 = 会话内按需显式动作（CC 非常驻，无后台整理进程）。本工具只做 确定性粗筛（零 LLM）——OS 无独立 LLM 凭据，判定由你（调用工具的会话内 agent）完成，工具只负责候选粗筛与操作应用（"agent 算、工具存"）。

返回四块（project_id 自动按当前上下文解析）：

• candidate_groups：有效 task_memos 按 scope_path/task 聚簇、簇内 BM25 两两 相似度超阈配对成的候选组（含组内各条全文 + id）。逐组做 LLM 精判： KEEP（都留）/ MERGE（合并）/ INVALIDATE（矛盾失效）/ NOOP（不动）。

• direction_inventory：全部有效方向层条目全文——逐条做陈旧检查（引用的 功能已退役/版本过时/世界已变 → 提 invalidate）。

• promotion_candidates：高频跨任务反复出现的簇，蒸馏为方向层条目的素材 （promote 操作，source_refs 回指源 memo）。

• operation_guide：四操作语义 + reconcile 三守则（只留高频有用 / 指向权威 而非复述 / 重写精简优先）+ 量大开 ultracode 提示。

判完后把确认的操作交给 memory_reconcile_apply 批量应用。

按需整理·应用：批量执行 LLM 精判确认后的操作（确定性，幂等）。

每条操作是一个 dict，按 op 字段分派（未知/缺字段返回 error，不阻断其余）：

• merge：{op:"merge", content:合并后新内容, memo_ids:[被并各条], memo_type?:"summary", scope_path?} —— 建新 memo，把被并各条置 invalid、 invalidated_by 指向新条（Zep 失效语义不删除）。

• invalidate：{op:"invalidate", memo_ids:[...]} —— 逐条失效（矛盾/被推翻）。

• score：{op:"score", memo_id, quality_score:1-10, reason} —— 补质量分， reason 入 meta。

• promote：{op:"promote", content, kind:constraint/design/directive/preference, scope?:"project"/global/user, source_refs?:[源 memo id]} —— 蒸馏提升为方向层 条目；红线照常生效（单条 ≤400 字 + 桶字符配额 global 1200 / project 1500 / user 300，超限该条返回 error 带用量；安全扫描同样生效）。

• keep / noop：不动（可省略）。

幂等：对已失效条目重复 invalidate/merge 返回 noop 不报错。应用后自动刷新 项目 last_reconcile_at（量阈软提示的基线）。

Get the current active OS context — active project, active teams, member list.

This is the infrastructure for all simplified operations. A single call returns the complete context of the current working environment, allowing Leader or other tools to auto-fill parameters like project_id, team_id, etc.

teams lists EVERY active team of the current project (a project routinely has several at once: the session container team plus one per Workflow run). team keeps the singular shape for backwards compatibility and holds the primary team picked by the same 3-tier priority as team_id auto-resolution (session container > plain project team > newest).

Returns: Context dict containing project / team / teams / agents

Check the health status of the AI Team OS API service.

Verifies the API service is running normally by accessing the team list endpoint, and reports one line of token-attribution coverage alongside it.

Returns: Health status info including API reachability, team count, and a usage-coverage summary (measured / dispatched per path, plus the narrowest link in the attribution chain)

Restart the AI Team OS FastAPI process safely (standardized restart flow).

Use this after backend code changes to pick up the new version without manually killing processes. The flow has three safety guards:

1. Busy-agent guard — refuses to restart while any agent is working (status=busy) unless force=True.

2. Port-pin guard — only ever restarts on the ORIGINAL port (default 8000, read from api_port.txt). If that port is held by an unrelated process it aborts rather than drifting to a random port.

3. Dead-before-spawn guard — waits until the old process has fully exited and released the port before spawning the new one; never spawns on a timeout.

If the API is already down, steps 2-4 are skipped and this becomes a plain "start" of the API on its configured port.

List recent events in the system, optionally filtered.

All four filters were already implemented server-side; the tool just never exposed them, so every call had to pull the global firehose and eyeball it (fixed 2026-07-27).

Default response is a COMPACT projection (marked by view="compact" + hint — it is a trimmed view, NOT missing fields): each row keeps id/type/source/ts plus a one-line summary derived from the event payload. Use fields="all" for full payloads.

Find ecosystem skills/plugins using a 3-layer progressive loading system.

Layer 1 (quick recommend): Describe your task and get top 3-5 matching skills with one-line descriptions and install commands. Layer 2 (category browse): Browse all skills grouped by category (memory / code-quality / frontend / security / dev-workflow / integration / etc.). Layer 3 (full detail): Get complete documentation for a single skill including features, OS complement relationship, and variants.

The integration category holds the ecosystem integration recipes (GitHub / Slack / Linear / fullstack team) that used to live in their own ecosystem_recipes tool — each one says which external MCP server to install and which OS tools it pairs with.

Get model governance state: available models (auto-discovered from local CC transcripts — the models you actually used), the current default startup model (~/.claude/settings.json "model" key), and per-model workflow agent usage over the last N days (orchestration charter observability: how much fable vs opus the fleet burned).

Set the default startup model for new CC sessions (writes the "model" key in ~/.claude/settings.json; empty string removes the key, restoring CC's own default). Takes effect on NEW sessions.

Send a message to a channel.

Supports cross-team broadcasting and @mention semantics.

Channel formats:

• "team:" — send to a specific team channel

• "project:" — send to a project-wide channel

• "global" — broadcast to all teams

Read messages from a channel.

Supports incremental pull via 'since' parameter to fetch only new messages.

Get channel messages that @mention a specific agent.

Verify whether a task is truly complete.

Checks:

1. Task status == completed

2. At least one memo record exists (task_memo_add was called)

3. A summary-type memo exists (task_memo_add type='summary' was called)

Use this after an agent reports completion to ensure all artifacts are present.

Scan popular Claude ecosystem repos (>=min_stars) and update ecosystem_repo_profiles.

Runs 8-10 gh search queries covering:

• topic:claude-code / topic:mcp / topic:mcp-server / topic:claude-agent

• topic:agent-framework + "claude" / topic:ai-agents + "claude"

• "claude code plugin" / "anthropic agent"

• anthropics org public repos

Deduplicates + filters >=min_stars + excludes known repos (CronusL-1141/AI-company etc.) Sets needs_deep_review=True for stars < 15000. relevance_category is auto-classified heuristically (based on topics + description keywords).

Query ecosystem_repo_profiles archive (Stage E enhanced).

Default response is a COMPACT projection (marked by view="compact" + hint — it is a trimmed view, NOT missing fields): each profile row keeps repo/stars/lang/status + summary. Full profile of a single repo: ecosystem_repo_get(repo_full_name); full rows here: fields="all".

Get holistic detail of an ecosystem repo (profile + tags + deep_reviews + relations + scan_run).

Search ecosystem repos by capability tags (reverse lookup from tag → repo).

Run an incremental or full ecosystem scan via the scanner service.

Compared to ecosystem_scan, this tool:

• skips repos last_scanned_at < 7 days (incremental strategy only)

• applies secondary owner / keyword filters

• marks repos pushed > 365 days ago as is_archived=True

• records every run as an EcosystemScanRun for audit

On-demand incremental refresh of the project's active ecosystem set.

Replaces the retired weekly cron (2026-07-10 decision: CC is not always-on, so long-running timers are pointless — refresh happens when the user asks for it). For each active-set repo (top_n by stars) this probes GitHub once, writes a status snapshot, and re-queues a Stage 0 shallow summary only when the repo has new pushes; 404/403 mark the profile deleted/private.

The response's hint field (present when repos were re-queued) reminds you to run the actual shallow scans via ultracode/Workflow and write results back with ecosystem_apply_shallow_summary.

Fetch a single EcosystemScanRun by id.

List recent scan runs ordered by started_at descending.

Queue a deep-review for a repo and return the dispatch prompt.

Creates an EcosystemDeepReview row queued on the funnel (stage_status='queued'; the legacy status column is a derived read-only view and returns 'queued' — no more 'running'), and embeds a sub-agent prompt (5-section template

• repo metadata) in the row's dispatch_prompt field. A background watchdog advances stage_status to shallow_failed (status derives to failed) after timeout_minutes if no report has been linked. The Leader is responsible for actually spawning the sub-agent (via the CC Agent tool; the session's implicit team is used automatically).

Look up the most recent deep-review for repo_id.

List deep-reviews newest-first, optionally filtered by status.

Cancel an in-flight (stage_status='queued') deep-review.

Advances the row's stage_status to shallow_failed (the legacy status column derives to failed) with a cancellation note. The sub-agent is expected to observe the row state and shut down on its own.

List ecosystem tag dictionary entries.

Three layers of tagging are supported:

• GitHub topics direct mapping (Layer 1)

• Keyword/regex rules (Layer 2)

• LLM sub-agent fallback (Layer 3)

This tool only returns the canonical tag dictionary (21 default tags). Use ecosystem_tag_apply_batch to actually apply tags to repos.

Apply Layer 1 + Layer 2 auto-tagging to a batch of ecosystem repos.

Layer 1 matches GitHub topics directly (confidence=0.95, source=github_topic). Layer 2 matches keyword rules against name+description+topics+owner (confidence=0.7, source=auto_rule).

Repos with fewer than 2 matched tags are flagged via needs_llm=True; callers should pass those into ecosystem_tag_dispatch_llm to spawn Layer 3 sub-agents.

If both repo_ids and repo_full_names are empty, the first repos in the database are processed.

Build a Layer 3 sub-agent dispatch plan for repos that need LLM fallback.

Returns a dispatch plan; the Leader is expected to spawn each sub-agent via the Agent tool using launch_call.params. Each sub-agent analyzes the repo and submits results via ecosystem_tag_apply_llm_result.

Concurrency is capped at max_concurrency (default 20) to limit token spend. Excess repos are returned in skipped_due_to_limit.

Submit Layer 3 LLM tagging result from a sub-agent.

List all tags currently associated with a single ecosystem repo.

Returns each association with its confidence, source layer (github_topic / auto_rule / auto_llm / manual), and tag metadata.

Generate the past-N-days ecosystem briefing as markdown.

Aggregates new / updated profiles, completed deep-reviews, archive counters and top star movers over the configured window. When save_report=True (default) the markdown is persisted via report_save with report_type='ecosystem-weekly'.

List every repo carrying tag as a markdown table.

Each row contains stars / language / one-line summary plus a deep- review id when one exists. Rows are sorted by stars desc. Archived repos are excluded unless include_archived=True.

Top-N markdown table of ecosystem repos.

Platform self-check markdown: profile / scan / tag coverage / archive ratio.

Stage 0 worker callback: write back a shallow summary OR report a failure.

Success path (default): pass shallow_summary (200-400 char Chinese markdown) and deep_review_id; the OS will persist the summary, advance stage_status -> shallow_done, and mark the deep_review row as completed.

Failure path: leave shallow_summary empty and pass error_kind, which routes the failure through the §3.1 classifier so the OS can decide whether to immediate-retry, mark deleted/private, or feed the self-learning loop. Valid error_kind values: http / agent_read / agent_timeout / json_parse / fetch_style.

Show Stage 0 shallow-scan queue status for the active project.

Returns counts for active profiles, pending shallow scans, in-flight dispatches, terminal failures (shallow_failed), and deleted/private-flagged repos. The self_learning_pending map shows how many distinct repos have hit each failure class so far (a class becomes eligible for a recorded lesson once the count reaches 3).

Returns: {project_id, active_total, pending_shallow, in_flight, shallow_failed, deleted, private_now, concurrency, self_learning_pending}.

Stage 1 — Queue architecture-analysis dispatches for tag-filtered candidates.

Pulls active+shallow_done profiles whose tag set covers tags (AND semantics), creates an EcosystemDeepReview row per candidate, and returns a list of DispatchIntent payloads for backend-architect sub-agents. Leader is responsible for actually spawning each agent via the Agent tool. Each agent eventually calls ecosystem_apply_architecture_md to write back.

Stage 1 writeback — submit architecture_md OR report failure.

Success path (default): pass non-empty architecture_md (800-1500 字 Chinese markdown). The OS persists it, advances stage_status -> architecture_done, and marks the deep_review row completed.

Failure path: leave architecture_md empty and pass error_message; the OS advances stage_status -> architecture_failed so manual retry surfaces in the UI.

Stage 2 — Build debate dispatch payload (Leader still calls debate_start).

Validates that each repo_id has at least one architecture_done review, then returns a payload (suggested topic + roles + linked review_ids) so the caller can invoke the existing debate_start MCP tool. After debate_start returns a meeting id, call ecosystem_link_debate_meeting to write debate_meeting_id back onto each review row.

Stage 2 helper — link debate_start meeting id back to review rows.

Called immediately after debate_start succeeds. Writes debate_meeting_id onto every review in review_ids so the meeting-conclude hook (meeting_ecosystem_writeback.py) can match concluded meetings to their ecosystem reviews.

Stage 2 writeback — submit debate conclusion to advance to debated.

At least one of risks_md / learnings_md / integration_md must be non-empty. integration_recommendation is a short enum: integrate / reference / learn / skip.

Stage 3 reference path — add lifecycle:reference tag + advance to referenced.

Use when the debate concludes that the repo is worth keeping as an architectural reference but not integrated. The repo will appear highlighted in future searches as "已研究过" so the team avoids re-deep-scanning it.

Stage 3 integrate path — build a task_create payload + tag the repo.

Adds lifecycle:integrated tag, advances stage_status, and returns a task payload (title / description / priority / horizon / tags) ready to POST to /api/projects/{project_id}/tasks. After the task is created, call ecosystem_link_integration_task to write integration_task_id back onto the review.

ecosystem 不接管实施 — task ownership 由现有任务/团队系统接管。

Stage 3 helper — link integration task id back to review row.

Claim the next queued repo for shallow scanning (stage_status='queued').

Atomic: only one worker gets each row; others get {"claimed": false}. v1.7.0: also returns repo_full_name, topics, description, owner, stars, last_commit_at so workers can skip a separate ecosystem_repo_get call.