@mytegroupinc/myte-core 0.0.55 → 0.0.57

package/README.md

@@ -33,7 +33,10 @@ This package exists so the public wrapper can stay small and versioned cleanly.
   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.
+- Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
+- `bootstrap` also writes `MyteCommandCenter/MyteBuildHarness.md` and `MyteCommandCenter/data/build-topology.yml`; these capture the project execution protocol and normalized topology without granting write permission.
+- `build verify --json` is a read-only local convergence check. It verifies the last bootstrap, active mission completion, actionable mission-operation state, per-mission terminal QA/QC coverage with no failed or pending cases, semantic/UI review evidence, and repository-gate evidence. It does not run QA/QC, repository tests, or semantic review itself.
+- Successful `myte` commands perform a cached, best-effort check for a newer package version and print any notice to `stderr`; `--json` output on `stdout` remains valid JSON. Disable it with `--no-update-check` or `MYTE_PACKAGE_UPDATE_CHECK=0`.
 - `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
@@ -47,7 +50,7 @@ This package exists so the public wrapper can stay small and versioned cleanly.
 - `feedback status|edit|document-add|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-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 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.
@@ -72,7 +75,7 @@ Only selected project-key writes require a server-validated approval envelope. T
 
 | Category | Commands | Artifact |
 | --- | --- | --- |
-| Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `suggestions create`, `suggestions revise` | Yes |
+| 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 |
 
@@ -91,7 +94,9 @@ Only selected project-key writes require a server-validated approval envelope. T
   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.
 - `feedback document-add --feedback-id <id> --prd-file ./document.md` creates a governed proposal to append one linked PRD document to the existing Feedback context. The addition is not live until the normal `feedback submit` -> owner/delegate `feedback review` flow applies it.
-- Governed document additions preserve existing document IDs, append a new stable document, create a new immutable PRD version, and emit `feedback_prd_document_added` so the Feedback context bubble/notification feed can link users back to the updated PRD context. Existing PRD sets may grow to twelve documents; new `create-prd --document-set` uploads remain capped at three.
+- Governed document additions preserve existing document IDs, append a new stable document, create a new immutable PRD version, and emit `feedback_prd_document_added` so the Feedback context bubble/notification feed can link users back to the updated PRD context. Existing PRD sets may grow to twelve documents; new `create-prd --document-set` uploads remain capped at three.
+- Every newly created PRD receives immutable version `1` and a stable primary document id. The API response returns `active_prd_version_id`, `active_prd_version_number`, and `primary_document_id` for immediate `feedback tickets create` use.
+- A sub-ticket may link at most 25 PRD documents. The backend validates that every version/document pair belongs to that exact Feedback/PRD before any single or batch mutation.
 - 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
@@ -104,7 +109,10 @@ 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, mission suggestion thread state, and `MyteCommandCenter/AgentsMyteAPI.md`.
+- Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards, mission suggestion thread state, and `MyteCommandCenter/AgentsMyteAPI.md`.
+- Read `MyteCommandCenter/MyteBuildHarness.md` and `MyteCommandCenter/data/build-topology.yml` before implementing a new project. Organize work by workflow/domain topology and map frontend/backend ownership before changing code.
+- Run `myte build verify --json` only after the final bootstrap and preserve its QA/QC, semantic-review, and repository-gate evidence files for review.
+- The build verifier does not run QAQC, repository tests, or semantic review; run those steps first and preserve their evidence for verification.
 - 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 and `--confirm-write --approval-artifact <path>`. The markdown file body is the PRD document; `description` is only the short board/card summary.
@@ -146,8 +154,13 @@ PRD document contract:
 `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.
+receive the API key. Authentication and authorization are reported only when
+the API actually returns those responses.
+
+For `policy_consent_required`, the CLI prints the required policy version and
+the mission-board review path. This confirms that the key is valid; the user
+who created the key must accept the current policy before Project Assistant
+routes can run. Key rotation does not replace that consent step.
 
 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
@@ -261,6 +274,10 @@ Agent rule: never guess `suggestion_id`. If `mission-ops.yml` is missing or stal
 | `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 all engineering subtickets linked to one Feedback/PRD. | Synchronous project-bound read; ticket summaries are also present in `feedback-sync`. |
+| `feedback tickets create` | Creates one ticket or one bounded batch from JSON/YAML. | `--dry-run` calls server validation; live writes require an approval artifact and idempotency. Batches are capped at 100 and return per-ticket receipts. |
+| `feedback tickets update` | Revision-fences one update or batch-updates `--ticket-ids` in one request. | CLI reads current revisions for flag-based batches; stale or duplicate targets fail the whole batch. |
+| `feedback tickets coverage` | Updates one ticket-to-PRD document coverage state. | Requires the ticket revision plus structured approval; the CLI resolves the current revision when omitted. |
 | `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. |
@@ -322,10 +339,11 @@ Read/sync routes:
 - `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>/tickets`
 - `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>`
+- `GET /api/project-assistant/run-qaqc/<batch_id>`
 
 Mutation routes:
 
@@ -349,17 +367,24 @@ Mutation routes:
 - `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`
-
-Query and QAQC status polling honors additive server timing from `Retry-After`
-and `next_poll_after_ms`, with bounded client jitter. This keeps one busy IDE
-fleet from synchronizing poll bursts. Older servers remain compatible through
-the existing bounded backoff fallback.
-
-The API keeps bounded CRUD and snapshot reads synchronous. Query and QAQC are
-durable asynchronous workflows; the CLI never assumes that every API action is
-a separate Celery task. Feedback sync pages are bounded (100 by default, 500
-maximum) and `create-prd` batch uploads are capped at 20 items by the backend.
+- `POST /api/project-assistant/suggestions/review`
+
+Query and QAQC status polling honors additive server timing from `Retry-After`
+and `next_poll_after_ms`, with bounded client jitter. This keeps one busy IDE
+fleet from synchronizing poll bursts. Older servers remain compatible through
+the existing bounded backoff fallback.
+
+The API keeps bounded CRUD and snapshot reads synchronous. Query and QAQC are
+durable asynchronous workflows; the CLI never assumes that every API action is
+a separate Celery task. Feedback sync pages are bounded (100 by default, 500
+maximum) and `create-prd` batch uploads are capped at 20 items by the backend.