myte

Canonical npm package for the Myte CLI.

Install

Local install:

• npm install myte
• run with npx myte ...
• or npm exec myte -- ...

Global install:

• npm i -g myte
• run with myte ...

No install:

• npx myte@latest ...

npm install myte does not add myte to your shell PATH. Use npx myte or npm exec myte -- ... unless you installed globally.

The npm line added N packages is a dependency-graph count, not a count of files or Myte features. The public myte package is a small command wrapper, @mytegroupinc/myte-core contains the CLI implementation, and undici provides portable proxy support. A fresh install therefore normally contains three graph nodes; npm may report fewer on an update when dependencies are already present or deduplicated. Run myte info or myte --version --verbose to inspect the exact topology.

Requirements

• Node 18.17+
• macOS, Linux, or Windows
• MYTE_API_KEY=<project_api_key> in your shell or workspace .env
• MYTEAI_API_KEY=<inference_api_key> only for myte ai
• MYTEAI_API_KEY=<inference_api_key> for mytecody
• git in PATH only for query --with-diff
• Standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY variables are honored through the core transport dependency.

The CLI searches for .env in the current folder and then up parent directories.

Common Commands

• npx myte config --json
• npx myte doctor --json
• npx myte info
• npx myte bootstrap
• npx myte sync-qaqc
• npx myte feedback-sync
• npx myte feedback get --feedback-id <id>
• npx myte feedback history --feedback-id <id>
• npx myte feedback status --feedback-id <id> --status in_review --reason "Ready for review"
• npx myte feedback edit --feedback-id <id> --title "Updated title" --feedback-text "Updated body" --reason "Clarify scope"
• npx myte feedback document-add --feedback-id <id> --prd-file ./docs/linked-addendum.md --title "Linked PRD addendum" --reason "Extend governed Feedback context"
• npx myte feedback assign --feedback-id <id> --user-id <user_id> --reason "Assign to builder"
• npx myte feedback archive --feedback-id <id> --reason "Superseded"
• npx myte feedback validate --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml
• npx myte feedback submit --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml
• npx myte feedback reviews --status open
• npx myte feedback revise --request-id <id> --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml
• npx myte feedback review --request-id <id> --action approve --reason "Looks correct"
• npx myte feedback review --request-ids "<id1,id2>" --action approve --reason "Batch approval"
• npx myte feedback move --feedback-id <id> --to-state in_progress --reason "Started"
• npx myte feedback move --feedback-ids "<id1,id2>" --to-state in_progress --reason "Batch move"
• npx myte feedback comment --feedback-id <id> --body-file ./updates/feedback-comment.md --confirm-write --approval-artifact ./updates/feedback-comment.md
• npx myte feedback tickets list --feedback-id <id> --json
• npx myte feedback tickets create --feedback-id <id> --file ./tickets.json --dry-run --json
• npx myte feedback tickets update --feedback-id <id> --ticket-ids "<id1,id2>" --status in_progress --confirm-write --approval-artifact ./ticket-update.yml --json
• npx myte feedback undo --feedback-id <id> --event-id <event_id> --reason "Undo accidental move"
• npx myte feedback prd-versions --feedback-id <id>
• npx myte feedback prd-diff --feedback-id <id> --version-id <version_id> --compare-to <base_version_id>
• npx myte feedback apply --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml
• npx myte suggestions sync
• npx myte mission archive --mission-ids "M001" --reason "Duplicate disposable mission"
• npx myte query "Summarize the current branch changes" --with-diff --json
• npx myte create-prd ./drafts/auth-prd.md --confirm-write --approval-artifact ./drafts/auth-prd.md
• npx myte create-prd ./drafts/auth-prd.md --assigned-user-email [email protected] --confirm-write --approval-artifact ./drafts/auth-prd.md
• npx myte create-prd ./drafts/proposal.md ./drafts/harness.md ./drafts/security.md --document-set --confirm-write --approval-artifact ./drafts/approval.md
• npx myte update-team "Backend deploy completed." --confirm-write --approval-artifact ./updates/team.md
• npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md --confirm-write --approval-artifact ./updates/owner.md
• npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md --confirm-write --approval-artifact ./updates/week-12.md
• npx mytecody doctor
• npx mytecody doctor --probe-gateway
• npx mytecody update --dry-run
• npx mytecody update

