Runbook de incidentes y rollback

[Kalebtron1]

Why this matters

A single runbook reduces incident time and lowers the chance of ad-hoc fixes.

Problem

There is no document that explains what to do when a deploy or flow fails.

Scope

• Add a short incident runbook with rollback steps and contact points.
• Document the production URLs, env vars, and deploy verification steps.
• Keep the runbook short enough to follow during an incident.

Implementation guidance

• Use docs/flows.md, README.md, vercel.json, and .env.example as the main references.
• Document the normal deploy path and the rollback path.
• Link the runbook from the main README if useful.

Out of scope

• Building a full support process or on-call rotation.
• Writing a long-form architecture guide.

Acceptance criteria

• PR includes the runbook content and links to the relevant files.
• Reviewer can follow the document to reproduce the deploy or rollback steps.
• The PR explains what checks should be done after a deploy.

Validation

• Review the runbook against the current deploy flow.
• Confirm every command or path in the document exists in the repo.
• Run the deploy path locally or document why it is not runnable locally.

PR requirements

• Include Closes #37.
• Keep the runbook concise and action-oriented.
• Note any production-only steps that cannot be reproduced locally.

Complexity

• Trivial (50 points)

[Jujukoder]

@Jujukoder has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

Good Morning, Maintainer. How are you doing? I'm interested in this issue, and I can solve it.

Thank you in advance!

Please Again!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Jujukoder to this issue.

[Cerome360]

@Cerome360 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hello maintainer, I'd like to work on #37. I read through the issue, and I appreciate that the goal is to create something people can actually rely on during an incident, not just another documentation page. Looking forward to contributing.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Cerome360 to this issue.

[maixuancanh]

@maixuancanh has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Hi, I'd like to write this as an operational runbook rather than a generic deployment guide. I'll derive the deploy and rollback paths from README.md, docs/flows.md, vercel.json, and .env.example, list only verified URLs and environment-variable names, and include concise post-deploy health checks and escalation points without exposing secrets. I'll validate every command and path and clearly mark any production-only step that cannot be reproduced locally.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @maixuancanh to this issue.

[Ifeanyiezeokafor]

@Ifeanyiezeokafor has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Why You Should Choose Me for This Task
I should be chosen for this task because I have solid experience in DevOps documentation, continuous deployment, and emergency incident response operations.
During a high-stress production outage, developers do not have time to read long-form architecture manuals or guess configuration parameters. They need a concise, bulletproof blueprint. I specialize in translating complex infrastructure environments into highly actionable, step-by-step incident responses that minimize System Recovery Time (MTTR).
Here is how my expertise aligns with your acceptance criteria:

• Action-Oriented Runbook Design: I know exactly how to structure emergency documentation. I will author a highly scannable incident runbook that outlines reproducible deployment and rollback steps, production URLs, critical environmental variables, and emergency escalation contacts without adding unnecessary fluff.
• Meticulous Path & Command Verification: I do not write theoretical documentation. I will cross-reference every path, script, and config option against your actual repository contents (vercel.json, .env.example, docs/flows.md) to guarantee that every terminal command works perfectly when followed sequentially under pressure.
• Strict Post-Deploy Validation Logic: I understand that rolling back is only half the battle; you must verify the fix. I will include an explicit, step-by-step verification checklist detailing exactly what network health markers, UI behaviors, and logs must be checked to confirm a recovery is successful.
• Ecosystem Awareness: I will clearly distinguish between local testing capabilities and production-only constraints, ensuring that contributors can easily understand the pipeline without guessing missing deployment steps.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ifeanyiezeokafor to this issue.