Clarify multi-project attachment in the README

Add a "Multiple projects" beat to the attach step (§4) explaining that
attachment is per-project-directory, not global — each project's
.smriti.json, SessionStart hook, and skill packs live inside that
project's directory, and a Claude Code or Codex session opened in a
project's directory automatically lands on that project's space. The
MCP server registration is machine-wide but stateless (every call
passes space="..." explicitly), so the server has no "current space"
of its own.

A clarification gap surfaced in user discussion: the README explained
`.smriti.json` but never explicitly walked through the multi-project
mental model.
This commit is contained in:
Himanshu Dongre 2026-05-20 21:08:57 +05:30
parent 3161c1a3c1
commit e73157285c

View file

@ -114,6 +114,8 @@ Use the resolved path from `smriti init` rather than a bare `"smriti-mcp"` — a
Use `smriti attach <space>` to bind (or re-bind) a repo to an existing Space without the full `init`.
**Multiple projects.** Attachment is per-project-directory, not global. Everything `smriti init` writes — `.smriti.json`, the SessionStart hook in `.claude/settings.json`, and the skill packs (`.claude/skills/smriti/SKILL.md` and `AGENTS.md`) — lives *inside the project directory*. Run `smriti init` once per project; the files for `~/code/project-a` and `~/code/project-b` never see each other. A Claude Code or Codex session opened in `~/code/project-a` automatically lands on space `project-a`; the same agent opened in `~/code/project-b` lands on `project-b`. The MCP server registration (the JSON block above) is machine-wide but stateless — every MCP call passes `space="..."` explicitly, so the server has no "current space" of its own.
### 5. Daily workflow — no `<space>` needed
Inside an attached repo, the everyday commands resolve the Space from `.smriti.json`: