release: dos.me checkout envelope fix + SSO cleanup + CI hygiene

.env.example

@@ -73,6 +73,28 @@ EXCLUDE_QUEUE=""
 # Concurrency divider for worker task allocation (default: 1)
 WORKER_CONCURRENCY_DIVIDER="1"
 
+## Remember to set your public internet IP address in the allow-list for the API token.
+##
+## Cloudflare is currently required to save things like social media avatars for accounts.
+CLOUDFLARE_ACCOUNT_ID="your-account-id"
+CLOUDFLARE_ACCESS_KEY="your-access-key"
+CLOUDFLARE_SECRET_ACCESS_KEY="your-secret-access-key"
+CLOUDFLARE_BUCKETNAME="your-bucket-name"
+CLOUDFLARE_BUCKET_URL="https://your-bucket-url.r2.cloudflarestorage.com/"
+CLOUDFLARE_REGION="auto"
+## Optional media normalization (postiz-uploader on RunPod Serverless). Requires STORAGE_PROVIDER="cloudflare".
+## When set, web uploads are transcoded to 1080p h264 mp4 / downsized images in the background;
+## the media record reports status "processing" until the normalized file replaces the original.
+#RUNPOD_API_KEY=""
+#RUNPOD_ENDPOINT_ID=""
+## Optional video clipping (YouTube video -> captioned vertical clips -> draft posts). Requires STORAGE_PROVIDER="cloudflare",
+## RUNPOD_API_KEY (with access to both endpoints below) and OPENAI_API_KEY. Ingest jobs go to the CPU endpoint, clip jobs to the
+## GPU endpoint of postiz-uploader (which needs its own Oxylabs account to fetch from YouTube); Deepgram transcribes videos
+## that have no usable captions.
+#RUNPOD_INGEST_ENDPOINT_ID=""
+#RUNPOD_CLIPPER_ENDPOINT_ID=""
+#DEEPGRAM_API_KEY=""
+
 # ==============================================================================
 # 4. Storage Providers (Cloudflare R2 or Local Disk)
 # ==============================================================================

.github/workflows/build.yml

@@ -90,5 +90,8 @@ jobs:
         # known ids, so they must not run concurrently against each other.
         run: pnpm exec jest --config tests/bootstrap.jest.cjs --ci --passWithNoTests --runInBand
 
+      - name: Test frontend primitives (vitest)
+        run: pnpm run test:frontend
+
       - name: Build applications
         run: pnpm run build

.github/workflows/eslint.yml

@@ -49,7 +49,7 @@ jobs:
 
       - name: Install ESLint SARIF Formatter
         run: |
-          pnpm add -D @microsoft/eslint-formatter-sarif@2.1.7
+          pnpm add -D @microsoft/eslint-formatter-sarif@3.1.0
 
       - name: Run ESLint
         # Transitional: violations are now VISIBLE as a failed step instead of

.gitignore

