Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ProcesosAgilesUMSS/sansistore/llms.txt

Use this file to discover all available pages before exploring further.

SansiStore follows a three-tier branching strategy designed for continuous integration with Vercel auto-deploys. Every change flows through a feature branch, a QA gate on main, and finally into production at the end of each sprint.

​
Branch Tiers

BranchPurposeURL
feature/*, fix/*, chore/*Day-to-day work, branched from mainpreview deploy per PR
mainStaging / QA (pre-release)https://sansistore-test.vercel.app
productionLive sitehttps://sansistore-umss.vercel.app
Vercel automatically deploys every push. Pushing to main updates the staging environment; merging into production updates the live site. PR branches get their own ephemeral preview URL.

​
Daily Workflow

1

Start from an issue

Every branch must be traceable to a GitHub issue — User Story, Bug, or Task. Create the issue first, then branch from main using a descriptive prefix:
git checkout main && git pull
git checkout -b feature/123-add-product-search
# or: fix/456-cart-total-rounding
# or: chore/789-update-deps
2

Open a pull request

Push your branch and open a PR into main. Fill in the PR template — keep the description clear about what changed and why. Link the related issue.
3

CI must pass

The pull request is not mergeable until all CI checks are green (lint, type-check, unit tests, and E2E tests).
4

Get approval and merge

At least one teammate must approve the PR. Once approved and CI is green, squash-merge into main. Delete the feature branch after merging.

​
Sprint Release (main → production)

1

QA sign-off on staging

After each sprint the team verifies the staging site at https://sansistore-test.vercel.app. Run the full E2E suite and confirm all acceptance criteria are met.
2

Open the release PR

Open a pull request from main → production. The PR title should include the sprint number, e.g. release: sprint 4.
3

Merge to production

Merge the PR after QA sign-off. Vercel deploys to https://sansistore-umss.vercel.app automatically.

​
Hotfix Workflow

Use this only for critical bugs discovered on the live site that cannot wait for the next sprint.
1

Branch from production

git checkout production && git pull
git checkout -b hotfix/order-payment-crash
2

Fix, test, and PR into production

Apply the minimal fix, ensure CI passes, and open a PR directly into production. Do not bundle unrelated changes.
3

Back-merge production → main

After merging the hotfix into production, immediately open a follow-up PR to merge production back into main so staging stays in sync.
git checkout main && git pull
git merge production
git push origin main

​
Global Rules

Breaking these rules can corrupt the shared history and block the entire team.
  • Never force-push to main or production.
  • Never push directly to main or production — all changes go through a PR.
  • Always start from an issue — no branch without a GitHub issue.
  • Use the PR template and keep descriptions clear.
  • CI must pass before merging any PR.

​
Daily Scrum Report

Log daily progress in the ScrumReports/ folder. Each team has a dedicated file (e.g., ScrumReports/scrum_report_core_devs.md). Append a new entry for each working day using the template below. 
- **Yesterday:** <what you completed> (include commit SHAs or PR/Issue # if relevant)
- **Today:** <what you will work on>
- **Blockers:** <None | describe the blocker and what you need to unblock>
Linking commit SHAs or PR numbers in the Yesterday field makes it trivial to trace work back to code during sprint retrospectives.

Build docs developers (and LLMs) love

Get started for freeTalk to us