@mytegroupinc/myte-core 0.0.28 → 0.0.30

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (7) hide show
  1. package/README.md +210 -196
  2. package/cli.js +6631 -6384
  3. package/lib/ai-gateway.js +115 -115
  4. package/package.json +28 -28
  5. package/scripts/feedback-live-full-harness.js +376 -0
  6. package/scripts/mission-live-disposable-harness.js +226 -226
  7. package/scripts/mission-live-full-harness.js +832 -832
package/README.md CHANGED
@@ -1,196 +1,210 @@
1
- # @mytegroupinc/myte-core
2
-
3
- Implementation package for the `myte` CLI.
4
-
5
- Most users should install the public wrapper instead:
6
-
7
- - `npm install myte`
8
- - run with `npx myte ...`
9
-
10
- This package exists so the public wrapper can stay small and versioned cleanly. It is not the recommended public install target.
11
-
12
- ## Requirements
13
-
14
- - Node `18+`
15
- - `MYTE_API_KEY` for project-scoped commands
16
- - `MYTEAI_API_KEY` for `myte ai`
17
- - `git` only when using `query --with-diff`
18
- - No runtime npm dependencies. The CLI uses Node 18+ built-ins for env loading, argument parsing, HTTP, and local context serialization.
19
-
20
- ## Behavior Summary
21
-
22
- - Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
23
- - `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
24
- - `feedback move|undo|prd-versions|prd-diff|history` calls the project-key Feedback API while leaving lifecycle rules and permissions server-side.
25
- - `feedback validate|apply` remains available for validation and owner-direct apply paths; live authorization, stale checks, and history stay server-side.
26
- - `query --with-diff` requires project repos to be configured for diff collection and fails fast when no matching local project repo can be resolved.
27
- - Public package documentation is intentionally minimal. Internal rollout and design notes are not part of the npm package contract.
28
-
29
- ## Agent Usage Contract
30
-
31
- Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
32
-
33
- - Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
34
- - Call `myte config --json` first when project identity or local repo detection is uncertain.
35
- - Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
36
- - Use `suggestions sync` only when you need to refresh mission review-thread state without refreshing the full board.
37
- - Use `query --with-diff` for project-scoped code review, planning, and implementation questions.
38
- - Use `create-prd` only with reviewed markdown files. The markdown file body is the PRD document; `description` is only the short board/card summary.
39
- - Use `feedback status|edit|assign|archive` for reviewable local artifacts, `feedback submit` for owner review, and `feedback review` for owner/delegate decisions.
40
- - Use `suggestions create` for both existing-mission edits and new-mission proposals. The only valid `change_type` values are `update` and `create`.
41
- - Use `suggestions revise` only against an existing `suggestion_id`; do not send `change_type` on revisions because the backend keeps the thread's original type.
42
- - Use `suggestions review` for owner/elevated mission-review decisions: `approve`, `request_changes`, or `reject`.
43
- - Use `mission archive` for project-key lifecycle archival. Do not send `Archived` through `mission status`; restore archived missions from the web archived-board view.
44
- - Use `feedback move` only when a direct audited state move is intended and include a concrete `--reason`.
45
- - Use `update-team` when an agent needs to leave a project-level implementation note or verification comment.
46
-
47
- Do not use `MYTE_API_KEY` against account/JWT web endpoints. The direct project-key surface is `/api/project-assistant/*`.
48
-
49
- PRD document contract:
50
-
51
- - Always put the complete PRD in the markdown file passed to `myte create-prd`.
52
- - `title` maps to the feedback/board title.
53
- - `description` maps to the short feedback/card summary and must not contain the full PRD.
54
- - Raw markdown uploads send `{ title, description?, prd_markdown }`.
55
- - `myte-kanban` uploads send `{ ticket_markdown }`, where the leading JSON block contains metadata and the remaining markdown is the PRD body.
56
- - The backend stores the markdown as `prd_markdown`, mirrors it as PRD text for search/sync, generates a DOCX attachment from it, and marks `prd_format=markdown`.
57
- - The UI renders the PRD from stored PRD text/document content, not from `description`.
58
-
59
- Feedback comment support:
60
-
61
- - `feedback-sync` includes existing feedback comment turns in local context.
62
- - Feedback-specific comment creation exists in the web backend at `/api/feedbacks/<feedback_id>/comments`, protected by JWT/project assignment.
63
- - There is no project-key CLI command for `myte feedback comment` yet. That requires a Project Assistant feedback-comment route plus npm command before agents should rely on it.
64
-
65
- ## Mission Action Map
66
-
67
- | Action | Command / Surface | Contract |
68
- | --- | --- | --- |
69
- | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
70
- | Sync only mission review threads | `myte suggestions sync --json` | Refreshes `MyteCommandCenter/data/mission-ops.yml` while preserving local workspace drafts. |
71
- | Suggest edit to existing mission | `myte suggestions create` with `change_type: update` and `mission_id` | Creates or appends to an active review thread; live mission is unchanged until approval. |
72
- | Suggest new mission | `myte suggestions create` with `change_type: create` | Requires `change_set.title` and `change_set.description`; creates a review thread only; the mission card is created only after approval. |
73
- | Revise a suggestion | `myte suggestions revise` with `suggestion_id` | Adds another revision to the same thread. Do not include `change_type`. |
74
- | Review a suggestion | `myte suggestions review` with `review_action: approve|request_changes|reject` | Project Owner or elevated mission-review delegate required. Approval mutates/creates the mission once; reject archives the thread only; request_changes keeps it actionable. |
75
- | Update mission status | `myte mission status --mission-ids "M001" --status todo|in_progress|done` | Project-key surface updates canonical mission status for active cards and refreshes local bootstrap + mission-ops by default. |
76
- | Archive mission | `myte mission archive --mission-ids "M001[,M002]" --reason "..."` | Project Owner or elevated delegate required. Sets `Archived`, removes cards from normal bootstrap/board state, writes mission activity, and refreshes local bootstrap + mission-ops by default. |
77
-
78
- Create payloads:
79
-
80
- ```yaml
81
- items:
82
- - change_type: update
83
- mission_id: M001
84
- change_description: Tighten acceptance criteria
85
- change_set:
86
- acceptance_criteria:
87
- - The API returns a stable error code for invalid input.
88
- ```
89
-
90
- ```yaml
91
- items:
92
- - change_type: create
93
- change_description: Add observability mission
94
- change_set:
95
- title: Add mission observability
96
- description: Track mission lifecycle actions with safe audit metadata.
97
- ```
98
-
99
- Revise payload:
100
-
101
- ```yaml
102
- items:
103
- - suggestion_id: 507f1f77bcf86cd799439302
104
- expected_revision: 1
105
- change_description: Revise after review
106
- change_set:
107
- description: Updated proposed mission description.
108
- ```
109
-
110
- YAML note: quote scalar values that contain `:` or other YAML-significant punctuation.
111
-
112
- ## Finding Mission And Suggestion IDs
113
-
114
- Run this first:
115
-
116
- ```powershell
117
- myte bootstrap --json
118
- ```
119
-
120
- Then read:
121
-
122
- | Needed Value | Local Source |
123
- | --- | --- |
124
- | Existing mission business id | `MyteCommandCenter/data/missions/*.yml` -> `mission_id`, for example `M001`. |
125
- | Pending suggestion id | `MyteCommandCenter/data/mission-ops.yml` -> `queue[].suggestion_id` or `threads[].suggestion_id`. |
126
- | Existing suggestion latest revision | `MyteCommandCenter/data/mission-ops.yml` -> `threads[].latest_revision` or `threads[].latest_server_revision.revision`. |
127
- | Existing suggestion review revision | `MyteCommandCenter/data/mission-ops.yml` -> `threads[].review_revision`. |
128
- | Thread type | `MyteCommandCenter/data/mission-ops.yml` -> `threads[].change_type`, either `update` or `create`. |
129
-
130
- Agent rule: never guess `suggestion_id`. If `mission-ops.yml` is missing or stale, run `myte bootstrap --json` again. Use `myte suggestions sync --json` only for a narrow refresh after a mutation.
131
-
132
- ## Feedback Action Map
133
-
134
- | Command | What It Does | Governance |
135
- | --- | --- | --- |
136
- | `feedback-sync` | Pulls feedback metadata, comments, and PRD context into `MyteCommandCenter`. | Read-only project-key API call. |
137
- | `feedback get` | Reads one feedback item's current server snapshot and `snapshot_hash`. | Read-only; backend checks project access. |
138
- | `feedback status` | Creates a local YAML proposal to change canonical lifecycle state. | No live mutation until `submit` and owner/delegate review, except owner-direct `apply`. |
139
- | `feedback edit` / `feedback refine` | Creates a local YAML proposal for title, description/body, priority, due date, tags, or notes. | Content changes go through owner-review membrane. |
140
- | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
141
- | `feedback archive` | Creates a local YAML proposal to archive. | Archive is governed by backend owner/delegate capability. |
142
- | `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Does not mutate live feedback before approval. |
143
- | `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Only valid for the original submitter and `needs_changes` requests. |
144
- | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
145
- | `feedback review` | Approves, rejects, requests changes, or cancels a review request. | Backend restricts approval/review decisions to Project Owner or elevated delegate for Feedback scope. |
146
- | `feedback move` | Moves a card across allowed board states directly with an audit event. | Safe states are direct; governed states such as archive/reject/deploy remain backend-authorized. |
147
- | `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
148
- | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
149
- | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
150
- | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
151
- | `feedback validate` | Sends an artifact to backend validation without mutation. | Useful before submit or owner-direct apply. |
152
- | `feedback apply` | Applies an artifact through the owner-direct/emergency path. | Not the normal collaborator flow; normal flow is `submit` -> `review`. |
153
-
154
- ## Direct Project API Surface
155
-
156
- All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
157
-
158
- Read/sync routes:
159
-
160
- - `GET /api/project-assistant/config`
161
- - `GET /api/project-assistant/bootstrap`
162
- - `GET /api/project-assistant/qaqc-sync`
163
- - `GET /api/project-assistant/feedback-sync`
164
- - `GET /api/project-assistant/feedback/<feedback_id>`
165
- - `GET /api/project-assistant/feedback/<feedback_id>/refinement/history`
166
- - `GET /api/project-assistant/feedback-review-requests`
167
- - `GET /api/project-assistant/feedback-review-requests/<request_id>`
168
- - `GET /api/project-assistant/feedback/<feedback_id>/events`
169
- - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions`
170
- - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions/<version_id>/diff`
171
- - `GET /api/project-assistant/suggestions`
172
- - `GET /api/project-assistant/run-qaqc/<batch_id>`
173
-
174
- Mutation routes:
175
-
176
- - `POST /api/project-assistant/query`
177
- - `POST /api/project-assistant/run-qaqc`
178
- - `POST /api/project-assistant/mission-status-update`
179
- - `POST /api/project-assistant/mission-archive`
180
- - `POST /api/project-assistant/project-comment`
181
- - `POST /api/project-assistant/update-owner`
182
- - `POST /api/project-assistant/client-update-drafts`
183
- - `POST /api/project-assistant/create-prd`
184
- - `POST /api/project-assistant/create-prds`
185
- - `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
186
- - `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
187
- - `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
188
- - `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`
189
- - `POST /api/project-assistant/feedback-review-requests/<request_id>/review`
190
- - `POST /api/project-assistant/feedback-review-requests/<request_id>/request-changes`
191
- - `POST /api/project-assistant/feedback-review-requests/<request_id>/cancel`
192
- - `POST /api/project-assistant/feedback/<feedback_id>/board-move`
193
- - `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
194
- - `POST /api/project-assistant/suggestions`
195
- - `POST /api/project-assistant/suggestions/revise`
196
- - `POST /api/project-assistant/suggestions/review`
1
+ # @mytegroupinc/myte-core
2
+
3
+ Implementation package for the `myte` CLI.
4
+
5
+ Most users should install the public wrapper instead:
6
+
7
+ - `npm install myte`
8
+ - run with `npx myte ...`
9
+
10
+ This package exists so the public wrapper can stay small and versioned cleanly. It is not the recommended public install target.
11
+
12
+ ## Requirements
13
+
14
+ - Node `18+`
15
+ - `MYTE_API_KEY` for project-scoped commands
16
+ - `MYTEAI_API_KEY` for `myte ai`
17
+ - `git` only when using `query --with-diff`
18
+ - No runtime npm dependencies. The CLI uses Node 18+ built-ins for env loading, argument parsing, HTTP, and local context serialization.
19
+
20
+ ## Behavior Summary
21
+
22
+ - Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
23
+ - `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
24
+ - `feedback move|undo|prd-versions|prd-diff|history` calls the project-key Feedback API while leaving lifecycle rules and permissions server-side. `feedback move --feedback-ids` sends one batch move request.
25
+ - `feedback validate|apply` remains available for validation and owner-direct apply paths; live authorization, stale checks, and history stay server-side.
26
+ - `query --with-diff` requires project repos to be configured for diff collection and fails fast when no matching local project repo can be resolved.
27
+ - Public package documentation is intentionally minimal. Internal rollout and design notes are not part of the npm package contract.
28
+
29
+ ## Agent Usage Contract
30
+
31
+ Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
32
+
33
+ - Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
34
+ - Call `myte config --json` first when project identity or local repo detection is uncertain.
35
+ - Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
36
+ - Use `suggestions sync` only when you need to refresh mission review-thread state without refreshing the full board.
37
+ - Use `query --with-diff` for project-scoped code review, planning, and implementation questions.
38
+ - Use `create-prd` only with reviewed markdown files. The markdown file body is the PRD document; `description` is only the short board/card summary.
39
+ - Use `feedback status|edit|assign|archive` for reviewable local artifacts, `feedback submit` for owner review, and `feedback review` for owner/delegate decisions.
40
+ - Use `feedback review --request-ids` for batch owner/delegate decisions; it sends one grouped backend batch, not one request per item.
41
+ - Use `suggestions create` for both existing-mission edits and new-mission proposals. The only valid `change_type` values are `update` and `create`.
42
+ - Use `suggestions revise` only against an existing `suggestion_id`; do not send `change_type` on revisions because the backend keeps the thread's original type.
43
+ - Use `suggestions review` for owner/elevated mission-review decisions: `approve`, `request_changes`, or `reject`.
44
+ - Use `mission archive` for project-key lifecycle archival. Do not send `Archived` through `mission status`; restore archived missions from the web archived-board view.
45
+ - Use `feedback move` only when a direct audited state move is intended and include a concrete `--reason`. Use `--feedback-ids` for batch active-state moves or authorized batch archive.
46
+ - Do not use the project-key API/CLI to unarchive Feedback. Normal `feedback-sync` excludes archived Feedback; unarchive from the web archived Feedback view.
47
+ - Use `update-team` when an agent needs to leave a project-level implementation note or verification comment.
48
+
49
+ Do not use `MYTE_API_KEY` against account/JWT web endpoints. The direct project-key surface is `/api/project-assistant/*`.
50
+
51
+ PRD document contract:
52
+
53
+ - Always put the complete PRD in the markdown file passed to `myte create-prd`.
54
+ - `title` maps to the feedback/board title.
55
+ - `description` maps to the short feedback/card summary and must not contain the full PRD.
56
+ - Raw markdown uploads send `{ title, description?, prd_markdown }`.
57
+ - `myte-kanban` uploads send `{ ticket_markdown }`, where the leading JSON block contains metadata and the remaining markdown is the PRD body.
58
+ - The backend stores the markdown as `prd_markdown`, mirrors it as PRD text for search/sync, generates a DOCX attachment from it, and marks `prd_format=markdown`.
59
+ - The UI renders the PRD from stored PRD text/document content, not from `description`.
60
+
61
+ Feedback comment support:
62
+
63
+ - `feedback-sync` includes existing feedback comment turns in local context.
64
+ - Feedback-specific comment creation exists in the web backend at `/api/feedbacks/<feedback_id>/comments`, protected by JWT/project assignment.
65
+ - There is no project-key CLI command for `myte feedback comment` yet. That requires a Project Assistant feedback-comment route plus npm command before agents should rely on it.
66
+
67
+ ## Mission Action Map
68
+
69
+ | Action | Command / Surface | Contract |
70
+ | --- | --- | --- |
71
+ | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
72
+ | Sync only mission review threads | `myte suggestions sync --json` | Refreshes `MyteCommandCenter/data/mission-ops.yml` while preserving local workspace drafts. |
73
+ | Suggest edit to existing mission | `myte suggestions create` with `change_type: update` and `mission_id` | Creates or appends to an active review thread; live mission is unchanged until approval. |
74
+ | Suggest new mission | `myte suggestions create` with `change_type: create` | Requires `change_set.title` and `change_set.description`; creates a review thread only; the mission card is created only after approval. |
75
+ | Revise a suggestion | `myte suggestions revise` with `suggestion_id` | Adds another revision to the same thread. Do not include `change_type`. |
76
+ | Review a suggestion | `myte suggestions review` with `review_action: approve|request_changes|reject` | Project Owner or elevated mission-review delegate required. Approval mutates/creates the mission once; reject archives the thread only; request_changes keeps it actionable. |
77
+ | Update mission status | `myte mission status --mission-ids "M001" --status todo|in_progress|done` | Project-key surface updates canonical mission status for active cards and refreshes local bootstrap + mission-ops by default. |
78
+ | Archive mission | `myte mission archive --mission-ids "M001[,M002]" --reason "..."` | Project Owner or elevated delegate required. Sets `Archived`, removes cards from normal bootstrap/board state, writes mission activity, and refreshes local bootstrap + mission-ops by default. |
79
+
80
+ Create payloads:
81
+
82
+ ```yaml
83
+ items:
84
+ - change_type: update
85
+ mission_id: M001
86
+ change_description: Tighten acceptance criteria
87
+ change_set:
88
+ acceptance_criteria:
89
+ - The API returns a stable error code for invalid input.
90
+ ```
91
+
92
+ ```yaml
93
+ items:
94
+ - change_type: create
95
+ change_description: Add observability mission
96
+ change_set:
97
+ title: Add mission observability
98
+ description: Track mission lifecycle actions with safe audit metadata.
99
+ ```
100
+
101
+ Revise payload:
102
+
103
+ ```yaml
104
+ items:
105
+ - suggestion_id: 507f1f77bcf86cd799439302
106
+ expected_revision: 1
107
+ change_description: Revise after review
108
+ change_set:
109
+ description: Updated proposed mission description.
110
+ ```
111
+
112
+ YAML note: quote scalar values that contain `:` or other YAML-significant punctuation.
113
+
114
+ ## Finding Mission And Suggestion IDs
115
+
116
+ Run this first:
117
+
118
+ ```powershell
119
+ myte bootstrap --json
120
+ ```
121
+
122
+ Then read:
123
+
124
+ | Needed Value | Local Source |
125
+ | --- | --- |
126
+ | Existing mission business id | `MyteCommandCenter/data/missions/*.yml` -> `mission_id`, for example `M001`. |
127
+ | Pending suggestion id | `MyteCommandCenter/data/mission-ops.yml` -> `queue[].suggestion_id` or `threads[].suggestion_id`. |
128
+ | Existing suggestion latest revision | `MyteCommandCenter/data/mission-ops.yml` -> `threads[].latest_revision` or `threads[].latest_server_revision.revision`. |
129
+ | Existing suggestion review revision | `MyteCommandCenter/data/mission-ops.yml` -> `threads[].review_revision`. |
130
+ | Thread type | `MyteCommandCenter/data/mission-ops.yml` -> `threads[].change_type`, either `update` or `create`. |
131
+
132
+ Agent rule: never guess `suggestion_id`. If `mission-ops.yml` is missing or stale, run `myte bootstrap --json` again. Use `myte suggestions sync --json` only for a narrow refresh after a mutation.
133
+
134
+ ## Feedback Action Map
135
+
136
+ | Command | What It Does | Governance |
137
+ | --- | --- | --- |
138
+ | `feedback-sync` | Pulls non-archived feedback metadata, comments, and PRD context into `MyteCommandCenter`. | Read-only project-key API call; archived Feedback is intentionally excluded. |
139
+ | `feedback get` | Reads one feedback item's current server snapshot and `snapshot_hash`. | Read-only; backend checks project access. |
140
+ | `feedback status` | Creates a local YAML proposal to change canonical lifecycle state. | No live mutation until `submit` and owner/delegate review, except owner-direct `apply`. |
141
+ | `feedback edit` / `feedback refine` | Creates a local YAML proposal for title, description/body, priority, due date, tags, or notes. | Content changes go through owner-review membrane. |
142
+ | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
143
+ | `feedback archive` | Creates a local YAML proposal to archive. | Archive is governed by backend owner/delegate capability. |
144
+ | `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Does not mutate live feedback before approval. |
145
+ | `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Only valid for the original submitter and `needs_changes` requests. |
146
+ | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
147
+ | `feedback review` | Approves, rejects, requests changes, or cancels one review request, or a batch with `--request-ids`. | Backend restricts approval/review decisions to Project Owner or elevated delegate for Feedback scope; batch review uses one grouped notification path. |
148
+ | `feedback move` | Moves a card or batch of cards across allowed board states directly with an audit event. | `--feedback-ids` sends one batch request. Blocked with `pending_feedback_review` while an active linked review request exists; governed states such as archive/reject/deploy/freeze remain backend-authorized. Project-key unarchive is not supported. |
149
+ | `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
150
+ | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
151
+ | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
152
+ | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
153
+ | `feedback validate` | Sends an artifact to backend validation without mutation. | Useful before submit or owner-direct apply. |
154
+ | `feedback apply` | Applies an artifact through the owner-direct/emergency path. | Not the normal collaborator flow; normal flow is `submit` -> `review`. |
155
+
156
+ Canonical feedback lifecycle states are `frozen`, `todo`, `in_progress`, `in_review`, `completed`, `deployed`, `rejected`, and `archived`.
157
+
158
+ Reusable live smoke harness after deploy:
159
+
160
+ ```bash
161
+ node ./scripts/feedback-live-full-harness.js --confirm-live --base-url https://api.myte.dev/api
162
+ ```
163
+
164
+ The harness creates five disposable `TEST` feedback items from markdown, verifies batch review and batch board movement, batch archives the disposable items, verifies normal `feedback-sync` excludes archived items, and verifies the project-key surface does not expose Feedback unarchive/restore.
165
+
166
+ ## Direct Project API Surface
167
+
168
+ All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
169
+
170
+ Read/sync routes:
171
+
172
+ - `GET /api/project-assistant/config`
173
+ - `GET /api/project-assistant/bootstrap`
174
+ - `GET /api/project-assistant/qaqc-sync`
175
+ - `GET /api/project-assistant/feedback-sync`
176
+ - `GET /api/project-assistant/feedback/<feedback_id>`
177
+ - `GET /api/project-assistant/feedback/<feedback_id>/refinement/history`
178
+ - `GET /api/project-assistant/feedback-review-requests`
179
+ - `GET /api/project-assistant/feedback-review-requests/<request_id>`
180
+ - `GET /api/project-assistant/feedback/<feedback_id>/events`
181
+ - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions`
182
+ - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions/<version_id>/diff`
183
+ - `GET /api/project-assistant/suggestions`
184
+ - `GET /api/project-assistant/run-qaqc/<batch_id>`
185
+
186
+ Mutation routes:
187
+
188
+ - `POST /api/project-assistant/query`
189
+ - `POST /api/project-assistant/run-qaqc`
190
+ - `POST /api/project-assistant/mission-status-update`
191
+ - `POST /api/project-assistant/mission-archive`
192
+ - `POST /api/project-assistant/project-comment`
193
+ - `POST /api/project-assistant/update-owner`
194
+ - `POST /api/project-assistant/client-update-drafts`
195
+ - `POST /api/project-assistant/create-prd`
196
+ - `POST /api/project-assistant/create-prds`
197
+ - `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
198
+ - `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
199
+ - `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
200
+ - `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`
201
+ - `POST /api/project-assistant/feedback-review-requests/<request_id>/review`
202
+ - `POST /api/project-assistant/feedback-review-requests/batch-review`
203
+ - `POST /api/project-assistant/feedback-review-requests/<request_id>/request-changes`
204
+ - `POST /api/project-assistant/feedback-review-requests/<request_id>/cancel`
205
+ - `POST /api/project-assistant/feedback/<feedback_id>/board-move`
206
+ - `POST /api/project-assistant/feedback/batch-board-move`
207
+ - `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
208
+ - `POST /api/project-assistant/suggestions`
209
+ - `POST /api/project-assistant/suggestions/revise`
210
+ - `POST /api/project-assistant/suggestions/review`