Behavior

• doctor performs read-only package, credential-presence, DNS, direct TCP/TLS, authenticated config, proxy, and workspace checks. It reports the failing layer without printing the API key, proxy URL, request body, or response body.
• Network failures distinguish DNS, TCP, TLS/certificate, timeout, captive portal/non-JSON, authentication, authorization, rate-limit, and server response failures. Do not disable TLS verification to work around a failed diagnostic.
• Safe transient reads and query polling use bounded retries. Query creation uses one stable idempotency key across ambiguous retries so a lost response cannot create duplicate inference jobs.
• Query and QAQC polling honor server Retry-After / next_poll_after_ms guidance and add bounded jitter to prevent synchronized IDE poll bursts.
• Owner updates are accepted into a durable delivery outbox; a successful CLI response means the update was queued, while delivery status remains server-owned.
• bootstrap, sync-qaqc, feedback-sync, and suggestions sync write project-scoped local context under MyteCommandCenter in the current workspace unless --output-dir is provided.
• Successful commands perform a cached, best-effort check for a newer myte package version. Notices are advisory, go to stderr, and do not break commands or JSON stdout. Disable with --no-update-check or MYTE_PACKAGE_UPDATE_CHECK=0.
• bootstrap writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
• build verify --json is read-only. It checks that every active mission in the last bootstrap has a readable terminal QA/QC summary with no failed or pending cases, but it does not run QA/QC, repository tests, or semantic review.
• mission status is active-state only (todo, in_progress, done). Use mission archive for project-key lifecycle archival; restore archived missions from the web archived-board view.
• mission status and mission archive refresh local bootstrap + mission-ops state by default after a successful mutation. Use --no-sync only when you intentionally want to skip the local refresh.
• feedback status|edit|assign|archive|refine writes local review artifacts under MyteCommandCenter/reviews/feedback.
• 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 and feedback tickets list|validate-create|validate-update are read/sync/validation commands with no approval artifact flags.
• feedback review --request-ids sends one backend batch review request with grouped notifications; do not loop single-review calls for batch decisions.
• feedback move|comment|undo|prd-versions|prd-diff|history calls the project-key Feedback API while authorization, stale snapshot checks, allowed transitions, and history remain enforced by the backend. feedback move --feedback-ids sends one batch board move request.
• feedback comment creates text-only feedback-specific comments. Attachments remain web UI only for this project-key endpoint.
• feedback-sync excludes archived Feedback from normal MyteCommandCenter state. Project-key API/CLI can archive authorized Feedback, but Feedback unarchive/restore is web UI only.
• feedback validate|apply remains available for validation and owner-direct apply paths.
• query --with-diff is stricter than the snapshot commands. It requires project repositories to be configured by the project owner or builder, and it requires at least one matching local project repo to be resolved for diff collection.
• If diff-scoped repo configuration is missing or no local project repo can be resolved, query --with-diff exits with an error instead of silently dropping diff context.
• Most markdown files are excluded from diff context by default so code and runtime configuration changes dominate the payload. Key instruction files such as README.md and AGENTS.md remain eligible.

Release certification uses the shipped scripts/project-assistant-live-full-harness.js. Its default mode is network-free and accounts for all 38 project-key routes. Live mode is pinned to GaahField, requires explicit mutation flags, exercises concurrent idempotency, and delegates cleanup only to the existing exact-ID mission and Feedback harnesses. The harness uses the canonical https://api.myte.dev/api base and recognizes the live project's Gaahfield MarketPlace title as the governed GaahField target.

Approval Artifact Requirements

Only selected project-key writes require a local approval artifact. The CLI adds write_approval metadata only when the command is in the required set and 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, feedback tickets create/update/coverage, 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 |

For required actions:

• First create a local .md, .markdown, .yml, .yaml, or .json approval artifact that lists the command, every target id, and the proposed change.
• Show the artifact path and full content or a concise complete summary to the user.
• After explicit approval, rerun the write with --confirm-write --approval-artifact <path>.
• Batch artifacts must enumerate every feedback id, suggestion id, request id, or PRD item.

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. It tells the API that a human approved this payload.

