engram-architecture-guardrails
Architecture guardrails for Engram across local store, cloud sync, dashboard, and plugins. Trigger: Any change that affects system boundaries, ownership, state flow, or cross-package responsibilities.
Installation
Suivez les instructions du dépôt pour votre agent. Consultez les fichiers et dépendances avant l’installation.
Voir la source ↗GuidesInstructions
When to Use
Use this skill when:
- Adding a new subsystem or major package
- Moving responsibilities between local store, cloud, dashboard, or plugins
- Changing sync flow, source-of-truth rules, or persistence boundaries
Core Guardrails
- Local SQLite is the source of truth; cloud is replication and shared access.
- Keep plugin/adaptor layers thin; real behavior belongs in Go packages.
- Prefer explicit boundaries: store, cloudstore, server, dashboard, autosync.
- New features must fit the existing local-first mental model before they fit the UI.
- Do not hide cross-system coupling inside helpers or templates.
Decision Rules
- Local-only concern ->
internal/store - Cloud materialization or org-wide control ->
internal/cloud/cloudstore - HTTP contract or enforcement ->
internal/cloud/cloudserver - Browser rendering and UX ->
internal/cloud/dashboard - Background orchestration ->
internal/cloud/autosync
Validation
- Add regression tests for every boundary change.
- Verify local, remote, and dashboard behavior still tell the same product story.
- If the change touches sync, test both push and pull paths.
Exemples
Consultez les exemples du dépôt source.
Voir la source ↗Historique source
- Date d’indexation
- 2026-03-11
- Mise à jour de l’index
- 2026-03-11
- Branch
- main
Les dates concernent ce répertoire. Consultez le dépôt pour l’historique du code.
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!