myte 0.0.7 → 0.0.9

package/README.md

@@ -10,23 +10,44 @@ Use one of these flows:
   - `npm install myte`
   - then run `npx myte config --json`
   - then run `npx myte bootstrap`
+  - then run `npx myte run-qaqc --mission-ids M001 --wait --sync`
   - then run `npx myte sync-qaqc`
+  - then run `npx myte feedback-sync`
+  - then run `npx myte suggestions sync`
+  - then run `npx myte suggestions create`
+  - then run `npx myte suggestions revise`
+  - then run `npx myte suggestions review`
   - then run `npx myte query "What changed in logging?" --with-diff`
   - then run `npx myte update-team "Backend deploy completed; QAQC rerun queued."`
+  - then run `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md`
   - then run `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md`
   - or `npm exec myte -- query "What changed in logging?" --with-diff`
 - Global install:
   - `npm i -g myte`
   - then run `myte bootstrap`
+  - then run `myte run-qaqc --mission-ids M001 --wait --sync`
   - then run `myte sync-qaqc`
+  - then run `myte feedback-sync`
+  - then run `myte suggestions sync`
+  - then run `myte suggestions create`
+  - then run `myte suggestions revise`
+  - then run `myte suggestions review`
   - then run `myte query "What changed in logging?" --with-diff`
   - then run `myte update-team "Backend deploy completed; QAQC rerun queued."`
+  - then run `myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md`
   - then run `myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md`
 - No install:
   - `npx myte@latest bootstrap`
+  - `npx myte@latest run-qaqc --mission-ids M001 --wait --sync`
   - `npx myte@latest sync-qaqc`
+  - `npx myte@latest feedback-sync`
+  - `npx myte@latest suggestions sync`
+  - `npx myte@latest suggestions create`
+  - `npx myte@latest suggestions revise`
+  - `npx myte@latest suggestions review`
   - `npx myte@latest query "What changed in logging?" --with-diff`
   - `npx myte@latest update-team "Backend deploy completed; QAQC rerun queued."`
+  - `npx myte@latest update-owner --subject "QAQC progress" --body-file ./updates/owner.md`
   - `npx myte@latest update-client --subject "Weekly client update" --body-file ./updates/week-12.md`
 
 `npm install myte` by itself does not put `myte` on your shell PATH. Use `npx myte` or `npm exec myte -- ...` unless you installed globally.
@@ -75,7 +96,9 @@ What it does:
 - validates the current wrapper workspace against the configured repo names
 - writes local files under `MyteCommandCenter/data`
 - writes a normalized public Command Center schema, not raw backend mission/proposal documents
+- mission cards now include richer execution context like `complexity`, `estimated_hours`, `due_date`, `subtasks`, `technical_requirements`, `resources_needed`, `labels`, and normalized `test_cases`
 - excludes internal fields like `_id`, `org_id`, `project_id`, `created_by`, `assigned_to`, and raw `qa_qc_results`
+- if the workspace still has old Command Center artifacts, rerunning current commands prunes legacy outputs like `bootstrap-manifest.json`, `data/qaqc/`, and `data/feedback/` automatically as the new files are written
 
 Files written:
 - `MyteCommandCenter/data/project.yml`
@@ -83,13 +106,33 @@ Files written:
 - `MyteCommandCenter/data/epics/*.yml`
 - `MyteCommandCenter/data/stories/*.yml`
 - `MyteCommandCenter/data/missions/*.yml`
-- `MyteCommandCenter/data/bootstrap-manifest.json`
 
 Useful forms:
 - `npx myte bootstrap --json`
 - `npx myte bootstrap --dry-run --json`
 - `npx myte bootstrap --output-dir ./MyteCommandCenter`
 
+## Queue mission QAQC and refresh local QAQC context
+
+Run this from any workspace with a valid project key:
+
+- `npx myte run-qaqc --mission-ids M001,M002 --wait --sync`
+- or `npm exec myte -- run-qaqc --mission-ids M001,M002 --wait --sync`
+- or `myte run-qaqc --mission-ids M001,M002 --wait --sync`
+
+What it does:
+- queues QAQC for up to 10 explicit mission ids through the project-key API surface
+- returns a `batch_id` immediately
+- uses `--wait` to poll the batch until it reaches a terminal state
+- uses `--sync` to refresh `MyteCommandCenter/data/qaqc.yml` after a completed batch
+- runs through the dedicated `project_api_qaqc` queue inside the existing Celery service, with a global budget of `20` dispatch starts/minute and `20` live jobs
+- a saturated `run-qaqc --wait` batch can take roughly `5-10` minutes before sync has final data to pull
+
+Useful forms:
+- `npx myte run-qaqc --mission-ids M001`
+- `npx myte run-qaqc --mission-ids M001,M002 --wait`
+- `npx myte run-qaqc --mission-ids M001,M002 --wait --sync --json`
+
 ## Sync active mission QAQC context
 
 Run this from the wrapper root that contains the project's repo folders:
