docs(adr): add glossary pages and ADR baseline structure
This commit is contained in:
@@ -25,8 +25,10 @@ export default defineConfig({
|
||||
{ text: "i18n Baseline", link: "/product-engineering/i18n-baseline" },
|
||||
{ text: "i18n Conventions", link: "/product-engineering/i18n-conventions" },
|
||||
{ text: "RBAC And Permissions", link: "/product-engineering/rbac-permission-model" },
|
||||
{ text: "Domain Glossary", link: "/product-engineering/domain-glossary" },
|
||||
{ text: "Environment Runbook", link: "/product-engineering/environment-runbook" },
|
||||
{ text: "Testing Strategy", link: "/product-engineering/testing-strategy" },
|
||||
{ text: "ADR Index", link: "/adr/" },
|
||||
{ text: "Workflow", link: "/workflow" },
|
||||
],
|
||||
},
|
||||
@@ -36,7 +38,17 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
text: "Public API",
|
||||
items: [{ text: "Section Overview", link: "/public-api/" }],
|
||||
items: [
|
||||
{ text: "Section Overview", link: "/public-api/" },
|
||||
{ text: "Glossary", link: "/public-api/glossary" },
|
||||
],
|
||||
},
|
||||
{
|
||||
text: "ADR",
|
||||
items: [
|
||||
{ text: "Index", link: "/adr/" },
|
||||
{ text: "0001 Monorepo Foundation", link: "/adr/0001-monorepo-foundation" },
|
||||
],
|
||||
},
|
||||
],
|
||||
socialLinks: [{ icon: "github", link: "https://example.com/replace-with-repo" }],
|
||||
|
||||
37
docs/adr/0001-monorepo-foundation.md
Normal file
37
docs/adr/0001-monorepo-foundation.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# ADR 0001: Monorepo Foundation
|
||||
|
||||
- Status: Accepted
|
||||
- Date: 2026-02-10
|
||||
|
||||
## Context
|
||||
|
||||
The CMS platform requires:
|
||||
|
||||
- separate admin and public apps
|
||||
- shared domain contracts and data access
|
||||
- consistent tooling and CI quality gates
|
||||
- incremental delivery through MVP stages
|
||||
|
||||
A fragmented multi-repo setup would increase coordination overhead and duplicate shared contracts.
|
||||
|
||||
## Decision
|
||||
|
||||
Adopt a Bun workspace monorepo with:
|
||||
|
||||
- `apps/admin` and `apps/web` for runtime surfaces
|
||||
- shared packages (`@cms/content`, `@cms/db`, `@cms/crud`, `@cms/ui`, `@cms/i18n`)
|
||||
- shared quality tooling (Biome, TypeScript, Vitest, Playwright, Turbo)
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- shared contract updates propagate in one change set
|
||||
- easier cross-app refactors and testing
|
||||
- single CI pipeline with consistent gates
|
||||
|
||||
### Negative
|
||||
|
||||
- stronger need for workspace discipline and clear boundaries
|
||||
- larger repository clone/build surface
|
||||
- potential for cross-package coupling if conventions are not enforced
|
||||
17
docs/adr/README.md
Normal file
17
docs/adr/README.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# ADR Index
|
||||
|
||||
Architecture Decision Records (ADRs) capture important technical decisions and context.
|
||||
|
||||
## Format
|
||||
|
||||
- Numbered files: `0001-<short-title>.md`
|
||||
- Immutable once accepted (new ADRs supersede old decisions)
|
||||
- Include:
|
||||
- Status
|
||||
- Context
|
||||
- Decision
|
||||
- Consequences
|
||||
|
||||
## Records
|
||||
|
||||
- [0001 - Monorepo Foundation](./0001-monorepo-foundation.md)
|
||||
@@ -7,6 +7,7 @@ Engineering documentation hub for this repository.
|
||||
- [Product / Engineering](/product-engineering/)
|
||||
- [Admin / User Guides](/admin-user-guides/)
|
||||
- [Public API](/public-api/)
|
||||
- [ADR Index](/adr/)
|
||||
|
||||
## Core Sources
|
||||
|
||||
|
||||
35
docs/product-engineering/domain-glossary.md
Normal file
35
docs/product-engineering/domain-glossary.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Domain Glossary
|
||||
|
||||
## Core Terms
|
||||
|
||||
### Owner
|
||||
|
||||
Highest-privilege admin role. Exactly one canonical owner must exist at all times.
|
||||
|
||||
### Support User
|
||||
|
||||
Hidden technical support account used for break-glass access and operational recovery.
|
||||
|
||||
### Admin Registration Policy
|
||||
|
||||
Runtime policy controlling whether `/register` can create additional admin users after owner bootstrap.
|
||||
|
||||
### Protected Account
|
||||
|
||||
Account that cannot be deleted/demoted through self-service flows (support + canonical owner).
|
||||
|
||||
### CRUD Service
|
||||
|
||||
Shared `@cms/crud` service abstraction combining schema validation, repository orchestration, and audit hooks.
|
||||
|
||||
### Permission Scope
|
||||
|
||||
RBAC access scope granularity: `own`, `team`, `global`.
|
||||
|
||||
### Roadmap Source Of Truth
|
||||
|
||||
`TODO.md` in repository root. Rendered in admin via `/todo`.
|
||||
|
||||
### Header Banner
|
||||
|
||||
Public-site announcement strip configured through `system_setting` key `public.header_banner`.
|
||||
@@ -10,8 +10,10 @@ This section covers platform and implementation documentation for engineers and
|
||||
- [RBAC And Permissions](/product-engineering/rbac-permission-model)
|
||||
- [i18n Conventions](/product-engineering/i18n-conventions)
|
||||
- [CRUD Examples](/product-engineering/crud-examples)
|
||||
- [Domain Glossary](/product-engineering/domain-glossary)
|
||||
- [Environment Runbook](/product-engineering/environment-runbook)
|
||||
- [Testing Strategy Baseline](/product-engineering/testing-strategy)
|
||||
- [ADR Index](/adr/)
|
||||
- [Workflow](/workflow)
|
||||
|
||||
## Scope
|
||||
@@ -23,6 +25,4 @@ This section covers platform and implementation documentation for engineers and
|
||||
|
||||
## Planned Expansions
|
||||
|
||||
- Domain model and glossary
|
||||
- ADR (Architecture Decision Record) index
|
||||
- Operational playbooks (incident, rollback, recovery)
|
||||
|
||||
43
docs/public-api/glossary.md
Normal file
43
docs/public-api/glossary.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# Public API Glossary
|
||||
|
||||
## Scope
|
||||
|
||||
Baseline terms for future public API design and integration discussions.
|
||||
|
||||
## Terms
|
||||
|
||||
### Public API
|
||||
|
||||
Externally consumable endpoints intended for non-admin clients.
|
||||
|
||||
### Resource
|
||||
|
||||
Entity exposed by an API endpoint (for example: `page`, `media`, `news`).
|
||||
|
||||
### Contract
|
||||
|
||||
The stable request/response schema for an endpoint version.
|
||||
|
||||
### Version
|
||||
|
||||
Compatibility boundary for API contracts (for example: `v1`).
|
||||
|
||||
### Authentication
|
||||
|
||||
Identity verification mechanism for protected API routes.
|
||||
|
||||
### Authorization
|
||||
|
||||
Permission check determining whether an authenticated actor can access a resource/action.
|
||||
|
||||
### Pagination
|
||||
|
||||
Mechanism for splitting large result sets across requests.
|
||||
|
||||
### Idempotency
|
||||
|
||||
Property where repeating a request does not change final state beyond the first successful call.
|
||||
|
||||
### Rate Limit
|
||||
|
||||
Request threshold policy applied per consumer/time window.
|
||||
@@ -11,6 +11,11 @@ No stable public API surface is documented yet.
|
||||
- Add API docs when real endpoints are implemented and versioned
|
||||
- Use OpenAPI as source of truth for endpoint reference
|
||||
- Keep integration guides and authentication examples here
|
||||
- Use glossary terms consistently across API specs and guides
|
||||
|
||||
## Reference
|
||||
|
||||
- [Public API Glossary](/public-api/glossary)
|
||||
|
||||
## Notes
|
||||
|
||||
|
||||
Reference in New Issue
Block a user