docs(#575,#333): Phase 0 spec — scope model and identity projection

[Weegy]

What

Phase 0 of the #575 / #333 wave: a measured spec document for the scope model
(#575) and identity/role projection (#333). It implements nothing — it ends with six
decisions that gate Phase 1.

Both issues are Cx 9, together touch 60–100+ files, and both modify the same seam
(resolveIdentity, principal ids, the turn's scope). Starting either one blind produces an
unreviewable PR the other has to undo. This document exists so that does not happen.

specs/575-scope-and-identity-foundation/spec.md — single file, no code.

Why now

#579 (PR #681, 12 files / +1898) is already in flight against a scope model that does not
exist. §7 measures what it actually needs.

Findings that changed the plan

Everything below is a direct measurement at e4e892e7, not a reading of the issue text.

1. Three unrelated things are called "scope." The turn's session scope (string), the
   memory-path scope (readonly string[]), and Org security postures with provenance-labelled input screening #579's security_posture_scope — which is a
   posture value, not a scope. The naming must be resolved before code.

2. The graph partition key is a lossy, non-injective projection of the scope string.
   sanitizeScope collapses : and :: to -, truncates at 80 chars and lowercases, so
   teams::c1, teams:c1 and teams-c1 all become one graph key. Today that is a recall
   nuisance; the moment scope becomes a security boundary it is an isolation bug. A
   :-separated ScopeId cannot simply be dropped into the existing pipe.

3. The proposed ScopeId union does not cover the values that actually occur —
   http-default, the machine scopes (routine:/schedule:/conductor:), and the bare
   sessionId. Shipping it as proposed would preserve the very denylist it is meant to
   delete. §3 proposes a six-variant union that does cover them.

4. 107 non-test sessionScope occurrences across 23 files — ~6 need a decision, ~10 are
   mechanical. Far more tractable than the file count suggests. The load-bearing one is the
   published channel-SDK contract (sessionScope?: string), which crosses a repo boundary
   into the private byte5 plugins with no compiler to catch a break.

5. 'teams-unknown' and 'unknown' in the directLineSticky denylist have no producer
   anywhere in this tree (0 hits outside the denylist and its tests).

6. PR feat(#579): org security postures + provenance-labelled inbound scree… #681 (Org security postures with provenance-labelled input screening #579) does not consume a scope model and is not blocked. tightenPosture
   takes two postures and no scope id; security_posture_scope is one anonymous
   deployment-wide value. It needs a type plus two pure functions — all of which fit inside
   Scope model with audience-floor permission intersection for shared rooms #575 Phase 1. Recommendation: do not block feat(#579): org security postures + provenance-labelled inbound scree… #681. The one ask is a field rename
   (security_posture_scope → security_posture_override) before it merges, to avoid a
   permanent collision with ScopeId.

7. Scope model with audience-floor permission intersection for shared rooms #575 Phase 1 does not depend on Identity & Role Projection — omadia as a team-player in the existing IT landscape (Principal = user|role everywhere) #333 at all; Phase 2 does. The two issues are
   sequential, not parallel, and the seam between them is the participant→Principal
   conversion. That ordering is the main scheduling output.

A premise this falsified

The wave framing listed #582 alongside #579 as blocked on the missing scope model. #582
is a deployment-directory contract with no scope concept in it. Only #579 has the
dependency — and even that one is far weaker than assumed.

Decisions needed (D1–D6, §8)

ScopeId shape · whether the published SDK contract changes (recommend: no) · whether the
graph key becomes injective (recommend: yes, as its own PR first) · mid-turn joiner
semantics · the #579 field rename · confirming the denylist entries against the private
plugin repo.

Test plan

• Docs-only change; no code, no tests affected.
• Every file:line in the document re-read at origin/main e4e892e7.
• Numeric claims re-derived after writing (107 occurrences / 23 files / 0 producers / 0 web-ui hits).
• PR feat(#579): org security postures + provenance-labelled inbound scree… #681 semantics read from its head commit 716a1cf5, not its description.

Risk / blast radius

None — a single new markdown file under specs/. No code, no schema, no CI surface.

Open risk carried in the document (§10)

The private omadia-byte5-plugins repo was not inspected; it may contain scope producers
and consumers of the SDK contract. That is why D2 and D6 are decisions rather than findings.

Awaiting sign-off. Phase 1 is not authorized until D1–D6 are answered.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}