design: shared scratchpads for lightweight collaborative work

[laynepenney]

Summary

Add a first-class shared scratchpad surface to gr2 for lightweight collaboration that does not require entering another worker's private directory and does not require a full pull request.

Why

The current private-worktree model is correct for isolated implementation, but it leaves a gap for collaborative drafting and lightweight joint editing.

Examples:

• blog drafts
• RFC/spec drafting
• release notes
• collaborative planning docs
• small shared review edits before a real PR exists

Today the bad options are:

• enter someone else's private workspace
• overuse PRs for draft collaboration
• push work into ad hoc shared files with weak ownership

User need

"I need a lightweight shared place to collaborate without crossing into someone else's private workspace and without paying the full cost of a PR."

Design direction

Treat shared scratchpads as a first-class workspace primitive, separate from private lanes.

Private lanes remain for:

• feature work
• review work
• repro work
• private agent/human context

Shared scratchpads are for:

• draft collaboration
• shared notes
• collaborative content editing
• bounded temporary joint work

Requirements

• explicit shared location owned by the workspace, not by one agent
• bounded purpose and lifecycle
• visible participants/metadata
• easy to create and remove
• does not weaken the rule that private workspaces remain private
• should be cheap enough to use for docs/blog/release-note collaboration

Non-goals

• not a replacement for implementation isolation
• not a substitute for final PR review
• not a general shared coding free-for-all

Open questions

• should this be modeled as a shared lane, a shared workspace area, or both?
• should shared scratchpads be doc-only first, then broader later?
• what metadata is required: name, purpose, participants, expiry, linked issue/PR?
• how should shared scratchpads appear in lane/status/exec surfaces?

Design refs

• design: gr2 repo maintenance and multi-repo lanes #542
• docs: design gr2 repo maintenance and lanes #543
• feat: gr2 exec lane-aware multi-repo build/test/run surface #544
• feat: gr2 lane checkout-pr for isolated multi-repo review lanes #546

[laynepenney]

Starting the prototype pass for shared scratchpads.

Planned first step:

• prototype shared scratchpad metadata and layout
• verify the lightweight collaboration workflow for docs/blog/RFC editing
• decide whether the first real slice should be doc-first or general-purpose

[laynepenney]

Prototype findings:

• shared scratchpads work as a separate workspace primitive without violating private lanes
• the doc-first variant already covers the main pain: blogs, RFCs, notes, release content
• the right UX shape is explicit metadata + lightweight list/show surfaces + next-step guidance
• review lanes and shared scratchpads should stay distinct: one is for isolated inspection, the other is for lightweight collaboration

Verified in the prototype:

• feature lane creation with explicit branch maps
• review lane creation as a cheap wrapper
• shared scratchpad creation with participants, purpose, refs, and lifecycle
• list/show/next-step surfaces that make the workflow legible

Recommendation: first production slice should be doc-first shared scratchpads, not general shared coding lanes.

[laynepenney]

Added the break-case matrix for the shared scratchpad prototype.

Reference:

• docs/ASSESS-gr2-shared-scratchpads-stress.md

This is now the verification gate for the prototype. The design should not be treated as solid until it survives the adversarial scenarios there, especially:

• concurrent shared editing
• stale scratchpads
• wrong-surface choice
• scope creep into shared implementation
• promotion from scratchpad to real repo artifact / PR