> ## Documentation Index
> Fetch the complete documentation index at: https://docs.genesiscomputing.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Project Manager Tools

> Create and coordinate missions and todos, manage dependencies, record progress, organize project assets, and start existing blueprints as tracked missions.

## **Overview**

### **Tool Name**

```json theme={null}
project_manager_tools
```

### **Purpose**

The **project\_manager\_tools** suite organizes work into missions and todos. It supports creation, assignment, dependencies, bulk operations, work recording, asset management, and starting existing blueprints as tracked Missions so projects move from plan to done with clear ownership and traceability.

### **Key Features & Functions**

<Steps>
  <Step title="Plan Missions" icon="project-diagram">
    Create and update missions with descriptions, status, and timelines, or retire a
    mission that should not resume.
  </Step>

  <Step title="Track Todos" icon="tasks">
    Create, assign, and update todos with rich details and statuses.
  </Step>

  <Step title="Manage Dependencies" icon="link">
    Add or remove todo relationships to enforce execution order.
  </Step>

  <Step title="Record Progress" icon="clock">
    Log work done with outcomes for audit-ready history.
  </Step>

  <Step title="Handle Assets" icon="folder-open">
    Attach and manage mission assets like files, links, and git paths.
  </Step>

  <Step title="Scale With Bulk Ops" icon="layer-group">
    Create or delete many todos at once with optional dependency wiring.
  </Step>

  <Step title="See Data Agent Involvement" icon="robot">
    List data agents assigned to missions and todos for load visibility.
  </Step>
</Steps>

<Tip>
  Use a short, action-oriented mission name and a precise todo title. It keeps lists scannable and status meetings fast.
</Tip>

<Note>
  Project-aware calls continue using a thread's saved active mission when the
  chat thread is reopened or no longer has a live in-memory thread object. If
  Genesis has already confirmed that the thread has no active mission, it
  persists that empty state too so later calls do not re-resolve a project
  unnecessarily.
</Note>

## **Input Parameters for Each Function**

### **`manage_todos`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **action** | Operation to perform. One of `CREATE`, `UPDATE`, `GET_TODO_DETAILS`, `CHANGE_STATUS`, `LIST`. | String |
| **for\_bot\_id** | Act on behalf of another data agent. | String |
| **todo\_details** | Structured details payload for create or update. | Object |
| **project\_id** | Mission id that owns the todo. Required for `CREATE`. | String |
| **todo\_name** | Todo title. Required for `CREATE`. | String |
| **what\_to\_do** | Detailed description of the work. Required for `CREATE`. | String |
| **depends\_on** | One or many todo ids that must complete first. | String or List |
| **assigned\_to\_bot\_id** | Data Agent id to assign the todo to. | String |
| **new\_status** | Target status for `CHANGE_STATUS`. One of `NEW`, `IN_PROGRESS`, `PAUSED`, `COMPLETED`, `CANCELLED`. | String |
| **todo\_id** | Target todo id for `UPDATE` and `CHANGE_STATUS`. | String |

### **`manage_projects`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **action** | Operation to perform. One of `CREATE`, `UPDATE`, `CHANGE_STATUS`, `LIST`. | String |
| **for\_bot\_id** | Act on behalf of another data agent. | String |
| **project\_details** | Structured details payload for create or update. | Object |
| **project\_name** | Mission name. Required for `CREATE`. | String |
| **description** | Mission description. Required for `CREATE`. | String |
| **new\_status** | New status for `CHANGE_STATUS`. One of `NOT_STARTED`, `IN_PROGRESS_ACTIVE`, `IN_PROGRESS_WITH_FAILURE`, `IN_PROGRESS_NEEDING_INPUT`, `PAUSED`, `STUCK`, `FAILED`, `COMPLETED`, `CANCELLED`, or `RETIRED`. | String |
| **reason** | Why the mission is being retired. Required when `new_status` is `RETIRED`. | String |
| **project\_id** | Mission id for `CREATE` response mapping and for `UPDATE`. | String |

