Files
alknet/tasks/architecture/spec-storage.md
glm-5.1 19b3d3a078 docs: write Phase 0 architecture foundation — ADRs 026-034, spec docs, and task updates
Phase 0a — ADRs (9 new):
- ADR-026: Transport/interface separation (three-layer model)
- ADR-027: Crate decomposition (core, secret, storage, flowgraph, napi, CLI)
- ADR-028: Auth as irpc service (AuthProtocol behind feature flag)
- ADR-029: Identity as core type (Identity + IdentityProvider in alknet-core)
- ADR-030: Static/dynamic config split (ArcSwap, ConfigReloadHandle)
- ADR-031: Forwarding policy (rule-based allow/deny, TransportKind-aware)
- ADR-032: Event boundary discipline (domain, irpc, call protocol boundaries)
- ADR-033: OperationEnv universal composition (three dispatch paths)
- ADR-034: Head/worker terminology (replace hub/spoke)

Phase 0b — New spec documents (7):
- identity.md, services.md, interface.md, configuration.md,
  storage.md, flowgraph.md, secret-service.md

Updated existing docs:
- auth.md: reference identity.md for canonical definitions, add AuthProtocol
- open-questions.md: resolve OQ-12, OQ-16, OQ-18, OQ-22, OQ-23-25
- README.md: add all new docs, ADRs 026-034

Marked 19 architecture tasks as completed.
2026-06-07 09:32:58 +00:00

56 lines
2.9 KiB
Markdown

---
id: architecture/spec-storage
name: Create storage.md architecture spec (or stub referencing crate docs)
status: completed
depends_on:
- architecture/adr-027-crate-decomposition
- architecture/adr-029-identity-core-type
- architecture/adr-032-event-boundary-discipline
scope: moderate
risk: low
impact: component
level: implementation
---
## Description
Create `docs/architecture/storage.md` — an architecture spec for the `alknet-storage` crate, covering the metagraph data model, identity tables, ACL graph, honker integration, and StorageProtocol irpc service.
The integration plan notes this could be "a new spec or reference alknet-storage's own docs." Since alknet-storage doesn't exist yet as a crate, we need an architecture spec here to define its contract — especially the interface back to core (`StorageIdentityProvider` implementing alknet-core's `IdentityProvider` trait).
If the crate will have its own detailed docs later, this spec can be a contract-level document: what storage provides, what it depends on, and how it connects to core.
**Source**: `docs/research/storage.md` (460 lines, comprehensive)
## Acceptance Criteria
- [ ] `docs/architecture/storage.md` exists with YAML frontmatter (`status: draft`)
- [ ] Follows spec format: What, Why, Architecture, Constraints, Open Questions, Design Decisions
- [ ] Documents metagraph data model: GraphType, NodeType, EdgeType, Graph, Node, Edge
- [ ] Documents identity tables: accounts, organizations, peer_credentials, api_keys, audit_logs
- [ ] Documents ACL as metagraph: PrincipalNode, DelegatesEdge, access control graph
- [ ] Documents encrypted node type: bridges to alknet-secret's EncryptedData format
- [ ] Documents honker integration: stream_publish/subscribe, notify/listen, queue/claim
- [ ] Documents System DB vs Tenant DB separation
- [ ] Documents `StorageIdentityProvider`: implements alknet-core's `IdentityProvider` trait (queries peer_credentials + ACL graph) per ADR-029
- [ ] Documents `StorageProtocol` irpc service with key variants
- [ ] States crate dependencies: rusqlite, honker, petgraph, jsonschema, irpc
- [ ] States crate does NOT depend on alknet-core (implements core's trait by depending on alknet-core types, not the full crate — or via the trait definition only)
- [ ] Event boundary per ADR-032: honker streams stay within storage service, StorageProtocol serves as internal boundary, call protocol events are projections
- [ ] References ADR-027, ADR-029, ADR-032
- [ ] `docs/architecture/README.md` updated to include storage.md
## References
- docs/research/storage.md — full metagraph, identity, ACL, honker definitions
- docs/research/integration-plan.md — Phase 2.2 (alknet-storage)
- docs/architecture/decisions/027-crate-decomposition.md
- docs/architecture/decisions/029-identity-core-type.md
## Notes
> To be filled by implementation agent
## Summary
> To be filled on completion