RFC: scope model — Project sharing + Workstream isolation

[larry-zy]

Summary

PowerContext derives a scope_id from a project and uses it to share durable context across Sessions; Handoff later reused that same scope as the identity of one linear Workstream. As a result scope_id is overloaded with three conflated meanings at once — the project (sharing unit), the memory-isolation / Runtime partition key, and the Workstream (isolation unit) — where sharing wants scopes to be the same and isolation wants them different. One key cannot be both, so the current model cannot express parallel work inside one project or development spanning several projects.

This RFC fixes the identity boundaries relating Project, Workstream, Session, and scope, and records the accepted model and invariants (I1–I8) without prematurely fixing user-flow orchestration, migration tooling, or concrete API/CLI/Dashboard shapes.

Decision — Alternative B

Three approaches were weighed (full comparison in Rationale and alternatives):

• A — three-layer model with a new workstream_id (cleanest, but reverses two RFC 0082 decisions and forces a backfill migration) → deferred, not discarded.
• B — keep scope_id as the Workstream identity and partition key; add a separate, additive, opt-in Project layer that carries the shared context → adopted.
• C — documentation-only clarification → rejected (no modeled capability).

Under B, isolation stays on the Workstream (scope_id ≡ Workstream: its own Sources / Memory head / linear Handoff history / Statistics) and sharing lives on the Project (project_id → Memory Artifact, read-only overlay from any member Workstream's Session). Both hold simultaneously — which a single overloaded scope_id could not express. No workstream_id this version; zero migration, no Core Protocol change; ungrouped scopes behave exactly as today.

Scope of this RFC

• Reconciles the affected existing RFCs — 0019 (MemoryBindingStore one-to-one binding + the named multi-instance extension seam), 0048 (one linear history per scope, CAS conflict), 0082 (Project → Workstream(≡scope_id) catalog, aggregation-only rule, branch-is-not-identity).
• English and Chinese versions kept in sync (docs/en/rfcs/ + docs/zh/rfcs/).

Intentionally left Unresolved (deferred to follow-up)

• Read-composition precedence / merge / dedup policy between the two heads.
• Whether and how a Session may write Project context (default: read-shared only).
• Context Pack surface for Project-level reads (RFC 0028 stays single-scope for now).
• The Workstream-boundary declaration surface (derive_scope_id currently keys only on the repository).

Notes for reviewers

• Filename keeps the 0000_ prefix per the RFC process; it will be renamed to this PR's number once assigned.

Refs #1219

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ larry-zy
❌ frostming
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[PsiACE]

hi @larry-zy , pls only add your rfc files in this PR -> edit the target branch to oceanbase:master

[larry-zy]

I've realized the problem — sorry, I'm fixing it now.

[larry-zy]

This PR adds an RFC ("Development Context and Scope Model") proposing to resolve scope_id's three-way semantic overload by keeping scope_id as the Workstream identity (and Runtime partition key) and introducing an explicit application-layer Project to carry shared context, without adding a new workstream_id. It is a documentation-only change: no source code is modified. The only additions are two synchronized RFC files, in English and Chinese, under docs/en/rfcs/ and docs/zh/rfcs/.

[PsiACE]

I wonder if Alternative B can be simplified by treating Project as a typed scope, while keeping it as a domain abstraction:

Project(scope=P)
  +-- Workstream(scope=A)
  +-- Workstream(scope=B)

The existing catalog already provides the A/B -> P relationship. If project_id uses the Runtime scope identity, Project context can reuse the current scoped Source and Memory path:

A/B --publish snapshot--> Sources(P) --> Memory(P)
prepare(A) --> Memory(A) + Memory(P)

This avoids a separate project_id -> Memory Artifact binding. The membership part of the catalog should belong to the Runtime rather than Handoff Report, and Project scopes should not expose Handoff or Continue.

Could you compare this model with the current Alternative B?