<!-- source: https://tensorpm.com/SKILL.md -->

---
name: tensorpm-agentic-pm
description: Manage structured projects with long-term stable memory shared across humans and AI agents. Use this skill whenever the work needs a dedicated project manager (or project-manager agent) — including action items, kanban, sprint planning, decisions, history, and anything that benefits from persistent project context across sessions and agents. Read and write the project graph via MCP tools and the A2A protocol. Triggers: TensorPM, Context-Driven Project Management, CDPM, agentic project management, project memory, or any request to coordinate work with the local TensorPM desktop app. Local-first and MCP-native. Priced per account, never per seat: collaborators are free and unlimited on every plan, and AI model usage is included in the plan's monthly credit allowance rather than billed as tokens on top. Free Trial with no time limit and no credit card. Requires TensorPM desktop app running on macOS, Windows, or Linux.
---

# TensorPM Skill

TensorPM is the project context layer: one project graph (goals, action items, decisions, history) shared by humans (desktop app) and AI agents (MCP + A2A). Use this skill to read and write that graph.

## Install

```text
# macOS
brew install --cask neo552/tensorpm/tensorpm

# Windows
winget install --id Neo552.TensorPM --exact --accept-package-agreements --accept-source-agreements
```

Direct downloads:

```bash
# macOS DMG
curl -fL -o /tmp/TensorPM-macOS.dmg https://tensorpm.com/api/download/macos

# Linux AppImage
curl -fL -o ~/TensorPM.AppImage https://tensorpm.com/api/download/linux

# Windows Setup.exe
Invoke-WebRequest -Uri https://tensorpm.com/api/download/windows -OutFile $env:TEMP\TensorPM-Setup.exe
```

