Saas-voc-server/TASKS.md

Backend implementation tasks

Status date: 2026-07-23

Phase 1 - isolated backend baseline

• Create E:\workspace\server\saas-voc-server as an independent Git repository.
• Keep moshengqi-server and future-server read-only.
• Add strict environment validation without credential fallbacks.
• Add pooled PostgreSQL access and an idempotent migration runner.
• Add an independent Parse Server application configuration.
• Add the initial domestic VOC schema, constraints, foreign keys, and indexes.
• Seed the demashi workspace and JD source metadata.
• Add health, sync, job-status, and snapshot endpoints.
• Add a database-free local-demo server for frontend integration using the normalized Demashi snapshot.
• Add Fmode timeout/retry/authentication behavior behind a server-only client.
• Add unit tests and compile under strict TypeScript settings.
• Add a shared platform repository contract with local-memory and PostgreSQL implementations.
• Add Parse-session authentication, workspace membership, and four-role RBAC.
• Add cursor-paginated product, relation, review, job, import, and platform workflow APIs.
• Add analysis requests, action workflows, alerts, and audit history without fake AI results.
• Cover local platform flows, viewer write denial, Parse session behavior, pagination, and audit writes.
• Run migrations against a newly provisioned PostgreSQL database.
• Smoke-test the local HTTP service under the supported Node 22 runtime.

Phase 2 - case-data persistence

• Add a batch importer for the normalized Demashi dataset.
• UPSERT 2,817 operating products, 38 relation stubs, and 9,717 daily metric rows in bounded batches.
• UPSERT 40 competitor relations with deterministic relation keys.
• Verify snapshot totals against demashi-summary.json.
• Switch DomesticDatasetService between static case mode and backend API mode.
• Run the existing 29-route desktop/mobile audit against API mode.

Phase 3 - real JD source contract

• Verify the existing Fmode gateway health endpoint over public TLS (HTTP 200 on 2026-07-23).
• Complete quota-controlled live JD product and review requests through the existing Fmode gateway using a process-only credential.
• Confirm the catalog JD product-detail path and required itemId parameter.
• Confirm the catalog JD review path and optional page parameter.
• Confirm the live double-data response envelope and first-page review pagination metadata.
• Confirm whether an empty first review page with next-page metadata represents collection-in-progress, then capture one non-empty sanitized review fixture.
• Save sanitized response fixtures without credentials or personal data.
• Implement JD product and review adapters against company-gateway contract fixtures.
• Process queued jobs with partial-failure events and bounded retries.
• Implement idempotent product/review UPSERT and truthful job progress updates.
• Verify source UPSERT and snapshot totals against the provisioned PostgreSQL database.

Phase 4 - deployable closure

• Provision a dedicated PostgreSQL database and least-privilege runtime role.
• Provision independent Parse application credentials.
• Put TLS and same-origin reverse proxying in front of /parse and /api/domestic-voc.
• Add backend authentication, workspace authorization, and role permission boundaries.
• Enable and integrate the frontend AuthGuard after Parse credentials and the first user are provisioned.
• Add backup, restore, retention, and failed-job replay procedures.
• Resolve or formally accept remaining moderate Parse transitive advisories.
• Complete end-to-end acceptance with Demashi product detail and real review evidence.

Explicitly deferred

• Multi-platform adapters beyond JD.
• Multi-tenant billing, SSO provisioning, and custom roles beyond the four built-in roles.
• Scheduled full-catalog crawling.
• AI reports, sentiment, pain points, or recommendations without review evidence.
• Any reuse of the cross-border production database or credentials.