On dependency-guard: inherited from the unmerged Wave 1 base (#101098) — no new dependency. Read-only surface (history list/get + UI); restore reuses the existing undo. Verified by the submitting orchestrator's own gate: extensions/dashboard 83 tests, UI dashboard+plugin+cell 138 tests, ui:build + full type-aware oxlint clean.

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

Dependency graph guard cleared

This PR no longer has blocked dependency graph changes. A future dependency graph change requires a fresh /allow-dependencies-change comment after the guard blocks that new head SHA.

• Current SHA: e9fc1b6513037bce23772c71b9359979dad30683

Codex review: needs real behavior proof before merge. Reviewed July 13, 2026, 5:51 AM ET / 09:51 UTC.

Summary
Adds SQLite-backed workspace history list, snapshot preview, structural diffs, provenance details, and exact-version restore in the Workspaces UI, plus three synchronous Kysely helpers on the public plugin-state SDK subpath.

PR surface: Source +1140, Tests +649, Docs +17, Generated 0, Other -1. Total +1805 across 23 files.

Reproducibility: not applicable. This PR adds a new Workspaces capability rather than repairing an established failing behavior. Source and tests provide a clear validation model, but they are not a current-main bug reproduction.

Review metrics: 3 noteworthy metrics.

• Public plugin SDK callables: 3 added. Each new callable becomes a compatibility-sensitive third-party plugin contract rather than an implementation-local helper.
• Workspace gateway methods: 3 added. History list, get, and restore expand the operator-facing RPC surface and require authorization and upgrade review.
• Persisted restore paths: 1 new exact-version path. The new mutation rewrites stored workspace state while preserving approvals and monotonic versioning, which warrants real upgrade and failure proof.

Stored data model
Persistent data-model change detected: database schema: ui/src/lib/workspace/history.test.ts, serialized state: ui/src/lib/workspace/history.test.ts, serialized state: ui/src/lib/workspace/history.ts, unknown-data-model-change: ui/src/lib/workspace/history.test.ts, unknown-data-model-change: ui/src/lib/workspace/history.ts, vector/embedding metadata: extensions/workspaces/src/store.test.ts, and 1 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #101822
Summary: This PR is the implementation candidate for the canonical workspace-history issue; the roadmap tracker is broader, while the Teams PR is adjacent work sharing an authorization integration seam.

Members:

• canonical: Dashboard: workspace time-travel — history scrub, version diff, and widget→logbook blame #101822 - The issue requests workspace history browsing, structural version comparison, restore, and provenance links, which are the central behaviors implemented here.
• partial_overlap: Modular Dashboard — Wave 2+ roadmap (tracking) #101136 - The roadmap tracks this feature among many Workspaces initiatives but is not a replacement implementation item.
• adjacent_distinct: Workspaces: add scoped Teams control hub #101913 - The Teams control-hub work is a separate feature but introduces an authorization projection that historical reads must respect when both features compose.
• adjacent_distinct: Teams: local multi-user Workspaces sharing with exact tab RBAC #105322 - The Teams foundation defines exact-tab authorization and persisted identity rules relevant to future history projection, but does not implement version history.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted current-head browser proof covering preview, exact restore, monotonic versioning, and a failed restore that leaves the panel open.
• Obtain an explicit maintainer decision on the three public plugin SDK exports and narrow them if general-purpose exposure is not intended.
• Resolve the current control-ui-i18n and checks-node-compact-small-2 failures, then refresh the review on the resulting head.

Proof guidance:

• [P1] Needs real behavior proof before merge: Only automated tests and static checks are supplied; add a redacted browser recording showing history open, snapshot preview, exact restore, monotonic result, and visible restore failure, then update the PR body to trigger review or ask for @clawsweeper re-review.

Risk before merge

• [P1] The three new plugin-state-runtime functions become supported third-party plugin API and may be difficult to narrow or remove after release; green API-baseline checks do not decide whether this is the intended permanent abstraction.
• [P1] Restore rewrites persisted workspace state and approval-sensitive fields, so unit coverage alone does not prove fresh-install and realistic upgrade behavior or demonstrate recovery from a failed restore in the browser.
• [P1] If the scoped Teams work lands, historical snapshot reads must use the same exact-resource projection as live reads or they could expose content omitted from the current authorized workspace view.
• [P1] The current head still reports failures in control-ui-i18n and checks-node-compact-small-2; their causes must be resolved or shown to be unrelated before merge.

Maintainer options:

1. Narrow and prove before merge (recommended)
   Approve the feature direction, narrow the public SDK seam if required, resolve current checks, and add real browser plus Teams-composition proof.
2. Accept the API and state risk
   Merge the current contract only after maintainers explicitly accept the three public helpers and the restore/authorization upgrade obligations.
3. Pause pending roadmap sponsorship
   Keep the PR open or close it later if maintainers do not want version history or another permanent plugin SDK expansion now.

Next step before merge

• [P1] A maintainer should decide the permanent plugin SDK boundary and feature sponsorship; afterward the contributor must provide real browser proof and clear the current failing checks.

Maintainer decision needed

• Question: Should Workspaces version history ship with these three general synchronous Kysely helpers as permanent public plugin SDK exports, or must the storage seam be narrowed before merge?
• Rationale: The feature is new user-facing product surface and the implementation expands a compatibility-sensitive public SDK; tests cannot determine the intended long-term API boundary.
• Likely owner: steipete — The unresolved choice concerns supported plugin SDK and product surface rather than a mechanical branch repair.
• Options:
  • Approve a narrower SDK seam (recommended): Keep the Workspaces feature but replace the three general helpers with the smallest purpose-specific plugin-state contract that satisfies this store.
  • Accept the proposed exports: Treat the three synchronous Kysely helpers as supported third-party plugin API and retain the accompanying documentation and baseline changes.
  • Pause the feature: Leave version history unmerged until the broader Workspaces roadmap and storage API direction are explicitly sponsored.

Security
Cleared: No standalone security or supply-chain regression is established in this head; the documented Teams composition requires an authorization follow-through before both features ship together.

Security (cross-PR, surfaced by the downstream Boardstate extraction's audit — SPEC invariant I6): private-tab leak via workspace history, emergent when this PR and #101913 both land.

• This PR (Workspaces: add version history and exact restore #101900) adds dashboard.workspace.history.get, which returns a full historical snapshot of the workspace document, but does not run it through any operator-visibility filter.
• Workspaces: add scoped Teams control hub #101913 (control-hub) introduces private / per-operator tabs and a filterWorkspaceForOperator that respondDoc applies to every live read so a response never leaks another operator's private tab.

Neither branch has the hole in isolation (this one has no private tabs yet; that one has no history endpoint). But once both are on main, history.get returns snapshots unfiltered, so a non-owner can read another operator's private tab out of any older version — bypassing the live-read filter.

Fix at integration: route the history.get snapshot through the same filterWorkspaceForOperator(doc, operatorId) that respondDoc uses for live reads (the version field stays the real/unfiltered value so client change-dedup is unaffected). Reference: the extracted Boardstate applies exactly this in its dashboard.workspace.history.get handler.

Flagging on both PRs so it isn't lost at merge. (The other two audit findings — approval-elevation via workspace.replace, and CSP on widget-route 404s — were single-branch and are fixed directly in #101094 and #101098.)

@100yenadmin thanks for the PR. ClawSweeper is still waiting on real behavior proof before this can move forward.

Useful proof can be a screenshot, short video, terminal output, copied live output, linked artifact, or redacted logs that show the changed behavior after the fix. Please redact private tokens, phone numbers, private endpoints, customer data, and anything else sensitive.

Once proof is added to the PR body or a comment, ClawSweeper or a maintainer can re-check it.