Projects

A project is how toryo knows a repository or folder of yours. Everything else in toryo works against a project by its stable id instead of carrying raw paths around: dispatch jobs, schedules, sequence runs, and every piece of knowledge.

Registering a repository is the first thing you do after installing:

toryo project add --name web --root /path/to/your/repo

A project can be your own or your team's. To work on one with your team, see Team projects.

The hierarchy#

A project can have a parent, which models customer → repository. A customer is a project with no parent; its repositories sit beneath it.

This matters for knowledge. A memory or document can be pinned to the customer or to a specific repository, and a search pinned to the parent surfaces everything from its children too. Customer-wide knowledge belongs on the parent project, because global is your own knowledge across all your projects, not one customer's.

A parent still has a directory of its own, typically the umbrella folder holding its repositories. Having no repository of its own, a parent stays yours and cannot be shared. Nor can any project with child projects.

Per-project settings#

• Code indexable, whether the code index walks this tree. Off for customer parents (their children already cover the source) and for repos with no source in them.
• Docs glob, which files the Refresh docs button pulls into the library. The default is markdown under docs/; override it for a repository that keeps non-prose there.
• Install command, shown by toryo project install-command <project>. When never set, it detects from the directory's marker files; registration detects it too. Add -- <argv…> to store a command, --none to record "no install here", or --detect to run detection again. code-task uses this command to install its worktree.
• Verification, shown by toryo project verification <project>. Set the full test command with -- <argv…>, disable it with --none, or re-detect it with --detect. --full-suite never|before-review|every-verify|ci chooses when it runs: never locally, before formal review (the default), at every verification, or on CI only. Under ci, --full-suite-check <name> must name the CI job or check name, not the workflow. --no-full-suite-check clears the name, which withholds readiness under ci. --timeout-ms <n> sets the full test command's bound: default 10 minutes, ceiling 60 minutes, refused above that rather than clamped. --default-timeout restores the default. See Local acceptance for how code-task uses it.
• Sensitive paths, set with toryo project sensitive-paths <project> -- <pattern…> and reset with --clear. These are repo-relative globs with only * and ** wildcards, at most 100. A base reconciliation touching one goes back for a full review. code-task already covers manifests, lockfiles, migrations, CI/deploy and auth with generic defaults; add your project's own contract files here.

The run reads install, verification and sensitive-path settings when it is created. Later settings changes reach only later runs. If a lookup fails, the run is still created and carries a warning.

Deliberately minimal#

A project row holds its identity, directory and parent, the indexing and docs settings, and the install, verification and sensitive-path settings code-task reads.

There are no sub-project paths: a consumer that needs a subdirectory appends a relative path at the point of use, the same way every toryo command takes explicit paths. Modelling subdirectories here would duplicate what is already on disk and go stale.

Richer per-project detail lives in the app that owns it, keyed by the project id.

Removing a project#

If a project's folder only moved, do not remove it. Point it at the new folder with toryo project update <project> --root <new folder>, which keeps everything it knows.

Removing one of your own projects hides it from every read at once, keeping it only as a record of the removal, and cleans up its knowledge straight away. Lasting memories and documents about it move to your global knowledge, and the rest (other memories and documents, the code index) is cleaned up, with a nightly sweep on the scheduler's system lane as a safety net for anything the immediate cleanup missed.

Before anything is removed, toryo project remove lists what will go, with a count for each kind of knowledge, and asks you to confirm. Board's Delete… shows the same list before its confirm button. In a script, where there is no one to ask, pass --yes; --dry-run prints the list and removes nothing. The cleanup runs in the background, and its result, including anything it could not clean, arrives as a notification.

To remove a project but keep its knowledge, pass --no-cleanup. Nothing ever cleans that project's knowledge afterwards, not the nightly sweep either.

A team project is removed differently. See When a shared project is removed.

In board#

The Projects screen registers and edits projects, sets the parent, toggles code indexing, and holds the Refresh docs button.

The edit pane's Verification section has Full suite, CI check name, Test command, Install command, Test timeout, and Sensitive paths. The test and install commands each offer Detect, None, and Custom. The pane writes through the same project commands you use in a terminal.

A team project with no checkout on this machine shows Not bound here. See Join a project a teammate shared.

Full command surface: CLI & contract reference.