@mytegroupinc/myte-core 0.0.45 → 0.0.47

package/README.md

@@ -18,11 +18,13 @@ This package exists so the public wrapper can stay small and versioned cleanly.
 - `git` only when using `query --with-diff`
 - No runtime npm dependencies. The CLI uses Node 18+ built-ins for env loading, argument parsing, HTTP, and local context serialization.
 
-## Behavior Summary
-
-- Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
-- Live project-key mutations require explicit user approval before the CLI sends them. Create a local approval artifact, show it to the user, then rerun with `--confirm-write --approval-artifact <path>`.
-- `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
+## Behavior Summary
+
+- Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
+- `feedback status|edit|assign|archive|refine` writes reviewable local YAML artifacts.
+- `feedback submit|revise|comment` are live writes that require `--confirm-write --approval-artifact <path>`.
+- `feedback review|move|undo|apply` are governed writes with backend permission checks but no approval artifact flags.
+- `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate` are read/sync/validation commands with no approval artifact flags.
 - `feedback move|comment|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.
 - `feedback validate|apply` remains available for validation and owner-direct apply paths; live authorization, stale checks, and history stay server-side.
 - `query --with-diff` requires project repos to be configured for diff collection and fails fast when no matching local project repo can be resolved.
@@ -35,13 +37,36 @@ This package exists so the public wrapper can stay small and versioned cleanly.
   gateway, and `MYTEAI_API_KEY`. Normal coding runs use the branded Codex
   harness with Myte context hardening; the experimental controller is not the
   default product path.
-- `mytecody doctor` reports both the signed MyteCody engine state and this npm
-  package version. `mytecody update` updates the engine only. Use
-  `npm install -g myte@latest` to update the launcher and the Myte API CLI
-  commands shipped by npm.
-- The package does not bundle the large MyteCody engine binary or the async
-  Responses bridge implementation. See `THIRD_PARTY_NOTICES.md` and
-  `TRADEMARKS.md` for Codex lineage and Myte brand notices.
+- `mytecody doctor` reports both the signed MyteCody engine state and this npm
+  package version. `mytecody update` updates the engine only. Use
+  `npm install -g myte@latest` to update the launcher and the Myte API CLI
+  commands shipped by npm.
+
+## Live Write Approval
+
+Only selected project-key writes require a server-validated approval envelope. The CLI adds `write_approval` metadata only for those commands after the caller supplies `--confirm-write --approval-artifact <path>`.
+
+| Category | Commands | Artifact |
+| --- | --- | --- |
+| Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `suggestions create`, `suggestions revise` | Yes |
+| Not required | `run-qaqc`, `mission status`, `mission archive`, `suggestions review`, `feedback review`, `feedback move`, `feedback undo`, `feedback apply` | No |
+| Never required | `config`, `query`, `bootstrap`, `sync-qaqc`, `feedback-sync`, `suggestions sync`, `feedback get/history/reviews/prd-versions/prd-diff/validate`, local feedback draft commands | No |
+
+- The approval artifact must be a local `.md`, `.markdown`, `.yml`, `.yaml`, or `.json` file shown to and approved by the user.
+- The artifact must list the exact operation, proposed change, and every target id or PRD item.
+- Batch artifacts for required actions must enumerate every item and the CLI sends the matching batch count to the API.
+- For required actions, the API validates the payload hash after stripping transport metadata, so direct HTTP writes with only the API key do not bypass approval.
+- For actions marked `Not required`, the backend still enforces project-key authentication, idempotency, owner/delegate capability rules, stale-state guards, validation, rate limits, and audit history.
+- In plain language, the artifact is the human-reviewed record of the exact write the agent is about to send. It is not a permission grant and it does not bypass project owner/delegate checks, idempotency, stale-state guards, validation, or audit.
+- Minimum artifact contents are the exact command, every target id or PRD item, a complete proposed-change summary, a reason, and `batch_count` when one command sends multiple items.
+- Mission edit/create batches use `suggestions create` or `suggestions revise`; list every item, including `change_type`, `mission_id` for updates, proposed title/description for creates, and `suggestion_id` plus expected revision for revisions.
+- PRD batches use one `create-prd fileA.md fileB.md ...`; list each PRD file/title/client ref and make `batch_count` match the number of PRDs.
+- Feedback submit/revise/comment artifacts are usually the same YAML or markdown file being submitted. For inline text or stdin, use a separate approval memo with the feedback id or request id and exact content.
+- Team, owner, and client update artifacts should name the audience and include the exact message body or a complete summary. Client updates should include target contact ids when used.
+- `feedback review --request-ids`, `feedback move --feedback-ids`, `mission status --mission-ids`, `mission archive --mission-ids`, and `run-qaqc --mission-ids` are batched governed writes, but they are marked `Not required` and should not receive approval artifact flags.
+- The package does not bundle the large MyteCody engine binary or the async
+  Responses bridge implementation. See `THIRD_PARTY_NOTICES.md` and
+  `TRADEMARKS.md` for Codex lineage and Myte brand notices.
 
 ## Agent Usage Contract
 
