Versions-and-roadmap.md
Versions, imports and what is next
Changing a file creates a new immutable version. Restoring an older version creates another version with those bytes; history is preserved. Renaming a file, changing its description or updating metadata does not create a new content version.
API updates include the version you read. If another edit arrived first, Stuff returns a conflict so your agent can reconcile both changes. Descriptions and metadata have their own revision counters.
Bringing things in
Upload files or a folder inside a space. Recoverable upload batches remember what completed and retry unfinished transfers. They are intended for practical folder imports, not a desktop filesystem-sync replacement.
The 1P wiki importer is an example of a normal API client. It creates spaces and folders, preserves source IDs and tags in metadata, rewrites known Markdown links, and detects changes made in Stuff before updating an imported file. It plans by default; applying is explicit. It never needs the Stuff database or object-store credentials.
Imports are repeatable copies, not an automatic two-way sync. Source deletions do not automatically delete Stuff files. An unresolved conflict stops the run and keeps completed work. Private and public imports use separate reviewed manifests, and publication comes after byte verification.
Still to come
The default home is spaces. Following a space, grouped updates from followed spaces, recommended public spaces, and ranked feeds are later work. A hundred-file import should not become a hundred feed cards; the useful unit of an update still needs design.
Ownership transfer, archiving a whole space, private subfolders within a shared space, full Office editing, more native design formats, and large-scale background synchronization are also future work. These are directions, not release-date promises.
Open with JavaScript for the full viewer.