Setup repo: migrate architecture specs, code stubs, and tasks from alkhub_ts
Copy architecture docs, ADRs, storage domain specs, research, reviews, and 56 storage architecture tasks from the alkhub_ts monorepo. Adapt for standalone @alkdev/hub repo structure (src/ not packages/hub/). Sanitize all sensitive information: - Replace private IPs (10.0.0.1) with localhost defaults - Remove internal server hostnames (dev1, ns528096) - Replace /workspace/ private paths with npm package references - Remove hardcoded credentials from examples - Rewrite infrastructure.md without private network details Add Deno project scaffolding: deno.json (pinned deps), .gitignore, AGENTS.md, entry point. Migrate existing code stubs (crypto, config types, logger) with updated import paths.
This commit is contained in:
@@ -0,0 +1,41 @@
|
||||
---
|
||||
id: document-system-account-email-convention
|
||||
name: Document System Account Email Convention
|
||||
status: completed
|
||||
depends_on: []
|
||||
scope: single
|
||||
risk: trivial
|
||||
impact: isolated
|
||||
level: implementation
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
**S03** (reframed): System-generated accounts (LLMs, bots, services) need email addresses for attribution in git commits, audit logs, and platform identity. To prevent collision between human and system-generated accounts, deployments need a documented convention.
|
||||
|
||||
The email domain/pattern is **deployment-configurable** — do NOT hardcode any specific domain in architecture documentation. Example conventions: `{model}@llm.example.com`, `{model}@system.example.com`, or any pattern the deployment chooses. The key requirement is that the convention is documented so implementers know how system accounts are identified.
|
||||
|
||||
## Decision
|
||||
|
||||
See `docs/decisions/storage-spec-phase1-resolutions.md` (D6): email reservation is a deployment concern, not an architecture hardcode.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] `identity.md` documents the configurable email convention pattern for system accounts
|
||||
- [ ] Documentation explicitly states that NO specific domain is hardcoded — the pattern is deployment-specific
|
||||
- [ ] A note is added to the accounts table or email column description explaining the convention
|
||||
- [ ] Example pattern is shown (e.g., `{model}@system.example.com`) with a clear "example only" annotation
|
||||
|
||||
## References
|
||||
|
||||
- docs/reviews/storage-architecture-review-2026-04-21.md#S03
|
||||
- docs/architecture/storage/identity.md
|
||||
- docs/decisions/storage-spec-phase1-resolutions.md#D6
|
||||
|
||||
## Notes
|
||||
|
||||
> To be filled by implementation agent
|
||||
|
||||
## Summary
|
||||
|
||||
> To be filled on completion
|
||||
Reference in New Issue
Block a user