@mytegroupinc/myte-core 0.0.46 → 0.0.49

package/README.md

@@ -9,22 +9,43 @@ Most users should install the public wrapper instead:
 
 This package exists so the public wrapper can stay small and versioned cleanly. It is not the recommended public install target.
 
-## Requirements
-
-- Node `18+`
+## Requirements
+
+- Node `18.17+`
 - `MYTE_API_KEY` for project-scoped commands
 - `MYTEAI_API_KEY` for `myte ai`
 - `MYTEAI_API_KEY` for `mytecody`
 - `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.
+- The CLI uses Node built-ins for env loading, argument parsing, direct HTTP,
+  and local serialization. `undici` supplies portable
+  `HTTP_PROXY`/`HTTPS_PROXY`/`NO_PROXY` support across the supported Node
+  versions.
 
 ## Behavior Summary
 
+- `myte doctor --json` performs read-only package, credential-presence, DNS,
+  TCP/TLS, authenticated config, proxy, and workspace checks without exposing
+  keys, proxy values, request bodies, or response bodies.
+- `myte info` and `myte --version --verbose` show the wrapper/core topology,
+  runtime dependencies, expected npm graph size, and version compatibility.
+- Network diagnostics preserve nested transport causes and distinguish DNS,
+  TCP, TLS/certificate, timeout, captive portal/non-JSON, authentication,
+  authorization, rate-limit, and server failures.
+- Safe transient reads and query polling use bounded retries. Query creation
+  reuses one idempotency key across ambiguous retries.
 - Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
-- `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
+- `feedback-sync` prefers stable ObjectId cursor pagination so concurrent
+  inserts cannot shift later pages. It remains compatible with older
+  offset-only API versions and rejects duplicate cross-page records instead of
+  committing an ambiguous local snapshot.
+- `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.
+- `query --with-diff` requires project repos to be configured for diff collection and fails fast when no matching local project repo can be resolved.
+- `query --json` returns the stable request ID, query job ID, answer, context-block count payload, and telemetry without echoing the query text.
 - Public package documentation is intentionally minimal. Internal rollout and design notes are not part of the npm package contract.
 - `mytecody` is a model-agnostic MyteCody team launcher. It supports `doctor`,
   `doctor --probe-gateway`, `update --dry-run`, and `update`. On first coding
@@ -41,15 +62,33 @@ This package exists so the public wrapper can stay small and versioned cleanly.
 
 ## Live Write Approval
 
-Project-key write commands add a server-validated approval envelope only after the caller supplies `--confirm-write --approval-artifact <path>`.
+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>`.
 
-- The approval artifact must be a local `.md`, `.yml`, `.yaml`, or `.json` file shown to and approved by the user.
+| 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 writes must enumerate every item and the CLI sends the matching batch count to the API.
-- The API validates the payload hash after stripping transport metadata, so direct HTTP writes with only the API key do not bypass approval.
-- 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.
+- 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.
+- Without `--document-set`, `create-prd fileA.md fileB.md ...` creates
+  independent Feedback items as before. With `--document-set`, one to three
+  Markdown files of at most 250,000 characters each create one parent Feedback
+  with ordered PRD documents. List every file/title/client ref and the matching
+  count in the approval artifact.
+- 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
 
@@ -57,20 +96,23 @@ 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.
-- 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 `create-prd --document-set` only when the explicit intent is one parent
+  Feedback with one to three ordered documents; omitting it preserves
+  independent multi-file creation.
+- 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/*`.
 
@@ -85,13 +127,29 @@ PRD document contract:
 - The UI renders the PRD from stored PRD text/document content, not from `description`.
 - Renderer-friendly PRDs should use one `# Title`, `##` sections, concise paragraphs, bullets, GitHub tables/checklists where useful, and fenced code blocks only for real code/config.
 - Do not wrap the whole PRD in a ` ```markdown ` fence. Do not use raw HTML, inline style blocks, or decorative banners.
-- PRD identity is explicit: `myte create-prd` creates a PRD asset with PRD metadata. Generic uploaded `.md`, `.docx`, `.pdf`, and `.txt` files remain normal attachments unless explicitly created as PRDs.
+- PRD identity is explicit: `myte create-prd` creates a PRD asset with PRD metadata. Generic uploaded `.md`, `.docx`, `.pdf`, and `.txt` files remain normal attachments unless explicitly created as PRDs.
+- Document sets retain exact source Markdown plus canonical rendering
+  Markdown, stable document IDs, per-document hashes, and independent
+  download/read targets.
+
+## Project Assistant Connectivity
+
+`myte doctor --json` should be the first diagnostic when a command reports
+`fetch failed`. A DNS or TCP result means the request did not reach HTTP. A
+TLS reset means the secure connection was interrupted before Myte could
+receive the API key. Authentication and authorization are reported only when
+the API actually returns those responses.
+
+The CLI honors `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`. It does not log
+their values and does not disable TLS verification. Captive portals and
+intercepting gateways are reported as non-JSON/HTML transport failures rather
+than as malformed Myte API responses.
 
 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
@@ -100,12 +158,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:
 
@@ -171,18 +229,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`.
 
@@ -194,13 +252,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.
-
-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`