The systems behind the shared workspace

01

The substrate: one primitive

Everything on a board is a node: a markdown document with a title, tags, optional value and effort scores, an optional deadline, and edges to other nodes. A note is a node. A task is a node. A decision, a deadline, a brainstorm fragment, a research finding: nodes. There is no separate notes-vs-tasks model to keep in sync, which is precisely why humans and agents can share the structure without an import/export step in between.

Structure comes from two kinds of edges. Hierarchy gives every node a parent, which makes the board a tree you can collapse, expand, and reason about spatially. On top of that, typed relationships cross-link the tree: blocked-by edges that constrain ordering, reference edges that carry “this relates to that”, and AI-derived similarity edges (more in section 04). The tree gives you a map; the cross-links give you the dependency and context web that flat lists structurally cannot express.

Because the primitive is small, the whole surface stays small: fifteen operations cover reading, writing, restructuring, and ranking the graph — for every client, human or machine.

02

Decisions are records, not chat scroll

The most expensive question in agent-assisted development is “what did we decide, and why?” The answer usually lives in a chat thread that ended, in a session that got compacted, or in a teammate's head. In DeveloSaur a decision is a node like everything else: recorded where the work happened, linked to the branch it changed, carrying the reasoning in its body.

That has two consequences. First, decisions are retrievable by meaning: an agent (or you) asks about auth choices from months ago and gets the actual record, not a grep across markdown files. Second, decisions are cross-vendor: the agent that reads the decision does not need to be the agent that wrote it. A choice recorded by Claude Code is context for Cursor tomorrow, or for a DeepSeek script next month. The record outlives the session, the model, and the vendor.

03

Sync: CRDT, not locks

Every project is a Yjs document. Each node's content lives in its own shared type inside that document, and every edit — human drag, agent write, offline change — becomes a CRDT update. Updates are appended to a log; periodically the server folds history into a snapshot and compacts, so loading a board means one snapshot plus a short tail of recent updates rather than replaying months of edits.

CRDTs are the reason the multi-actor claim holds. Two agents and a human editing the same branch do not need locks, turn-taking, or a merge dialog: concurrent updates commute, and every replica converges to the same state. An agent that worked offline (or just slowly) merges cleanly when its updates land. Nobody's write clobbers anybody's.

One honest note on transport: clients exchange updates on a fast polling loop rather than held-open sockets. We chose boring transport on purpose — CRDT semantics make the transport layer almost irrelevant, because correctness never depends on delivery timing. Collaboration feels live; the guarantee underneath is convergence, not milliseconds.

04

The index nobody maintains

In the background, every node's content is embedded into a vector index. Nobody tags for it, nobody rebuilds it, nobody is asked to “organize the knowledge base” — it tracks the graph as the graph changes.

Two features ride on it. Semantic search: agents and humans ask in plain language (“what did we decide about rate limiting?”) and get nodes by meaning, not substring luck. And derived edges: the system proposes similarity links between nodes that belong together but were never manually connected — the related work you forgot you had. For agents this is the difference between “read the whole board into context” and “retrieve the five nodes that matter”, which is what keeps large boards usable from a small context window.

05

Priority is derived, and everyone sees the same list

The TODO list is not a second data structure that drifts from the board — it is derived from the tree. Sibling order in the graph is priority order; the ranked list is a depth-first walk of the actionable nodes. Reorder a branch and the list follows. On top of that sit a small number of explicit controls: a pinned head for “this comes first no matter which branch it lives in”, a DOING layer for work that is actively in progress, and tags whose weights decide what counts as actionable at all.

Two guardrails are graph-native rather than bolted on: a node never sorts above something that blocks it, and overdue deadlines surface regardless of where they sit. The important property is that the ordering is a function of visible state. Your agent pulls the same ranked list you see on the canvas, for the same reasons — so “what should I work on next?” has one answer per board, not one answer per participant.

06

Two heads, one build

The same server ships in two places. A local host runs with the desktop app on 127.0.0.1:41777, so agents on your machine work your real boards without credentials leaving it. A cloud gateway at mcp.develosaur.com serves agents that live elsewhere — hosted connectors, online chat, CI. They are one codebase and one version; the tool surface cannot fork between them.

That surface is fifteen verbs, one per intent: review_tree, read_nodes, find, gather_context for reading; create_nodes, update_nodes, complete_nodes, move_nodes, archive_nodes, delete_nodes for writing; edges and prioritize for structure and ordering; tags, projects, capture for the rest. MCP clients call them as MCP tools. Everything else calls them as REST routes — same operations, same board — with llms.txt as the single document that teaches any agent the whole surface, and an OpenAPI description generated from the routes rather than curated by hand.

This is why “every agent” is a design property instead of a slogan: MCP support is a convenience, not a requirement. A model with no MCP anywhere in its harness — DeepSeek under Ollama, a cron script, a framework agent with an HTTP tool — gets the same fifteen operations over plain HTTP.

07

Trust boundaries

Anonymous and authenticated traffic never share a lane. An agent that connects with no credentials gets a sandbox: a throwaway board in server memory, capped in size, cleared after an hour idle, and structurally unable to reach any real account's projects. It exists so anyone can watch the thing work in thirty seconds; it can be claimed into a real account when it turns out to be worth keeping.

Real boards sit behind OAuth 2.1. The gateway publishes standard discovery metadata, accepts both dynamic client registration and client-ID metadata documents, and requires PKCE. Agents that cannot host a browser callback — which is every CLI and coding agent — use the device flow: the agent displays a short code, you approve it in your browser, and it continues in the same conversation. No config files, no pasted tokens, no restarts.

The tokens agents hold are opaque. They are not database credentials in disguise: on every request the gateway resolves the token to the user it belongs to, and every read and write is checked by row-level security as that user. A vendor's server holding your connector token holds exactly one capability — talking to this API as you, revocably — and every connected agent is listed in Settings, individually revocable.