Projects and workspaces¶

A project groups related issues. The work still happens on issues; the project is the container that ties them together.

A project's most useful feature is its workspace — a folder on disk where agents write files (reports, code, artifacts) and where you can upload reference material.

Creating a project¶

Sidebar → Work → Projects → + New Project. Fields:

Field	Notes
Name	Free text. Shown everywhere.
Description	Optional. Markdown.
Status	Backlog, Planned (the default), or In Progress. (Archived is reached later via Archive, not this dropdown.)
Shortname	Optional, short (e.g. `PROJ`). Used as a short tag on the project.
Color	A colour swatch shown next to the project name. Handy when you have many.
Working Directory	Optional. The on-disk path the workspace resolves to. Created automatically if it doesn't exist. Leave blank to use a Trimus-managed folder.

Click Create Project.

The workspace, explained¶

Every project has a workspace directory — the target of the agent /write-file action and of the project's Workspace Files panel. It resolves one of two ways:

If you set a Working Directory — that exact path is used. Typically a real checkout, e.g. /repos/acme-marketing-site. Operator-managed.
Otherwise — Trimus auto-creates a fallback under the company's home directory and uses that.

Either way, when an agent writes to the project (via /write-file docs/foo.md), the file lands at the resolved path, and any missing subdirectories are created for it.

When to set a Working Directory¶

You want agents to work inside a real repo. Point it at the checkout. The agent's /write-file lands an uncommitted change; you stage and commit through your normal git tooling.
Several agents share one output target. Every issue attached to the project resolves to the same path, so parallel agents build up a single output tree.
You want the files to live somewhere you control rather than inside Trimus's managed home.

When to leave it blank¶

You just want a place for agents to drop reports.
You don't have a repo yet.
You don't need operator-level control over the path.

Filling the workspace¶

Three ways files land in a project's workspace:

Agent /write-file — the agent writes a file as part of its reply. The most common path for "write me a report" issues.
Manual upload — the Workspace Files panel on the project page has an upload form. You can name an optional path (docs/sub/file.md) to place the file under a subdirectory.
Directly on disk — when the Working Directory is a real path you have shell access to.

The Workspace Files panel¶

On the project's detail page. It lists every file in the workspace (it skips noise like .git), and shows the resolved path at the top so you know exactly where files are going. For each file you get Download and Delete. The upload form sits above the list; leave its path blank to upload to the workspace root.

How agents use the workspace¶

When an agent's issue is attached to a project, it can write a file like this in its reply:

/write-file docs/reports/sec-filings-guide.md
```markdown
# SEC Filings Guide for Quants
...
```

Trimus validates the path (no traversal, no absolute paths, up to 4 MiB), creates any missing parent folders, writes the file, and records a "file written" entry on the issue's Timeline (it also appears under the issue's Files written by agents section).

If the issue is not attached to a project, the write still happens — it falls back to the company files directory (<company-home>/files/) or, failing that, the instance files directory ($TRIMUS_HOME/files/), and as a last resort the content is preserved as an issue comment. Attach the issue to a project — you can do this inline from the issue's Properties panel — if you want the file in the project workspace. See the /write-file action for the full cascade.

Goals¶

Projects can be linked to goals for higher-level tracking (a goal can be a task, milestone, objective, or vision). Manage goals from the Goals page in the sidebar and link them to projects there; goal progress then shows up on the company Dashboard.

Project knowledge¶

The project detail page can turn the project's files into searchable context for the agents working its issues. Three related controls:

Project Knowledge toggle (knowledge_indexed) — index the project's files into a project-scoped semantic-retrieval (RAG) store. Once on, relevant snippets are auto-injected into the prompt of any agent working one of the project's issues, so they answer from the actual files instead of guessing.
Expert Agent — a dormant, per-project agent you chat with for project Q&A ("what does this project cover?", "where's the spec for X?"). Creating one also opts the project into indexing, since it answers from the same store.
Linked Knowledge — a card shown once the project is indexed. Attach a curated subset of the company Knowledge Base so the project's agents also see those documents, without pulling in the whole company KB.

Archiving¶

Set the project's status to archived, or click Archive Project on its detail page. Archived projects drop out of the default Projects filter and are skipped by routines and wake-ups, but their issues and workspace files are kept — nothing is deleted. Bring one back by setting its status to active again.

Deleting¶

Projects have no hard-delete button by default. If you truly need to remove one, archive it first, then have an instance admin delete it permanently from Trash.