Projects & saving over time

A personal handover is a standalone snapshot: private to your account, complete on its own, addressed by an exact code like #001. That's perfect for "save this state now, load it later or somewhere else." A project adds the thing a single snapshot can't do · it's where your work accumulates over time, and where a team can work the same ground together.

Why saving over time into a project matters

A personal snapshot captures one thread. A project captures the work.

Each soil save @project adds a thread to the project, and they don't replace each other · they stack. soil load @project then brings the project back: the project knowledge in full · the decisions, constraints, and architecture the work has settled on, merged across every thread · plus every thread listed and attributed, with the newest restored inline. Any older thread is one command away (soil load @project #NNN); it is listed, not lost, and not summarized either. The more you save into a project, the more complete the project knowledge becomes. How the load is bounded spells out exactly what arrives inline.

That's the payoff worth being explicit about: a project becomes a compounding, restorable brain of everything you've done. Decisions don't get lost when a thread ends or a model is swapped out. A fresh AI · or a teammate who's never seen any of the chats · picks up the project's accumulated knowledge and the current frontier, not just the last conversation. You're not re-explaining the project ever again; you're loading it.

This accumulation is the paid capability. Personal, standalone saves and loads stay free; a project is where saving over time turns into a durable, shared body of work.

Working in a project

The whole flow, end to end:

1. Create a project in the console dashboard (owning one is a Pro feature).
2. Invite your team (optional) · by shareable link or by email. Membership is the boundary: only members can see or touch the project.
3. soil save @project #thread-name · this thread joins the project under that name. Omit the # part (soil save @project) and the save auto-names it. Do this again, and again · the project accumulates.
4. soil list @project · every thread in the project: code, name, contributor, readiness.
5. soil load @project #003 or soil load @project #thread-name · one thread, by its code or by its name.
6. soil load @project · the project in one restore: the project knowledge, every thread listed and attributed, the newest restored inline.

Load one thread (step 5) when you only want that slice; load the project (step 6) when you want the accumulated state and the current frontier in one restore.

The full command set

Names are kept, never overwritten

Every named save is preserved. Saving #auth-flow when that name already exists doesn't replace the earlier one · Soil keeps both and stores the new save as #auth-flow-001 (then -002, …), each a distinct, uniquely loadable handover. There is no "re-save over the same name," and nothing you saved before is ever touched. To capture a fresh checkpoint, just save again · the project simply gains another thread.

There is no separate rename step. The surest way to name a thread is in the command (soil save @acme-app #auth-flow); to steer the automatic name on an unnamed save, just say what to call it ("save this into @acme-app as auth flow").

What #NNN addresses

Every handover you save · personal or a thread you add to a project · gets a numeric load code from one counter on your account, so within your account every #NNN maps to exactly one handover. soil load #001 always loads your own handover #001. A project thread is reachable with the @project scope: soil load @project #003 loads that thread by code, soil load @project #auth-flow by name (case-insensitive; if two threads share a name, Soil asks for the code rather than guessing). A bare soil load #003 is always one of your personal loads · it never silently reaches into a project. To bring back a teammate's work, load the project (soil load @project) and read the thread inline or by its code, or address the thread by name.

Worked examples:

soil save @acme-app             · add this thread, auto-named
soil save @acme-app #auth-flow  · add this thread under that name
soil list @acme-app             · see its threads: #009 auth-flow (Maria, Strong) …
soil load @acme-app             · restore the project: knowledge, every thread listed, newest inline
soil load @acme-app #010        · restore one thread, by code
soil load @acme-app #auth-flow  · the same thread, by name

Personal saves and loads are unchanged and stay free. The @project namespace is purely additive: without an @, nothing about your personal flow changes.

Membership is the isolation boundary

Personal handovers are isolated per account: you only ever see your own. Shared projects add a second boundary: every operation on a project is checked against your membership of that project. If you are not a member, the project behaves as if it does not exist (you get a not-found, never a hint that it is there). This is the security crux of the feature, and it is enforced on every project read, list, load, and save.

Whole-project restore

soil load @project assembles one restore from the project's threads: every thread clearly delimited and attributed (a masked contributor label and the thread's title, never a raw identity), preceded by a table of contents and a generated project header, with the project knowledge woven in. It is honest about what it is: it presents what each thread actually captured, attributed per thread, rather than inventing a single merged narrative. Each thread restored in full also carries the recorded working-style observations from its most recent save, attributed · so the restore shows how the work has actually been run, not just what it decided.

Loading a project · how many saves merge into one load

A project can accumulate as many threads as you like · three or three hundred · and soil load @project still produces one restore that stays light enough for the model to actually read. It does that with a deliberate three-layer bound, so the load never grows unmanageable no matter how much the project has piled up.

1. Project knowledge first. The model reads the project knowledge before anything else · the merged, de-duplicated truth of the project across every thread: the load-bearing decisions, constraints, identity, architecture, workflow, and rejected approaches, grouped by kind, with who contributed each and its supersession lineage (what replaced what). This is the single source of project truth, so the model starts from the settled picture rather than reconstructing it thread by thread. The project knowledge is itself bounded · it carries the active entries, paginated, and leaves out provisional or unconfirmed ones.

2. The most-recent threads inline. Only the two most recent threads' full restore prompts are inlined · the active frontier, where the work actually is right now. The project knowledge already holds everything that has settled, so the model needs only the live edge in full.

3. Everything else in a table of contents. Every other thread is still listed · nothing is dropped · in the table of contents, each with its code, and any one of them is loadable in full on demand: soil load @project #NNN. The older work isn't gone; it's one code away.

Is it too heavy for the model?

No · and that's the whole point of the bound. Inlining every thread's full restore prompt used to grow with the project: on a mature project it was measured at roughly 64–86 KB (~21,500 tokens) · the heaviest payload at exactly the moment a saturated thread can least afford it. With the bound, the inline part of the load is roughly constant · project knowledge plus the two frontier threads · whether the project holds 3 threads or 300. The rest is always one code away.

How threads are prioritized

The bound is just three priorities applied in order:

Where the accumulation goes

Each soil save @project does two things: it adds a thread to the project, and it patches the project knowledge · the model dispositions each decision by diff (affirm it, supersede it, retire it, or add a new one). So the project's knowledge accumulates in a bounded, de-duplicated ledger that keeps growing in coverage without growing the load · while each soil load @project stays light. A decision that was argued about keeps that history in the ledger: it records that the question was contested and how it settled, so a fresh AI · or a teammate's model that never saw the argument · will not quietly reopen it. That is the continuity model: the project gets richer over time, and the restore stays readable.

Roles and invites

A project has an owner (who created it) and members. The owner can invite others two ways: a shareable invite link (works without email) and an email invite (the recipient gets a link). Accepting an invite while signed in adds your account as a member.

Pro feature

Creating and owning a project is a Pro feature · this is the paid capability, where saving over time accumulates into a shared, restorable body of work. Personal, standalone saves and loads stay free for everyone. You upgrade yourself from the console dashboard Account page · Upgrade to Pro opens Stripe Checkout, and Manage subscription opens the Stripe customer portal for invoices, card changes and cancellation. See billing & subscription.