Set `new_status` to `RETIRED` when work stopped early and the mission must remain
terminal. Include a non-empty `reason`; retired missions cannot return to an active
state or continue Blueprint execution.

<Note>
  Project and todo ids are generated by the platform. Store them in your automation so later updates and dependency wiring are reliable.
</Note>

### **`start_blueprint_mission`**

Start an existing blueprint as a tracked Mission from the current thread. This
is the supported execution path when the user asks Genesis to run, execute,
kick off, or create work from a blueprint. Genesis creates or reuses the
Mission/project, links it to the conversation, and enters the requested phase
automatically before the kickoff turn begins.

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **blueprint\_name** | Existing blueprint name to run. Required. | String |
| **mission\_name** | Optional Mission/project name. When omitted, Genesis derives a name from the blueprint. | String |
| **description** | Optional Mission description or kickoff context. Benign formatting tags such as `<b>` are accepted; dangerous HTML remains rejected. When omitted, Genesis stores `Mission created from blueprint '<blueprint_name>'.` | String |
| **phase** | Entry phase to start. Defaults to `"0"`. | String |
| **mode** | Blueprint execution mode. When omitted, the blueprint's `default_mode` applies, which is `goal` for most shipped blueprints and for new ones; a running Mission keeps its recorded mode. For a new Mission of a blueprint without a valid `default_mode`, an omitted mode returns `mode is required`, so pass one explicitly. `goal` advances phases automatically and pursues each phase's exit criteria under goal-mode limits, `manual` lets the user drive phase transitions, and `continuous` is a legacy value still accepted for callers that name it. | String |
| **goal\_statement** | Optional goal description in the person's words. Used only in `goal` mode; when omitted or blank, the goal names the blueprint. | String |
| **source\_context** | Optional blueprint source selection. Use `default` for the production/default source or `wip` for the caller's active working copy. | String |
| **llm\_provider** | Optional default LLM provider for the Mission thread. | String |
| **llm\_tier** | Optional default LLM tier for the Mission thread. One of `frontier`, `main`, or `fast`. | String |
| **demo\_scope** | Required canonical presenter scope when the blueprint carries the `demo:disposable` tag. Use 1–32 lowercase letters and digits with single hyphens between words; spaces, uppercase, and underscores are rejected. In the web UI, start disposable demos from [Presenter Controls](/docs/Blueprint/Blueprint-Library-And-Missions#presenter-controls) so Genesis derives and locks the scope — do not type a scope manually in the **Start Mission** modal. | String |
| **preserve\_active\_phase\_on\_reuse** | Optional. When `true`, reusing an existing Mission preserves its verified active phase; if no verified phase exists, Genesis enters the requested `phase`. Defaults to `false`. | Boolean (default `false`) |

<Note>
  `bot_id`, `thread_id`, and `user_id` are supplied implicitly by Genesis at
  runtime. `start_blueprint_mission` requires a current thread so the Mission
  can be linked to the active conversation.
</Note>

<Note>
  If `_blueprint_tool(action="GET_BLUEPRINT_INFO", ...)` reports
  `requires_source_selection=true`, choose `source_context` explicitly before
  calling `start_blueprint_mission`. Use `_blueprint_tool` for blueprint
  discovery, registry management, or lower-level recovery, not for manually
  executing steps copied from blueprint metadata.
</Note>

**Example**

```python theme={null}
start_blueprint_mission(
    blueprint_name="data_vault_build",
    mission_name="Data Vault Buildout",
    description="Build the first customer-ready warehouse skeleton.",
    phase="0",
    mode="manual",
    source_context="default",
    llm_tier="main",
)
```

To state the outcome explicitly in goal mode, pass `goal_statement`:

```python theme={null}
start_blueprint_mission(
    blueprint_name="data_vault_build",
    mode="goal",
    goal_statement="Deliver a validated first customer-ready warehouse skeleton",
)
```

In goal mode, the kickoff tells the agent to advance sequential phases with
`PROCEED_TO_NEXT_PHASE` without asking for confirmation, stopping for a
blueprint-directed gate or when operator input is needed. See [Goal mode
transitions](/docs/Blueprint/Blueprint-Branching#goal-mode-transitions) for
phase criteria and transition behavior.

Successful responses include `project_id`, `repo_id`, `phase`, `requested_mode`,
`reused_existing_project`, and both `project_result` and `phase_result` for
follow-up inspection. When phase entry succeeds, `mode` reports the mode actually
applied; it can differ from `requested_mode` if goal mode could not be applied. If
an existing phase is preserved with `preserve_active_phase_on_reuse=true`, `mode`
reports that phase's current mode. A response where phase entry did not start omits
`mode`, because no new mode was applied. When a phase is preserved, the response
also includes `active_phase_preserved: true`, the canonical `active_phase`, and
the originally requested `requested_phase`; `phase` reports the preserved phase
number.

When a phase starts without preserving an existing active phase, Genesis also
writes a `MISSION_STARTED` INFO log anchor. The system-test blueprints use it
for error attribution; see [Blueprint system-test guidance](/docs/Blueprint/Blueprint-Library-And-Missions).

**Policy-blocked mission start**

When workspace **High-Risk Tool Controls** block tools the blueprint requires,
Genesis returns `success: false` before creating a mission. The response
includes a human-readable `error` plus structured fields:

| Field | Type | Description |
| - | - | - |
| `code` | string | `blueprint_tool_policy_blocked` |
| `policy_blocked` | boolean | Always `true` for this failure. |
| `blocked_policy` | string | `high_risk_tools_disabled` when the workspace toggle blocks the high-risk tool family. |
| `blocked_tools` | object\[] | Each item includes `name`, `display_name`, and `description` for a blocked tool such as `execute_python_code`. |
| `blueprint_name` | string | Blueprint that was requested. |
| `bot_id` | string or null | Agent id used for the preflight check. |
| `source_context` | string or null | Source selection passed to the tool, when set. |
| `admin_location` | string | UI hint for where an admin enables high-risk tools (`Config > Users > High-Risk Tools`). |
| `admin_path` | string | Config path hint (`/config/users`). |
| `manual_execution_guardrail` | string | Instructs the agent not to run blueprint phases manually while required tools stay blocked. |

Enable the high-risk tool family under
[Workspace Policies](/docs/Setup/Workspace-Policies#tool-permissions), then
retry `start_blueprint_mission`.

If Genesis cannot load the blueprint manifest for preflight (for example an
unresolved `source_context="wip"` source), the tool also returns `success: false`
with `manual_execution_guardrail` and does not create a mission.

**MCP / agent-to-agent continuous kickoff**

For an external agent that should drive the blueprint between configured gates,
use `mode="continuous"`. Continuous mode does not bypass a phase whose manifest
sets `require_human_approval: true`: Genesis pauses the mission and sends the
approval request to the originating Google Chat conversation when that transport
is available. `continuous` is a legacy mode kept for existing integrations; a
new integration can omit `mode` to run in the blueprint's default, normally
`goal`. Standard chat and UI starts use that default too, and pass
`mode="manual"` when the operator will drive phase transitions.
From the Genesis MCP v2 `genesis` tool you can start the Mission in the same
pattern as other initial tool calls, for example:

```python theme={null}
genesis(
    action="thread_create",
    agent_id="Adam",
    initial_action="tool_call",
    initial_tool_name="start_blueprint_mission",
    initial_arguments_json='{"blueprint_name":"data_vault_build","mode":"continuous"}',
    submit_mode="async",
)
```

<Note>
  Partner or host applications that supervise missions from their own UI should
  use the REST **BlueprintRun** API (`POST /api/blueprints/{name}/runs`,
  `POST /api/runs/{run_id}/input/{input_id}`) rather than
  `start_blueprint_mission`. See
  [Programmatic BlueprintRun](/docs/Blueprint/Programmatic-BlueprintRun).
</Note>

### **`record_todo_work`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **todo\_id** | Todo id to record work against. | String |
| **work\_description** | Narrative of what was done. | String |
| **work\_results** | Outputs, findings, or links to artifacts. | String |
| **for\_bot\_id** | Act on behalf of another data agent. | String |

### **`get_todo_history`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **todo\_id** | Todo id whose history to return. | String |

### **`get_project_todos`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **project\_id** | Mission id to list todos for. | String |
| **for\_bot\_id** | Act on behalf of another data agent. | String |

### **`get_todo_dependencies`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **todo\_id** | Todo id whose dependencies to retrieve. | String |
| **for\_bot\_id** | Act on behalf of another data agent. | String |
| **include\_reverse** | Include todos that depend on this todo when `true`. | Boolean |

### **`manage_todo_dependencies`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **action** | One of `ADD` or `REMOVE`. | String |
| **todo\_id** | The dependent todo id. | String |
| **depends\_on\_todo\_id** | The prerequisite todo id that must complete first. | String |
| **for\_bot\_id** | Act on behalf of another data agent. | String |

### **`delete_todos_bulk`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **todo\_ids** | Array of todo ids to delete. | List of String |
| **for\_bot\_id** | Act on behalf of another data agent. | String |

### **`create_todos_bulk`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **project\_id** | Mission id for all created todos. | String |
| **todos** | Array of todo objects. Each supports `todo_name`, `what_to_do`, optional `depends_on`, `assigned_to_bot_id`, `todo_type`, `fields`. | List of Objects |
| **for\_bot\_id** | Act on behalf of another data agent. | String |

### **`manage_project_assets`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **action** | One of `CREATE`, `UPDATE`, `DELETE`, `LIST`, `GET_DETAILS`. | String |
| **project\_id** | Mission id that owns the asset. | String |
| **asset\_id** | Asset id for `UPDATE`, `DELETE`, `GET_DETAILS`. | String |
| **asset\_details** | Structured details payload. | Object |
| **description** | Asset description for `CREATE` and `UPDATE`. | String |
| **asset\_type** | Type such as `GIT`, `FILE`, `LINK`, `G-SHEET`. | String |
| **git\_path** | Git path when asset type is `GIT`. | String |
| **data** | Arbitrary JSON metadata. | String |

### **Checked project records**

The record-writing and detail tools create and maintain typed project records with
declared goals, versioned assets, attributed notes, and server-checked evidence. They
are separate from the mission and todo tools above and belong to their own tool group,
`project_record_tools`: a thread with only `project_manager_tools` active does not have
those tools. A mission phase starts with them only when its blueprint lists
`project_record_tools` for that phase; otherwise the agent can add the group itself with
`manage_context`, if its tool policy allows the group and the provider's function limit
has room, and must add it again after the next phase starts. `project_list` is also
available through `context_tools`, which new chats hold. This slice currently supports
`palantir_databricks`, which is opened by planning the Foundry space with
`foundry_plan_migration` and not by `project_open`, with three interim goals pending their final definitions:
`landed` uses `foundry_copy_receipt`, `rebuilt_and_ran` uses `databricks_run`, and
`proved` uses `prover_grade`. A `landed` check accepts only a Foundry copy the server
filed under this project and goal.

#### **`project_list`**

Lists the signed-in person's live checked migration projects, newest first, with each
goal's status and the next tool call for continuing the project. Call this first when
someone asks about a migration they already started, including from a new chat; it
does not list Missions, TODOs, retired projects, or another person's projects. Use the
returned project only when it matches the work they named. Answer status questions
from the listed goals, and follow `next` only when they want to continue. If no listed
project matches, search threads, runs, or proofs rather than saying the work does not
exist. Use `project_read` for a project's notes and evidence.

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **user\_id** | Signed-in person's id, supplied implicitly from the conversation context. | String or null (optional, default `null`) |

The response contains `projects`, `truncated`, and `unreadable`. Each project includes
its `id`, `name`, `project_type`, `source`, `created_at`, `plan_incomplete`, goals
(including status and planned done-of-total counts), and `next`. When multiple
projects share a source, `same_source_as` explains how to choose which one to
continue. Do not call a project complete while `plan_incomplete` is true. An empty
`projects` list means the person has no checked migration project under way only
when `truncated` is false and `unreadable` is empty. Report unreadable ids as projects
that exist but could not be read. On `success: false`, report the error briefly.

Cost: one database `SELECT` when the person has no live project; otherwise three
`SELECT`s for their 20 newest live projects, their goals, and notes. It does not call
a source system.

#### **`project_open`**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **name** | Name for this project instance. | String (required) |
| **project\_type** | A declared type that is opened by hand. `palantir_databricks` is refused here: plan the Foundry space with `foundry_plan_migration`, which opens that project with its scope. | String (required) |
| **parameters** | Object containing `source`, `targets`, and `rendering`. | Object (required) |

A Palantir-to-Databricks migration project is not opened with this tool. Planning the
Foundry space with `foundry_plan_migration` opens it for the signed-in person, or
resumes the one they have, and returns its `id` in the plan's `project` block; calling
`project_open` with `palantir_databricks` returns `success: false` and names that tool.
No project type declared today is opened by hand.

For a type that is opened by hand it returns the new project `id` and `project_type`;
use that `id` with `project_note` and `project_read`. Unknown project types, missing parameters, or
undeclared parameter names return `success: false`.

#### **`project_note`**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **id** | Project id. For a Foundry migration it is `project.id` in `foundry_plan_migration`'s answer; for a type opened by hand, the `id` `project_open` returned. | String (required) |
| **goal** | Goal declared by the project type. | String (required) |
| **evidence** | Typed evidence citation; see supported evidence below. | Object (optional, default `null`) |
| **asset** | Asset registration with `id` and `version` for this goal. A newer version supersedes the previous one. | Object (optional, default `null`) |
| **finding** | Finding to preserve as an attributed note; requires `evidence`. | String (optional, default `null`) |
| **waive\_reason** | Non-empty reason a person decided to waive the goal. | String (optional, default `null`) |

The evidence kinds in this slice are:

| **`evidence.kind`** | **Required citation fields** | **Server check** |
| - | - | - |
| `prover_grade` | `grade_run_id`, `diff_hash` | Re-reads a succeeded `spec_conformance` grade and its comparison with the noting person's Prover access. The grade must name that `diff_hash`, have a `spec_hash`, have verdict `verified`, `not_verified`, or `verified_with_indeterminate`, and not be reopened. It passes on its own only when the review page reads the grade as **Verified**. Otherwise, a verified person's review-page acceptance can meet the goal when it covers every item that kept this same grade's comparison off **Verified**. For a partially specified grade, that includes every open clause; an unreadable seal cannot pass on acceptance. |
| `databricks_run` | `databricks_run_id` | Not a hand note. A notebook published under the project with `foundry_publish_notebook` is registered on `rebuilt_and_ran` by Genesis, and each `run_notebook` of that notebook on the same connection is filed under the project and recorded there by itself once the run ends. A run counts only when it succeeded, every task ran the published notebook, and it started after that publish; it certifies that the notebook ran, not what it wrote. A failed run is recorded with "Last run failed" and its reason, and the goal reads unmet until a later run succeeds. Publishing the notebook again makes the goal stale for that pipeline until a run of the new notebook is recorded. A citation of a filed run behaves like a citation of a filed copy. A run Genesis did not file under this project, including one cited by its job id, stays unverified. |
| `foundry_copy_receipt` | `copy_receipt_id` | Not a hand note. Genesis records every copy filed under the project on `landed` by itself once the copy has ended, checking that the table holds that copy with Foundry's row count. The note says when the copy was checked; that verdict is the table as it was then, and a recorded copy is not checked again. A citation of a filed copy's receipt, alone on `landed` with no `asset` or `finding`, writes no note: for a copy not yet recorded it asks that the copy be recorded with its next check's verdict, normally within a minute, and for a recorded copy it answers with the verdict and `checked_at`. Either way it returns `recorded_by_server`, `state`, `reason` and `message`. On another goal, or with an `asset` or `finding`, it is refused. Registering a dataset that has a filed copy as an `asset`, in any note including a waiver, is refused. A receipt Genesis did not file under this project stays unverified. |

Genesis looks for finished, unrecorded copies once a minute and records each one as a
note by the server that says when it was checked. A copy still running is not checked
until it reports how it ended. A check that cannot answer yet (for example, a stopped
SQL warehouse) is tried again later.
An older copy whose table now holds a newer copy filed under the same project reads
as replaced and does not count. A table that no longer exists, or that holds a copy
which failed, is recorded as failed. See [Databricks connection setup](/docs/Integrations/Data%20Sources/Databricks/Databricks)
for connection and warehouse access requirements.

For `palantir_databricks`, register each asset other than a filed copy or a published
notebook against the goal it belongs to in an earlier note before citing it. The goals have
no fixed input assets, so evidence can only match an asset registered to that same goal at
its current version: `prover_grade` matches the asset version to `diff_hash`. A project
opened by planning expects `rebuilt_and_ran` to cover every pipeline the plan can
translate; a pipeline it cannot translate is listed as a gap. If more than one asset on the goal has that version,
include `asset_id` in `evidence` to identify the intended asset. For Databricks
connection setup and access, see
[Connect to Databricks](/docs/Integrations/Data%20Sources/Databricks/Databricks) and
[Connections](/docs/Setup/Connections).

Only the project owner or an administrator can add notes. Evidence that cannot be
checked, does not identify a current asset version, or is not confirmed is recorded
as unverified and does not meet the goal. A confirmed passing check can meet the
goal; a confirmed failing check records a failed goal. A goal with multiple registered
assets is met only when every asset has passed at its current version; any failed
check makes it failed, and a new version or newly registered asset makes a met goal
stale. This only accounts for registered assets, not assets that should have been
registered but were omitted. A waiver must be a separate note made in the
authenticated person's own chat turn; agent, Slack, and Teams turns cannot waive a
goal. The result includes the current `status`, `verification`, and note `id`. The
first note for a goal added to the project type after a project was opened also
reconciles that goal into the stored project.

A `prover_grade` accepted this way is recorded as passed on a person's acceptance, not
on the grade alone; the note names the accepting person or people and the accepted
items. Acceptance must belong to the cited grade's run and population, so an acceptance
for an earlier grade does not count. If the review outcome cannot be read, the citation
stays unverified and can be retried. When the grade itself does not read **Verified**,
checking for acceptance also reads the comparison's review history and, when a verified
approval stands, resolves its review population and findings, including an uncapped scan
of stimulus records. Approver display names use cached user lookups.

A citation of a Foundry copy the server filed runs no warehouse statement and writes no
note. It costs one read of the project, one SELECT of the copy's row, and, when it asks
for the copy to be recorded, one UPDATE. The warehouse check runs in Genesis's
recording job: at most four statements on the customer's SQL warehouse
(`DESCRIBE DETAIL`, `SHOW TBLPROPERTIES`, `COUNT(*)` and `DESCRIBE DETAIL` again), each
with a 120-second limit and a session open bounded to about two minutes. A stopped
warehouse may start and bill its minimum.

After registering `current-comparison` at version `diff_...` in an earlier note, add
this evidence note:

```json theme={null}
{
  "id": "proj_...",
  "goal": "proved",
  "evidence": {
    "kind": "prover_grade",
    "grade_run_id": "run_...",
    "diff_hash": "diff_..."
  }
}
```

#### **`project_read`**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **id** | Project id. For a Foundry migration it is `project.id` in `foundry_plan_migration`'s answer; for a type opened by hand, the `id` `project_open` returned. | String (required) |

Returns the project with its goals, notes, and assets. Current status is computed
from the latest asset versions and goal preconditions; only the project owner or an
administrator can read the record. The response includes `created_at`, and goals
are returned in the project type's declaration order.

### **`get_project_bots`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **project\_id** | Mission id to summarize data agent use. | String |

### **`get_todo_bots`**

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **todo\_id** | Todo id to list associated data agents for. | String |

### **`_blueprint_tool`**

The same tool group also exposes **`_blueprint_tool`** for blueprint
discovery, lower-level phase operations, import/export, and registry
management. Use `GET_BLUEPRINT_INDEX` and `GET_BLUEPRINT_INFO` to inspect
available blueprints and source options. When the user wants to run a
blueprint from chat, call `start_blueprint_mission` instead of manually
executing steps from `GET_BLUEPRINT` or `GET_BLUEPRINT_INFO`. The actions
below cover rename, upload-to-install, and local-to-managed promotion
workflows.

<Note>
  These management actions follow Genesis blueprint-management permissions. In
  standard deployments, Eve is the agent that runs them.
</Note>

#### **`action="RENAME_BLUEPRINT"`**

Rename an existing custom or remote-backed blueprint using the same backend
flow as the Blueprint Library UI.

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **blueprint\_name** | Current blueprint name. Required. | String |
| **new\_name** | New blueprint name. Required. Use only lowercase letters, numbers, underscores, or hyphens. Maximum length `100`. | String |
| **blueprint\_id** | Optional stable blueprint identity for duplicate-name resolution when the same name exists in more than one source. | String |
| **bot\_id** | Acting agent override. Implicit from the current tool context when omitted. | String |
| **thread\_id** | Thread context override. Implicit from the current tool context when omitted. | String |

<Note>
  Local renames complete immediately. Remote-backed renames return pull-request
  metadata and become effective after the pull request is merged and the next
  source sync applies the rename. Genesis rejects the action when the target
  name already exists, the blueprint is default, or referenced missions are
  still in flight.
</Note>

**Example**

```python theme={null}
_blueprint_tool(
    action="RENAME_BLUEPRINT",
    blueprint_name="customer_onboarding",
    new_name="customer_lifecycle",
)
```

#### **`action="INSTALL_BLUEPRINT_FROM_UPLOAD"`**

Create a blueprint from a ZIP in the `uploads` repo using the same validation
flow as the Blueprint Library UI. This action is **create-only**: when the
target name already exists locally or in the managed write target, Genesis
returns `success: false` with `error_code: BLUEPRINT_IMPORT_NAME_COLLISION` (or
`BLUEPRINT_IMPORT_COLLISION_CHECK_FAILED` when collision detection itself
fails) and does not overwrite or append a version. Use the Blueprint Library
import UI or `POST /api/blueprints/import` when the operator needs **Add as a
new version** or **Replace** behavior.

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **upload\_path** | Path under the `uploads` repo. Required. Use a relative path such as `thread_123/customer_onboarding.zip`. | String |
| **target\_repo\_id** | Optional destination repo ID. Omit it or set it to `blueprints` for the default local install. Set it to a managed git repo ID such as `genesis_blueprints` to install into that repo's WIP worktree, commit there, and register the managed artifact. | String |
| **target\_name** | Optional installed blueprint name override. When omitted, Genesis uses the blueprint name from the manifest. | String |
| **auto\_register** | Automatically register the blueprint after install. Default: `true`. For local installs, this must remain `true`. | Boolean |
| **bot\_id** | Acting agent override. Implicit from the current tool context when omitted. | String |
| **thread\_id** | Thread context override. Implicit from the current tool context when omitted. | String |

<Note>
  Use `target_repo_id` for this action, not `blueprint_source_repo_id`.
  `upload_path` must stay relative to `uploads/` and cannot contain `.` or
  `..` path segments.
</Note>

**Example**

```python theme={null}
_blueprint_tool(
    action="INSTALL_BLUEPRINT_FROM_UPLOAD",
    upload_path="thread_123/customer_onboarding.zip",
    target_repo_id="genesis_blueprints",
    target_name="customer_onboarding",
)
```

#### **`action="PROMOTE_BLUEPRINT_TO_MANAGED_REPO"`**

Move a blueprint that is already installed locally into a managed git-backed
repo without asking the user to re-upload the ZIP.

**Parameters**

| **Name** | **Definition** | **Format** |
| - | - | :-: |
| **blueprint\_name** | Local blueprint to promote. Required. | String |
| **target\_repo\_id** | Managed destination repo ID. Required. | String |
| **replace\_existing** | Overwrite a same-named blueprint already registered in the target managed repo. Default: `false`. | Boolean |
| **bot\_id** | Acting agent override. Implicit from the current tool context when omitted. | String |
| **thread\_id** | Thread context override. Implicit from the current tool context when omitted. | String |

<Note>
  Use `target_repo_id` here too. `blueprint_source_repo_id` is for the legacy
  `IMPORT_BLUEPRINT` flow and is rejected for promotion.
</Note>

<Note>
  Promotion is only for blueprints currently installed in the local
  `blueprints` repo. If the blueprint is already in the target managed repo,
  Genesis returns a success no-op. If it is already managed in a different
  repo, Genesis returns an error instead of performing a cross-managed-repo
  migration.
</Note>

**Example**

```python theme={null}
_blueprint_tool(
    action="PROMOTE_BLUEPRINT_TO_MANAGED_REPO",
    blueprint_name="customer_onboarding",
    target_repo_id="genesis_blueprints",
    replace_existing=True,
)
```

## **Use Cases**

1. Managing complex data engineering projects with multiple interdependent tasks
2. Coordinating team workflows with automated task assignment and progress tracking
3. Building project documentation and asset libraries with organized file management
4. Tracking mission progress with detailed work logs and completion metrics
5. Managing dependencies between tasks to ensure proper execution sequencing
6. Creating comprehensive project dashboards with data agent assignment and progress visibility
7. Coordinating cross-functional projects with multiple stakeholders and deliverables

## **Workflow/How It Works**

1. **Create a mission** with name and purpose.
2. **Break down work** into todos and assign to data agents or people.
3. **Wire dependencies** so prerequisites complete first.
4. **Record work** as progress is made, attaching outputs and links.
5. **Manage assets** at the mission level for easy retrieval.
6. **Scale** with bulk create or delete when scope shifts.

<Warning>
  Avoid circular dependencies. If A depends on B and B depends on A, scheduling will stall. Use `get_todo_dependencies` to verify the graph before large changes.
</Warning>

## **Integration Relevance**

* **file\_manager\_tools** for storing specs, outputs, and evidence.
* **make\_baby\_bot** to assign specialized agents to todos.
* **data\_connector\_tools** to link data work directly to tasks.
* **git\_action** for versioned assets and code paths.
* **handoff** to orchestrate multi-agent workflows.
* **slack\_tools** to notify owners on status changes.

## **Configuration Details**

* Status values must match the allowed set for reliable dashboards.
* Use `for_bot_id` when automations act on behalf of a controller agent.
* Store returned ids from create calls for subsequent updates and dependency wiring.
* Choose asset types that reflect storage location and retrieval method.

## **Limitations or Notes**

1. Deletions are permanent. Export state before bulk removals.
2. Very large dependency graphs can be hard to visualize. Document key chains in the mission description.
3. Bulk operations may take time on large projects. Plan during low-traffic windows.
4. Data Agent assignment depends on availability and permissions.
5. Asset references require valid external integrations where applicable.

## **Output**

* **Task Operations**
  Creation confirmations, detail payloads, and status updates.
* **Mission Operations**
  Creation confirmations, status changes, and listings.
* **Work Recording**
  Timestamped entries with descriptions and results.
* **History**
  Full audit trails of changes and actors.
* **Dependencies**
  Add or remove confirmations and resolved trees.
* **Bulk Ops**
  Summaries with success and failure counts.
* **Assets**
  Created or updated records, listings, and detail views.
* **Data Agents** \
  Assignment summaries and participation metrics.
* **Errors**
  Clear messages for invalid ids, status mismatches, or permission failures.