When a provisioning operation fails, the outcome card gives only the recorded error and a generic instruction. The check that explains the failure is far down the page.
provisioning-presentation.ts:91-93 describes every failure as "Review the recorded failure and execution evidence before submitting another operation."
The failing check's expected and observed values only appear in the checks list (ProvisioningProgress.svelte:62-70), below the phases, the command card and the checkpoints. On a failed rebuild at 1440 px wide, the map check starts about 1,850 px down the page.
The outcome card already links to logs, diagnostics and map configuration (+page.svelte:137), but not to the evidence those links would act on.
Fix
Show the failing or blocking check in the outcome card as one line, e.g. "Map check: expected zombie_moon, observed zombie_theater"
Replace the generic failure description when a failing check is known
When a provisioning operation fails, the outcome card gives only the recorded error and a generic instruction. The check that explains the failure is far down the page.
- `provisioning-presentation.ts:91-93` describes every failure as "Review the recorded failure and execution evidence before submitting another operation."
- The failing check's expected and observed values only appear in the checks list (`ProvisioningProgress.svelte:62-70`), below the phases, the command card and the checkpoints. On a failed rebuild at 1440 px wide, the map check starts about 1,850 px down the page.
The outcome card already links to logs, diagnostics and map configuration (`+page.svelte:137`), but not to the evidence those links would act on.
**Fix**
- [ ] Show the failing or blocking check in the outcome card as one line, e.g. "Map check: expected zombie_moon, observed zombie_theater"
- [ ] Replace the generic failure description when a failing check is known
Closing this as not needed. The issue overstated the problem.
On the real verification failures, the recorded error already shown in the outcome card explains the cause:
An unhealthy container fails with "Container is still unhealthy after recovery restart and rebuild. Inspect the server before retrying." (native.ts:411)
An old Plutonium revision fails with "Running Plutonium r… is older than production r…" (native.ts:751)
Showing the failing check next to that error would mostly repeat it. The part that does stand, the generic "Review the recorded failure and execution evidence…" description (provisioning-presentation.ts:101), is covered by #88.
Closing this as not needed. The issue overstated the problem.
On the real verification failures, the recorded error already shown in the outcome card explains the cause:
- An unhealthy container fails with "Container is still unhealthy after recovery restart and rebuild. Inspect the server before retrying." (`native.ts:411`)
- An old Plutonium revision fails with "Running Plutonium r… is older than production r…" (`native.ts:751`)
Showing the failing check next to that error would mostly repeat it. The part that does stand, the generic "Review the recorded failure and execution evidence…" description (`provisioning-presentation.ts:101`), is covered by #88.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When a provisioning operation fails, the outcome card gives only the recorded error and a generic instruction. The check that explains the failure is far down the page.
provisioning-presentation.ts:91-93describes every failure as "Review the recorded failure and execution evidence before submitting another operation."ProvisioningProgress.svelte:62-70), below the phases, the command card and the checkpoints. On a failed rebuild at 1440 px wide, the map check starts about 1,850 px down the page.The outcome card already links to logs, diagnostics and map configuration (
+page.svelte:137), but not to the evidence those links would act on.Fix
Closing this as not needed. The issue overstated the problem.
On the real verification failures, the recorded error already shown in the outcome card explains the cause:
native.ts:411)native.ts:751)Showing the failing check next to that error would mostly repeat it. The part that does stand, the generic "Review the recorded failure and execution evidence…" description (
provisioning-presentation.ts:101), is covered by #88.