#154 - [GH-ISSUE #566] Review: add Resolution Center messaging (App Review communications) - feasibility + UX - starred/App-Store-Connect-CLI

Originally created by @rudrankriyam on GitHub (Feb 16, 2026). Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/566 ## Summary Add first-class, non-interactive commands for **Resolution Center style messaging** with App Review. This should cover two core workflows: - read threads/messages (so CI/agents can surface review questions/rejections) - send replies (so teams can respond without using the web UI) ## Why this matters When a submission is blocked or rejected, the Resolution Center thread becomes the primary coordination channel: - App Review asks clarifying questions (login, entitlement usage, feature behavior) - teams need to reply quickly, often from CI logs / release automation context - it is easy to miss messages when the workflow requires “someone manually check the web UI” A CLI surface makes the workflow: - scriptable - auditable (JSON artifacts) - easier to drive via agents ## Current state (verified) - `asc review` covers review **details**, **attachments**, **submissions**, and **submission items**. - There is no command for Resolution Center message threads. - The offline OpenAPI snapshot (`docs/openapi/paths.txt`) does not include endpoints for Resolution Center threads/messages. ## Constraints ### Public API limitation If Resolution Center threads/messages are not available via the public App Store Connect API, an API-key/JWT-only CLI cannot implement this directly. ### Authentication model Resolution Center messaging appears to require **Apple ID web session** state (cookie + CSRF-like headers), not API key JWT. That implies: - higher breakage risk - additional security surface (session material is extremely sensitive) ## Proposed UX Introduce a dedicated subcommand group: ```bash asc review resolution-center <subcommand> [flags] ``` ### Read threads/messages ```bash # List threads for a review submission asc review resolution-center threads list --submission-id "SUBMISSION_ID" # List messages for a thread asc review resolution-center messages list --thread-id "THREAD_ID" # Convenience: list newest messages for a submission asc review resolution-center latest --submission-id "SUBMISSION_ID" ``` ### Send a reply ```bash # Reply to an existing thread (explicit confirm) asc review resolution-center reply \ --thread-id "THREAD_ID" \ --message "We updated the demo account; please retry." \ --confirm ``` ### Output - Default output: **minified JSON** - `--output table|markdown` for humans - deterministic ordering (threads/messages sorted by timestamp, stable tiebreakers) ## Proposed implementation approach (two-phase) ### Phase 1: Honest command surface (safe default) Add the commands with clear behavior in API-key mode: - print an explicit error explaining that Resolution Center messaging is not available via API key - return a deterministic, machine-readable JSON payload describing what would have been fetched/sent - optionally print an `--open` URL (web UI deep link) to complete the action manually This mirrors the “AI-drivable even when blocked” pattern: pipelines can still generate the exact spec and proceed once a human completes the UI step. ### Phase 2: Optional experimental web-session mode If the project decides to support web-session-based operations: - require an explicit opt-in flag (e.g. `--experimental-web-session`) - require session material via env var only (never printed; never stored by default) - strict redaction in debug output - `reply` requires `--confirm` Tracked separately: #567 ## Test plan (TDD-first) - [ ] cmdtests for Phase 1: - [ ] commands exist and are self-documenting - [ ] deterministic error messaging + exit code - [ ] deterministic JSON spec output - [ ] unit tests for payload shaping/deterministic ordering - [ ] if Phase 2 is implemented: httptest coverage for request construction + response parsing (no real network) ## Acceptance criteria - [ ] `asc review resolution-center --help` exists and documents constraints clearly. - [ ] Read commands produce deterministic JSON output. - [ ] Reply command is non-interactive and guarded (`--confirm`). - [ ] Default mode does not attempt undocumented network calls. - [ ] `make test` passes.

kerem commented

2026-02-26 21:33:49 +03:00

Owner

Originally created by @rudrankriyam on GitHub (Feb 16, 2026).
Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/566

Summary

Add first-class, non-interactive commands for Resolution Center style messaging with App Review.

This should cover two core workflows:

read threads/messages (so CI/agents can surface review questions/rejections)
send replies (so teams can respond without using the web UI)

Why this matters

When a submission is blocked or rejected, the Resolution Center thread becomes the primary coordination channel:

App Review asks clarifying questions (login, entitlement usage, feature behavior)
teams need to reply quickly, often from CI logs / release automation context
it is easy to miss messages when the workflow requires “someone manually check the web UI”

A CLI surface makes the workflow:

scriptable
auditable (JSON artifacts)
easier to drive via agents

Current state (verified)

asc review covers review details, attachments, submissions, and submission items.
There is no command for Resolution Center message threads.
The offline OpenAPI snapshot (docs/openapi/paths.txt) does not include endpoints for Resolution Center threads/messages.

Constraints

Public API limitation

If Resolution Center threads/messages are not available via the public App Store Connect API, an API-key/JWT-only CLI cannot implement this directly.

Authentication model

Resolution Center messaging appears to require Apple ID web session state (cookie + CSRF-like headers), not API key JWT.
That implies:

higher breakage risk
additional security surface (session material is extremely sensitive)

Proposed UX

Introduce a dedicated subcommand group:

asc review resolution-center <subcommand> [flags]

Read threads/messages

# List threads for a review submission
asc review resolution-center threads list --submission-id "SUBMISSION_ID"

# List messages for a thread
asc review resolution-center messages list --thread-id "THREAD_ID"

# Convenience: list newest messages for a submission
asc review resolution-center latest --submission-id "SUBMISSION_ID"

Send a reply

# Reply to an existing thread (explicit confirm)
asc review resolution-center reply \
  --thread-id "THREAD_ID" \
  --message "We updated the demo account; please retry." \
  --confirm

Output

Default output: minified JSON
--output table|markdown for humans
deterministic ordering (threads/messages sorted by timestamp, stable tiebreakers)

Proposed implementation approach (two-phase)

Phase 1: Honest command surface (safe default)

Add the commands with clear behavior in API-key mode:

print an explicit error explaining that Resolution Center messaging is not available via API key
return a deterministic, machine-readable JSON payload describing what would have been fetched/sent
optionally print an --open URL (web UI deep link) to complete the action manually

This mirrors the “AI-drivable even when blocked” pattern: pipelines can still generate the exact spec and proceed once a human completes the UI step.

Phase 2: Optional experimental web-session mode

If the project decides to support web-session-based operations:

require an explicit opt-in flag (e.g. --experimental-web-session)
require session material via env var only (never printed; never stored by default)
strict redaction in debug output
reply requires --confirm

Tracked separately: #567

Test plan (TDD-first)

cmdtests for Phase 1:
- commands exist and are self-documenting
- deterministic error messaging + exit code
- deterministic JSON spec output
unit tests for payload shaping/deterministic ordering
if Phase 2 is implemented: httptest coverage for request construction + response parsing (no real network)

Acceptance criteria

asc review resolution-center --help exists and documents constraints clearly.
Read commands produce deterministic JSON output.
Reply command is non-interactive and guarded (--confirm).
Default mode does not attempt undocumented network calls.
make test passes.

kerem closed this issue

2026-02-26 21:33:50 +03:00

Author

@rudrankriyam commented on GitHub (Feb 26, 2026):

Closing as resolved by #778, which added web review submissions/threads/messages workflows that cover this request.

@rudrankriyam commented on GitHub (Feb 26, 2026): Closing as resolved by #778, which added web review submissions/threads/messages workflows that cover this request.

Rows
Columns

[GH-ISSUE #566] Review: add Resolution Center messaging (App Review communications) - feasibility + UX #154