RFC

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 model/context/impact/verify loop, 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.

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

Workspace Graph

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:

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.