The shared library family packages cross-project primitives so every service does not reimplement authentication clients, logging, UI components, Zod schemas, dependency baselines, guards, interceptors, and operational conventions.
It is implementation-only: no secrets and no project-specific folder structure.
- Status
- Building
- Autonomy (AAL)
- L1 → L3
- Packages
- @arcanada/*
- Repository
- Arcanada-one/arcanada-shared
01
Write it once
Authentication clients, logging, guards, interceptors and UI components are meant to be packaged once instead of being rebuilt in every service.
02
One place for dependency versions
Shared base configs and a Renovate preset are designed to let one update reach many projects.
03
Implementation only
The library carries no secrets and no project-specific folder structure.
Capabilities
Status not stated
- Backend guards, interceptors, logging, and Auth Arcana client utilities
- Frontend components, hooks, utils, and theme tokens
- Zod schemas and cross-project contracts
- Shared base configs and Renovate preset
- Reuse mandate integration for new project scaffolds
Current autonomy level
Weakest link
The library is still being assembled from proven patterns; consumers are not yet uniformly migrated to shared packages.
Roadmap to L3
- Publish the first stable @arcanada/* package set.
- Migrate one backend and one frontend consumer as reference implementations.
- Add compatibility tests so shared updates do not break downstream services.
Links
Next step
Review the current build and its development plan
BUILDING means active development, not a promise of public availability. Use the current capabilities and roadmap above as the reference.
Review the path to the target level