dotdog update

Dotdog Workspaces: One Graph for N Repos

Dotdog can now describe a product boundary that spans one repo, a monorepo, or many separate repositories.

specdog blog

Most real software products do not live inside one neat folder forever. A product might start as a single repo, then grow into a web app, API, worker, docs site, infrastructure repo, and shared package set. Humans can keep that map in their heads for a while. Agents should not have to guess.

The Dotdog workspace bridge gives that product map a small, explicit home: .doghouse/workspace.json.

What a workspace represents

A workspace is the product boundary. A repo is one implementation boundary inside it. That distinction matters because agents often need to answer product questions that cross repo lines:

Which API does this web flow call?
Which worker handles this event?
Which repo owns the billing surface?
Which graph facts belong to the API versus the customer portal?

Dotdog now has first-class language for that shape. A single repo is still valid. A monorepo is still valid. A product made from N repos is valid too.

The manifest

The workspace manifest is intentionally small and readable:

{
  "version": 1,
  "workspace": { "id": "example-product", "name": "example-product" },
  "repos": [
    { "alias": "example-api", "role": "api", "path": "../example-api" },
    { "alias": "example-web", "role": "web", "path": "../example-web" },
    { "alias": "example-worker", "role": "worker", "path": "../example-worker" }
  ],
  "groups": [],
  "edges": []
}

The aliases are the important part. They let Dotdog report facts with a repo-qualified source instead of flattening everything into one ambiguous project graph.

example-api:src/routes/checkout.ts
example-web:src/features/checkout/index.ts
example-worker:src/jobs/order-created.ts

The CLI shape

The first workflow is direct:

dotdog workspace init --id example-product
dotdog workspace add ../example-api --alias example-api --role api
dotdog workspace add ../example-web --alias example-web --role web
dotdog workspace validate
dotdog workspace graph --json

workspace validate checks the manifest. workspace graph emits deterministic workspace graph JSON that humans, scripts, and agents can consume.

Safer agent context

The MCP server now exposes workspace.list as a read-only structured tool. It reports workspace metadata without treating repository text as instructions. Source code and docs are useful context, not trusted commands.

This keeps Dotdog aligned with the core idea behind the project: give agents a clear graph to query, keep boundaries explicit, and avoid asking a model to reconstruct product architecture from scattered prose.

Start with /dotdog for install commands and workspace examples.

What comes next

The first workspace bridge focuses on explicit manifests, validation, repo registries, workspace graphs, and the MCP read surface. Future work can layer on inferred cross-repo search, trace, and richer workspace tools. The base is now in place: one product boundary, many repos, one graph.

← Back to blog