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, which isolate one behavior at a time. They are evidence and proposed tests, not adoption claims.

The reference portfolio

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.

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

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.

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.

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.

                    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.

                     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

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 defines the shared responsibilities. The transposition document owns the proposed mapping flow. The reference scenarios isolate the protocol behaviors behind these end-to-end cases.