Projects

A project is a directory with its own noemata.json — one database, one file store, one set of integrations. Every command that reads or writes project state (up, run, validate, …) resolves its target by walking up from your current directory to the nearest ancestor noemata.json, or by an explicit --project <path>.

Single project

The common case, and what noemata init scaffolds by default: one noemata.json at the root of the directory you’re working in. No registry file is needed — the project is found by walking up from wherever you run a command.

Multiple projects

Run noemata init again inside a tree that already has a project — a monorepo with a project per service, say — and Noemata registers the new one in noemata.projects.json, a small manifest listing every project’s directory:

{
  "projects": [{ "dir": "./services/api" }, { "dir": "./services/web" }]
}

The manifest is anchored at an existing manifest’s directory if there is one, or at the git root otherwise — so one manifest usually covers a whole repo. Paths inside it are relative to the manifest’s own directory.

• noemata ls lists every project in the manifest, plus whichever one contains your current directory, with each one’s configured state and running services.
• noemata rm unlinks a project from the manifest and, when confirmed, deletes the files Noemata owns in its directory.
• A stale entry — a directory the manifest lists that no longer has a noemata.json (moved or deleted) — is flagged by ls rather than silently dropped.

Most commands operate on one project at a time, resolved the same way as the single-project case: the nearest ancestor noemata.json to your current directory, or the sole registered project if you’re not inside any of them. Use --project <path> to target a different one explicitly.

What’s shared, what isn’t

Each project is independent — its own database, its own file store, its own integrations — except for the manifest itself, which is a shared list of directories and nothing more. There’s no cross-project reference between frames in different projects, and no shared config: two projects in the same manifest can point at entirely different databases.