Minimum artifact contents:

• command: the exact CLI command to run.
• targets: every affected feedback id, request id, suggestion id, mission id, PRD file/client ref, project, or contact id.
• proposed_change: a complete summary of the status, text, PRD, comment, or mission change.
• batch_count: required when one command sends multiple items.
• reason or approval_note: why the write is being sent.

Batch guidance:

• Mission edit/create batches use myte suggestions create or myte suggestions revise. The artifact must list each item. For edits include change_type: update, the existing mission_id, and changed fields. For new missions include change_type: create, title, description, and acceptance details. For revisions include each suggestion_id and expected revision.
• Without --document-set, myte create-prd fileA.md fileB.md ... preserves the existing behavior and creates one independent Feedback item per file.
• With --document-set, one to three Markdown files create one Feedback item with ordered, independently readable PRD documents. Each document is validated locally against the 250,000-character server contract. The approval artifact must list every file/title/client ref and the matching document count.
• Feedback submit/revise/comment artifacts are usually the same YAML or markdown file being submitted. If the command uses inline text or stdin, create 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.

For actions marked Not required, call the command directly. The backend still enforces project-key authentication, idempotency, owner/delegate capability rules, stale-state guards, validation, rate limits, and audit history.

Agent Usage Contract

Codex, Claude, and other coding agents should use one project-scoped key per workspace:

MYTE_API_KEY=<project_api_key>

The key resolves the project server-side. Agents should not pass project_id manually for normal CLI commands, and they should not call account-scoped web/JWT endpoints with this key.

Recommended agent flow:

1. Run myte config --json to confirm the project, API base, configured repos, and local workspace detection.
2. Run myte bootstrap --json, myte feedback-sync --json, or myte sync-qaqc --json to hydrate local context under MyteCommandCenter. bootstrap also writes MyteCommandCenter/AgentsMyteAPI.md, the local action matrix agents should consult before mutating Myte state. Use myte suggestions sync --json only for narrow mission-review refreshes after bootstrap.
3. Use myte query "<goal/evidence/ask>" --with-diff when local code changes matter.
4. Use myte create-prd <file.md> --confirm-write --approval-artifact <path> only after the PRD markdown has been reviewed by a human. Add --document-set for one parent with up to three ordered documents. Without that flag, multiple files remain independent PRDs. The file body is the PRD document; --description is only the short board/card summary. New PRDs are unassigned by default; add --assigned-user-id <id> or --assigned-user-email <exact-email> to assign an eligible project user atomically during creation.
5. Use myte feedback status|edit|assign|archive|refine to create reviewable local artifacts. feedback submit and feedback revise require an approval artifact; feedback review does not because the backend owner/delegate review membrane is the approval control.
6. Use myte feedback move only for direct board movement that is intentionally audited, with a clear --reason; use --feedback-ids for batch moves or batch archive.
7. Use myte suggestions create|revise|review for mission review threads. suggestions create and suggestions revise require an approval artifact; suggestions review does not because the backend Project Owner/elevated-delegate decision is the approval control. Valid create change_type values are exactly update and create; revisions keep the existing thread type and must not include change_type.
8. Use myte mission archive for project-key mission lifecycle archival. Archive requires Project Owner or elevated delegate capability; restore is web-only from the archived missions board.
9. Use myte update-team "<content>" --confirm-write --approval-artifact <path> for project/team comments through /api/project-assistant/project-comment, and myte feedback comment --feedback-id <id> --body-file ./comment.md --confirm-write --approval-artifact ./comment.md for feedback-specific implementation notes.

PRD document contract:

• Always put the complete PRD in the markdown file passed to myte create-prd.
• title maps to the feedback/board title.
• description maps to the short feedback/card summary and must not contain the full PRD.
• The markdown body is sent as prd_markdown or ticket_markdown, stored as the PRD document source, mirrored as PRD text for search/sync, and used by the backend to generate the PRD DOCX.
• The UI renders the PRD from the stored document text, not from the card 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.
• Document-set uploads preserve the exact source Markdown and also store a normalized rendering copy. Rendering cleanup never silently rewrites the approved source.
• Every newly created PRD receives immutable version 1 and a stable primary document id. Creation responses return active_prd_version_id, active_prd_version_number, and primary_document_id, which can be passed directly into feedback tickets create.
• A sub-ticket may link at most 25 PRD documents, and the backend rejects any version/document pair that does not belong to that exact Feedback/PRD before mutation.