@@ -101,23 +144,85 @@ Run this from the wrapper root that contains the project's repo folders:
 What it does:
 - fetches a project-scoped QAQC sync snapshot from the API using your project key
 - works even if `bootstrap` has not been run yet
-- creates `MyteCommandCenter/data/qaqc` automatically if it does not exist
+- creates `MyteCommandCenter/data/qaqc.yml` automatically if it does not exist
 - syncs only active `Todo` and `In Progress` missions
 - writes a public QAQC summary per mission, not raw `qa_qc_results` or raw batch docs
-- removes previously QAQC-managed mission files from `MyteCommandCenter/data/missions` when they are no longer active
+- keeps active mission QAQC state in one deterministic file that grows and shrinks with the current working set
+- fully rewrites `MyteCommandCenter/data/qaqc.yml` on every sync and does not delete `MyteCommandCenter/data/missions/*.yml`
 
 Files written:
 - `MyteCommandCenter/data/project.yml`
-- `MyteCommandCenter/data/missions/<mission_id>.yml` for active missions
-- `MyteCommandCenter/data/qaqc/active-missions/<mission_id>.yml`
-- `MyteCommandCenter/data/qaqc/manifest.json`
-- `MyteCommandCenter/data/qaqc/latest-batch.json`
+- `MyteCommandCenter/data/qaqc.yml`
 
 Useful forms:
 - `npx myte sync-qaqc --json`
 - `npx myte sync-qaqc --dry-run --json`
 - `npx myte sync-qaqc --output-dir ./MyteCommandCenter`
 
+## Sync open feedback and PRD context
+
+Run this from the wrapper root that contains the project's repo folders:
+
+- `npx myte feedback-sync`
+- or `npm exec myte -- feedback-sync`
+- or `myte feedback-sync`
+
+What it does:
+- fetches a project-scoped feedback snapshot from the API using your project key
+- defaults to open `Pending` feedback
+- writes one deterministic feedback snapshot under `MyteCommandCenter/data/feedback.yml`
+- includes readable PRD markdown inline when available
+- fully replaces the aggregated feedback sync file so stale feedback does not accumulate locally
+- does not delete `MyteCommandCenter/data/missions/*.yml`
+
+Files written:
+- `MyteCommandCenter/data/project.yml`
+- `MyteCommandCenter/data/feedback.yml`
+
+Useful forms:
+- `npx myte feedback-sync --json`
+- `npx myte feedback-sync --dry-run --json`
+- `npx myte feedback-sync --status Pending --source User`
+
+## Sync and iterate on mission suggestions
+
+- `npx myte suggestions sync`
+- or `npm exec myte -- suggestions sync`
+- or `myte suggestions sync`
+
+What it does:
+- fetches the project suggestion workflow snapshot with the project API key
+- writes one deterministic workflow file at `MyteCommandCenter/data/mission-ops.yml`
+- keeps active first-come-first-serve queue state in `queue`
+- keeps full lineage for active and terminal items in `threads[]`
+- `suggestions sync` should be the first step before ideating locally so new submissions start from the latest aggregated thread state
+- preserves top-level `workspace.<actor_scope>` blocks and per-thread `workspace.<actor_scope>` drafts across sync so coding agents can keep local drafts in one file
+- synced `threads[]` include aggregate diffs, conflict summaries, and archived decision lineage so local agents do not need to reconstruct review state
+
+Create/revise/review:
+- `npx myte suggestions create --file ./changes/create.yml`
+- `npx myte suggestions revise --file ./changes/revise.yml`
+- `npx myte suggestions review --file ./changes/review.yml`
+
+Local single-file mode:
+- `suggestions create` can read local `workspace.<actor_scope>.draft_submissions[]` from `mission-ops.yml`
+- `suggestions revise` can read local per-thread `workspace.<actor_scope>` draft blocks when `draft_status` is `submit`, `ready`, or `pending_submit`
+- `suggestions review` is owner-only and can read local per-thread owner review blocks using `review_action`, `review_note`, `final_change_set`, and `review_revision`
+- `suggestions review` requires an explicit `review_action` of `request_changes`, `approve`, or `reject`
+- there is no persisted save-draft review action
+- suggestion notifications deep-link into the project Reviews workspace for the affected thread
+- create/revise/review resync `mission-ops.yml` by default unless `--no-sync` is passed
+- create/revise/review auto-send idempotency and client-session metadata so retries stay deterministic without manual headers
+- `--print-context` prints the JSON payload that would be submitted for create/revise/review
+- after successful review approvals, the CLI rewrites the affected `MyteCommandCenter/data/missions/*.yml` cards automatically
+
+Useful forms:
+- `npx myte suggestions sync --json`
+- `npx myte suggestions create --file ./changes/create.yml --json`
+- `npx myte suggestions create`
+- `npx myte suggestions revise`
+- `npx myte suggestions review`
+
 ## Query with deterministic diff context
 
 Example:
