mirror of
https://github.com/Luchexx/wacrm.git
synced 2026-11-02 17:29:45 +00:00
faee4eea44
Drops the "WaCRM" branded name across user-facing surfaces in favour
of a descriptive name. Branded names that imply WhatsApp ownership or
sponsorship are a trademark fair-use risk; a relationship-based name
("CRM Template for WhatsApp") sidesteps that.
Scope:
- Brand text in nav, sidebar, footer, docs shell, mock window chrome.
- SITE_NAME / SITE_DESCRIPTION / legalName in src/lib/seo/site-config.ts.
- README, CONTRIBUTING, docs/, .github/ templates and policies.
- package.json description.
- Auth pages, settings copy, FAQ, code comments.
Out of scope (intentionally — these are infra renames the project
owner should drive separately so links and the package lockfile stay
consistent):
- The github.com/ArnasDon/wacrm repo URL.
- The wacrm.tech domain / homepage field.
- The package.json "name" field.
- The Hostinger application name and Meta system-user name in deploy
docs (existing-deployment instructions).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
125 lines
4.4 KiB
Markdown
125 lines
4.4 KiB
Markdown
# Using this template
|
|
|
|
This is a **template repository**, not a collaborative product. The
|
|
expected flow is:
|
|
|
|
1. **Fork** it to your own GitHub account or organisation.
|
|
2. **Deploy** the fork — see [`docs/`](./docs/README.md).
|
|
3. **Customise** your fork. Rebrand, add the features you need, remove
|
|
the ones you don't, swap hosting, change the schema.
|
|
|
|
You **don't** need to send changes back upstream. The fact that your
|
|
fork diverges is the whole point — the upstream is deliberately
|
|
opinionated about stack, UX, and scope, and your fork is where those
|
|
opinions become yours.
|
|
|
|
## Fork and run
|
|
|
|
```bash
|
|
# 1. Fork on GitHub: https://github.com/ArnasDon/wacrm → Fork
|
|
# 2. Clone your fork
|
|
git clone https://github.com/<your-username>/wacrm.git
|
|
cd wacrm
|
|
|
|
cp .env.local.example .env.local # fill in Supabase + Meta creds
|
|
npm install
|
|
npm run dev
|
|
```
|
|
|
|
Full setup (Supabase migrations, WhatsApp Business API, deploy) lives in
|
|
[`docs/`](./docs/README.md).
|
|
|
|
## Keeping your fork up to date
|
|
|
|
Pull in upstream bug fixes and security patches periodically:
|
|
|
|
```bash
|
|
git remote add upstream https://github.com/ArnasDon/wacrm.git # once
|
|
git fetch upstream
|
|
git checkout main
|
|
git merge upstream/main # or: git rebase upstream/main
|
|
# Resolve any conflicts (likely in areas you've customised), then push
|
|
git push origin main
|
|
```
|
|
|
|
If you've made heavy local customisations, rebasing can surface
|
|
conflicts every time you pull. Pinning to a specific upstream tag and
|
|
updating on your schedule is a valid alternative.
|
|
|
|
## Reporting bugs in the upstream template
|
|
|
|
If you find a bug in the upstream code — not one you introduced in your
|
|
fork — please file it using the
|
|
[bug report](https://github.com/ArnasDon/wacrm/issues/new?template=bug_report.yml)
|
|
template. Including the commit SHA, the runtime (Hostinger / Vercel /
|
|
local / other), and logs will get to a fix fastest.
|
|
|
|
## Reporting security issues
|
|
|
|
**Do not file security issues publicly.** Follow the private flow in
|
|
[SECURITY.md](./.github/SECURITY.md).
|
|
|
|
## Upstream pull requests
|
|
|
|
Not the primary flow, but welcome in specific cases:
|
|
|
|
- **Security fixes** — always welcome, please follow SECURITY.md first
|
|
for disclosure.
|
|
- **Bug fixes** that match upstream intent (crash, correctness,
|
|
documentation errors, typos) — land quickly.
|
|
- **Small improvements** (accessibility, obvious UX nits) — usually
|
|
welcome, open an issue first to check alignment.
|
|
|
|
Less likely to land:
|
|
|
|
- **New features.** The template's scope is intentionally narrow. A
|
|
"great idea for a CRM" is often a great idea for *your* CRM — i.e.
|
|
your fork — but would dilute the template for the next forker.
|
|
- **Stack changes** (different ORM, different UI kit, different auth
|
|
provider). These belong in a fork, not upstream.
|
|
- **Opinionated refactors** without a concrete correctness or
|
|
performance motivation.
|
|
|
|
If you do send a PR, the usual rules apply:
|
|
|
|
- Branch off the latest `main` (don't push to a merged branch — commits
|
|
end up orphaned).
|
|
- Run `npm run typecheck` and `npm run format` locally first.
|
|
- Fill in the PR template, especially the **Test plan**.
|
|
- One logical change per PR.
|
|
- Commit-message first line is imperative + terse; the body explains
|
|
the *why*, the diff shows the *what*.
|
|
|
|
Expect a review within a few days. PRs opened without an issue may be
|
|
closed — open the issue first to align.
|
|
|
|
## If you maintain a public fork
|
|
|
|
- Rebrand. The "CRM Template for WhatsApp" name, favicon, and
|
|
`wacrm.tech` URL belong to the upstream project; please swap them
|
|
for your own before putting your deployment in front of users.
|
|
- Keep the MIT [`LICENSE`](./LICENSE) file — that's how the template's
|
|
permissions travel with the code. Attribution in a `README` section
|
|
is appreciated but not required.
|
|
- You are free to re-license additions to your fork however you like.
|
|
|
|
## Dev-loop reference
|
|
|
|
Even if you never send a PR upstream, these are the scripts you'll use
|
|
in your fork:
|
|
|
|
| Command | What it does |
|
|
| --- | --- |
|
|
| `npm run dev` | Turbopack dev server on port 3000. |
|
|
| `npm run build` | Production build. Next also runs its own typecheck here. |
|
|
| `npm run typecheck` | `tsc --noEmit`. Fast TS-only pass. |
|
|
| `npm run lint` | ESLint. |
|
|
| `npm run format` | Prettier write. |
|
|
| `npm run format:check` | Prettier in check-only mode. Useful in CI. |
|
|
|
|
## Licensing
|
|
|
|
This template is MIT ([`LICENSE`](./LICENSE)). Anything you contribute
|
|
upstream is assumed to be MIT too. Your fork's additions are yours to
|
|
license however you like.
|