Verify Infrastructure

This Skill references the current forgentic Railway infrastructure. Update it when infrastructure changes.

When to Use

Running the post-setup verification checklist after setup, rebuild, or ad-hoc health check.

Prerequisites

• Playwright MCP available as a deferred tool
• Required credentials are available through environment variables on the forgentic container or through the relevant MCP/tool configuration
• Railway MCP available as a deferred tool

Procedure

1. Check for existing Verify document at Forge/Output/Verify_Infra_YYYY_MM_DD.md for today’s date.

   • If it exists, continue with incomplete items (⬜).
   • If not, use Create Page skill to create it in Forge/Output/ with the current date.

2. Populate the Verify document by reading “Part D: Post-Setup Verification Checklist” in Forge/Forge_Setup.md. For each subheading in Part D, create a subheading and a three-column table: | Check | Status | Notes | with every item set to ⬜.

3. Build, git add, commit, push the Verify document and sidebar update.

4. Prepare for Playwright verification:

   • Read Forge/Skills/Playwright_MCP/SKILL.md
   • Consult the Playwright MCP skill’s current credential/environment-variable guidance for credentials
   • Never use page.screenshot (causes “No endpoints found that support image input” error)
   • Use Accessibility Tree (browser_snapshot) to verify page contents

5. Run automated verification on each item:

   • Skip items requiring Operator intervention (leave as ⬜)
   • Mark verified items: ✅ (pass), ⚠️ (warn), 🛑 (fail)

6. Co-verify remaining items with the Operator, presenting items in numbered groups:

   1. Identify the next group of related incomplete items (e.g., multiple backups on the same dashboard, multiple env vars in the same service). Each group gets a number.
   2. Give clear instructions to the Operator on how to test the item:
      • Number each group (“1. Railway Backups”, “2. RoboForm Backups”, etc.)
      • Where to go
      • What to do
      • Exact details (name of env vars, etc.)
      • End with: Reply with: Pass | Warn | Fail
      • Expected result
   3. STOP - wait for user input
   4. Operator follows testing instructions and enters result
   5. Verify the outcome and mark the item: ✅ (pass), ⚠️ (warn), 🛑 (fail)
   6. Move back to step 1. in a loop until no items are incomplete

7. Finalize the Verify document — after all items are resolved, add below the tables:

   • ### Results — total Fail, Warn, Pass counts
   • ### Issues found — numbered list of issues, or “None”

8. Git add, commit, push.

9. Output only the Results and Issues to the Operator.

10. End with: Verification report is ready at [Verify Infra {YYYY-MM-DD}](https://os.uvilo.com/{path to Verify document})

Rules

• Status values: ⬜ (incomplete), ✅ (pass), ⚠️ (warn), 🛑 (fail)
• Never use page.screenshot — always use Accessibility Tree
• Vercel-protected sites: always include both bypass query params on first navigation
• Credentials come from environment variables or tool-specific MCP configuration — never from a former secrets file