Connectivity Diagnostics

Run this before assuming an API key or server failure:

myte doctor --json

Interpret the first failed layer:

• dns: the API hostname could not be resolved.
• tcp: the host resolved but port 443 could not be reached.
• tls: the secure connection was reset or certificate validation failed before an HTTP request reached Myte.
• http: Myte or an intermediary returned a status or non-JSON response.
• authentication / authorization: the API received the request and rejected the credential or capability.

An authorization response with policy_consent_required means the key is valid, but the user who created it must review and accept the current Myte Policy from the mission-board link printed by the CLI. Rotate the key only if the API reports authentication failure or revocation; policy acceptance is a separate user-governance step.

On restricted Wi-Fi, complete any captive-portal login, configure the network's supported proxy/VPN, or retry on another network. The CLI honors HTTP_PROXY, HTTPS_PROXY, and NO_PROXY; it never recommends disabling certificate verification.

Preferred file shape:

```myte-kanban
{
  "title": "Feedback Search PRD",
  "description": "Improve feedback search across titles, descriptions, and stored PRD text.",
  "priority": "Medium",
  "tags": ["feedback", "search"]
}
```

# Feedback Search PRD

## Goal

Full PRD content goes here.

Feedback comments nuance:

• myte feedback-sync reads existing feedback comment turns and stores them in MyteCommandCenter/data/feedback.yml.
• The web product supports feedback-specific comment create/fetch through JWT-authenticated /api/feedbacks/<feedback_id>/comments.
• The project-key npm CLI supports myte feedback comment --feedback-id <id> --body "..." --confirm-write --approval-artifact ./comment.md and --body-file ./comment.md --confirm-write --approval-artifact ./comment.md.
• Project-key feedback comments are text-only in this slice and cap content at 500,000 characters. Use the web UI when attachments are required.

Commands

• config: verify the project key and inspect local repo resolution
• bootstrap: write project board context locally
• run-qaqc: queue QAQC for explicit mission ids
• mission status: update active mission state
• mission archive: archive missions without hard delete
• sync-qaqc: refresh active mission QAQC context locally
• feedback-sync: refresh feedback and PRD context locally
• feedback status|edit|assign|archive|refine: create reviewable local feedback artifacts only
• feedback submit|revise|comment: live Feedback writes requiring --confirm-write --approval-artifact <path>
• feedback review|move|undo|apply: governed Feedback writes with no approval artifact flags
• feedback-sync|get|history|reviews|prd-versions|prd-diff|validate: read, sync, or validate Feedback state
• suggestions sync|create|revise|review: work with mission suggestion workflow state
• query: ask the project assistant, optionally with local diff context
• ai: use the Myte AI gateway
• mytecody: MyteCody team launcher installed by this package. It supports doctor, doctor --probe-gateway, update --dry-run, and update. On first coding run, it installs the branded MyteCody engine and signed client assets from the Myte release manifest into a user-local Myte cache after signature/hash checks. Coding execution requires those assets, a reachable Myte AI Cody 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.
• create-prd: upload deterministic PRD markdown as the stored renderable PRD document; use description only as the short card summary
• update-team, update-owner, update-client: send project updates through the project-key surface
• Successful myte commands check the npm registry at most once per day for a newer package version. Notices are advisory, go to stderr, and never block the command. Use --no-update-check or MYTE_PACKAGE_UPDATE_CHECK=0 to disable them.

Notes

• The package ships the CLI only. Internal rollout notes, validation logs, and project-specific operating docs are not part of the public npm contract.
• The package does not bundle the large MyteCody engine binary or the async Responses bridge implementation. The mytecody launcher installs or updates signed engine/client assets through the Myte release manifest.
• mytecody update is intentionally engine-scoped. npm package updates use npm install -g myte@latest.
• The public myte package is the supported entrypoint. The scoped @mytegroupinc/myte-core package is the implementation dependency used by the wrapper.
• See THIRD_PARTY_NOTICES.md and TRADEMARKS.md for Codex lineage and Myte brand notices.

