This repository is the design-time system architecture source of truth for the wgt-system organization.
It records the architecture above individual bounded contexts: system-level context relationships, capability ownership, cross-context integration policy, system ADRs, the service/capability catalogs, and bootstrap rules for future bounded contexts.
Before introducing generic cross-context infrastructure, check the Capability Catalog.
- a concise map of accepted bounded contexts and their relationships;
- the normative system-wide architecture principles;
- a catalog of existing system capabilities and their owners;
- the binding integration policy between bounded contexts;
- the home for architecture decisions that are genuinely system-wide;
- the bootstrap reference for new
wgt-system/<service>bounded contexts.
It is not:
- a runtime service or bounded context;
- a shared code library or package dependency;
- a runtime service registry;
- a central business-domain model;
- a shared persistence model;
- a replacement for architecture documentation inside service repositories;
- a dumping ground for service-internal details;
- a requirement for Kubernetes, a service mesh, an event bus, or any other deployment technology.
Runtime code must not depend on this repository.
This repository is authoritative for:
- system-wide architecture principles;
- system-level bounded-context relationships;
- cross-context ownership boundaries;
- generic system capability ownership;
- system-wide integration policies;
- system-level ADRs;
- the existence and purpose of accepted system bounded contexts/services;
- new-service bootstrap rules.
Individual service repositories remain authoritative for:
- their domain semantics and domain model;
- aggregates, entities, value objects, and domain rules;
- internal application architecture and persistence;
- exact provider-owned Published Contract schemas and detailed API semantics;
- service-specific ADRs and implementation choices;
- service-specific release and readiness state.
System documents should link to service specifications and record only stable system-facing facts. They must not duplicate whole service specifications.
If this repository and a service repository appear to disagree, do not silently overwrite either side. Determine whether the disagreement concerns system-level ownership or service-internal semantics, record the inconsistency, and reconcile it through the appropriate control plane.
- Wiiii Got This — cross-platform integration and presentation.
- Vocation — local-first personal job market.
- Illumination — local-first personal learning.
- Conveyance — generic synchronization/relay delivery.
- Orientation — generic geospatial capability: Discover, Explore, Navigate, and Current Location representation.
Each bounded context retains ownership of its business semantics and authoritative state. Integration does not transfer that ownership.
Before designing a new bounded context or cross-context feature:
- Read ARCHITECTURE_PRINCIPLES.md for the durable system-wide rules.
- Read SYSTEM_CONTEXT.md to understand existing ownership boundaries.
- Check CAPABILITY_CATALOG.md before building generic infrastructure.
- Follow INTEGRATION_POLICY.md for concrete cross-context boundaries and the cross-device decision model.
- Use NEW_SERVICE_CHECKLIST.md when introducing a bounded context.
- Consult SERVICE_CATALOG.md for system-facing facts and provider source links.
- Add a system ADR under
adr/only when the decision is genuinely system-wide.
The Service Catalog is design-time architecture documentation. It must not be treated as runtime discovery data.
- System Architecture Principles
- System Context
- Architecture Model
- Capability Catalog
- Service Catalog
- Integration Policy
- New Service Checklist
- Agent Rules
- System ADRs
- Reusable AGENTS section
main— accepted stable system architecture.dev— ongoing or proposed architecture work.
Architecture evolves through intentional commits and ADRs. Product-style semantic release tags are not required for this repository.