@@ -49,24 +74,20 @@ Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant
 
 - Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
 - Call `myte config --json` first when project identity or local repo detection is uncertain.
-- Before any live write, create a local approval artifact, show it to the user, and get explicit approval. Use `.md` for comments, human updates, and PRD markdown; use `.yml`/`.yaml` or `.json` for structured mission/feedback decisions and batch writes.
-- After approval, rerun the mutation with `--confirm-write --approval-artifact <path>`. Batch artifacts must enumerate every feedback id, mission id, suggestion id, request id, or PRD item.
-- Direct HTTP calls with `MYTE_API_KEY` cannot bypass this gate on live project-content mutations. The API returns `428` with agent instructions when approval metadata is missing or mismatched.
-- Read/sync/query/validate commands, `--print-context`, and `--dry-run` do not require write approval.
-- Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
+- Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards, mission suggestion thread state, and `MyteCommandCenter/AgentsMyteAPI.md`.
 - Use `suggestions sync` only when you need to refresh mission review-thread state without refreshing the full board.
 - Use `query --with-diff` for project-scoped code review, planning, and implementation questions.
-- Use `create-prd` only with reviewed markdown files. The markdown file body is the PRD document; `description` is only the short board/card summary.
-- Use `feedback status|edit|assign|archive` for reviewable local artifacts, `feedback submit` for owner review, and `feedback review` for owner/delegate decisions.
+- Use `create-prd` only with reviewed markdown files and `--confirm-write --approval-artifact <path>`. The markdown file body is the PRD document; `description` is only the short board/card summary.
+- Use `feedback status|edit|assign|archive|refine` for reviewable local artifacts. `feedback submit` and `feedback revise` require an approval artifact; `feedback review` does not because the backend owner/delegate decision is the approval control.
 - Use `feedback review --request-ids` for batch owner/delegate decisions; it sends one grouped backend batch, not one request per item.
-- Use `suggestions create` for both existing-mission edits and new-mission proposals. The only valid `change_type` values are `update` and `create`.
-- 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.
-- Use `suggestions review` for owner/elevated mission-review decisions: `approve`, `request_changes`, or `reject`.
+- Use `suggestions create` for both existing-mission edits and new-mission proposals, with `--confirm-write --approval-artifact <path>`. The only valid `change_type` values are `update` and `create`.
+- Use `suggestions revise` only against an existing `suggestion_id`, with `--confirm-write --approval-artifact <path>`; do not send `change_type` on revisions because the backend keeps the thread's original type.
+- Use `suggestions review` for owner/elevated mission-review decisions: `approve`, `request_changes`, or `reject`. No approval artifact is required for review decisions.
 - Use `mission archive` for project-key lifecycle archival. Do not send `Archived` through `mission status`; restore archived missions from the web archived-board view.
 - 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.
-- Use `feedback comment --feedback-id <id> --body-file ./comment.md` for text-only feedback-specific implementation notes. Attachments remain web UI only for this project-key endpoint.
+- Use `feedback comment --feedback-id <id> --body-file ./comment.md --confirm-write --approval-artifact ./comment.md` for text-only feedback-specific implementation notes. Attachments remain web UI only for this project-key endpoint.
 - Do not use the project-key API/CLI to unarchive Feedback. Normal `feedback-sync` excludes archived Feedback; unarchive from the web archived Feedback view.
-- Use `update-team` when an agent needs to leave a project-level implementation note or verification comment.
+- Use `update-team --confirm-write --approval-artifact <path>` when an agent needs to leave a project-level implementation note or verification comment.
 
 Do not use `MYTE_API_KEY` against account/JWT web endpoints. The direct project-key surface is `/api/project-assistant/*`.
 
@@ -87,7 +108,7 @@ Feedback comment support:
 
 - `feedback-sync` includes existing feedback comment turns in local context.
 - Feedback-specific comment creation exists in the web backend at `/api/feedbacks/<feedback_id>/comments`, protected by JWT/project assignment.
