saqib mirandClaude Sonnet 5
3e2a5b97a3
Implements tasks T021-T025 from specs/002-saas-integration/tasks.md (User Story 2, P2): an admin can register, rotate, revoke, and change the status of a ProductIntegration, and retrieve its audit trail. - ProductIntegrationsService: register (finds-or-creates the Product by external id), rotate (dual-credential transition window per research.md), revoke, updateStatus, getAuditTrail -- each writes its own AuditLog entry via a new shared integration-audit-log.repository.ts (extracted from the auth plugin, which now reuses it instead of writing to Prisma directly). - Routes: POST /admin/products/:externalProductId/integration, POST/admin/integrations/:id/rotate|revoke, PATCH .../status, GET .../audit-trail -- gated by the existing fastify.authenticate (human/admin JWT) decorator. - New integration test (product-integrations-admin.test.ts) covers Quickstart Scenarios 5-7 end-to-end against a real Postgres/Redis: register+rotate+audit-trail, and revoke-takes-effect-immediately. Verified passing against a live database. Known, pre-existing limitation flagged (not fixed here, out of scope): fastify.authenticate is currently a no-op stub with no real JWT verification, so these admin endpoints aren't actually access-controlled yet -- that depends on the unimplemented identity/auth module. Documented in the contract and checklist notes so it isn't mistaken for done. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Development
docker compose --env-file .env.development -f docker-compose.development.yml up -d --build
Test
docker compose --env-file .env.test -f docker-compose.test.yml up --build
Production
docker compose --env-file .env.prod -f docker-compose.prod.yml up --build -d
Stop
docker compose -f docker-compose.prod.yml down
Local environment setup
.env.development, .env.test, and .env.prod are gitignored (they hold real credentials) —
copy .env.example to the one you need and fill in real values before running any command above.
CI/CD
Every push/PR triggers the Jenkins pipeline defined in Jenkinsfile. Stage order:
checkout → install → environment validation → typecheck → lint → format check → unit test →
integration test → E2E test → build → Docker build → publish → deploy. Publish/deploy only run
on branches with a configured deploy target (main → prod, develop/test → test); other
branches validate and build only. Pipeline run status and per-stage logs are visible in the
Jenkins UI for the relevant job — see specs/001-ci-pipeline/quickstart.md for how to validate
the pipeline itself, and specs/001-ci-pipeline/contracts/pipeline-stage-contract.md for the
guarantees each stage makes.
Required Jenkins credentials (see the header comment in Jenkinsfile for exact IDs): per target
environment (test, prod) a Postgres password, Redis password, JWT secret, and AWS access
key/secret, plus one shared Docker registry username/password. None of these are ever read from
a file in this repository.