# Build, update, extend, or deploy a live Microsoft commercial marketplace SaaS integration

> **Important:** Treat all generated output as an **uncertified starting implementation**. It is not Microsoft approval or certification and is not automatically production-ready. The publisher owns independent security review, testing, deployment validation, and verification against the live offer and current Microsoft documentation. **Never ask the publisher to paste secrets, credentials, client secrets, access tokens, purchase tokens, or customer data.**

## 1. Plain-language goal

Help the publisher build, update, or extend the customer journey after a buyer selects a Microsoft commercial marketplace SaaS offer. The default core profile is:

1. a live landing page and buyer sign-in;
2. secure association of the Marketplace subscription with the publisher's account or workspace;
3. a protected server-side publisher identity for Marketplace calls;
4. applicable fulfillment and activation;
5. lifecycle webhooks, durable state synchronization, status, and recovery.

Include subscription information for applicable documented lifecycle events.

This is a live-only implementation prompt. Never add a deployed demo, sandbox, simulator, fictional-data mode, synthetic provider, or runtime fallback. Controlled mocks and test doubles are test-only and must be impossible to select in deployed runtime composition.

## 2. Select an operating mode and implementation path

Determine capabilities first and state one mode:

- **Repository editing mode:** Repository/filesystem access is available. Inspect the supplied repository; follow its instructions and conventions except for Accelerator update or upgrade instructions and scripts excluded by SRC-08; modify or create tracked artifacts; preserve unrelated work; and run available tests/checks. When deployment is requested, inspect existing deployment conventions and create or update tracked deployment artifacts; do not require the publisher to supply a deployment script. Execute a live deployment only when explicitly requested and authorized under DEP-01–DEP-06. Plan, then proceed unless materially blocked.
- **Chat-only/no-repository mode:** Repository editing is unavailable. Never say files were inspected, edited, created, or tested. Provide complete proposed files or clearly bounded code sections with filenames, setup steps, an inline contract manifest, tests or commands, and unresolved blockers. Generate the requested bounded deliverable.

Then determine whether the supplied folder or described project contains an existing implementation. Unless the publisher has already explicitly selected a path, ask the applicable question before implementation:

- **Existing implementation:** Ask whether it is based on the Microsoft Commercial Marketplace SaaS Accelerator and whether the publisher wants to update and reconcile it against the newest upstream implementation, or instead wants to continue extending the existing implementation without an Accelerator update. Do not infer the choice solely from similar files or architecture.
- **New implementation:** Ask whether the publisher wants to start from the SaaS Accelerator or build from scratch. Before asking, explain that the open-source SaaS Accelerator provides an existing, opinionated reference implementation, while starting from scratch provides greater architectural and stack flexibility but may require more Marketplace-specific configuration, implementation, security review, integration work, and testing.

Treat this implementation-path choice as material. Do not automatically fall back to bespoke development merely because no implementation exists. If the publisher selects the SaaS Accelerator path, follow ACC-01–ACC-06. If the publisher selects a from-scratch path and no stack is supplied, ask the publisher to select a stack; do not silently choose one.

Do not assume browsing, autonomous editing, a long context window, or the ability to create separate artifacts. Missing instruction tiers, optional resources, or `PUBLISHER_IMPLEMENTATION_GUIDE.md` are skipped, not treated as conflicts. Use that guide only if actually supplied, and treat it as supplemental.

## 3. Intake: ask only what materially matters

Before implementation, collect or infer this **non-secret** information:

- requested scope and desired deliverable;
- whether deployment implementation, preflight, or live deployment execution is requested;
- existing app or new app;
- selected implementation path: existing SaaS Accelerator update, existing implementation without an Accelerator update, new SaaS Accelerator implementation, or new from-scratch implementation;
- for an Accelerator update, any known installed version, source revision, prior update history, and intentional publisher customizations;
- stack, runtime, and hosting target, if known or required for the selected path;
- preferred infrastructure/deployment technology, if the repository has no established convention;
- for live deployment, the approved target environment, tenant and subscription identifiers, region, resource group, resource-name constraints, expected existing-resource behavior, and authorized change scope;
- offer and plan identity placeholders;
- activation model, if known;
- whether metered billing is configured or metering work is requested;
- whether the publisher explicitly wants a metering UI and, if so, its intended users and scope;
- persistence and deployment constraints;
- expected public URLs or URL placeholders;
- available repository, files, and relevant instructions.

