Where do sources and triggers end up when I create them without naming a project?

Tares puts them in the Default project. Default holds whatever was made outside another project, such as an API call or MCP tool that leaves project out, and any part no project uses any more. A part leaves Default when another project takes it in. Default is listed first and cannot be deleted.

How it works

Every Tares instance has a Default project. Sources, triggers, agents, MCP servers and skills belong to the instance, and any number of projects can use the same one. A project holds a goal and its wiring, and Default is the project that catches everything not placed elsewhere.

Two things put a part in Default:

• You create it outside another project. An API call or MCP tool that leaves project out lands there.
• No project uses it any more.

Two things take a part out of Default:

• Another project takes the part in. It then leaves Default.
• A project that takes in a trigger also takes in the sources that trigger reads.

For sources, a new source joins the project it is created in, which is Default when you name none. You can add it to more projects later, so one source can serve several projects without copying anything. Triggers behave the same way: the project that takes one in uses it, and the trigger stops being a Default part.

Default is listed first among your projects and you cannot delete it. Deleting any other project removes the triggers, agents, MCP servers and skills it made, keeps any part another project uses, and lets you pick which of its sources go too.

For the full vocabulary of projects, sources and triggers, see Concepts. For how this fits into incident work, start at AI SRE.

Set it up

1. Create the source or trigger without naming a project. In the API or an MCP tool, leave the project argument out. Sources are added at runtime, so no restart is needed. A source definition like this one, created with no project named, lands in Default:

- name: logs
  connector: docker_logs
  poll: 5s
  config:
    container: tares-demo-api-server   # the container name (docker ps)
    labels:
      - { name: service, const: api-server, primary: true }

2. Open the projects list in the console. Default is listed first. Your new source or trigger is on its page.
3. To move a part out of Default, have another project take it in. Add the source to that project, or add the trigger and the sources it reads come along.
4. Check where everything sits. All resources in the console shows every part on the instance with the projects that use it.
5. Next time, name the project when you create the part if you already know which job it belongs to. It then joins that project directly and never sits in Default.

What you get

• Nothing you create is homeless. A source or trigger made without a project is in Default, where you can find it.
• Parts keep their place as you reorganize. A part moves out of Default when another project takes it in, and it returns to Default when no project uses it any more.
• Shared parts stay shared. Two projects can watch the same logs or use the same trigger without copies.
• A stable starting point. Default is always listed first and cannot be deleted, so the instance always has a project to hold loose parts.
• Clear boundaries for reads. A read covers every source by default. Name a project to read only that project’s sources and the findings recorded in it.
• Portable setup. In the catalog YAML, each trigger names the project that made it and each source lists the projects it is in, so a file imports into another instance.

When something else fits

• If a part belongs to one job from the start, name the project when you create it instead of letting it land in Default.
• If you want to remove a part, delete the part itself. Deleting a part removes it from every project that used it, and Default cannot be deleted.

Related