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.
41 lines
1.7 KiB
Markdown
41 lines
1.7 KiB
Markdown
---
|
|
id: add-account-deactivation
|
|
name: Add Account Deactivation Mechanism
|
|
status: completed
|
|
depends_on: []
|
|
scope: narrow
|
|
risk: low
|
|
impact: component
|
|
level: implementation
|
|
---
|
|
|
|
## Description
|
|
|
|
W02: The `accounts` table has no `enabled`/`suspended` column. Combined with `organizations.ownerId → RESTRICT`, an org owner's account cannot be deleted, and there's no way to deactivate when an employee leaves. Other tables (`api_keys`, `clients`) already have `enabled` columns — add consistency.
|
|
|
|
Add a `status` enum column (`active`/`suspended`/`deactivated`) to the `accounts` table spec. Document how deactivation interacts with cascade constraints and active sessions.
|
|
|
|
## Decision (D5)
|
|
|
|
Use a `status` enum (`active` | `suspended` | `deactivated`), not a boolean. More extensible — allows distinguishing admin-suspended from user-deactivated in the future. This is especially important because RESTRICT cascade on audit_logs.ownerId means accounts with audit entries can never be hard-deleted; deactivation is the path forward.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] `identity.md` accounts table includes `status` pgEnum (`active`/`suspended`/`deactivated`) with NOT NULL default `active`
|
|
- [ ] Interaction with cascade constraints documented (e.g., deactivated accounts can still own orgs but cannot authenticate)
|
|
- [ ] `table-reference.md` updated with the new column
|
|
- [ ] Consistency with `api_keys.enabled` and `clients.enabled` patterns noted
|
|
|
|
## References
|
|
|
|
- docs/reviews/storage-architecture-review-2026-04-21.md#W02
|
|
- docs/decisions/storage-spec-phase1-resolutions.md#D5
|
|
- docs/architecture/storage/identity.md (accounts table)
|
|
|
|
## Notes
|
|
|
|
> To be filled by implementation agent
|
|
|
|
## Summary
|
|
|
|
> To be filled on completion |