Architecture and ownership
Use the repository's architecture, modelling conventions and context catalogue as the current shared reference. Context READMEs own the detailed operations, invariants and implementation limits.
Service boundaries
Consult the context catalogue for the complete current map. Deployment grouping and bounded-context ownership answer different questions. Every context owns its model and any persisted data, including its credentials and migration history.
Follow the owner
- Party Governance owns canonical Party authentication and verified provider associations.
- Project owns the canonical source-managed Project and complete child memberships.
- Marketplace owns Orders; its catalogue and buyer ports remain development stand-ins.
- Resource Provisioning owns allocation and native account evidence.
- SSH Access owns public-key lifecycle and Site application.
- Member Credentials owns offline consent for native actions.
- LLM Access owns allocations, chat access, budgets and personal keys.
- Support owns customer linkage and support-ticket workflows.
- Contracts define the Project integration boundary and its authority/freshness rules.
- Browser subscriptions define server-authorised delivery and revision-aware recovery.
How to use the examples
The learning path uses Beto examples selected for a specific principle. Read the associated implementation and tests before extending a pattern. Metallo's current layout and unfinished integration work require individual review; they do not define a general template for a new context.
Adding a context explains registration, isolation and verification. Changes to shared policy belong in an architectural decision.
Page source
Source snapshot ยท Revision f928834c8.