@@ -150,7 +255,9 @@ Examples:
 
 - File path:
   - `npx myte create-prd ./drafts/auth-prd.md`
+  - `npx myte create-prd ./drafts/auth-prd.md ./drafts/billing-prd.md`
   - or `npm exec myte -- create-prd ./drafts/auth-prd.md`
+  - or `npm exec myte -- create-prd ./drafts/auth-prd.md ./drafts/billing-prd.md`
   - or `npx myte@latest create-prd ./drafts/auth-prd.md`
 - From stdin on macOS/Linux:
   - `cat ./drafts/auth-prd.md | npx myte create-prd --stdin`
@@ -184,14 +291,17 @@ Raw markdown also works:
 
 Deterministic field mapping:
 - Required: a valid project API key, the PRD markdown body, and a title.
+- One command can upload one file or many files. Single uploads hit `/project-assistant/create-prd`; multi-file uploads automatically use the batch upload path.
 - `title` maps to the feedback title.
 - `description` maps to the feedback description/card summary. Legacy `feedback_text` is still accepted for older payloads.
-- The markdown body after the metadata block, or the full raw markdown file when no metadata block is used, is stored verbatim as PRD content.
+- The context blob that becomes the stored PRD document is the full `prd_markdown`, or the markdown body after the `myte-kanban` metadata block when using `ticket_markdown`.
+- That PRD markdown blob is stored verbatim as PRD content.
 - The backend uses that stored PRD markdown/text to generate the downloadable PRD DOCX.
 - Additional structured fields should go in the `myte-kanban` JSON block. Supported keys include `priority`, `status`, `tags`, `assigned_user_email`, `assigned_user_id`, `due_date`, `repo_name`, `repo_id`, `preview_url`, and `source`.
 
 To inspect the exact payload before sending it:
 - `npx myte create-prd ./drafts/auth-prd.md --print-context`
+- `npx myte create-prd ./drafts/auth-prd.md ./drafts/billing-prd.md --print-context`
 - `npx myte create-prd ./drafts/auth-prd.md --description "Short card summary" --print-context`
 
 ## Team updates
@@ -214,6 +324,27 @@ Useful forms:
 - `npx myte update-team "Backend deploy completed." --print-context`
 - `npx myte update-team "Backend deploy completed." --json`
 
+## Owner updates
+
+Use `update-owner` to send a direct project-owner email through the project-key Project Assistant surface.
+
+Examples:
+
+- `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md`
+- `npx myte update-owner --subject "Board cleanup needed" --body-markdown "## Status\n- Phase 2 review pending"`
+- `Get-Content -Raw .\updates\owner.md | npx myte update-owner --stdin --subject "Owner update"`
+
+What it sends:
+
+- `POST /api/project-assistant/update-owner`
+- payload: `{ "subject": "...", "body_markdown": "..." }`
+
+Notes:
+
+- the owner recipient is resolved from the authenticated project
+- the CLI cannot set an arbitrary recipient address
+- the backend sends the email through Myte SMTP and stores a durable send record
+
 ## Client update drafts
 
 Use `update-client` to draft a branded client update email for owner review.
@@ -242,8 +373,14 @@ Notes:
 - `npm install myte`
 - `npx myte bootstrap`
 - `npx myte sync-qaqc`
+- `npx myte feedback-sync`
+- `npx myte suggestions sync`
+- `npx myte suggestions create --file ./changes/create.yml`
+- `npx myte suggestions revise`
+- `npx myte suggestions review`
 - `npx myte config --json`
 - `npx myte query "Summarize the current branch changes" --with-diff`
 - `npx myte create-prd ./drafts/auth-prd.md`
 - `npx myte update-team "Backend deploy completed; QAQC rerun queued."`
+- `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md`
 - `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "myte",
-  "version": "0.0.7",
+  "version": "0.0.9",
   "description": "Myte developer CLI (Project Assistant + deterministic diffs).",
   "type": "commonjs",
   "license": "MIT",
@@ -16,6 +16,6 @@
     "node": ">=18"
   },
   "dependencies": {
-    "@mytegroupinc/myte-core": "0.0.7"
+    "@mytegroupinc/myte-core": "0.0.9"
   }
 }