-- Project-key comment creation is available through `myte feedback comment --feedback-id <id> --body "..."` or `--body-file ./comment.md`.
+- Project-key comment creation is available through `myte feedback comment --feedback-id <id> --body "..." --confirm-write --approval-artifact ./comment.md` or `--body-file ./comment.md --confirm-write --approval-artifact ./comment.md`.
 - The project-key feedback comment endpoint is text-only in this slice and caps content at 500,000 characters. Use the web UI when comment attachments are required.
 
 ## Mission Action Map
@@ -96,12 +117,12 @@ Feedback comment support:
 | --- | --- | --- |
 | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
 | Sync only mission review threads | `myte suggestions sync --json` | Refreshes `MyteCommandCenter/data/mission-ops.yml` while preserving local workspace drafts. |
-| 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. |
-| 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. |
-| Revise a suggestion | `myte suggestions revise` with `suggestion_id` | Adds another revision to the same thread. Do not include `change_type`. |
-| 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. |
-| 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. |
-| 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. |
+| Suggest edit to existing mission | `myte suggestions create --file ./create.yml --confirm-write --approval-artifact ./create.yml` with `change_type: update` and `mission_id` | Creates or appends to an active review thread; live mission is unchanged until approval. |
+| Suggest new mission | `myte suggestions create --file ./create.yml --confirm-write --approval-artifact ./create.yml` 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. |
+| Revise a suggestion | `myte suggestions revise --file ./revise.yml --confirm-write --approval-artifact ./revise.yml` with `suggestion_id` | Adds another revision to the same thread. Do not include `change_type`. |
+| Review a suggestion | `myte suggestions review` with `review_action: approve|request_changes|reject` | Project Owner or elevated mission-review delegate required; no approval artifact required. Approval mutates/creates the mission once; reject archives the thread only; request_changes keeps it actionable. |
+| Update mission status | `myte mission status --mission-ids "M001" --status todo|in_progress|done` | Project-key surface updates canonical mission status for active cards; no approval artifact required; refreshes local bootstrap + mission-ops by default. |
+| Archive mission | `myte mission archive --mission-ids "M001[,M002]" --reason "..."` | Project Owner or elevated delegate required; no approval artifact required. Sets `Archived`, removes cards from normal bootstrap/board state, writes mission activity, and refreshes local bootstrap + mission-ops by default. |
 
 Create payloads:
 
@@ -167,18 +188,18 @@ Agent rule: never guess `suggestion_id`. If `mission-ops.yml` is missing or stal
 | `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. |
 | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
 | `feedback archive` | Creates a local YAML proposal to archive. | Archive is governed by backend owner/delegate capability. |
-| `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Does not mutate live feedback before approval. |
-| `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Only valid for the original submitter and `needs_changes` requests. |
+| `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Requires `--confirm-write --approval-artifact <path>`; does not mutate live feedback before approval. |
+| `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Requires `--confirm-write --approval-artifact <path>`; only valid for the original submitter and `needs_changes` requests. |
 | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
-| `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. |
-| `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. |
-| `feedback comment` | Creates a text-only comment on one Feedback item. | Backend checks project-key access, owner/assigned permission, idempotency, and the 500,000-character content cap. Attachments remain web UI only. |
-| `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
+| `feedback review` | Approves, rejects, requests changes, or cancels one review request, or a batch with `--request-ids`. | No approval artifact required; backend restricts approval/review decisions to Project Owner or elevated delegate for Feedback scope; batch review uses one grouped notification path. |
+| `feedback move` | Moves a card or batch of cards across allowed board states directly with an audit event. | No approval artifact required. `--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. |
+| `feedback comment` | Creates a text-only comment on one Feedback item. | Requires `--confirm-write --approval-artifact <path>`; backend checks project-key access, owner/assigned permission, idempotency, and the 500,000-character content cap. Attachments remain web UI only. |
+| `feedback undo` | Reverses an audited board event when there is no conflict. | No approval artifact required; backend validates event ownership/project scope and conflict state. |
 | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
 | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
 | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
 | `feedback validate` | Sends an artifact to backend validation without mutation. | Useful before submit or owner-direct apply. |
-| `feedback apply` | Applies an artifact through the owner-direct/emergency path. | Not the normal collaborator flow; normal flow is `submit` -> `review`. |
+| `feedback apply` | Applies an artifact through the owner-direct/emergency path. | No approval artifact required; not the normal collaborator flow; normal flow is `submit` -> `review`. |
 
 Canonical feedback lifecycle states are `frozen`, `todo`, `in_progress`, `in_review`, `completed`, `deployed`, `rejected`, and `archived`.
 
@@ -190,13 +211,16 @@ node ./scripts/feedback-live-full-harness.js --confirm-live --base-url https://a
 
 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.
 
-## Direct Project API Surface
-
-All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes. Live project-content mutation routes also require write-approval headers; the official CLI supplies them from `--confirm-write --approval-artifact <path>`.
-
-Read/sync routes:
-
-- `GET /api/project-assistant/config`
+## Direct Project API Surface
+
+All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
+
+`myte ai` is separate from this project-scoped surface. It uses `MYTEAI_API_KEY` and calls `POST https://api.myte.ai/v1/chat/completions`, or `${MYTEAI_API_BASE}/v1/chat/completions` when that base is configured.
+
+Read/sync routes:
+
+- `GET /api/project-assistant/query/<job_id>`
+- `GET /api/project-assistant/config`
 - `GET /api/project-assistant/bootstrap`
 - `GET /api/project-assistant/qaqc-sync`
 - `GET /api/project-assistant/feedback-sync`