@@ -71,3 +71,7 @@ scripts/*.env
 .playwright-mcp/
 .cloudflared/
 
+
+# playwright
+playwright-report/
+test-results/

CHANGELOG.md

@@ -9,6 +9,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Changed
+- **ESLint Workflow Green via eslint 9 Migration**:
+  - Bumped eslint 8.57 -> ^9 and @typescript-eslint/* 7.18 -> ^8; the ESLint workflow had been red because eslint 8 cannot parse the flat `eslint.config.mjs`, so eslint crashed before producing the SARIF file.
+  - CI SARIF formatter moved to `@microsoft/eslint-formatter-sarif@3.1.0`; dead `.eslintignore` removed (eslint 9 ignores node_modules by default). Flat config unchanged; violations stay visible through the SARIF upload under the transitional `continue-on-error` gate (audit C9).
+
 ### Fixed
 - **Customer-Facing UI, SDK and MCP Announcing Upstream Infrastructure (Upstream Endpoint Leaks)**:
   - Root cause: the Branding Guard scanned only AGPL attribution (repo, image, author), so it reported "0 strict branding leaks" while runtime endpoints still pointed at upstream infrastructure.
@@ -28,6 +33,21 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   - Beta container recreated with the same immutable image digest; a one-off boot hang after recreate (backend blocked pre-Nest with no network sockets) was cleared by a plain `docker restart`.
 
 ### Added
+- **Prod Compose Phase B Executed on crove-server (2026-09-21, JOY approved)**:
+  - Installed `scripts/docker-compose.prod.yaml` at `/opt/crove` (backups kept), recreated crove-post / crove-redis / cloudflared with the I-B4 image pin + healthcheck; crove-post reports `healthy`.
+  - Adopted the S18 healthchecks across the Temporal stack: temporal, temporal-postgresql and temporal-elasticsearch all report `healthy`; functional proof via tctl after every step.
+  - Rotated `CROVE_TEMPORAL_POSTGRES_PASSWORD` from the well-known dev default to a 32-char random secret (env files + DB role updated together; temporal reconnects with the new password).
+  - Removed the legacy `crove-postgres` and `postiz-redis` containers (prod verified on Supabase + `crove-redis`; volumes retained).
+  - Two evidence-based corrections merged back into `scripts/docker-compose.prod.yaml`: dynamicconfig stays `development-sql.yaml` (the auto-setup image ships no production template and `./dynamicconfig` shadows the image dir), and the temporal healthcheck probes `$(hostname -i)` instead of localhost (the server binds the container IP - localhost probes reported `unhealthy` while the server was fine).
+  - `docs/ops/prod-compose-reconciliation.md` updated from "plan" to "executed" with deviations and residual items (pg_hba trust rows internal-only, `crove_postgres-volume` kept 2 weeks, crove-web dormant).
+- **Frontend Test Track (Minimal Batch)**:
+  - Added a vitest + Testing Library baseline for shared form primitives (`vitest.frontend.config.ts`, `tests/frontend/`, `pnpm run test:frontend`, CI step in `build.yml`): 14 tests over Button, Textarea and Checkbox. Frontend previously had zero tests.
+  - Added a Playwright smoke E2E harness (`playwright.config.ts`, `tests/e2e/`, `pnpm run test:e2e`): public checks (auth redirect, Crove branding, DOS ID presence, login page) verified against beta; the authenticated compose -> schedule -> calendar flow is scaffolded and activates with `E2E_DOS_EMAIL` / `E2E_DOS_PASSWORD` once a dedicated beta test account exists. Not wired into CI yet.
+  - Added `docs/ops/prod-compose-reconciliation.md` cataloging the prod compose drift on `crove-server` (repo audit hardening vs the older VM deploy copy, legacy `crove-postgres` / `postiz-redis` remnants) and the ordered maintenance-window plan.
+- **Refactor Documentation Suite (Minimal Batch)**:
+  - Added `docs/adr/0001-upstream-sync-and-fork-delta.md` recording the verified upstream-sync policy: the pnpm/App Router/SWR+Zustand structure originated upstream (commit `4ba51565` is contained in `upstream/main`), so the daily sync corridor stays open for both backend and frontend.
+  - Added `docs/fork-delta.md` inventorying every deliberate fork divergence (owned paths, diverging shared files, planned divergence, frozen contracts).
+  - Added `docs/refactor/minimal-batch.md` (approved 2026-09-21) plus its Vietnamese dark-theme reading copy `docs/refactor/minimal-batch-vi.html`: foundation safety (upstream sync, eslint 9 CI green, crove-sso leftovers, prod compose drift) and test/docs baseline (Playwright smoke, Vitest baseline, CLAUDE.md corrections).
 - **MCP Client Icons & Onboarding Enhancements (Upstream Sync)**:
   - Added Nanoclaw and other third-party MCP client icons support in Public API.
   - Upgraded onboarding experience and interactive modal walkthroughs.

CLAUDE.md

@@ -1,48 +1,31 @@
-This project is Postiz, a tool to schedule social media and chat posts to 28+ channels.
+This project is **Crove Post** (`@crove/*`), a fork of [Postiz](https://github.com/gitroomhq/postiz-app) (AGPL-3.0) that schedules social media posts through 35 provider integrations (see `libraries/nestjs-libraries/src/integrations/integration.manager.ts`).
 You can add posts to the calendar, they will be added into a workflow and posted at the right time.
-You can find things like:
-- Schedule posts
-- Calendar view
-- Analytics
-- Team management
-- Media library
-
-This project is a monorepo with a root only package.json of dependencies.
-Made with PNPM.
-We have 3 important folders
-
-- apps/backend - this is where the API code is (NESTJS)
-- apps/orchestrator - this is temporal, it's for background jobs (NESTJS) it contains all the workflows and activities
-- apps/frontend - this is the code of the frontend (Vite ReactJS)
-- /libraries contains a lot of services shared between backend and orchestrator and frontend components.
-
-We are using only pnpm, don't use any other dependency manager.
-Never install frontend components from npmjs, focus on writing native components.
 
-The project uses tailwind 3, before writing any component look at:
-- /apps/frontend/src/app/colors.scss
-- /apps/frontend/src/app/global.scss
-- /apps/frontend/tailwind.config.js
+Fork-specific surfaces (not in upstream): DOS ID SSO (`api.dos.me`), DOS shared billing (`libraries/nestjs-libraries/src/dos-billing`), runtime branding engine (`libraries/helpers/src/utils/brand.config.ts` + `scripts/branding-guard.ts`), DOS ecosystem sync / first-party bootstrap (`apps/backend/src/ecosystem`), and the `apps/web` marketing site. Everything else intentionally tracks upstream. See `docs/adr/0001-upstream-sync-and-fork-delta.md` and `docs/fork-delta.md`.
 
-All the --color-custom* are deprecated, don't use them.
+This project is a monorepo with a root-only package.json of dependencies.
+Made with PNPM. We are using only pnpm, don't use any other dependency manager.
+Never install frontend components from npmjs, focus on writing native components.
 
-And check other components in the system before to get the right design.
+## Layout
 
-When working on the backend we need to pass the 3 layers:
-DTO >> Controller >> Service >> Repository (no shortcuts)
-In some cases we will have
-DTO >> Controller >> Manager >> Service >> Repository.
+- apps/backend - NestJS API. Controllers are thin; most logic lives in libraries.
+- apps/orchestrator - NestJS Temporal worker: workflows, activities, signals.
+- apps/frontend - Next.js 16 App Router dashboard (React 19, port 4200). This is Next.js, not Vite.
+- apps/web - fork-owned Next.js marketing site.
+- apps/extension - Chrome MV3 extension (Vite + crxjs).
+- apps/sdk - published public SDK (`@crove/node`, built with tsup).
+- apps/commands - NestJS CLI commands.
+- libraries/nestjs-libraries - shared backend services: database (Prisma), integrations, uploads, billing, dos-billing, ecosystem, temporal, chat/MCP.
+- libraries/react-shared-libraries - shared frontend primitives: form controls, toaster, translation.
+- libraries/helpers - shared utils (`custom.fetch`, `brand.config`, `ecosystem.config`).
 
-Most of the server logic should be inside of libs/server.
-The backend repository is mostly used to write controller, and import files from libs.server.
+## Frontend
 
-For the frontend follow this:
-- Many of the UI components lives in /apps/frontend/src/components/ui
-- Routing is in /apps/frontend/src/app
-- Components are in /apps/frontend/src/components
-- always use SWR to fetch stuff, and use "useFetch" hook from /libraries/helpers/src/utils/custom.fetch.tsx
+- Routing lives in `/apps/frontend/src/app` with route groups `(app)`, `(extension)`, `(provider)`.
+- Always use SWR to fetch stuff, and use the "useFetch" hook from `/libraries/helpers/src/utils/custom.fetch.tsx`.
 
-When using SWR, each one have to be in a separate hook and must comply with react-hooks/rules-of-hooks, never put eslint-disable-next-line on it.
+When using SWR, each one has to be in a separate hook and must comply with react-hooks/rules-of-hooks, never put eslint-disable-next-line on it.
 
 It means that this is valid:
 const useCommunity = () => {
@@ -57,10 +40,42 @@ const useCommunity = () => {
   };
 }
 
-- Linting of the project can run only from the root.
-- Use only pnpm.
-- Never use RAW SQL queries, always use Prisma.
-- The system is in production with many users, if you want to change something, you need to be sure that you are not breaking anything for existing users and a migration might be needed
+- Client state uses Zustand with two stores: the composer store (`components/new-launch/store.ts`) and the modal manager (`components/layout/new-modal.tsx`). The timezone preference is not Zustand - it is localStorage + dayjs (`components/layout/set.timezone.tsx`). There is no Redux.
+- Styling is Tailwind 3 + SCSS tokens. Before writing any component look at:
+  - `/apps/frontend/src/app/colors.scss`
+  - `/apps/frontend/src/app/global.scss`
+  - `/apps/frontend/tailwind.config.cjs` (note: `.cjs`)
+
+All the --color-custom* are deprecated, don't use them; use the `--new-*` tokens. The design language is documented in `DESIGN.md`.
+`/apps/frontend/src/app/polonto.css` is vendored Polotno/Blueprint CSS, do not hand-edit it.
+
+- Most UI is in `/apps/frontend/src/components`: `new-launch` (post composer), `launches` (planner/calendar), `layout` (app shell), `billing` (DOS shared billing), `agents` (CopilotKit chat), `media` (Polotno editor), `public-api`, `settings`, `auth`.
+- `/apps/frontend/src/components/ui` is nearly empty. Shared form primitives live in `/libraries/react-shared-libraries/src/form`.
+- Backend DTOs are reused in forms via `classValidatorResolver` (intentional coupling, keep it).
+
+## Backend
+
+When working on the backend we need to pass the 3 layers:
+DTO >> Controller >> Service >> Repository (no shortcuts)
+In some cases we will have
+DTO >> Controller >> Manager >> Service >> Repository.
+
+Most of the server logic lives in `/libraries/nestjs-libraries`.
+The backend app is mostly used to write controllers and import from the libraries.
+
+- Never use RAW SQL queries, always use Prisma (schema at `/libraries/nestjs-libraries/src/database/prisma/schema.prisma`).
+- The database is PostgreSQL on Supabase with PgBouncer; the Prisma datasource uses `directUrl` for migrations.
+- Publishing pipeline: `PostsService` starts a Temporal workflow (`postWorkflowV*`); workers run in `apps/orchestrator` with one activity worker per provider task queue.
+- Code must always be generic: provider-specific logic only inside the provider file in `/libraries/nestjs-libraries/src/integrations/social`. Extend the provider interface and call it generically; never write `if (facebookProvider) {}` inside a generic file.
+
+## Temporal rules (load-bearing)
+
+- Workflow files that are already in origin/main can never be changed in place, because changing a workflow fails all its activities. Instead create a new workflow with the version, and everywhere the workflow is being called, change it to the new workflow version.
+- Workflow activity parameters cannot be changed, as it will break the workflow. If we need to change the parameters, create a new activity with the new parameters, and then create a new workflow that uses the new activity.
+
+## Working rules
+
+- The system is in production with many users: make sure changes do not break anything for existing users, and a migration might be needed.
 - Whenever you generate a PR, PR description, or similar, **always** follow the PR Template (.github/PULL_REQUEST_TEMPLATE.md)
 - Every PR description **must** contain a `# QA` section with real, numbered steps a reviewer can follow to verify the change (setup, action, expected result), written so they can be run without asking the author anything. This is not optional and applies to humans and agents alike, including one-line fixes. The section is extracted verbatim and shown on the review board, so:
   - Use the exact heading `# QA` (`# Testing`, `# Test plan`, `# How to test`, `# How to verify`, `# Verification`, `# Steps to test` and `# Manual testing` are also recognised, but prefer `# QA`). The whole heading must match, so something like `## Testing philosophy` is not picked up.
@@ -70,6 +85,6 @@ const useCommunity = () => {
 - Avoid as much as possible creating new files with pure logic of algorithms, it's usually wrong
 - When you write code, make sure that what you add looks like something similar somewhere else in the code, don't make weird patterns
 - When you finished running, run another agents that matches the new code with the existing system code, to see that it looks similar and is not a weird pattern.
-- Workflows files can never be changed if they are already in origin/main, because changing a workflow will fail all its activities, instead create a new workflow with the version, and everywhere the workflow being called, change it to the new workflow version.
-- Workflows activities parameters cannot be changed, as it will break the workflow, if we need to change the parameters, if we need to change the parameters, we need to create a new activity with the new parameters, and then create a new workflow that uses the new activity.
-- Code must always be generic, there can't be a way that a specific logic, let's say facebook or instagram, appear in a file that use a generic logic, instead, we need to edit the interface of the provider, add another function, and then generically call it from the generic code, and then implement the specific logic in the provider implementation. we can't have something like if(facebookProvider) {} inside a non facebook provider file. 
+- Linting of the project can run only from the root.
+- Use only pnpm.
+- Branding guard (`scripts/branding-guard.ts`, enforced in CI) blocks reintroducing upstream endpoints or branding; use `branding-guard-allow:` comments only for deliberate references.

ROADMAP.md

@@ -1,5 +1,7 @@
 # Crove Post Roadmap
 
+> **Current batch (approved 2026-09-21):** the Minimal Batch - foundation safety (upstream sync, eslint 9 CI green, crove-sso leftovers, prod compose drift) and test/docs baseline (Playwright smoke, Vitest baseline, CLAUDE.md corrections, ADR-0001 + fork-delta inventory). Scope and deferrals: `docs/refactor/minimal-batch.md`. UI items below stay deferred until that batch is reviewed on beta.
+
 ## 1. Frontend & UI/UX Modernization (Crove OS Standards)
 
 - [ ] **Design System & Visual Refresh**:

SECURITY.md

@@ -44,7 +44,7 @@ We consider an issue a vulnerability when it is a weakness in an in-scope, suppo
 
 ## Contacting Us
 
-All security correspondence goes through [GAdvisory](https://postiz.gadvisory.org/request), our security advisory platform. The form routes four types of request:
+All security reports and related correspondence must be submitted through [GAdvisory](https://postiz.gadvisory.org/request), our security advisory platform. The form routes four types of request:
 
 - **Report a vulnerability.** See [Reporting Security Vulnerabilities](#reporting-security-vulnerabilities).
 - **Dispute a CVE or Advisory.** Challenge the validity of a record we published. Disputes and their resolution are public and permanent. Our CVE Record Dispute Policy is linked from this flow.
@@ -64,7 +64,7 @@ If you discover a security vulnerability in the Postiz app, report it through [G
 - Steps to reproduce the vulnerability
 - Any relevant code or configuration files
 
-If the report has immediate urgency, please also contact one (or more) of the maintainers via email:
+Email the maintainers only when the report requires immediate, time-critical attention. Email does not replace submitting the report through GAdvisory.
 
 - @egelhaus ([E-Mail](mailto:egelhaus@ennogelhaus.de))