Mission Action Map

| Action | Command / Surface | Contract | | --- | --- | --- | | 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 | Narrow refresh for mission-ops.yml after bootstrap or a mutation. | | 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; 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. | | Update mission status | myte mission status --mission-ids "M001" --status todo|in_progress|done | Active status update only; no approval artifact required; refreshes local bootstrap + mission-ops by default. | | Archive mission | myte mission archive --mission-ids "M001" --reason "..." | Project Owner or elevated delegate required; no approval artifact required. Keeps the mission record, hides it from normal board/bootstrap state, and refreshes local bootstrap + mission-ops by default. |

After bootstrap, find ids locally:

• existing mission ids: MyteCommandCenter/data/missions/*.yml -> mission_id
• suggestion ids: MyteCommandCenter/data/mission-ops.yml -> queue[].suggestion_id or threads[].suggestion_id
• revise revision: threads[].latest_revision or threads[].latest_server_revision.revision
• review revision: threads[].review_revision
• thread type: threads[].change_type

Feedback Action Map

| Command | What It Does | Governance | | --- | --- | --- | | feedback-sync | Pulls non-archived feedback metadata, comments, and PRD context into MyteCommandCenter. | Read-only project-key API call; archived Feedback is intentionally excluded. | | feedback get | Reads one feedback item's current server snapshot and snapshot_hash. | Read-only; backend checks project access. | | 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. | | 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. | 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. | 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 tickets list | Lists engineering subtickets linked to one Feedback/PRD. | Read-only and included in feedback-sync for IDE discovery. | | feedback tickets create | Creates one ticket or one JSON/YAML batch. | --dry-run validates without mutation; live batches are approval-gated, idempotent, capped at 100 and return receipts. | | feedback tickets update | Updates one ticket or many --ticket-ids in one revision-fenced batch. | The backend validates the whole batch before mutation and returns 409 for stale revisions. | | feedback tickets coverage | Changes one ticket's coverage for one retained PRD document. | Synchronous, revision-fenced and approval-gated. | | 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. | 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.

Reusable live smoke harness after deploy:

npx --package @mytegroupinc/myte-core node ./node_modules/@mytegroupinc/myte-core/scripts/feedback-live-full-harness.js --confirm-live --base-url https://api.myte.dev/api

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.

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
• GET /api/project-assistant/feedback/<feedback_id>/tickets
• GET /api/project-assistant/feedback/<feedback_id>
• GET /api/project-assistant/feedback/<feedback_id>/refinement/history
• GET /api/project-assistant/feedback-review-requests
• GET /api/project-assistant/feedback-review-requests/<request_id>
• GET /api/project-assistant/feedback/<feedback_id>/events
• GET /api/project-assistant/feedback/<feedback_id>/prd/versions
• 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>

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
• POST /api/project-assistant/project-comment
• POST /api/project-assistant/update-owner
• 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
• POST /api/project-assistant/feedback-review-requests/<request_id>/review
• POST /api/project-assistant/feedback-review-requests/batch-review
• POST /api/project-assistant/feedback-review-requests/<request_id>/request-changes
• POST /api/project-assistant/feedback-review-requests/<request_id>/cancel
• POST /api/project-assistant/feedback/<feedback_id>/board-move
• POST /api/project-assistant/feedback/batch-board-move
• POST /api/project-assistant/feedback/<feedback_id>/comments
• POST /api/project-assistant/feedback/<feedback_id>/tickets
• POST /api/project-assistant/feedback/<feedback_id>/tickets/batch
• POST /api/project-assistant/feedback/<feedback_id>/tickets/batch/validate
• PATCH /api/project-assistant/feedback/<feedback_id>/tickets/<ticket_id>
• PATCH /api/project-assistant/feedback/<feedback_id>/tickets/batch
• POST /api/project-assistant/feedback/<feedback_id>/tickets/batch-update/validate
• PATCH /api/project-assistant/feedback/<feedback_id>/tickets/<ticket_id>/prd-coverage
• POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo
• POST /api/project-assistant/suggestions
• POST /api/project-assistant/suggestions/revise
• POST /api/project-assistant/suggestions/review