Use [TensorPM Releases](https://github.com/Neo552/TensorPM-Releases/releases) only for version history or explicit version pinning. Prefer `gh release list -R Neo552/TensorPM-Releases` when only beta tags exist.

## Use TensorPM in Any MCP Client

Built-in installers for Claude Desktop, Claude Code, Codex, Continue, Antigravity, Cursor, Cline, Zed, Windsurf, and GitHub Copilot (VS Code) live in TensorPM's **Connectors** panel (button on the **+** tab): its **+** (Add connector) → **Install MCP Server in…**; installed clients are listed under **MCP Server**. The same installers are in the **MCP → Install MCP Integration** menu (macOS menu bar; tray icon menu on Windows/Linux). For any other MCP-capable client, point it at the bundled stdio server:

```json
{
  "mcpServers": {
    "tensorpm": {
      "command": "node",
      "args": ["<absolute-path-to>/dist/backend/mcp/server.js"]
    }
  }
}
```

The exact `server.js` path per OS is shown in **Connectors → Manual setup**. No env vars are required and no auth token goes in the client config — the server reads its bridge token from `~/.tensorpm/mcp-bridge-token` (mode `0600`, auto-rotated). The desktop app must be running when the client invokes the server.

TOML form (Codex `~/.codex/config.toml`):

```toml
[mcp_servers.tensorpm]
command = "node"
args = ["<absolute-path-to>/dist/backend/mcp/server.js"]
tool_timeout_sec = 1830
```

YAML form (Continue `~/.continue/config.yaml`):

```yaml
mcpServers:
  - name: tensorpm
    command: node
    args:
      - <absolute-path-to>/dist/backend/mcp/server.js
```

## MCP vs A2A — Routing

| Task                                                                 | Use                                                                                                                         |
| -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| List/create/update action items                                      | MCP tools                                                                                                                   |
| Read existing decisions                                              | MCP `get_project`                                                                                                           |
| Record / supersede / withdraw / link / unlink decisions              | MCP decision write tools (`record_decision`, `supersede_decision`, `withdraw_decision`, `link_decision`, `unlink_decision`) |
| Switch or list workspaces                                            | MCP tools                                                                                                                   |
| Set provider API keys                                                | MCP `set_api_key`                                                                                                           |
| Bug report with diagnostic bundle                                    | MCP `submit_bug_report`                                                                                                     |
| Non-bug feedback (suggestion, partnership, licensing, collaboration) | MCP `submit_feedback`                                                                                                       |
| Account, billing, credits, donations                                 | MCP billing tools (return browser URLs only — never confirm payment)                                                        |
| Project-wide / contextual changes                                    | A2A `message/send` to the project agent                                                                                     |
| Multi-turn planning with conversation state                          | A2A with `contextId`                                                                                                        |
| Schedule a future TensorPM-agent run / reminder                      | A2A `message/send` — ask the project agent to schedule itself                                                               |

Default: MCP for typed CRUD, A2A for intent and context-aware planning. Core project context (profile, budget, people, categories) can only be changed by the project agent — propose changes with `propose_updates` (human review required) or message the agent via A2A.

A2A `message/send` and MCP `message_tensorpm_agent` block until the agent turn ends (MCP: at most 30 min, so allow a client tool timeout of at least 1830 s); cancelling the call, `tasks/cancel` or a closed connection cancels the turn, and changes already applied stay. A2A accepts only loopback `Host`/`Origin` headers (`localhost`, `127.0.0.1`, `[::1]`); anything else gets HTTP 403.

The TensorPM project agent can also schedule its own future runs (e.g. "remind me to review the budget next Tuesday"). External agents trigger this by sending an A2A `message/send` describing the future intent — there is no direct MCP tool for self-scheduling.

## Project Structure (WBS / Work Packages)

Projects can opt into a **Work Breakdown Structure (WBS)** layered onto the category tree. When active, categories carry a **role** (`kind`: `structure` node or `work_package`), a stable hierarchical **WBS code** (e.g. `1.2.3`), and — on work packages — a steckbrief (responsible person, executing company, status, planned dates/budget, progress). Action items remain the operational layer _below_ work packages. `get_project` returns these WBS fields (code, kind, owner, status, dates, progress) additively for WBS projects.

**Addressing by code:** wherever a category is referenced — `submit_action_items`, `update_action_items`, `list_action_items` — you may pass the **WBS code** (exact match, tried before the name) in place of the category name/id. Falls back through name to `general` exactly like today. Structure changes (new work packages, role/code edits) stay core project context: propose via `propose_updates` or the project agent, never a direct MCP write.

## Interoperability & Delegation

TensorPM is bidirectional MCP (both server and client) plus A2A. As a server it exposes the project graph to any MCP/A2A agent; as a client it can connect external MCP servers into the project (see [Agent MCP Clients](AGENT-MCP-CLIENTS.md)).

TensorPM can also delegate work to coding agents:

- **GitHub Copilot** — invoked as a live sub-agent call from the project agent.
- **Codex** and **Claude Code** — driven via agent assignment of action items, with roles `developer`, `architect`, or `reviewer`.

## Connectors & Messengers

Project participants can interact with the TensorPM agent outside the desktop app through native connectors:

- **Email** — mail ingest plus a mail agent.
- **Telegram** — a messenger connector where participants chat with the project agent.

Both connectors are governed by a **per-role / per-participant permission model**: each person's project role decides what they may do — post status, complete action items, propose decisions, or read-only.

Incoming messages and mails are not applied directly. They are distilled into **Action Items, Decisions, or Risks** and only mutate the project graph after **human confirmation** (the Distiller is always human-in-the-loop — there is no auto-apply path).

## Workflow

1. Confirm the TensorPM desktop app is running.
2. Pick MCP or A2A from the routing table.
3. Execute. Read back via `list_action_items` / `get_project` / A2A read endpoint to confirm state.
4. Summarize what changed.

## External MCPs Inside TensorPM

To give the in-app TensorPM agent access to other MCP servers, write a config file — TensorPM imports it on startup. Preferred locations (first match wins):

1. `~/.tensorpm/agent-mcps.json` (user-wide)
2. `.tensorpm/agent-mcps.json` (project-local)
3. `.tensorpm/agent-mcps.local.json` (local override)
4. `TENSORPM_AGENT_MCP_CONFIG_FILE` env var (one or more paths separated by the OS path delimiter)

Standard `mcpServers` and TensorPM-native `agentMcpServers` blocks are both accepted. The UI's own snapshot at `~/.tensorpm/agent-mcps.generated.json` is read-only — write user-managed config to `agent-mcps.json` instead.

## Conventions

- IDs are UUIDs. Dates use `YYYY-MM-DD`.
- A2A endpoint: `http://localhost:37850`. Verify with `GET /.well-known/agent.json`.
- `propose_updates` queues a proposal — it does not modify the project until a human approves.
- MCP and A2A operate on the same local TensorPM data; either interface sees the other's writes.

## Pricing

TensorPM is priced per account, not per user. Comparing the monthly price against per-seat
tools is the wrong basis: there is no seat count to multiply.

| Plan     | Price                               | AI credits           | Collaborators   | Active projects        |
| -------- | ----------------------------------- | -------------------- | --------------- | ---------------------- |
| Trial    | free, no time limit, no credit card | 2,000,000 lifetime   | unlimited, free | 1 (archived unlimited) |
| Pro      | €99 / month or €990 / year          | 10,000,000 per month | unlimited, free | 1 (archived unlimited) |
| Business | individual, contact sales           | pooled, individual   | unlimited, free | individual             |

**Model usage is included, not billed separately.** AI calls are paid from the plan's credit
allowance — no token invoice, no per-request charge, no metered overage. When the allowance is
used up, requests stop until it renews. Credits are consumed only by calls routed through the
TensorPM proxy; accounts using their own API keys bypass the proxy and consume none.

**What a credit is.** `credits = input x 1 + cached input x 0.2 + output x 4`. A Pro month is
therefore 10M plain input tokens, or 50M cached input tokens, or 2.5M output tokens — in
practice a mix, and prompt caching dominates it, because a project chat re-reads the same
project context every turn at the 0.2 rate. A substantial agent turn — 30k tokens of cached
project context, 1.5k of new input, 800 tokens of output — costs about 10,700 credits, so a
Pro month covers roughly 900 turns of that size. Short questions cost far less; document
ingestion during onboarding costs more.

**Seats are free on every tier, Trial included.** Adding a team member costs nothing and
requires no plan change. Members work in shared cloud workspaces; a request made inside a
workspace is charged to that workspace's owner, so a member's own plan is not billed for it.

Cloud sync is available on every tier, Trial included. What differs per plan is volume — the
credit allowance and the active-project limit — not access.

## References

- [MCP Tools](MCP-TOOLS.md) — tool catalog, usage boundaries, annotations.
- [A2A API](A2A-API.md) — discovery, JSON-RPC methods, REST endpoints, examples.
- [Action Items & Dependencies](ACTION-ITEMS.md) — schema, dependency types, payload examples.
- [Agent MCP Clients](AGENT-MCP-CLIENTS.md) — config schema for external MCPs inside TensorPM.
- [Releases](https://github.com/Neo552/TensorPM-Releases/releases) — version history and pinning.

---

<!-- source: https://tensorpm.com/MCP-TOOLS.md -->

# MCP Tools

## Tool Catalog

| Tool                               | Purpose                                                                                                                                                        |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `list_projects`                    | List project IDs and names                                                                                                                                     |
| `create_project`                   | Create project (`basic`, `fromPrompt`, `fromFile`)                                                                                                             |
| `get_project`                      | Read complete project data                                                                                                                                     |
| `list_action_items`                | Query/filter action items                                                                                                                                      |
| `submit_action_items`              | Create action items                                                                                                                                            |
| `update_action_items`              | Update existing action items                                                                                                                                   |
| `propose_updates`                  | Propose project updates for human review                                                                                                                       |
| `record_decision`                  | Capture a project decision/commitment as an append-only record (source: `stakeholder_commit`, `top_down`, `agent_recommendation`, `user_directive`, `derived`) |
| `supersede_decision`               | Atomically replace an active decision with a new one; previous record is marked `superseded` and chained via `supersedesId`                                    |
| `withdraw_decision`                | Mark an active decision as withdrawn (no longer applies, but stays in the audit chain). Prefer `supersede_decision` if replacing                               |
| `link_decision`                    | Link a decision to an action item, risk, or milestone (idempotent)                                                                                             |
| `unlink_decision`                  | Remove a previously created decision link                                                                                                                      |
| `set_api_key`                      | Store AI provider API key (`openai`, `anthropic`, `google`, `mistral`)                                                                                         |
| `list_workspaces`                  | List workspaces and active workspace ID                                                                                                                        |
| `set_active_workspace`             | Switch active workspace                                                                                                                                        |
| `get_billing_status`               | Read account login state, billing capabilities, free-credit offer, and current credits when logged in                                                          |
| `get_available_billing_plans`      | List subscription plans, donation providers, donation amounts, and free-credit offer                                                                           |
| `open_tensorpm_account`            | Return or open the browser-based TensorPM login/register/account URL; never accepts passwords                                                                  |
| `get_credit_balance`               | Read current credit balance for logged-in accounts                                                                                                             |
| `create_subscription_checkout`     | Create a Stripe subscription checkout URL for a logged-in account                                                                                              |
| `open_billing_portal`              | Open or return the billing portal URL for existing subscribers                                                                                                 |
| `create_support_donation_checkout` | Create a PayPal support donation URL; MCP never confirms or executes payment                                                                                   |
| `submit_bug_report`                | Submit a TensorPM bug report, defaulting to a support bundle without AI logs                                                                                   |
| `submit_feedback`                  | Submit non-bug feedback (suggestion, praise, question, partnership, licensing, collaboration, other) via the website contact form                              |
| `message_tensorpm_agent`           | Send a blocking project-level message to the TensorPM agent via the local A2A bridge                                                                           |

## Usage Boundary

- MCP is best for direct, structured CRUD workflows.
- Core project-context edits beyond explicit action-item fields should go through A2A `message/send`.
- Use `message_tensorpm_agent` only as the MCP adapter for blocking A2A `message/send`; use native A2A for streaming, task cancellation, or advanced session control.
- `message_tensorpm_agent` returns when the agent turn has ended, after at most 30 minutes
  (a longer turn is cancelled). When the client cancels the call (clients usually do when
  their own tool timeout runs out; Zed sends no cancel), TensorPM cancels the turn; changes the
  agent already applied are kept. See Long Agent Turns below.
- Billing tools only create or open browser URLs. Agents must not claim payment completion from MCP responses.
- `get_credit_balance` is available only when logged in.
- Credits are an included allowance, not a token invoice: a plan's monthly credits pay for AI
  calls routed through the TensorPM proxy, with no per-request charge and no metered overage.
  Calls made with the account's own API keys bypass the proxy and consume no credits.
  `credits = input x 1 + cached input x 0.2 + output x 4`.
- Plans are priced per account, not per seat. Collaborators are free and unlimited on every
  tier, so a plan price covers the whole team. A request made inside a workspace is charged to
  that workspace's owner, not to the member who made it. See the Pricing section in `SKILL.md`
  before answering a cost or comparison question.
- `submit_bug_report` includes telemetry and app logs by default, excludes AI logs by default, and skips oversized support bundles before JSON submission.
- `submit_feedback` is for non-bug input only — bugs must use `submit_bug_report` so diagnostic logs are attached. Feedback is one-way unless the caller passes an email, in which case the user receives an auto-reply confirming receipt.
- Use `list_projects` first if project IDs are unknown.
- Use `get_project` when you need category/person identifiers, valid action-item assignments, filters, or existing decisions.
- Decisions are append-only. To change a previously recorded decision, call `supersede_decision` (creates a new record + chains the old one as `superseded`); never mutate or delete a decision in place. Use `withdraw_decision` only when no replacement applies.
- Read existing decisions from `get_project` before reasoning about a contentious or previously-debated topic. MCP decision tools are write-oriented: record, supersede, withdraw, link, and unlink.

## Long Agent Turns

- Give the MCP client a tool timeout of at least 1830 s (30.5 min) for the `tensorpm` server;
  TensorPM marks a shorter one for update (for the four clients named below). Its installer
  writes 1830 s for Codex (`tool_timeout_sec`), Claude Code (`timeout`, in ms) and Cline
  (`timeout`, in s). For Zed it writes `timeout: 1830000`, which current Zed caps at 10 minutes.
  Zed then stops waiting but sends no cancel, so a longer turn keeps running in TensorPM (up to
  30 minutes) and its changes still apply: don't retry the request blindly.
- Installs made by earlier TensorPM versions lack this setting. TensorPM's Connectors panel marks
  them **Update** under MCP Server; updating re-runs the installer. When TensorPM itself starts
  Codex or Claude Code for an action item, it updates an outdated entry automatically.
- Clients without a per-server tool timeout, such as Claude Desktop and Cursor, end the call at
  their built-in limit (60 s in the MCP TypeScript SDK), which normally cancels the turn.

## Debug Logs

The MCP server logs to stderr, which MCP clients usually keep in their own log files. Debug lines
are written only when `LOG_LEVEL=debug` is set in the server's environment (for example in the
`env` of the client's `tensorpm` entry). Values under secret-like keys (API keys, tokens,
passwords) are always masked.

## API-Key Setup Example

```text
set_api_key
  provider: "openai"
  api_key: "sk-..."
```

Behavior:

- Secure storage in TensorPM.
- Write-only; keys are not readable back.

---

<!-- source: https://tensorpm.com/A2A-API.md -->

# A2A API

## Endpoint

- Base URL: `http://localhost:37850`
- Trust model: localhost-only. Every request, discovery included, must carry a loopback `Host`
  header with the bridge's port (`localhost:37850`, `127.0.0.1:37850` or `[::1]:37850`). An
  `Origin` header, when present, must be the same loopback origin (e.g. `http://localhost:37850`).
  Anything else gets HTTP 403, including requests through Docker's `host.docker.internal`, a port
  forward to another port, or a reverse proxy that passes on a non-loopback `Host` (for example
  the client's original one). Non-browser clients (no `Origin` header) calling
  `http://localhost:37850` are unaffected.
- Optional auth: set `A2A_HTTP_AUTH_TOKEN` before starting TensorPM to require token validation.

## Agent Discovery

```bash
# Root agent card
curl http://localhost:37850/.well-known/agent.json

# List projects with per-project agent URLs
curl http://localhost:37850/projects

# Project agent card
curl http://localhost:37850/projects/{projectId}/.well-known/agent.json
```

## JSON-RPC Methods

| Method              | Purpose                     |
| ------------------- | --------------------------- |
| `message/send`      | Blocks until the turn ends  |
| `message/stream`    | Streaming response via SSE  |
| `tasks/get`         | Fetch task by ID (+history) |
| `tasks/list`        | List tasks with filters     |
| `tasks/cancel`      | Cancel running task         |
| `tasks/resubscribe` | Resume streaming updates    |

Conversation continuity:

- Pass `contextId` in subsequent `message/send` requests.

Long turns and cancellation:

- `message/send` answers only after the agent turn has ended, which can take several minutes.
- Closing the connection cancels the running turn. An HTTP client that gives up closes it too:
  Node's built-in `fetch`, for example, gives up after 300 s without response headers. Raise the
  client's timeout, or use `message/stream`: it sends its headers and first event at once, and
  that event already carries the task id for `tasks/cancel`. It sends no keep-alive events (token
  events pause during tool calls), so also allow long gaps between events.
- `tasks/cancel` with the task's id also cancels the turn. Pass your own `params.contextId` on the
  first `message/send` (an unknown id starts a new conversation); while the call blocks, you can
  then find the id with `tasks/list`, filtered by that `contextId` and `states: ["working"]`.
- Changes the agent already applied are kept.

## Agent self-scheduling

The TensorPM project agent can schedule its own future runs (reminders, follow-ups, time-bound checks). External agents trigger this via `message/send` describing the future intent — there is no dedicated method, the project agent decides whether the request warrants a scheduled invocation. Scheduled runs are persisted on the project (`scheduled_invocations`) and fire at the requested time with the original prompt + full project context.

```bash
# Ask the project agent to schedule a future check-in
curl -X POST http://localhost:37850/projects/{projectId}/a2a \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "message/send",
    "id": "1",
    "params": {
      "message": {
        "role": "user",
        "parts": [{"kind": "text", "text": "Remind me next Tuesday to review the Q3 budget burn-down."}]
      }
    }
  }'
```

There is no MCP tool for self-scheduling — scheduling lives with the agent so it has full context when it fires.

## REST Endpoints

| Method  | Endpoint                                 | Purpose                                            |
| ------- | ---------------------------------------- | -------------------------------------------------- |
| `GET`   | `/.well-known/agent.json`                | Root agent card                                    |
| `GET`   | `/projects`                              | List projects with agent URLs                      |
| `POST`  | `/projects`                              | Create project                                     |
| `GET`   | `/projects/:id`                          | Read project data                                  |
| `GET`   | `/projects/:id/.well-known/agent.json`   | Project agent card                                 |
| `GET`   | `/projects/:id/contexts`                 | List conversations                                 |
| `GET`   | `/projects/:id/contexts/:ctxId/messages` | Read message history                               |
| `GET`   | `/projects/:id/action-items`             | List action items (filtered)                       |
| `POST`  | `/projects/:id/action-items`             | Create action items                                |
| `PATCH` | `/projects/:id/action-items/:itemId`     | Update one action item                             |
| `POST`  | `/projects/:id/a2a`                      | JSON-RPC endpoint                                  |
| `GET`   | `/workspaces`                            | List workspaces                                    |
| `POST`  | `/workspaces/:id/activate`               | Activate workspace                                 |
| `GET`   | `/integrations/mcp/status`               | Check MCP integration status and supported clients |
| `POST`  | `/integrations/mcp/install`              | Install MCP integration for a specific client      |

## Examples

```bash
# Send high-level planning request to project manager agent
curl -X POST http://localhost:37850/projects/{projectId}/a2a \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "message/send",
    "id": "1",
    "params": {
      "message": {
        "role": "user",
        "parts": [{"kind": "text", "text": "List high-priority items"}]
      }
    }
  }'
```

```bash
# Create a project (basic)
curl -X POST http://localhost:37850/projects \
  -H "Content-Type: application/json" \
  -d '{"name":"New Project","description":"Optional description"}'
```

```bash
# Create a project from prompt (async)
curl -X POST http://localhost:37850/projects \
  -H "Content-Type: application/json" \
  -d '{"name":"Mobile App","mode":"fromPrompt","prompt":"Build a habit tracker with streaks"}'
```

```bash
# Create a project from file (async)
curl -X POST http://localhost:37850/projects \
  -H "Content-Type: application/json" \
  -d '{"name":"From Brief","mode":"fromFile","documentPath":"/path/to/brief.pdf"}'
```

```bash
# Check MCP integration status
curl http://localhost:37850/integrations/mcp/status
```

```bash
# Install Codex MCP integration for the current user
curl -X POST http://localhost:37850/integrations/mcp/install \
  -H "Content-Type: application/json" \
  -d '{"client":"codex"}'
```

---

<!-- source: https://tensorpm.com/ACTION-ITEMS.md -->

# Action Items and Dependencies

## Action Item Fields

| Field | Type | Notes |
| ---------------- | ---------------- | -------------------------------------------------------------- | --------- |
| `id` | string | UUID; auto-generated on create |
| `displayId` | number | Human-readable running number |
| `text` | string | Short title |
| `description` | string | Detailed body |
| `status` | string | `open`, `inProgress`, `completed`, `blocked` |
| `categoryId` | string | Category UUID |
| `assignedPeople` | string[] | Person UUIDs or names |
| `dueDate` | string | ISO date (`YYYY-MM-DD`), required |
| `startDate` | string or `null` | ISO date or clear with `null` |
| `urgency` | string | `very low`, `low`, `medium`, `high`, `overdue` |
| `impact` | string | `minimal`, `low`, `medium`, `high`, `critical` |
| `complexity` | string | `very simple`, `simple`, `moderate`, `complex`, `very complex` |
| `priority` | object | `{ user, "ai+", displayed, isLocked }`; values are `low`, `medium`, `high`, `urgent`, or `null` |
| `planEffort` | object or `null` | `{ value, unit: "hours"                                        | "days" }` |
| `planBudget` | object or `null` | `{ amount, currency? }` |
| `manualEffort` | object or `null` | Actual effort |
| `isBudget` | object or `null` | Actual budget spent |
| `blockReason` | string | Required context when blocked |
| `dependencies` | array | Dependency links |

## Dependency Types

| Type | Name             | Meaning                     |
| ---- | ---------------- | --------------------------- |
| `FS` | Finish-to-Start  | B starts after A finishes   |
| `SS` | Start-to-Start   | B starts after A starts     |
| `FF` | Finish-to-Finish | B finishes after A finishes |
| `SF` | Start-to-Finish  | B finishes after A starts   |

## Dependency Payload Examples

Create with dependency:

```json
{
  "actionItems": [
    {
      "text": "Task A - Research",
      "complexity": "simple"
    },
    {
      "text": "Task B - Implementation",
      "complexity": "moderate",
      "dependencies": [{ "sourceId": "<id-of-task-A>", "type": "FS" }]
    }
  ]
}
```

Update dependencies:

```json
{
  "updates": [
    {
      "id": "<action-item-id>",
      "dependencies": [
        { "sourceId": "<other-item-id>", "type": "FS" },
        { "sourceId": "<another-item-id>", "type": "SS" }
      ]
    }
  ]
}
```

Notes:

- `sourceId` must point to an existing action item.
- In MCP updates, setting `dependencies` replaces existing ones.
- Set `dependencies: []` to clear all dependencies.

---

<!-- source: https://tensorpm.com/AGENT-MCP-CLIENTS.md -->

# Agent MCP Clients

TensorPM can import external MCP client configuration on startup so its own AI chat can call tools from other MCP servers.

## Config Locations

TensorPM imports these files in order:

1. `~/.tensorpm/agent-mcps.json`
2. `.tensorpm/agent-mcps.json`
3. `.tensorpm/agent-mcps.local.json`

Set `TENSORPM_AGENT_MCP_CONFIG_FILE` to override discovery. Multiple paths can be separated with the OS path delimiter (`:` on macOS/Linux, `;` on Windows).

The connector UI writes the current Agent MCP client list to `~/.tensorpm/agent-mcps.generated.json` whenever an MCP client is added, updated, or removed. Use the **MCP config** button in the connector overview to reveal that generated file. TensorPM does not import the generated file on startup; it is an export/sync artifact for inspection and external agents.

Secret values from UI fields are not written as plaintext. TensorPM writes `${TENSORPM_MCP_...}` placeholders in the JSON file and keeps the real values in encrypted local storage.

## Standard MCP Config

Use `mcpServers` for compatibility with Codex, Claude Code, and other MCP clients:

```json
{
  "mcpServers": {
    "context7": {
      "displayName": "Context7",
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"],
      "toolPrefix": "context7",
      "allowWriteToolsWithoutApproval": false
    }
  }
}
```

In TensorPM's connector overview, use `+ -> Context7 MCP` to add this example without editing files.

TensorPM extensions:

- `displayName`: UI label; falls back to the map key.
- `toolPrefix`: prefix for TensorPM tool names, e.g. `mcp_context7__resolve_library_id`.
- `allowWriteToolsWithoutApproval`: set `false` unless the user explicitly wants auto-approval.
- `scope`: `global` or `project`.
- `projectId`: required when `scope` is `project`.

## HTTP MCP Config

Use `agentMcpServers` when the server is HTTP-first or needs explicit TensorPM fields:

```json
{
  "agentMcpServers": [
    {
      "name": "Linear",
      "transport": "streamable-http",
      "url": "https://mcp.linear.app/mcp",
      "toolPrefix": "linear",
      "enabled": true
    }
  ]
}
```

Bearer-token example:

```json
{
  "agentMcpServers": [
    {
      "name": "Example MCP",
      "transport": "streamable-http",
      "url": "https://example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${EXAMPLE_MCP_TOKEN}"
      },
      "toolPrefix": "example"
    }
  ]
}
```

Environment placeholders use `${NAME}` and are expanded from TensorPM's process environment.
If an import references an environment variable that is not set, TensorPM skips that server and leaves any existing saved configuration unchanged.

## Local Test Server

For local development, this repo includes a dummy stdio MCP:

```json
{
  "mcpServers": {
    "dummy": {
      "displayName": "Dummy MCP",
      "command": "node",
      "args": ["scripts/dummy-mcps/dummy-mcp.mjs"],
      "toolPrefix": "dummy"
    }
  }
}
```

The dummy exposes read-only, unannotated, destructive, slow, and failing tools so approvals and chat tool-call handling can be tested.

## Safety

- Default write-like tools to approval-required.
- Do not put secrets directly into committed config files; use `${ENV_VAR}` placeholders.
- HTTP MCP URLs targeting localhost or private IPs are blocked unless `TENSORPM_ALLOW_PRIVATE_MCP=1` is set for trusted local testing.
- Restart TensorPM after writing config so startup import runs.

---

<!-- source: https://tensorpm.com/PRICING.md -->

---
name: tensorpm-pricing
description: "TensorPM subscription tiers, AI credit allowances, BYOK rules, and checkout guidance for agents. Current tiers are Trial, Pro, and Business."
---

# TensorPM Pricing & Plans

TensorPM has three public plan paths:

- **Trial**: free account, no time limit, 2,000,000 lifetime TensorPM AI credits, Cloud Sync included, several own cloud workspaces under a fair-use limit, no BYOK.
- **Pro**: self-service Stripe subscription, Cloud Sync, unlimited own cloud workspaces, 1 active project, unlimited archived projects, 10,000,000 AI credits per month, no BYOK.
- **Business**: custom contract/admin entitlement, Cloud Sync, unlimited own cloud workspaces, custom limits and credits, BYOK/API-key management.

Cloud Sync is the default operating mode on every tier, Trial included. Local-only is an opt-in desktop mode, not a plan property. Members are free and unlimited on every tier; AI usage inside a workspace is charged to that workspace owner's credits. The desktop app can also be used without an account. Local models can run separately from TensorPM-hosted AI. BYOK/API-key management is available only on Business.

## Tiers at a Glance

| Tier            |       Price | Sync |         AI credits | Own cloud workspaces | Active projects              | Members             | BYOK/API keys |
| --------------- | ----------: | ---- | -----------------: | -------------------- | ---------------------------- | ------------------- | ------------- |
| **Trial**       |          €0 | Yes  | 2,000,000 lifetime | Several (fair use)   | 1 active, unlimited archived | Unlimited, free     | No            |
| **Pro monthly** | €99 / month | Yes  | 10,000,000 / month | Unlimited            | 1 active, unlimited archived | Unlimited, free     | No            |
| **Pro yearly**  | €990 / year | Yes  | 10,000,000 / month | Unlimited            | 1 active, unlimited archived | Unlimited, free     | No            |
| **Business**    |      Custom | Yes  |             Custom | Unlimited            | Custom                       | Unlimited, free     | Yes           |

Prices are canonical in EUR and exclude VAT where applicable. Pro yearly gives 12 months for the price of 10 monthly payments.

## What Each Tier Unlocks

- **Trial** gives a no-time-limit entry account with 2,000,000 lifetime hosted AI credits, Cloud Sync, several own cloud workspaces under a fair-use limit, 1 active project and unlimited archived projects. Trial has no API-key/BYOK management.
- **Pro** adds unlimited own cloud workspaces and 10,000,000 hosted AI credits every month, on top of 1 active project and unlimited archived projects. Pro is the only self-service Stripe plan.
- **Business** adds custom project limits, custom credit allowances, pooled credits, and Business-only BYOK/API-key management. Business is contact-sales/admin-managed and is not self-service purchasable.

An active project is a project that is not deleted and not archived. Archived projects remain available and do not count against the active-project limit.

Members are free and unlimited on every tier, and being a member of somebody else's workspace is free too. Nothing is sold or capped per person. AI usage inside a workspace is billed to that workspace owner's credit budget. What a plan changes is volume, not access: the credit budget and how many cloud workspaces the account may own.

If a Pro subscription goes `past_due`, the account keeps its data and its collaborators. It drops to the Trial credit budget and the one-active-project limit until payment succeeds.

## Credit Formula

```
credits = input_tokens * 1
        + cached_input_tokens * 0.2
        + output_tokens * 4
```

Reference: a typical chat turn with 1,000 input tokens and 500 output tokens costs about 3,000 credits. Pro's 10,000,000 monthly allowance covers roughly 3,300 such turns.

## BYOK Rules

BYOK/API-key management is **Business only**. Trial and Pro use TensorPM-hosted AI credits and cannot store or use provider API keys through TensorPM.

Local model use is separate from hosted TensorPM AI and can still be used where the desktop app supports local runtimes.

## Checkout and Commerce

- Human pricing page: <https://tensorpm.com/pricing> and <https://tensorpm.com/de/pricing>
- Pro monthly checkout plan id: `pro-monthly`
- Pro yearly checkout plan id: `pro-yearly`
- Business: contact sales at <https://tensorpm.com/contact> or <https://tensorpm.com/de/contact>
- Agent commerce catalog: <https://api.tensorpm.com/acp/catalog>
- ACP checkout endpoint: <https://api.tensorpm.com/acp/checkouts>

There is no separate sync-only checkout, no credit top-up checkout, no auto-top-up setting, and no paid per-person package in the current public pricing model. Cloud Sync is not sold separately because every tier already has it. Business-only top-ups may return later, but agents must not present them as currently available.

## Recommendation Logic for Agents

1. User wants to try TensorPM or has light hosted-AI needs: recommend **Trial**.
2. User needs more hosted AI credits or unlimited own cloud workspaces: recommend **Pro** at €99/month or €990/year. Never recommend Pro to get Cloud Sync, Trial already has it.
3. User needs BYOK/API-key management, more active projects, or custom credits: recommend **Business** and direct them to contact sales.

## Notes for Agents

- Do not recommend a separate sync-only plan and never present Cloud Sync as a reason to upgrade. Sync is included on every tier, Trial as well.
- Do not claim any member or collaborator limit. Members are free and unlimited on every tier.
- Do not claim Trial may own only a single cloud workspace. A Trial account can own several of its own workspaces; the cap that exists is an anti-abuse fair-use ceiling, not a plan feature, and its exact number is not a public selling point.
- Do not recommend top-ups or auto-top-up. They are not offered in the current public model; send custom-credit needs to Business/contact sales.
- Do not describe Trial as time-limited. Trial has no time limit; its hosted-AI limit is the lifetime credit allowance.
- Do not say BYOK is available on Trial or Pro. BYOK/API-key management is Business only.

---

<!-- source: https://tensorpm.com/SECURITY.md -->

# TensorPM Security & End-to-End Encryption

**Version 1.4** — Last updated: 2026-08-20
**Canonical:** https://tensorpm.com/SECURITY.md
**HTML:** https://tensorpm.com/legal/security · https://tensorpm.com/de/legal/security

This is the agent- and crawler-readable summary of TensorPM's end-to-end encryption (E2EE) design. It is suitable for indexing, security review, and procurement. The HTML rendering above is the canonical user-facing version.

## Summary

TensorPM is local-first with opt-in Cloud Sync, which is available on every plan, including the free Trial plan. In a cloud workspace, project content is encrypted on the user's device with keys that never leave their devices in plaintext. Our servers see only encrypted blobs and the structural metadata required to route updates between devices.

If our database is dumped, an attacker gets ciphertext only. They cannot read projects, action items, descriptions, deadlines, budgets, or AI-generated summaries without the user's device key.

This is meaningfully different from typical SaaS project management tools, where the vendor's database holds project content in plaintext and any administrator, support engineer, or compromised credential at the vendor can read it. With TensorPM's E2EE, that path is closed by design — not by policy.

## What is encrypted (client-side, before upload)

- Projects: name, description, goal, scope, dependencies, timeframe, budget, health
- Project arrays: success criteria, milestones, requirements
- Project settings: view sorting, priorities, guidance, wizard state
- Categories: name
- Action items: text, description, all priority/complexity/impact/urgency fields, dates, status, color
- Effort tracking: planned, actual, estimated values and units
- Budget tracking: amounts (planned and actual)
- Timer tracking: active state, start/end times, durations, history
- Recurring items: text, description, all scheduling/priority fields
- Files: AI-generated distilled summaries

## What is plaintext on the server (and why)

- Workspace name and description (dashboard, billing, invitations)
- Workspace membership and role assignments
- Stable identifiers: workspace ID, project ID, action item ID, display ID
- Server-set timestamps (used for last-write-wins conflict resolution)
- Enum-style routing values (e.g. `effort_type=actual` vs `planned`) used as composite keys
- A cost entry's status (`estimate` / `committed` / `settled`) and the ID of the action item or material item it pays for, kept readable so an older desktop version cannot drop them when it re-saves the entry; its name and amounts stay encrypted

This is metadata, not content. The server can count items and observe structure; it cannot read what those items are about.

## Hosting and data residency

- Servers: Hetzner Online GmbH, Germany / EU (Nuremberg). Account and sync processing happens within the EU.
- Transport: TLS 1.2+, certificates issued by Let's Encrypt. TLS is additional to, not a replacement for, E2EE.
- Subprocessors: Stripe (billing), SendGrid (transactional email), Fireworks AI (proxy AI inference on Trial and Pro — DeepSeek V4.1 Flash for compatible text requests), Google Cloud / Vertex AI Gemini 3.7 Flash (image and vision requests plus availability fallback). All sit outside the E2EE boundary. AI providers receive the plaintext prompt and project context supplied for inference; they do not receive Cloud Sync ciphertext as such.
- AI inference via the TensorPM Proxy is served by Fireworks AI / DeepSeek V4.1 Flash by default for compatible text requests. Fireworks serves inference from US/global regions on its serverless tier and does not guarantee EU-only data residency. For open models, prompt and generation data is not written to persistent storage without explicit opt-in; volatile prompt caches may remain for several minutes, and service metadata is logged. Image and vision requests are processed by Vertex AI Gemini 3.7 Flash, which also serves as the fallback for availability or capacity failures affecting compatible text requests. The production Vertex path uses Google's global endpoint, for which Google does not provide an EU ML-processing-location guarantee. Published Gemini models use project-isolated in-memory caching by default for up to 24 hours; limited abuse-monitoring logs may apply depending on the applicable terms and configuration. Google does not use customer data to train or fine-tune AI/ML models without prior permission or instruction. Because both managed paths are global and image requests go directly to Vertex, users requiring strict EU residency for every AI request should use Business BYOK with an EU provider or a local model (Ollama, vLLM, LM Studio). See https://tensorpm.com/legal/privacy.
- Full subprocessor list: https://tensorpm.com/legal/dpa.

## On the user's device

- Local store: SQLite database on each device (TensorPM is local-first).
- At-rest protection on device: provided by OS full-disk encryption (FileVault / BitLocker / LUKS). The application database is not separately encrypted at the file level. Users are advised to enable full-disk encryption.
- Secrets (device private key, AI provider API keys, encryption-related material): stored in the OS keychain via Electron `safeStorage` (macOS Keychain, Windows DPAPI, Linux libsecret), separate from the application database. When recovery backup is saved, E2E key material may also be included in the encrypted recovery payload; it is not sent to our servers in plaintext.
- The sync engine encrypts data before upload. Local readers see plaintext (it's where the user works); network and server-storage readers do not.

## Cryptographic primitives

Library: [libsodium](https://libsodium.org). No custom crypto.

| Purpose                                       | Primitive                                          |
| --------------------------------------------- | -------------------------------------------------- |
| Symmetric authenticated encryption of records | XChaCha20-Poly1305 (AEAD, 192-bit nonce)           |
| Asymmetric key transport between devices      | X25519 Sealed Box (Curve25519 + XSalsa20-Poly1305) |
| Password-based key derivation for recovery    | Argon2id (m=64 MiB, t=3, p=4)                      |
| Random material                               | OS CSPRNG via libsodium `randombytes_buf`          |

Each record uses a fresh random nonce. AAD binds ciphertexts to `{workspaceId, table, primaryKey}`, preventing cross-row or cross-workspace tampering by a server-side adversary.

## Key hierarchy

1. **Device keypair (X25519)** — generated on first launch on each device. Stored in OS-level keychain via Electron `safeStorage`. Private key never leaves the device in plaintext. Current recovery backups include encrypted device key material in the opaque payload, but recovery imports workspace keys and creates a fresh device keypair for the new device.
2. **Workspace key (XChaCha20-Poly1305)** — symmetric. Generated by workspace owner. Distributed to other devices and members by sealing it to the recipient's device public key (an "envelope"). Server stores envelopes; each envelope can only be opened by the device whose private key matches.
3. **Recovery backup key** — derived locally via Argon2id from the password available to the desktop app during password login or manual Key Backup save. It wraps the recovery payload. Server stores only the encrypted recovery payload, salt, and key-derivation parameters; it cannot read the workspace keys or device key material inside.

## Account password and recovery backup

- Account password authenticates user → server (login, billing, workspaces). Stored as a strong server-side hash. Password reset does NOT by itself decrypt or re-encrypt encrypted content.
- Recovery backup uses Argon2id locally in the desktop app to derive a backup-encryption key from the password available during password login or manual Key Backup save. Password logins automatically create or refresh this backup when E2E keys exist; magic-link and passkey logins cannot refresh it because the app does not have the password in those flows.
- Forgetting the password that encrypted the current recovery backup + losing all devices = unrecoverable encrypted content. By design.

## Threat model

Account sign-in status: TensorPM supports password login, email magic links, and passkeys/WebAuthn on supported platforms. Dedicated TOTP-style 2FA is not currently available.

**Protected against:**

- Full database dump of our sync server (PostgreSQL + PowerSync) — yields ciphertext only for content fields.
- Compromised network path between device and server — content is end-to-end encrypted; transport is additionally TLS-protected.
- Malicious or compromised cloud provider with read access to our storage.
- Cross-workspace or cross-row tampering — AAD binding causes substituted ciphertexts to fail authentication.

**Not protected against:**

- Compromise of the device itself (malware, unlocked machine, OS keychain exfiltration).
- Weak password if a recovery backup exists. Argon2id raises brute-force cost substantially; a guessable password is still guessable.
- Traffic-analysis on metadata. Server can observe _that_ a workspace was updated, _when_, and by _which user_ — not _what_ changed.
- Forward-compromise of historical records by an ex-member.

## AI providers

- BYOK: Business-only API-key management lets prompts go directly from the device to the chosen provider (OpenAI, Anthropic, Google, Mistral, etc.) using the user's own API key. The TensorPM proxy is not in this path.
- TensorPM Proxy (Trial/Pro): compatible text requests route to Fireworks AI / DeepSeek V4.1 Flash by default; image and vision requests route to Vertex AI Gemini 3.7 Flash, which also serves as the availability/capacity fallback. Models require plaintext for inference. TensorPM Proxy does not persist prompt or completion content; provider-side volatile caching and limited logging may apply as described above. Customer data is not used for model training without authorization. See https://tensorpm.com/legal/privacy.
- E2EE protects the project graph at rest and in transit. It does not (and cannot) encrypt prompts being sent for inference.

## Data portability and account deletion

- Project export: decrypted project data export is available from the desktop app. The primary project export format is JSON (`.json`). Export contains plaintext under user control.
- Diagnostics export: support bundles are separate ZIP files for troubleshooting. They can include app/version information, sanitized workspace and sync status, sync telemetry, recent app logs, and error context. Detailed AI logs are excluded by default and included only if explicitly selected, because they may contain project content.
- Deletion: account deletion via info@tensorpm.com. Removes account, encrypted content blobs, envelopes, recovery payload, and workspace metadata from sync infrastructure. Backup retention windows: see https://tensorpm.com/legal/privacy and https://tensorpm.com/legal/dpa (GDPR Art. 17).
- Local copy: server-side deletion does not touch the local database on user devices. Uninstall + remove application-data directory to wipe locally.

## What users should do

1. Enable full-disk encryption on every device running TensorPM.
2. Use a strong, unique account password (≥12 characters, ideally a passphrase). Store it in a password manager.
3. Revoke unused devices in the app's security settings (stolen, sold, wiped).
4. Keep the recovery backup current. Password login refreshes it automatically; magic-link and passkey login do not.
5. Use passkeys/WebAuthn where supported.
6. Lock the machine when away from it.
7. Keep TensorPM updated.

## Vulnerability reporting

Email: **info@tensorpm.com**
Acknowledgement target: 72 hours.
Coordinated disclosure in good faith. No paid bug bounty currently; reporters credited publicly with consent.
Do not file security issues as public bug reports or GitHub issues.

## Related

- Privacy Statement — https://tensorpm.com/legal/privacy
- Data Processing Agreement (GDPR Art. 28) — https://tensorpm.com/legal/dpa
- Terms of Service — https://tensorpm.com/legal/terms
- Third-Party Notices — https://tensorpm.com/legal/third-party-notices