Files
hub/tasks/architecture/storage/document-system-account-email-convention.md
glm-5.1 2b63cda1c7 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.
2026-05-25 10:56:32 +00:00

1.6 KiB

id, name, status, depends_on, scope, risk, impact, level
id name status depends_on scope risk impact level
document-system-account-email-convention Document System Account Email Convention completed
single trivial isolated 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