Promotions

Promotions is the review and release surface for validated Staging changes. The Assistant commits only after validation; Promotions owns the files, diff, dependencies, Undo, GitHub, and release state.

​

Reading Staging

Cards are shown newest first on a Staging rail. The rail records when each change was applied; connectors and Depends on #… labels show the actual requirements between proposals. Two adjacent cards are not automatically dependent. A dependency can come from a dbt ref, semantic object, Evidence query relation, changed schema node, deletion, or overlapping file. Older cards created before dependency metadata existed are shown as a conservative group so Platinur never separates them based on a guess. Open Details for the side panel:

• Overview shows the request, validation, dependencies, and release metadata.
• Diff lists changed files collapsed by default. Expand one file or all files to inspect the code-style diff; its repository path appears above the code.
• The small Assistant button beside a file starts a new chat with that file attached.

The GitHub button opens the generated-model folder on the active environment branch.

​

Undo

The compact Undo action on a Staging card checks dependencies before the confirmation opens.

• If another staged proposal requires the target, Undo is blocked and names the dependent work.
• If it is independent, Platinur reconstructs every survivor on current Production and validates that state before changing Git or the workspace.
• After validation, Staging resets and replays the survivors in their original order. Production is not affected.
• Dashboard deletion Undo restores the former group assignment and only deliveries paused by that deletion. Revoked share links remain revoked and may be recreated.

Undo is unavailable while a release PR owns the Staging lock.

​

Prepare a release

Press Prepare release to open the release side panel.

1. Select changes. All staged work starts selected. Uncheck independent work that should wait.
2. Review dependencies. If a selected proposal requires an earlier proposal, Platinur includes it automatically and marks it Required dependency.
3. Review the Production delta. The panel shows included changes, work staying in Staging, and exact files that would change in Production.
4. Name the release. The editable name becomes the pull-request title. Add an optional description or ask the Assistant to draft both.
5. Validate release. Platinur builds and validates the exact Production candidate and the full Staging state that will remain after release.
6. Publish release. Platinur creates a fixed branch from current Production, opens the GitHub pull request, merges it when repository rules allow, syncs Production, reconstructs remaining Staging work, and starts the production refresh.

Changing the selection after validation invalidates the preflight. Production or Staging moving after validation also fails closed and requires another preflight.

​

GitHub behavior

The PR head is a unique release branch created from the current Production commit. It contains only the reconstructed, dependency-closed release—not the moving cumulative staging branch. This means an independent change can remain in Staging even if it was applied earlier than a released change. After merge, Platinur resets Staging to the new Production commit and replays the remaining proposals. Release safety no longer depends on retaining the old Staging commit ancestry. If repository rules permit, Platinur merges automatically. Otherwise merge or close the PR in GitHub and Promotions reconciles it. Only one release PR may be active per account. If the repository is not configured and the Platinur GitHub App can create repositories, the first Staging commit lazily creates a private platinur-<company-slug> repository. Otherwise the action routes you to GitHub configuration.

​

After merge

• Included proposals become deployed and remain beneath the named release for audit.
• Production syncs from its configured branch and starts dbt/Evidence refreshes.
• If every proposal was included, Staging resets to Production and the active list clears.
• If independent work remains, it is replayed in its original order on the new Production base and one combined Staging refresh starts.

A production refresh failure does not roll back or relabel the GitHub release. It is a separate operational failure in Monitoring.

​

When a release stops

• Validation fails: no PR is created. Fix or regroup the affected proposal and validate again.
• State moved after validation: the stale plan is rejected; reopen or revalidate the composer.
• PR closed without merging: the lock clears and every proposal stays staged.
• Branch protection: the PR remains open for required checks or review; merge it in GitHub.
• Conflict with Production: close or resolve the active PR before another release.
• Staging reconstruction fails after merge: Production remains released and Promotions records a reconstruction failure for reconciliation; it never pretends Production rolled back.
• Production refresh failure: the release stays merged; inspect the dbt/Evidence run in Monitoring.