Tutorial 03: Set up project memory

This tutorial prepares one public test repository and its writable test store. Its single focus is the identity and scope foundation that every later coding-memory tutorial reuses.

Complete Tutorial 00: Connect your coding harness to Loom and Tutorial 02: Connect to multiple stores first.

Start here: make loom_demo the session default

1. Verify the tutorial repository and store

Continue in the public palmerpenguins repository that you checked out and opened as your coding harness's workspace in Tutorial 00. If that repository is not the current workspace, return to Tutorial 00: Connect your coding harness to Loom and complete its first step before continuing.

Repository scope and store selection solve different problems: the repository tells Loom which work the memory belongs to, while the store tells Loom where to read and write it. Verify both before creating facts so later sessions can retrieve them from the same boundary.

Before continuing, have the agent verify that the exact [loom_demo] alias exists and contains Project("loom_demo") plus the starter Roadmap and Decision used below. If the alias or seed is absent, reinstall the current Loom Cloud bundle and stop here. Do not use an unrelated [demo] or [tutorials] store just because its name looks close.

2. Resolve your GitUser identity

Loom attributes every fact to a real author so a shared store stays trustworthy across multiple developers. The author identity comes from git, not from you typing a name.

Loom's substrate is resolve-or-reject: an edge can only point at a node that already exists, so the identity node must be created before any fact carries an Author() edge to it. Bootstrap it with a get-or-create save:

Canonical deduplication does not merge new edges into an existing fact. If a tutorial fact already exists under another author, resaving its canonical returns the existing fact id and leaves its original Author() edge unchanged; report that history rather than claiming it was re-attributed.

If git config user.email is empty, points at a stale CI identity, or is otherwise not the identity you intend to use, fix it before saving anything — a wrong email silently forks a second author node that never matches your real history.

3. Build the repository, project, workspace, and organization scope chain

Facts are filed with InScope() edges to plain entity nodes, and those nodes are connected by PartOf edges into a chain: Repo -> Project -> Workspace -> Organization. Reads at a node automatically union up that chain — a repository-level read also sees project-, workspace-, and org-wide facts — so the chain has to actually exist, or reads from an ancestor come back empty even when the data is right there.

The resulting Entity/Relation shape is:

Repo("palmerpenguins")
  PartOf → Project("palmerpenguins")
    PartOf → Workspace("palmerpenguins")
      PartOf → Organization("loom-tutorials")

Repo, Project, Workspace, and Organization are Entity types: they describe what each node is. PartOf is a Relation type: it connects those different entities without changing their identities.

The loom-scope guidance closes the loop between stored scope and live sessions. Without it, a new agent may infer the repository name but miss the workspace and organization, reducing hook reads to repository-only context and hiding project-scoped facts.

PartOf edges are one-directional and the union-up direction only goes toward ancestors. Reading from Project("palmerpenguins") now also picks up anything scoped at the workspace or organization level — but reading from Organization("loom-tutorials") directly will not show facts scoped narrowly at the project below it. Ancestors see down into nothing; descendants see up the whole chain. Keep that direction straight: file a fact at the narrowest node that applies, and read from wherever you're currently working.

4. Reveal what is already in the store

Before saving any project facts, ask for a bounded inventory of the whole store. This is more revealing than naming a few types in advance: it shows both the data you expected and anything you did not know was there, without letting a large type overwhelm the response.

The result should orient you, not act as a fixed snapshot. Counts grow as the tutorials add facts, while the concrete types and scope labels explain what each item means and where it applies.

Decision (1):
  - small reviewed tutorial changes before live deploys

Directive (2):
  - ask before pushing origin main
  - keep access bundles local

GitUser (1):
  - dev1@gmail.com

Organization (1):
  - loom-tutorials

Project (2):
  - loom_demo
  - palmerpenguins

Repo (1):
  - palmerpenguins

Roadmap (1):
  - publish runnable onboarding demo for new agents [active]

Workspace (1):
  - palmerpenguins

Read this as "the inventory includes at least these" rather than an exact report: the counts and examples change as you work through this and later tutorials, and on a rerun you will also see the facts previous passes saved — extra Directives, a Finding, and PaidService entries from Tutorial 07, among others. That is expected, not pollution; this question is a quick store orientation, not a hard-coded report. On a fresh account it exposes exactly the seeded loom_demo starter facts alongside the identity and scope nodes you just created, in one bounded view. Only populated types appear; Tutorial 04 uses the type catalog to show declared types even when they have no facts yet.

This inventory is deliberately whole-store rather than project-scoped. The returned labels show that the seeded Directive, Decision, and Roadmap items are scoped to Project("loom_demo") — the demo store's own starter project — while the sample GitUser("dev1@gmail.com"), Repo("palmerpenguins"), and its project/workspace/organization ancestors are the identity and scope entities from §2–§3. Your real run substitutes its Git email. When you need only project-scoped coding facts, ask for that scope explicitly; identity and scope nodes do not themselves carry the same filing edge.

5. Takeaways

• Resolve author identity from git config user.email, never from a typed-in name.
• Bootstrap edge targets before saving facts that point to them; rerunning the get-or-create setup is safe.
• File facts at the narrowest applicable scope in the verified Repo -> Project -> Workspace -> Organization chain.
• Start with a bounded whole-store inventory, then narrow reads to the project when needed.
• Continue to Tutorial 04: Understand entities, relations, and types.