Thanks @jensenpat — this is a careful, well-documented change. The dormant-by-default design is sound, the layered guard rails (tag-ref + opt-in variable + forks-can't-read-secrets) are correct, and the SHA-pinned action plus --noCommit draft gate are exactly the right defaults for touching a publishing pipeline from CI. Scope is tight (workflow + wrapper + docs), and the publish-store.ps1 error handling is genuinely thoughtful — exit-0 on a missing .msixupload (since the MSIX step is continue-on-error), throw on ambiguous multiple matches, and an explicit $LASTEXITCODE check after & msstore (correct, since $ErrorActionPreference = "Stop" doesn't trap native-exe exit codes).

A couple of things worth verifying before the first live run — both at the msstore CLI boundary, where a wrong flag name fails the very first automated submission:

1. msstore publish argument syntax. The script invokes it positionally with -id:

   $publishArgs = @("publish", $upload, "-id", $ProductId)
   $publishArgs += "--noCommit"

   The earlier (now-replaced) doc described it as msstore publish -i <pkg>.msixupload -id <ProductId> --noCommit — i.e. the package behind an -i flag rather than positional. Worth confirming against the actual CLI version the pinned microsoft-store-apppublisher@v1.1 action installs: (a) does publish take the package path positionally or via -i/--inputDirectory, and (b) are the flags -id and --noCommit (vs --appId/-nc etc.)? If the action is available locally, a quick msstore publish --help would settle both. Not a blocker since the feature is dormant until credentials land, but it's the one path that can't be exercised by CI before a real tag.

2. reconfigure failure mode (minor). If AETHERSDR_STORE_PRODUCT_ID is set but a secret is later rotated/missing, the msstore reconfigure run step fails and reddens an otherwise-successful release — slightly at odds with the "never redden a good release" goal that publish-store.ps1 itself honors. Arguably desirable (you want to notice broken creds), so just flagging it, not asking for a change.

Everything else looks good to me. Nice work keeping this safe-by-construction.

_{🤖 aethersdr-agent · cost: $3.5370 · model: claude-opus-4-8}

Reviewed the workflow, the publish-store.ps1 wrapper, and the docs. This is careful, well-guarded work — the dormant-by-default design is the right call, and the layered guard rails check out. Thanks @jensenpat. A couple of notes, both minor.

Guard rails — sound

Confirmed against the workflow trigger (on: push: tags: ['v*'] + workflow_dispatch): the whole job only runs on v* tag pushes, so the step's startsWith(github.ref, 'refs/tags/') guard is effectively v*-scoped, and the vars.AETHERSDR_STORE_PRODUCT_ID != '' opt-in plus fork secret isolation give three independent gates before Partner Center is touched. The --noCommit draft gate on top is good defense-in-depth. No concerns on the safety model.

The PS wrapper itself is solid: @(...)-wrapped glob so .Count is reliable, newest-first sort, explicit multi-match refusal, and the deliberate exit-0-on-missing-package (matching the continue-on-error MSIX step) vs. exit-non-zero on a real publish failure. That distinction is exactly right.

Two things worth a second look

1. msstore flag spellings are untestable in CI — verify them manually. The whole path is dormant until credentials land, so a typo in -id or --noCommit won't surface until the first real release tag (and then it reddens or, worse, mis-submits a live product). The msstore CLI is built on System.CommandLine, which is strict about token form — --noCommit vs --no-commit, and -id vs --app-id. Please confirm the exact spellings against the pinned microsoft/microsoft-store-apppublisher@v1.1 CLI version (a quick msstore publish --help locally), since CI can't catch this for you.

2. reconfigure failure can be masked in the combined run: block. The workflow runs msstore reconfigure and then powershell -File publish-store.ps1 in a single step. GitHub's pwsh wrapper only propagates $LASTEXITCODE at the end of the block. If reconfigure fails (e.g., a mis-pasted secret) and the MSIX build happened to produce no .msixupload (the script then exit 0s), the step goes green with no submission and no error — auth breakage stays invisible. Consider either splitting reconfigure into its own step, or adding if ($LASTEXITCODE -ne 0) { throw } right after the reconfigure call so a bad auth config always fails loudly.

Neither blocks merge given the feature is wired-but-dormant. Nice clean separation between the workflow, the wrapper, and the docs.

_{🤖 aethersdr-agent · cost: $1.8975 · model: claude-opus-4-8}