Skip to main content
The working directory is not a convenience string. It selects relative workflow paths, starts project discovery and roots direct-run state.

​
Two roots can exist

Project discovery walks from cwd toward its ancestors and stops at the first nika.yaml. Direct-run trace storage does not walk upward. It stays under the process room.
ROOT MAP · DISCOVERY WALKS, STORAGE STAYS
The arm and serve paths enter the discovered project root before they fire. Their sidecar and triggered-run traces therefore share the project .nika/ directory. A direct nika run or LocalNika call writes under its own cwd. Set LocalNika.cwd to the project root when one policy boundary and one evidence well are the goal.
That one choice aligns:
  • relative workflow arguments;
  • upward nika.yaml discovery;
  • direct-run .nika/traces/;
  • arm and serve .nika/arm/ plus triggered-run traces.

​
Nested project files are real boundaries

MONOREPO · FIRST PROJECT FILE WINS
A nested nika.yaml is useful when a service needs a separate ceiling or project profile. It is not a path shortcut. Every process below it now sees a different control plane.
Review a nested project file like a package boundary. Adding one changes policy discovery for every CLI and SDK process started below that directory.

​
Probe the production room

Run checks from the exact directory the service manager or container will use:
A clean report from the repository root does not prove a nested service uses the same project file or reads the same trace store.

​
Path contract by operation

​
Continue

Project setup

Build the root-aligned directory layout.

Runtime state

Persist the two evidence lanes deliberately.

SDK configuration

Constructor and call-level precedence.

Resident server

Operate the project-rooted firer.