# Open Workplace use cases Status: Non-normative examples for `open-workplace/0.2-draft` These cases test complete environments through the shared responsibility model. They complement the smaller [reference scenarios](reference-scenarios.md), which isolate one behavior at a time. They are evidence and proposed tests, not adoption claims. ## The reference portfolio ```text Observed or locally qualified ├── 1. A lived multi-repository Workplace └── 2. An existing team tech harness Control cases ├── 3. The smallest useful Workplace └── 4. No additional Workplace structure Boundary tests ├── 5. Two agents resolving separate contexts └── 6. Two independent implementation Profiles ``` Each case names the starting evidence, responsibility boundary, human decisions, observable result and maturity. Profile vocabulary appears only when the case explicitly exercises that Profile. ## Use case 1: a lived multi-repository Workplace ### Starting environment One person coordinates product repositories, public websites, research, publishing and reusable agent practices. Codex and Claude enter through different provider surfaces. Repositories keep their own Git history, permissions and delivery lifecycle. The Workplace itself is declared separately. Its Sources identify owners for shared constitution, personal continuity and durable domains; its Relationships reach external authorities without absorbing them. ```text declared Workplace ├── Sources · constitution, decisions, methods ├── Material · retained research and accepted revisions ├── Projections · provider entrypoints └── Relationships · repositories and public destinations ``` ### Endroit 0.10 binding The qualified local Endroit 0.10 release candidate represents this case with `WORKPLACE.md`, Member/Desk/Room Documents, Equipment, Site and Route Documents, derived Checkout addresses and provider Projections. Those names are Endroit-owned. `Home` and `Instance` are legacy 0.8 terms; durable Occupant/Role and Mount are not part of the 0.10 Profile. ### Observable result A fresh provider session can identify the Workplace, Profile, objective, relevant Sources, Material and Relationships without receiving the previous provider's transcript. It can recover provenance and name limits before a consequential effect. ### Maturity and limits One evolving Workplace and one local Profile candidate demonstrate the pattern. The Endroit 0.10 candidate is not yet published or deployed, and a second independent Profile has not been observed. ## Use case 2: transposing an existing team tech harness ### Starting environment A useful harness already has provider instructions, Skills, hooks, executable scenarios, several independent repositories, personal configuration and local links. Recognition must preserve that working topology. ### Candidate responsibility map ```text Observed evidence Candidate responsibility harness repository and Git → external authority or Workplace boundary provider instructions → Source or Projection, owner unresolved reusable Skills → Profile-specific reusable methods personal configuration → Source with a personal owner notes and run evidence → Material with explicit durability target repositories → external authorities local links → Relationships or derived local addresses ``` The human selects the Workplace boundary, confirms owners and authorizes any application separately. Repository names and directory containment never settle those decisions. ### Observable result The proposal preserves repository origins and current harness behavior, names every inference and loss, and shows an expected diff before mutation. A fresh session can verify the accepted representation from owned Sources. ### Maturity and limits A real harness supplies starting evidence. Its public transposition remains a proposal; private repository names and integration details are excluded. ## Use case 3: the smallest useful Workplace ### Starting environment One developer has one primary repository, a few practices and results that must survive provider sessions. The repository remains an external authority; the durable layer should stay smaller than the work it clarifies. ```text one declared Workplace ├── one authoritative constitution Source ├── only the durable Material that earned retention ├── one Relationship to the repository └── one rebuildable provider Projection ``` ### Observable result A fresh session finds the few authoritative Sources, distinguishes personal continuity from product truth and identifies the external destination. No extra durable domain exists merely to mirror a folder. ### Maturity and limits Endroit can represent and validate this shape locally. The complete newcomer journey and placement choice need evidence outside the dogfood Workplace. ## Use case 4: no additional Workplace structure ### Starting environment A person performs one isolated task whose result ends with the session. The repository already has one clear owner; no cross-session Material or external Relationship needs another durable boundary. ```text authorized repository ↓ recognition short-lived work with one clear owner ↓ recommendation No additional Workplace structure needed. ``` ### Observable result The agent names the inspected evidence, explains why additional structure adds no value and performs no adoption action. A candidate Workplace is not the default success result. ## Use case 5: two agents resolving separate contexts ### Starting environment Codex works on a product change while Claude prepares launch Material. Both enter the same declared Workplace, but each resolves a different objective, Source set, Material set and external Relationship. ```text declared Workplace │ ┌──────────────┴──────────────┐ │ │ Resolved Context A Resolved Context B product Sources launch Sources product Relationship website Relationship Codex execution Claude execution ``` ### Observable result Each agent can explain its objective, Sources, authority and destination. Neither receives authority from the other execution. If their mutation scopes converge, host file locks and Git merge controls still apply. ### Maturity and limits Provider projections and separate contexts exist in the dogfood Workplace. A controlled concurrency study has not established how often semantic ownership alone prevents collisions. ## Use case 6: two independent implementation Profiles ### Starting environment A human authorizes one environment description without selecting a target. Two independent owners map it through their Profiles. ```text source description │ ┌─────────────┴─────────────┐ │ │ Endroit Profile independent Profile │ │ resolved context A resolved context B └─────────────┬─────────────┘ │ responsibility, provenance, authority and loss ``` Matching filenames or object counts does not establish semantic fidelity. The human accepts or rejects reported losses and authorizes each application separately. ### Maturity and limits This case is unproven. Endroit provides the sole sourced Profile in this corpus; cross-Profile conformance remains an open test. ## Coverage | Use case | Boundary | Ownership | Semantic axes | External authority | Provider change | Maturity | | --- | --- | --- | --- | --- | --- | --- | | Lived Workplace | Declared | Observed | Observed | Preserved | Observed | One local Profile | | Existing harness | Candidate | Mapped | Partial | Preserved | Preserved | Proposed | | Smallest Workplace | Declared | Minimal | Minimal | Preserved | Candidate | Locally represented | | No added structure | Not needed | Existing | Ephemeral | Existing | Not needed | Negative control | | Separate contexts | Shared | Separate scopes | Preserved | Separate destinations | Observed | Study pending | | Two Profiles | Compared | Compared | Compared | Compared | Candidate | Unproven | ## Review questions - Did the case start from observed evidence rather than a preferred tree? - Can every Source claim name its owner and provenance? - Did every external authority retain its history and permissions? - Are durability, currentness, acceptance, completion and external effect still independent? - Could the result be smaller without losing useful ownership? - Which step still needs human judgment or mutation authority? - Is each claim demonstrated, proposed or unproven? The [architecture](architecture.md) defines the shared responsibilities. The [transposition](transposition.md) document owns the proposed mapping flow. The [reference scenarios](reference-scenarios.md) isolate the protocol behaviors behind these end-to-end cases.