Document work area workflow and schema setup

README.md

@@ -114,6 +114,25 @@ optional `projects.plan_data` JSON field; it does not run the full setup script
 or rewrite existing records. Existing projects start with an empty draft, and
 no existing card dates are overwritten.
 
+## Work areas
+
+Each project has its own named work areas. A card can link to one area while
+keeping its independent Kanban column, priority, and plan dates. The board
+shows an area-colored edge and label on linked cards; the area legend filters
+the visible cards. The Plan page shows the same area labels alongside its
+existing priority-colored schedule bars. Existing cards remain uncategorised
+until assigned on their card page.
+
+The quick-add and intake forms ask for an existing area or a new name. New
+areas receive the next unused color from a fixed palette; the color is saved
+on the area record. `work_areas` is related to `projects`, and client reads
+follow the project's client access rule. Client writes are validated by the
+app before using the admin connection.
+
+Run `npm run setup-work-area-schema` with `.env.local` loaded to add only the
+`work_areas` collection and optional `cards.work_area` relation. The same
+schema addition is included in `npm run setup-remote` for new environments.
+
 ## Specs and plans
 
 - `docs/superpowers/specs/` — design documents