WS-001: Why the Workspace Hub exists

Status	Accepted
Date	2026-08
Sources	workspace CLAUDE.md §5–§5e; proposal intake practice

Context

Engineering Runtime spans many private repos across product and Control Plane. New ideas arrive as screenshots and notes. Agents and humans need a single intake path before anyone edits a hub.

Problem

Without a gate, features land directly in child repos: no shared batch id, no implementation map, docs drift, and “done” means “code pushed” rather than tested and recorded. Knowledge of how we work lives only in people’s heads.

Decision

Keep a dedicated workspace repo (engineering-runtime-workspace) that is not an implementation hub. It owns:

1. The ER map and bootstrap/update scripts
2. inbox/ → proposals → approve → implement → test → record → verify → archive
3. analyzed/reading/ background notes (not a ticket queue)

Code changes still happen only in product / Control Plane hubs, and only from approved proposals tied to an inbox batch.

Alternatives considered

Alternative	Why not
Proposals inside each hub	No single batch; cross-hub asks fragment
Issues/Projects only	No Implementation map or §5b/§5c evidence standard
Skip intake for “small” fixes	Small fixes are how docs and chrome drift

Consequences

• Agents must not implement from planning-only or empty inbox batch ids
• One active implementable inbox batch at a time
• Closed dumps move to inbox-archive/, not silent delete (§5e)