feat: add organization domain foundation

docs/FEATURES/organizations.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Draft
+Ready for initial backend implementation.
 
 ## Goal
 
@@ -173,6 +173,32 @@ Workspace-level screens remain centered on the selected workspace.
 - Workspace APIs must preserve workspace scoping and account for inherited organization permissions.
 - New backend contracts require OpenAPI regeneration while the backend is running.
 
+## Implementation Readiness
+
+The initial implementation should proceed through the task files in `docs/TASKS/organizations/`.
+
+Recommended order:
+
+1. `001-organization-domain-foundation.md`
+2. `002-organization-membership-permissions.md`
+3. `003-organization-settings-ui.md`
+4. `004-workspace-selector-organization-switcher.md`
+
+Task 001 should establish the organization table, workspace ownership, current-user organization read APIs, and development bootstrap data. It should not attempt the full inherited permission model beyond enough access data to prove a user can access their organizations.
+
+Task 002 should introduce organization memberships and explicit organization permissions before frontend settings or switcher work relies on permission-gated data.
+
+Frontend tasks should start only after backend contracts have been regenerated into `shared/openapi/openapi.json` and `frontend/src/api/schema.d.ts`.
+
+Initial backend routes:
+
+```txt
+GET /api/organizations
+GET /api/organizations/{organizationId}
+```
+
+Workspace responses should include `organizationId` once workspaces are owned by organizations.
+
 ## Out Of Scope For Initial Implementation
 
 - Preserving existing local data through migration. Development data can be wiped.