Projects

A project is what you set up and look after in Tares: a named set of sources, views, triggers, agents and, where needed, MCP servers, with one page. Every object in a project is an ordinary Tares object on its normal page (Sources, Triggers, Tares agents, MCP servers); the project page is the combined view of them.

A project starts in one of two ways:

• From a Tares template. A template is a ready-made setup: pick one, answer a few questions, click Start, and Tares creates the objects behind it.
• From existing objects. Assemble a project by hand from sources, views, triggers, agents and MCP servers you already have. Nothing is created; the project adopts them.

The Projects entry sits at the top of the console sidebar because it is the quickest way from an empty instance to something running. The primitives stay below it for when you want to wire things by hand.

Tares templates

A template marked demo needs the demo stack rather than your own systems; its setup page shows what to run first, with copy buttons, and detects what is already running.

Starting from a template

Open Projects, pick a template card, click Set up. The setup page asks only for what it cannot work out itself: the AI SRE demo looks at Docker and fills in the Prometheus and api-server URLs from the running containers; the shared code context wizard lists the repositories your GitHub token can see. The last step shows exactly what Start creates, with the names of the objects. Some setup steps check themselves (an Anthropic key that is already set shows as done, and can be pasted right there when it is not).

Assembling from existing objects

Next to the templates, From existing objects builds a project without creating anything: name it, tick the sources, views, triggers, agents and MCP servers that are not part of another project, click Start. The project adopts them (the ownership badge appears on their pages) and its page shows the runs of its agents and the last firing of its triggers.

• Edit changes the list. Removing an object from the project releases it; it is never deleted.
• Delete removes the project and releases its objects, leaving every one of them in place.
• There is no plan behind a hand-assembled project, so Repair and customized do not apply: edit the objects on their own pages, the project shows them as they are.

The project page

Each running project has a page with:

• Cards for the counts that matter (sources or repos, runs, trigger last fired, created).
• How it works: the chain in four lines.
• Actions, when the project has them (the AI SRE demo’s Cause an incident and Clear the fault).
• Runs: every run of the project’s agents, newest first, with status, rounds and the result; each row opens that run on the agent’s page. Runs marked first look ran once when the project started.
• Configuration: the settings you chose, the sources, the object list (each object linked to its own page with its state), and the change history (created, updated, paused, resumed, repaired).

Pause turns the triggers and agents off; sources keep ingesting so the timeline stays complete. Resume turns them back on. Edit reopens the setup with your values; on save the project re-plans and applies only what changed. Delete removes the objects a template created; events already stored stay unless you tick “also purge the events its sources ingested”.

Ownership

Objects in a project carry a part of project badge on their own pages and are fully ordinary there. For a project started from a template:

• Edit one by hand and it is marked customized; the project keeps your version on its next re-plan instead of overwriting it.
• Delete one by hand and the project page lists it as missing, with a Repair button that re-creates it from the plan (Repair also resets a customized object back to the plan).
• An object that already existed with the same name and belonged to no project is adopted, not duplicated (this is how the AI SRE demo picks up a demo catalog you imported earlier).

In the catalog

A project can be declared in catalog YAML, so a seed catalog can ship one and tares up creates it on first boot:

projects:
  - template: ai_sre_demo
    name: AI SRE demo
    params:
      prometheus_url: http://localhost:9090
      api_server_url: http://localhost:8080
      container: tares-demo-api-server
  - template: custom
    name: checkout watch
    objects:
      - { kind: source, name: checkout_logs }
      - { kind: trigger, name: checkout_errors }
      - { kind: agent, name: incident-first-look }

Import creates the project by name or updates an existing one; export includes the section with the parameters (never credential values). The old form (usecases: with recipe:) is still read until two releases after 1.14.

The API

Everything the console does is on the management API:

Objects returned by /api/sources, /api/views, /api/triggers, /api/agents/builtin and /api/mcp-servers carry owned_by (the project id) and customized.

The pre-1.14 routes (/api/usecases*, with their old response shape) keep working until two releases after 1.14.