@@ -209,11 +233,10 @@ Read/sync routes:
 - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions/<version_id>/diff`
 - `GET /api/project-assistant/suggestions`
 - `GET /api/project-assistant/run-qaqc/<batch_id>`
-- `POST /api/project-assistant/query`
-- `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
 
-Live project-content mutation routes:
+Mutation routes:
 
+- `POST /api/project-assistant/query`
 - `POST /api/project-assistant/run-qaqc`
 - `POST /api/project-assistant/mission-status-update`
 - `POST /api/project-assistant/mission-archive`
@@ -222,6 +245,7 @@ Live project-content mutation routes:
 - `POST /api/project-assistant/client-update-drafts`
 - `POST /api/project-assistant/create-prd`
 - `POST /api/project-assistant/create-prds`
+- `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
 - `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
 - `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
 - `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`

package/THIRD_PARTY_NOTICES.md

@@ -1,21 +1,21 @@
-# Third-Party Notices
-
-This package includes the Myte CLI launcher and MyteCody distribution client.
-
-The branded MyteCody engine installed by the launcher is derived from the
-OpenAI Codex open-source project. OpenAI Codex is licensed under the
-Apache License, Version 2.0.
-
-Source lineage tracked for this slice:
-
-- Project: OpenAI Codex
-- Version baseline: `0.139.0`
-- License: Apache-2.0
-- Upstream: https://github.com/openai/codex
-
-The MyteCody engine and signed client assets are distributed separately from
-this npm package through a Myte release manifest. This package verifies release
-artifacts before installing them into the user's Myte-owned local cache.
-
-Myte names, marks, logos, terminal branding, and product design are not part of
-the OpenAI Codex project and remain Myte-owned brand assets.
+# Third-Party Notices
+
+This package includes the Myte CLI launcher and MyteCody distribution client.
+
+The branded MyteCody engine installed by the launcher is derived from the
+OpenAI Codex open-source project. OpenAI Codex is licensed under the
+Apache License, Version 2.0.
+
+Source lineage tracked for this slice:
+
+- Project: OpenAI Codex
+- Version baseline: `0.139.0`
+- License: Apache-2.0
+- Upstream: https://github.com/openai/codex
+
+The MyteCody engine and signed client assets are distributed separately from
+this npm package through a Myte release manifest. This package verifies release
+artifacts before installing them into the user's Myte-owned local cache.
+
+Myte names, marks, logos, terminal branding, and product design are not part of
+the OpenAI Codex project and remain Myte-owned brand assets.

package/TRADEMARKS.md

@@ -1,10 +1,10 @@
-# Trademarks
-
-Myte, Myte AI, MyteCody, "MYTE CODY - Your Tech Your Way", logo assets, terminal
-animation assets, and related product branding are Myte-owned marks and brand
-assets.
-
-OpenAI and Codex are trademarks or project names of their respective owners.
-MyteCody uses a Codex-derived open-source engine under the applicable open
-source license, but MyteCody is a Myte product surface and is not presented as
-an official OpenAI product.
+# Trademarks
+
+Myte, Myte AI, MyteCody, "MYTE CODY - Your Tech Your Way", logo assets, terminal
+animation assets, and related product branding are Myte-owned marks and brand
+assets.
+
+OpenAI and Codex are trademarks or project names of their respective owners.
+MyteCody uses a Codex-derived open-source engine under the applicable open
+source license, but MyteCody is a Myte product surface and is not presented as
+an official OpenAI product.