Ask focused questions only for missing inputs that materially affect safe implementation. Permit placeholders for deploy-time values. **Do not request credentials, client secrets, access tokens, purchase tokens, or customer data.**

## 4. Instruction precedence

Apply, in order:

1. host/system instructions;
2. stable security, privacy, authorization, data-integrity, and Accelerator change-preservation invariants here, including SRC-08 and ACC-04;
3. current authoritative Microsoft documentation for the applicable boundary;
4. explicit publisher requirements;
5. supplied repository instructions and conventions, except Accelerator update or upgrade instructions and scripts excluded by SRC-08;
6. discretionary guidance here.

A lower tier cannot override a higher one. A more specific instruction controls only its scope. Report material conflicts with affected requirement IDs; stop only the affected boundary when safe resolution is impossible. Continue independent work only if doing so cannot conceal or worsen the conflict.

## 5. Documentation access, authority, and applicability

- **SRC-01 — Current authority and discovery:** If browsing is available, consult current canonical Microsoft Learn sources before implementing or changing a Marketplace boundary or assessing release eligibility. The URLs below are non-exhaustive seeds. Follow applicable linked contract/reference pages, inspect the current Marketplace offers documentation index, resolve redirects, and record newly discovered applicable pages. Current Microsoft Learn—not memory, examples, existing code, or the manifest—is authoritative.
- **SRC-02 — Applicable capabilities:** Determine applicability from publisher inputs, verified offer/activation configuration, explicitly confirmed metering configuration, requested scope, and supplied implementation boundary. Determine metering implementation and metering UI applicability separately: metering applies only when configured or requested, and a metering UI applies only when explicitly requested and metering applies. The core profile is the default. Do not require unrelated capabilities. Missing material inputs block only the affected boundary.
- **SRC-03 — Exact traceability:** Map each implemented provider boundary to the exact URL and heading/section governing its configuration, code, durable data, operations, and tests. A general “follows the docs” claim is insufficient.
- **SRC-04 — No-browse or uncertain-doc behavior:** If browsing is unavailable, produce only architecture, scaffolding, provider-boundary interfaces, placeholders, tests/verification plans, and an explicit documentation-verification checklist. Do not fill mutable endpoints, API versions, claims, fields, payloads, statuses, limits, or timing rules from memory; claim contract compliance; implement unverifiable details as facts; or claim live readiness. Inaccessible, ambiguous, or contradictory current documentation blocks the affected boundary even when browsing is available.
- **SRC-05 — Change isolation:** Isolate provider-controlled identities, versions, endpoints, claims, payloads, statuses, events, limits, and timing behind explicit provider boundaries.
- **SRC-06 — Supplemental material:** Supplied repository documentation may add context but never overrides current Microsoft Learn.
- **SRC-07 — Accelerator source:** When the SaaS Accelerator path applies, use the current `main` branch of the official open-source [Commercial Marketplace SaaS Accelerator repository](https://github.com/Azure/Commercial-Marketplace-SaaS-Accelerator), identified through its [README](https://github.com/Azure/Commercial-Marketplace-SaaS-Accelerator/blob/main/README.md), as the source for the newest Accelerator implementation. Record the retrieved commit SHA and retrieval date. Current applicable Microsoft Learn documentation remains authoritative for Marketplace behavior.
- **SRC-08 — Ignore bundled update guidance:** For the update workflow defined by this prompt, ignore and do not follow update or upgrade instructions, scripts, or procedures contained in the upstream SaaS Accelerator repository, linked from its README, or copied into the publisher's Accelerator-derived implementation. Do not use an Accelerator upgrade script to reconcile or deploy the publisher's update. Instead, use the fresh-source comparison and deliberate reconciliation required by ACC-02–ACC-05. Review and apply required database migration artifacts from the reconciled source only under the normal comparison, testing, authorization, and deployment gates.

No-browse output is a **design-time degraded output**, never a deployed demo, simulation, provider substitute, or runtime fallback.

## 6. Documentation discovery matrix

Use every source applicable to a boundary; one page does not replace another page defining part of the contract.

| Boundary | Non-exhaustive authoritative seeds | Required determination |
|---|---|---|
| Offer and activation | [Create a SaaS offer](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/create-new-saas-offer-technical) | Verify technical configuration and applicability. |
| Publisher identity | [Register a SaaS application](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-registration); [Fulfillment APIs overview](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-apis) | Verify current identity, OAuth, and authorization contract. |
| Landing and association | [SaaS landing page](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/azure-ad-transactable-saas-landing-page); [Subscription APIs](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-subscription-api); [Fulfillment APIs overview](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-apis) | Implement applicable resolution, association, and activation. |
| Lifecycle | [SaaS subscription lifecycle management](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-life-cycle); [Subscription APIs](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-subscription-api) | Synchronize applicable subscription and entitlement changes. |
| Webhooks | [SaaS fulfillment webhooks](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-webhook); [SaaS subscription lifecycle management](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-life-cycle) | Authenticate, validate, deduplicate, process, and recover notifications. |
| Conditional operations | [SaaS fulfillment operations APIs](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-operations-api); [SaaS fulfillment webhooks](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-webhook) | Include only for applicable documented events. |
| Conditional metering | [SaaS metered billing](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/saas-metered-billing); [Marketplace metering service APIs](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/marketplace-metering-service-apis); [Create a SaaS offer](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/create-new-saas-offer-technical) | Include metering only when explicitly confirmed or requested; include a metering UI only when the publisher explicitly requests it. |
| SaaS Accelerator selection or update | [SaaS Accelerator README](https://github.com/Azure/Commercial-Marketplace-SaaS-Accelerator/blob/main/README.md); [source repository](https://github.com/Azure/Commercial-Marketplace-SaaS-Accelerator) | Identify the exact current `main` commit, local baseline and customizations, required migrations, and reconciliation scope. Ignore repository-provided update or upgrade instructions and scripts. |

## 7. Marketplace contract manifest

- In **repository mode**, create or update a tracked, repository-appropriate artifact conceptually named `marketplace-contract-manifest`.
- In **chat-only mode**, include the manifest as a table in the final response.

The manifest is reviewable evidence/cache, never authority. For each consulted or blocked boundary, record URL, access date, exact section, applicability reason, mutable contract details when verified, implementation and test mappings, discrepancies, blockers, and release impact. Record discovered applicable capabilities and pages. Compare an existing manifest with current sources and preserve useful change history. Never include secrets, tokens, customer data, or unnecessary provider payloads.

- **CS-01 — Provider identity:** Record verified Marketplace identity use.
- **CS-02 — OAuth contract:** Record verified flow, authority, audience/resource/scope, and authorization.
- **CS-03 — API selection:** Record verified versions, endpoints, methods, and selection rules.
- **CS-04 — Landing contract:** Record verified landing, purchase-token, Resolve, activation, and timing semantics.
- **CS-05 — Operations contract:** When applicable, record retrieval, processing, acknowledgement, retry, and timing.
- **CS-06 — Metering time contract:** When metering applies, record event-time, window, and clock semantics.
- **CS-07 — Metering uniqueness:** When metering applies, record deduplication, aggregation, and uniqueness.
- **CS-08 — Provider limits:** Record applicable verified limits.

## 8. Delivery and configuration

- **DEL-01 — Inspect:** In repository mode, inspect relevant architecture, runtime, persistence, migrations, tests, security, deployment, configuration, manifest, instructions, and unrelated work before editing.
- **DEL-02 — Suitability:** Report if the supplied repository cannot safely host the service. Select or create a stack only with publisher authorization.
- **DEL-03 — Plan and proceed:** Plan boundaries, identities, state, configuration, security, manifest, and tests; proceed in repository mode unless materially blocked.
- **DEL-04 — Change discipline:** Reuse sound conventions, minimize dependencies, preserve unrelated work, and isolate provider contracts.
- **DEL-05 — Evidence:** Map applicable requirement IDs to changed/proposed artifacts and tests; report migrations, configuration, non-applicability, discrepancies, and blockers.
- **DEL-06 — Release gate:** Use the readiness labels in Section 15; never claim Microsoft certification.
- **ACC-01 — Explicit path selection:** Do not choose between a SaaS Accelerator implementation and a from-scratch implementation on the publisher's behalf. For an existing implementation, confirm whether an Accelerator upstream update is requested. For a new implementation, obtain the publisher's Accelerator-versus-from-scratch choice after explaining the tradeoff in Section 2.
- **ACC-02 — Fresh upstream source:** When an Accelerator update or new Accelerator implementation is selected, retrieve a fresh copy of the official repository's current `main` branch in an isolated temporary location. Record its commit SHA and retrieval date. Never assume a cached or existing local copy is current. If current upstream cannot be retrieved, block the Accelerator implementation or update rather than claiming it is current.
- **ACC-03 — Baseline and comparison:** For an Accelerator update, determine the installed version or nearest common upstream baseline from repository history, version metadata, deployment artifacts, or other inspectable evidence. Prefer a three-way comparison of the prior upstream baseline, current upstream `main`, and publisher implementation. If no reliable baseline can be established, perform a two-way comparison, label the reduced confidence, and do not guess whether ambiguous code is upstream or publisher-authored. Compare source, dependencies, database migrations, configuration, infrastructure, tests, and documentation while excluding secrets and generated artifacts.
- **ACC-04 — Reconciliation:** Before editing, classify upstream additions, fixes, removals, migrations, and breaking changes separately from publisher customizations. Reconcile the current upstream changes into the publisher implementation while preserving intentional customizations, repository conventions, open-source license notices, environment-specific configuration, and unrelated work. Never overwrite the publisher tree with a blind pull, copy, script, or deployment. Ignore repository-provided update or upgrade instructions and scripts. Surface materially ambiguous conflicts for publisher decision and stop only the affected boundary.
- **ACC-05 — Reconciliation evidence:** Run available upstream and repository-specific checks after reconciliation. Report the prior baseline, selected upstream commit, comparison method, incorporated and intentionally omitted upstream changes, preserved customizations, conflicts, migrations, configuration changes, manual steps, and test results.
- **ACC-06 — New Accelerator implementation:** For a new Accelerator implementation, begin from the freshly retrieved current upstream `main` revision rather than recreating it from memory or generating a superficially similar bespoke application. Apply only publisher-requested customizations and verified Marketplace contract changes. For a from-scratch implementation, follow the publisher-selected stack and do not silently import Accelerator architecture or code.
- **DEP-01 — Deployment implementation:** Reuse the repository's established infrastructure-as-code and deployment conventions, except that an Accelerator update must not use Accelerator update or upgrade instructions, procedures, or orchestration scripts excluded by SRC-08, including copies in the publisher's tree. Reconciled database migration artifacts remain subject to review and the normal deployment gates. If no other convention exists, ask the publisher to select or authorize a deployment technology; do not silently choose one. Do not require the publisher to supply a deployment script. Create tracked, repeatable deployment artifacts and documentation without embedding secrets. Accept existing resource and application identifiers as optional inputs. When required identifiers are not supplied, make the deployment provision the applicable Microsoft Entra application registrations, service principals, managed identities, and other resources, then use their generated identifiers in dependent configuration.
- **DEP-02 — Identity provisioning:** Before reusing a supplied identity, verify that it exists in the approved tenant and matches the required ownership, audience, redirect URIs, permissions, and Marketplace role under the currently verified contract. When a required identity is absent, create it only in the authorized tenant. Treat actual identity creation as an external mutation requiring DEP-03 authorization. Persist generated non-secret identifiers in deployment outputs or protected configuration. Send generated credentials directly to an approved secret store; never render, return, log, or commit them. Do not replace or modify an existing identity without explicit scoped authorization.
- **DEP-03 — Explicit authorization:** Creating or editing deployment artifacts does not authorize live deployment. Before creating, changing, replacing, or deleting external resources; changing cloud, identity, DNS, database, or Partner Center configuration; or starting cost-incurring services, obtain explicit publisher authorization for the target environment, tenant, subscription, and change scope. Never accept legal, license, consent, or cost prompts on the publisher's behalf. Read-only inspection and preflight may proceed when otherwise permitted.
- **DEP-04 — Preflight and change safety:** Before mutation, verify the selected cloud context, authentication, required roles and permissions, tool and runtime versions, repository state, working directory, build and migration prerequisites, provider registrations, quotas, name availability, expected costs, network and public-ingress assumptions, existing resources and local artifacts, configuration closure, and rollback or remediation options. Distinguish create, update, reuse, replace, migrate, and delete actions; do not assume deployment is idempotent. Do not begin mutation while a material prerequisite is unresolved, and never purge, replace, delete, overwrite, or repurpose an existing resource or publisher file without explicit scoped authorization.
- **DEP-05 — Secrets and interaction:** Identify interactive prompts before execution. Require the publisher to respond directly to legal, license, consent, or cost prompts or provide an approved non-interactive input. Provision required secrets through publisher-controlled secure entry or an approved secret store without exposing them to the agent. Never request or expose secrets through chat, tracked files, command arguments, logs, evidence, or responses. If secure provisioning is unavailable, block the affected deployment boundary.
- **DEP-06 — Execution, evidence, and partial failure:** Execute only the authorized command and scope. Record sanitized inputs, confirmed target context, start and end times, exit status, material resource and migration results, resulting endpoints, and applicable smoke and readiness checks. Verify actual command and resource outcomes; continued execution or a completion message alone is not evidence of success. On failure, stop additional mutation when safe and do not automatically rerun, roll back, delete, or recreate resources unless authorized and understood. Report completed, failed, skipped, and unknown steps; residual resources and possible ongoing costs; local-file changes; credential-rotation concerns; safe retry boundaries; and required remediation.
- **CFG-01 — Configuration:** Follow supplied repository conventions; otherwise describe categories and placeholders without inventing key names.
- **CFG-02 — Categories:** Cover applicable publisher identity, protected credentials, provider contract selection, offer/activation, storage, public ingress, buyer authentication, workers, observability, retention, deployment, and metering dimensions only when metering applies. Include metering UI configuration only when that UI is explicitly requested.
- **CFG-03 — Validation:** Fail startup or readiness safely when required live configuration cannot be validated. Never convert failure into provider success.
- **CFG-04 — Public URLs:** Use secure public URLs where documented; never put credentials, tokens, or customer data in URLs.
- **CFG-05 — Secrets:** Use protected secret storage. Never commit, render, echo, log, place in URLs, or expose secrets/tokens to browsers.
- **ID-01 — Identity separation:** Separate server-side publisher identity from buyer identity.
- **ID-02 — Publisher OAuth:** Implement only the currently verified server-side OAuth and authorization contract.
- **ID-03 — Token handling:** Keep tokens in trusted server components; never persist them as business data. Cache only when required, protected, and safely refreshed from verified expiry.
- **ID-04 — Contract selection:** Centralize verified provider endpoints, versions, and identity settings.
- **ID-05 — Clock:** Use synchronized UTC time and fail affected processing when timing correctness is unverifiable.

## 9. Core live requirements

- **LAND-01 — Purchase-token non-persistence:** Accept a purchase token only at the landing boundary, transfer it immediately to the trusted server for its documented purpose, and never persist, log, trace, render, return, or retain it in browser state.
- **LAND-02 — Resolve and association:** Resolve server-side, process retries idempotently, and persist only verified subscription data needed for durable association.
- **LAND-03 — Buyer authorization:** Authenticate buyers independently; authorize account/workspace selection and creation server-side.
- **LAND-04 — Correlation:** Use opaque, one-time, server-controlled correlation without embedding the purchase token; bind, expire, consume, and replay-protect it.
- **LAND-05 — Unverifiable context:** Preserve last verified state, pause, reconcile, and alert rather than infer billing or entitlement context.
- **LIFE-01 — Activation model:** Implement only the verified, configured activation flow after required association/setup.
- **LIFE-02 — Verified completion:** Grant entitlement or show completion only after durable, documented provider success.
- **LIFE-03 — Alternate activation:** When publisher activation is not documented for the configured model, do not invent it; associate securely and reconcile.
- **LIFE-04 — Lifecycle state:** Maintain explicit legal transitions; reject stale, invalid, conflicting, or unverifiable transitions.
- **LIFE-05 — Lifecycle effects:** Apply verified access, entitlement, plan/quantity, suspension, restoration, termination, and offboarding effects only where applicable.
- **WEB-01 — Authenticated ingress:** Treat webhooks as public ingress; validate identity, integrity, freshness, authorization, shape, and limits exactly as documented.
- **WEB-02 — Identity separation:** Do not equate notification, subscription, operation, or customer identifiers unless the verified contract permits it.
- **WEB-03 — Durable inbox:** After authentication and structural validation, durably deduplicate each logical delivery before mutation.
- **WEB-04 — Verify before mutation:** Retrieve/verify provider state when required; fail closed on identity, action, target, or state mismatch.
- **WEB-05 — Atomic processing:** Apply a transition once and atomically persist mutation, applicable acknowledgement intent, and durable follow-on work.
- **WEB-06 — Documented timing:** Meet and measure verified timing without bypassing authentication, verification, or durability.
- **WEB-07 — Acknowledgement durability:** Only when acknowledgement applies, persist intent before transmission and retry/reconcile uncertainty without fabricating outcomes.
- **WEB-08 — Evidence:** Test duplicates, invalid transitions, latency/uncertainty, retry, worker takeover, and restart recovery.

## 10. Data integrity and conditional metering

- **DATA-01 — Durable atomic storage:** Use durable transactional storage or an equivalent atomic mechanism for live state; enforce concurrency safety and restart recovery.
- **DATA-02 — Necessary records:** Store only durable association, subscription, entitlement, lifecycle, inbox, retry, reconciliation, audit, and applicable operation/metering state.
- **DATA-03 — Constraints:** Enforce identity uniqueness, permitted associations, idempotency, referential integrity, and applicable billing deduplication.
- **DATA-04 — Atomic units:** Atomically persist business mutations with follow-on work and, when applicable, billing intent with reservation/recovery state.
- **DATA-05 — Minimization:** Exclude purchase tokens, credentials, access tokens, unnecessary payloads, and unnecessary personal data; document retention/deletion.

Apply **MTR-01–MTR-08 only when the publisher explicitly confirms configured metered billing or requests metering work**. Treat a metering UI as separate optional presentation scope: include a usage, billing-report, or other metering UI only when the publisher explicitly requests it and metering applies; otherwise do not add one.

- **MTR-01 — Applicability and dimensions:** Verify configured dimensions and eligibility from current docs and publisher configuration.
- **MTR-02 — Accounting state:** Keep immutable period/usage state sufficient for incremental reporting without double billing or incorrect carryover.
- **MTR-03 — Calculation contract:** Derive units and calculations only from verified docs and versioned offer configuration.
- **MTR-04 — Reservation:** Durably reserve reportable usage before transmission to prevent concurrent duplicate reporting.
- **MTR-05 — Provider constraints:** Enforce verified time, uniqueness, aggregation, quantity, batch, and request limits.
- **MTR-06 — Outcomes:** Advance accepted accounting state only after documented acceptance or conclusive reconciliation.
- **MTR-07 — Recovery:** Recover uncertain/pending reports idempotently after crashes, lease loss, timeout, or network uncertainty; escalate exhausted retries.
- **MTR-08 — Lifecycle controls:** Stop accrual/reporting when verified lifecycle or configuration prohibits it; reconcile existing uncertainty without creating usage.

## 11. Security, experience, and operations

- **SEC-01 — Trusted server:** Keep credentials, tokens, purchase-token processing, and Marketplace calls server-side.
- **SEC-02 — Authorization:** Enforce account/workspace scope and entitlement server-side for every customer/admin action.
- **SEC-03 — Browser protections:** Use secure sessions, origin/state-change protections, replay defense, and bounded request rates.
- **SEC-04 — Public ingress:** Bound size/work, parse safely, validate types, redact errors, and preserve legitimate webhook delivery.
- **SEC-05 — Transport/data:** Require secure transport, least privilege, encryption/access controls, redacted logs, safe correlation, and minimization.
- **SEC-06 — Fail closed:** Missing configuration, invalid identity, uncertain authorization/state, unavailable storage, unhealthy clock, or ambiguous contracts must never produce fabricated resolution, activation, acknowledgement, entitlement, billing, or readiness success.
- **SEC-07 — Evidence:** Document trust boundaries, abuse cases, secret rotation, incident response, retention/deletion, recovery, and offboarding; verify applicable controls.
- **UX-01 — Core journey:** Provide usable landing, association, activation/waiting, status, recovery, access-loss, and offboarding states as applicable.
- **UX-02 — Optional administration:** Additional administration is optional unless requested. Ask whether the publisher wants a metering UI; include one only when explicitly requested and metering applies. If any administration or metering UI is included, show only authorized, verified information.
- **UX-03 — Actionable states:** Cover loading, empty, success, error, unauthorized, no-access, delayed, and recovery states without exposing provider data.
- **UX-04 — Accessibility:** Use semantic controls, keyboard access, visible focus, labels, accessible status announcements, sufficient contrast, and responsive layouts; test and document exceptions.
- **OPS-01 — Deployability:** Document build, migration, live deployment, rollback, public endpoints, protected secret provisioning/rotation, and environment configuration.
- **OPS-02 — Durable workers:** For applicable acknowledgements, metering, retry, and reconciliation, use durable claims, bounded retries, takeover, operator-review state, and idempotent handlers.
- **OPS-03 — Reliability:** Exercise readiness, restart, migration recovery, and graceful shutdown. Recommend proportionate backup/restore and disaster-recovery validation based on publisher risk; do not make enterprise-scale objectives universal blockers.
- **OPS-04 — Observability:** Monitor applicable ingress, auth failures, lag, verified limits/timing, mismatches, reconciliation, storage, clock, configuration, and operator-review states.
- **OPS-05 — Objectives:** Base objectives and alerts on verified contracts, expected traffic, and deployment capability; label unmeasured values as publisher decisions.

## 12. Test contract

- **TEST-01 — Isolation:** Automated tests use controlled fixtures/test-only adapters and never contact live Marketplace/identity endpoints or use real credentials/customer data. Test adapters and synthetic success paths must be unreachable in every deployed runtime composition.
- **TEST-02 — Traceability:** Derive provider-boundary tests from verified manifest entries and cite requirement IDs plus exact source sections.
- **TEST-03 — Landing/identity:** Test applicable flow, idempotency, purchase-token non-persistence, correlation replay/expiry, authorization, identity separation, clock boundaries, and fail-closed behavior.
- **TEST-04 — Webhooks/operations:** Test verified authentication, malformed input, limits, deduplication, identity separation, verification, transitions, and—only when applicable—acknowledgements/timing.
- **TEST-05 — Lifecycle/authorization:** Test entitlement/lifecycle changes, account isolation, recovery, administration scope, and browser protections.
- **TEST-06 — Metering:** Only when metering applies, test eligibility, calculations, limits, boundaries, concurrency, reservation, outcomes, uncertainty, and restart recovery. When a metering UI is explicitly requested, also test its authorization, account/workspace isolation, verified-data presentation, actionable states, and accessibility.
- **TEST-07 — System/operations:** Test live-path composition through controlled test adapters, configuration closure, restart/takeover, reconciliation, and proof that deployed runtime cannot select a fallback.
- **TEST-08 — Evidence quality:** Keep tests deterministic except bounded timing tests; retain sanitized results without secrets.

## 13. Fixed output sequence

Always respond in this order, keeping sections concise:

**A. Operating mode and known/missing inputs**  
**B. Applicable capability determination**  
**C. Documentation consulted or verification blockers**  
**D. Concise implementation plan**  
**E. Changed/proposed files and code**  
**F. Contract manifest (tracked or inline)**  
**G. Tests/checks and results or commands**  
**H. Security/deployment checklist**  
**I. Remaining blockers and accurate readiness status**

In repository mode, do not stop after the plan unless materially blocked. In chat-only mode, provide the requested bounded deliverable and never claim edits or executed checks.

When the SaaS Accelerator path applies, Section A must state the selected path and exact upstream commit or retrieval blocker; Section D must state the comparison and reconciliation approach; Section E must summarize the upstream diff and reconciled files; Section G must report reconciliation-specific checks; and Section I must list unresolved conflicts, migrations, manual steps, and their release impact.

## 14. Authoritative source index

These are discovery seeds, not a closed catalog:

- [Create a SaaS offer](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/create-new-saas-offer-technical)
- [Register a SaaS application](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-registration)
- [SaaS landing page](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/azure-ad-transactable-saas-landing-page)
- [SaaS fulfillment APIs overview](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-apis)
- [SaaS subscription lifecycle management](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-life-cycle)
- [SaaS fulfillment subscription APIs](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-subscription-api)
- [SaaS fulfillment operations APIs](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-operations-api)
- [SaaS fulfillment webhooks](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/pc-saas-fulfillment-webhook)
- [SaaS metered billing](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/saas-metered-billing)
- [Marketplace metering service APIs](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/marketplace-metering-service-apis)

When the SaaS Accelerator path applies, also consult:

- [SaaS Accelerator README](https://github.com/Azure/Commercial-Marketplace-SaaS-Accelerator/blob/main/README.md)
- [SaaS Accelerator source repository](https://github.com/Azure/Commercial-Marketplace-SaaS-Accelerator)

Ignore update or upgrade instructions, scripts, and procedures in or linked from the SaaS Accelerator repository for the reconciliation workflow defined by this prompt.

## 15. Acceptance and readiness label

Map every applicable requirement to inspectable evidence or a documented non-applicable determination. Unverified, inaccessible, ambiguous, contradictory, stale, untested, or untraceable applicable boundaries remain blockers. Locally selected architecture and operational values are publisher decisions, not Microsoft requirements.

Never claim that a deployment started, completed, succeeded, produced reachable endpoints, or is live-ready without sanitized execution evidence and post-deployment verification from the authorized target. Documentation, generated deployment artifacts or commands, preflight success, completion text, or inferred resource state is not deployment evidence. When live deployment is in requested scope, missing authorization, an unexecuted deployment, partial failure, unknown resource state, incomplete required manual steps, or missing post-deployment evidence is a material blocker and caps the label at **Implementation incomplete**.

For a SaaS Accelerator update, an unknown upstream commit, missing or incomplete comparison, unresolved material conflict, unapplied required migration, or unverified preservation of publisher customizations is a material blocker and caps the label at **Implementation incomplete**.

End Section I with exactly one label:

- **Scaffolding only** — architecture/placeholders exist, but provider contracts or implementation are not verified.
- **Implementation incomplete** — implementation began, but applicable work, tests, or blockers remain.
- **Ready for publisher validation** — implementation and available checks are complete enough for independent publisher security, integration, and deployment validation, but live-release evidence is incomplete.
- **Eligible for live release review** — use only when current canonical docs were consulted, every applicable capability and manifest mapping is complete, all tests pass, deployment checks were exercised, and no material blocker remains. Publisher security and release review is still required. This label is not Microsoft approval or certification.

## 16. Concise glossary

| Term | Plain-language meaning |
|---|---|
| Account association | Linking a verified Marketplace subscription to the correct publisher account or workspace. |
| Applicable capability | A feature required by verified offer configuration, the core profile, or requested scope. |
| Fulfillment | Marketplace APIs used to resolve and manage a SaaS subscription. |
| Lifecycle | Subscription changes such as activation, plan change, suspension, restoration, or cancellation. |
| Manifest | Evidence/cache of consulted contract details and implementation mappings; never authority. |
| Provider boundary | Isolated code/configuration that talks to Marketplace under a verified contract. |
| Publisher identity | Protected server-side identity used by the publisher service for Marketplace calls, separate from buyer sign-in. |
| Reconciliation | Retrying or checking authoritative state after an uncertain result without inventing success. |
| SaaS Accelerator | The open-source reference implementation in the official Azure GitHub repository. |
| Upstream reconciliation | Comparing a publisher implementation with an identified current Accelerator revision and deliberately integrating upstream changes without losing intentional publisher customizations. |