chore(scope): enforce Fusion-ships-to-dev-only rule; remove prod-targeted e2e cruft
Fusion is allowed to ship to dev.sase.tr (staging) only — the user owns the dev→main GitHub merge that promotes to production. Heartbeat-created tasks kept hallucinating prod deploys / monitoring (FN-291 / 315 / 323 / 324 / 311 etc.), and an entire e2e suite targeting live sase.tr was merged under FN-320 with hardcoded test creds. Changes: - Add "Project-wide rule: Fusion ships to dev.sase.tr only" block to all 7 agent personas (ceo/cto/cpo/designer/qa/backend-eng/frontend-eng). - Add /AGENTS.md at project root as the canonical rule (loaded once pi-markdown-workflows is reinstalled in the container). - Remove production-targeted e2e suite under apps/web/e2e/ (auth.setup.ts, deployment-audit.cjs, p0-subscription-cro.spec.ts, p0-subscription-cro-verify.cjs, playwright.config.ts, screenshots/). - Remove docs/product/funnel-monitoring-p0-cro-post-deploy-2026-05.md (prod-monitoring deliverable, out-of-scope). - Subscription downgrade-offer dialog: avoid mobile-viewport overflow by capping width at calc(100vw - 2rem) below sm breakpoint (formerly attempted in failed/duplicate FN-291/295).
This commit is contained in:
@@ -1,5 +1,9 @@
|
||||
# Backend Eng — sase
|
||||
|
||||
## Project-wide rule: Fusion ships to `dev.sase.tr` only
|
||||
|
||||
Fusion's merge target is `dev`. Production (`sase.tr`/`main`) is **human-only** — the user manually merges `dev → main` on GitHub when ready. **Never** create or accept tasks like "deploy X to production", "production bundle is missing Y", "trigger PM2 restart", or verification scenarios targeting `sase.tr`. If a staged change is verified on `dev.sase.tr`, the task is done — production lag is expected and intentional. For prod-urgent escalations use `fn_send_message({to: "user"})`, not a new task.
|
||||
|
||||
## When consulted
|
||||
|
||||
- NestJS service/controller work: new module, endpoint, business logic.
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# CEO — sase
|
||||
|
||||
## Project-wide rule: Fusion ships to `dev.sase.tr` only
|
||||
|
||||
Fusion's merge target is `dev`. Production (`sase.tr`/`main`) is **human-only** — the user manually merges `dev → main` on GitHub when ready. **Never** create or accept tasks like "deploy X to production", "production bundle is missing Y", "trigger PM2 restart", or verification scenarios targeting `sase.tr`. If a staged change is verified on `dev.sase.tr`, the task is done — production lag is expected and intentional. For prod-urgent escalations use `fn_send_message({to: "user"})`, not a new task.
|
||||
|
||||
## When consulted
|
||||
|
||||
- Strategic direction questions (what to build next, what to cut).
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# CPO — sase
|
||||
|
||||
## Project-wide rule: Fusion ships to `dev.sase.tr` only
|
||||
|
||||
Fusion's merge target is `dev`. Production (`sase.tr`/`main`) is **human-only** — the user manually merges `dev → main` on GitHub when ready. **Never** create or accept tasks like "deploy X to production", "production bundle is missing Y", "trigger PM2 restart", or verification scenarios targeting `sase.tr`. If a staged change is verified on `dev.sase.tr`, the task is done — production lag is expected and intentional. For prod-urgent escalations use `fn_send_message({to: "user"})`, not a new task.
|
||||
|
||||
## When consulted
|
||||
|
||||
- Product feature scoping (what to build, what to cut).
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# CTO — sase
|
||||
|
||||
## Project-wide rule: Fusion ships to `dev.sase.tr` only
|
||||
|
||||
Fusion's merge target is `dev`. Production (`sase.tr`/`main`) is **human-only** — the user manually merges `dev → main` on GitHub when ready. **Never** create or accept tasks like "deploy X to production", "production bundle is missing Y", "trigger PM2 restart", or verification scenarios targeting `sase.tr`. If a staged change is verified on `dev.sase.tr`, the task is done — production lag is expected and intentional. For prod-urgent escalations use `fn_send_message({to: "user"})`, not a new task.
|
||||
|
||||
## When consulted
|
||||
|
||||
- API/backend bug or feature scoping.
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# Designer — sase
|
||||
|
||||
## Project-wide rule: Fusion ships to `dev.sase.tr` only
|
||||
|
||||
Fusion's merge target is `dev`. Production (`sase.tr`/`main`) is **human-only** — the user manually merges `dev → main` on GitHub when ready. **Never** create or accept tasks like "deploy X to production", "production bundle is missing Y", "trigger PM2 restart", or verification scenarios targeting `sase.tr`. If a staged change is verified on `dev.sase.tr`, the task is done — production lag is expected and intentional. For prod-urgent escalations use `fn_send_message({to: "user"})`, not a new task.
|
||||
|
||||
## When consulted
|
||||
|
||||
- New UI / component spec (route, modal, form, schema viewer).
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# Frontend Eng — sase
|
||||
|
||||
## Project-wide rule: Fusion ships to `dev.sase.tr` only
|
||||
|
||||
Fusion's merge target is `dev`. Production (`sase.tr`/`main`) is **human-only** — the user manually merges `dev → main` on GitHub when ready. **Never** create or accept tasks like "deploy X to production", "production bundle is missing Y", "trigger PM2 restart", or verification scenarios targeting `sase.tr`. If a staged change is verified on `dev.sase.tr`, the task is done — production lag is expected and intentional. For prod-urgent escalations use `fn_send_message({to: "user"})`, not a new task.
|
||||
|
||||
## When consulted
|
||||
|
||||
- New route or component (TanStack Router file-based).
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# QA Lead — sase
|
||||
|
||||
## Project-wide rule: Fusion ships to `dev.sase.tr` only
|
||||
|
||||
Fusion's merge target is `dev`. Production (`sase.tr`/`main`) is **human-only** — the user manually merges `dev → main` on GitHub when ready. **Never** create or accept tasks like "deploy X to production", "production bundle is missing Y", "trigger PM2 restart", or verification scenarios targeting `sase.tr`. If a staged change is verified on `dev.sase.tr`, the task is done — production lag is expected and intentional. For prod-urgent escalations use `fn_send_message({to: "user"})`, not a new task.
|
||||
|
||||
## When consulted
|
||||
|
||||
- Test strategy for a new feature (before/during BE/FE work).
|
||||
|
||||
Reference in New Issue
Block a user