Publish a change and verify what users receive

# Apply the “Publish a change and verify what users receive” guide in your agent

## Objective
Identify the exact candidate, validate its important behavior and publish only within the authorized scope. After deployment, check the served version and the affected public journey. Prepare the previous immutable deployment and any data-compatibility limits before calling rollback a recovery plan.

## Prerequisites
- Inspect the repository, documentation, and existing conventions.
- Confirm the need matches the guide scope: Separate local tests, CI, Preview, Production and a recoverable rollback decision.
- Preserve the correct decisions already in place.

## Guide steps
- 1. Identify the candidate — Record repository, branch, commit and target environment. Check for unrelated or private files before committing. A local build can pass while a different commit is deployed. Choose checks based on changed risk: affected behavior, important failure and artifact integrity. Respect required project checks, but do not rerun unrelated matrices after a documentation-only adjustment.
- 2. Understand environment differences — Preview validates a candidate under its own access and configuration. Production may have different variables, domains and data. Confirm the target project rather than choosing a similarly named deployment. Never copy secrets into reports to prove configuration. Report presence or a scoped functional result. A protected Preview that could not be opened stays unverified, even when its build succeeded.
- 3. Example: publish a help guide — For a bilingual guide, check both routes, canonical links and the copied instruction. After merge and deployment, read the public build identity and open the actual guide from its hub. A health response proves only what that endpoint checks. It does not prove every interaction or a database migration. Test the changed public action separately and avoid real destructive writes for verification.
- 4. Prepare rollback limits — Record the previous immutable deployment and the supported reassignment procedure. Check whether current data and migrations remain compatible with it. Restoring old code does not reverse a destructive migration or recover deleted data. Execute rollback only with authorization and a defined trigger. Prefer a verified existing deployment when the platform supports it; rebuilding the old commit can produce different dependencies or configuration.
- 5. Report the evidence chain — List local check, remote commit, CI result, deployment and public verification separately. If a stage is blocked, name that stage and the next concrete action rather than declaring everything delivered. This workflow is provider-neutral guidance, not a deployment script or permission to publish. Store release, human utility and field performance are separate evidence layers.

## Acceptance criteria — Verify in your product
- The candidate commit is known.
- The target environment is verified.
- Relevant checks are attached.
- Public identity matches the deployment.
- The affected journey works.
- Rollback data limits are explicit.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Anchor the guide in the project

## Objective
Turn the applied steps into durable repository conventions.

## Checks
- Link each decision made to the guide step that justifies it.
- Add the checklist to the relevant reviews.
- Record out-of-scope cases for the neighboring guides.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:a5bb432215c78c6f5e40d277bb6cbe8e1cf1f93f7a14ce8c8f4e6cbbe2cdcae7

# Diagnose a failed application of the “Publish a change and verify what users receive” guide

## Observed symptom
[DESCRIBE THE SYMPTOM HERE]

## Observable checks
- Replay the steps in order and note the first one that diverges:
- 1. Identify the candidate — Record repository, branch, commit and target environment. Check for unrelated or private files before committing. A local build can pass while a different commit is deployed. Choose checks based on changed risk: affected behavior, important failure and artifact integrity. Respect required project checks, but do not rerun unrelated matrices after a documentation-only adjustment.
- 2. Understand environment differences — Preview validates a candidate under its own access and configuration. Production may have different variables, domains and data. Confirm the target project rather than choosing a similarly named deployment. Never copy secrets into reports to prove configuration. Report presence or a scoped functional result. A protected Preview that could not be opened stays unverified, even when its build succeeded.
- 3. Example: publish a help guide — For a bilingual guide, check both routes, canonical links and the copied instruction. After merge and deployment, read the public build identity and open the actual guide from its hub. A health response proves only what that endpoint checks. It does not prove every interaction or a database migration. Test the changed public action separately and avoid real destructive writes for verification.
- 4. Prepare rollback limits — Record the previous immutable deployment and the supported reassignment procedure. Check whether current data and migrations remain compatible with it. Restoring old code does not reverse a destructive migration or recover deleted data. Execute rollback only with authorization and a defined trigger. Prefer a verified existing deployment when the platform supports it; rebuilding the old commit can produce different dependencies or configuration.
- 5. Report the evidence chain — List local check, remote commit, CI result, deployment and public verification separately. If a stage is blocked, name that stage and the next concrete action rather than declaring everything delivered. This workflow is provider-neutral guidance, not a deployment script or permission to publish. Store release, human utility and field performance are separate evidence layers.

## Possible causes
- A step was skipped or executed out of order.
- The actual need falls outside the guide scope.
- A checklist criterion was never verified.

## Bounded fixes
- Redo only the diverging step and what depends on it.
- Document the gap if the guide scope does not cover the need.

## Final verification — Verify in your product
- The candidate commit is known.
- The target environment is verified.
- Relevant checks are attached.
- Public identity matches the deployment.
- The affected journey works.
- Rollback data limits are explicit.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Prevent the next drift

## Objective
Turn the first diverging step into an explicit project check.

## Checks
- Add a focused check on the step that diverged.
- Verify the checklist on a second real case.
- Document the scope limit you hit.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:e305db5a6d82092570b6f6680c3a65f172c5e640c6a90c5a698d3eb3b41032fc