i-plane 1.1.0 → 1.1.1

package/docs/api-coverage.md

@@ -27,6 +27,46 @@ The compatibility target uses the `issues/` routes. The current public
 documents `work-items/` instead. A route migration must be verified against the
 target server; do not change paths solely to match a newer documentation release.
 
+## What modules and intake are for
+
+A module groups work toward a feature, milestone or other goal and may span
+several cycles. A cycle is a time window. Work items can belong to multiple
+modules. A module's lead and members are separate from work item assignees.
+The module status describes its overall planning stage; work item states show
+individual progress. See [Plane's module guide](https://docs.plane.so/core-concepts/modules).
+
+Intake is a queue for reports and requests that have not yet been accepted into
+project work. Requests start in Triage with a pending decision. They can be
+accepted, rejected, snoozed or linked to an existing work item as a duplicate.
+This keeps undecided requests out of committed work. See the
+[intake overview](https://docs.plane.so/intake/overview).
+
+| Resource | Plane fields | Current CLI support |
+| --- | --- | --- |
+| Module | Name, description, overall status, start/due dates | `module create` with name, `--description`, `--status`, `--start`, `--due` |
+| Module ownership | Lead and members | Available in the API/UI; not set by this CLI |
+| Module contents | Related work items | `module add`, `module issues`; membership can overlap across modules |
+| Intake request | Title, description, priority | `intake create`; `intake update --name`, `--description`, `--priority` |
+| Intake decision | Pending, rejected, snoozed, accepted, duplicate; snooze deadline; duplicate target | `intake update --status`, `--snooze-until`, `--duplicate-of` |
+| Intake work properties | Assignees, labels, due date and other UI properties | Not exposed by intake commands; use normal `update` after acceptance |
+| Intake channels | In-app submissions, public forms, email | CLI submits through the API; it does not configure forms/email |
+
+The UI guide and API defaults are not interchangeable. The module guide says
+new modules start in Backlog, while the tested API instance returned `planned`
+when status was omitted. CLI examples therefore specify `--status planned`.
+The UI can choose a work item state while accepting an intake request; the
+current CLI/API acceptance path moves it to the default project state. A normal
+`update --state` can then select a different state.
+
+A focused check of the published CLI confirmed that adding a work item to a
+second module preserves its first membership, and that intake acceptance moves
+a request from pending/Triage into the normal Backlog state on the tested
+instance. Temporary check data was deleted.
+
+Field references: [module creation](https://developers.plane.so/api-reference/module/add-module),
+[intake properties](https://docs.plane.so/core-concepts/intake), and
+[intake updates](https://developers.plane.so/api-reference/intake-issue/update-intake-issue-detail).
+
 ## Compatibility details
 
 Enabling intake on project creation requires a follow-up project PATCH to create

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "i-plane",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "CLI \u0434\u043b\u044f Plane \u0441 \u043f\u043b\u043e\u0442\u043d\u044b\u043c \u0432\u044b\u0432\u043e\u0434\u043e\u043c \u043f\u043e\u0434 \u0430\u0433\u0435\u043d\u0442\u0430",
   "type": "module",
   "license": "MIT",