Workspai.dev

RFC

Public product thinking and architecture notes for the Workspace Intelligence category.

RFCs are where the category gets shaped before implementation details harden.

They should be explicit about what is shipped, what is planned, what is a hypothesis, and which claims are allowed.

Shipped baseline

The current public baseline includes versioned Workspace Intelligence contracts, the contract-ordered canonical chain, its unified runner, an evidence-backed Workspace Knowledge Graph, evidence artifacts, generated command and contract references, and consumer surfaces exposed by the CLI. The linked contracts and command catalog—not this RFC—are authoritative for shipped behavior.

Shipped Workspace Graph baseline

The CLI ships a model-derived, hash-bound Knowledge Graph with stable entity identity, typed relations, portable proofs, bounded search, entity filtering, evidence lookup, shortest proof paths, change overlays, renderers, and a workspace-local token-efficiency benchmark. MCP exposes the same graph through contracted tools. Coverage still depends on observable provider evidence; unsupported source-symbol languages and absent ownership/runtime inputs remain explicitly unknown rather than inferred as fact.

Planned

The topics below are architectural directions under evaluation. A planned topic is not a promise that its complete command, contract, or consumer surface ships today.

RFC topics

Progressive Workspace Graph layers

Expansion from the shipped dependency baseline toward a broader graph of the software system, not only a code graph.

Possible layers:

  • structural graph,
  • dependency graph,
  • ownership graph,
  • runtime graph,
  • change graph,
  • evidence graph,
  • agent graph.

Atlas

Evidence-backed workspace map generated from Workspace Intelligence, not a free-form wiki copied from repository files.

Package separation

Future standalone packages such as doctor, MCP, agents, skills, and graph should reuse the same contracts when invoked from the main CLI or independently.

GitHub App

GitHub App should be a consumer surface:

Proposed pull-request intelligence flowThis is an RFC boundary: a GitHub consumer would project pull-request changes through the canonical intelligence stages.

It should answer: "What does this PR mean for the software system?"

Workspai.com

Future product surface for live repository analysis, Workspace Health, AI Understanding Score, Agent Readiness, dashboards, and cloud workflows.

Hypotheses

  • A repository-level graph can become a reusable package while the workspace layer remains a thin composition boundary.
  • A consumer contract can let agent frameworks share one canonical model without coupling the core to a specific renderer.
  • Evidence-backed pull-request explanations can reduce repeated context reconstruction when their claims remain traceable to contracts and artifacts.

These hypotheses require implementation and evaluation evidence before they can be promoted to shipped capability claims.

RFC discipline

Every RFC should include:

  • current implementation state,
  • proposed contract changes,
  • generated artifacts,
  • consumer surfaces,
  • allowed public claims,
  • forbidden claims until implementation exists.

On this page