Pular para conteúdo

Tasks: Public API Build Configuration

Input: Design documents from /specs/001-api-build-url/

Prerequisites: plan.md, spec.md, research.md, data-model.md, build contract, and quickstart.md

Tests: This hotfix uses production build, image, and browser smoke verification rather than a new test framework.

Phase 1: Setup

Purpose: Establish the deploy-facing configuration contract before code changes.

  • T001 [P] Record NEXT_PUBLIC_API_URL and the Dokploy Build Time Argument procedure in prontuare-web/.env.production.example and prontuare-web/README.md

Phase 2: Foundational Configuration

Purpose: Make the public API destination available before the Next.js browser bundle is built.

⚠️ CRITICAL: Complete this phase before validating either user story.

  • T002 Update prontuare-web/Dockerfile to accept NEXT_PUBLIC_API_URL as a Docker build argument and expose it only to the build stage before pnpm run build

Checkpoint: The image has an explicit build-time configuration boundary.

Phase 3: User Story 1 - Use the deployed API (Priority: P1) 🎯 MVP

Goal: A clinician's browser sends every web API request to the configured public API host.

Independent Test: Build with https://prontuare-api.inviosat.com, run a browser authentication flow, and confirm the request host does not contain localhost.

  • T003 [US1] Update client API-base resolution and production validation in prontuare-web/lib/api.ts so a production bundle cannot use an absent, invalid, or localhost API destination
  • T004 [US1] Build prontuare-web/Dockerfile with the public API build argument and verify the compiled output does not contain http://localhost:3301
  • T005 [US1] Run the authentication browser smoke flow from specs/001-api-build-url/quickstart.md and record the observed public API request host

Checkpoint: User Story 1 is usable and independently verified.

Phase 4: User Story 2 - Make configuration failures visible (Priority: P2)

Goal: A deploy owner receives an actionable build error instead of a broken localhost bundle.

Independent Test: Run a production image build without the required build argument and confirm the failure names NEXT_PUBLIC_API_URL.

  • T006 [US2] Run a development build without NEXT_PUBLIC_API_URL and verify the documented local API default remains available in prontuare-web/lib/api.ts
  • T007 [US2] Run the negative Docker build from specs/001-api-build-url/quickstart.md and verify the failure names NEXT_PUBLIC_API_URL
  • T008 [US2] Verify prontuare-web/README.md distinguishes Dokploy Build Time Arguments from runtime Environment Variables and requires a rebuild after changes

Checkpoint: User Story 2 is independently verified.

Phase 5: Deployment and Cross-Cutting Validation

Purpose: Validate the actual artifact and leave reproducible evidence.

  • T009 Run pnpm run build in prontuare-web/ with the production API destination and confirm type checking and route generation succeed
  • T010 Run all steps in specs/001-api-build-url/quickstart.md against the Dokploy web deployment after rebuilding it with NEXT_PUBLIC_API_URL=https://prontuare-api.inviosat.com
  • T011 Commit the approved spec artifacts and hotfix files, then report the commit, image/build result, browser evidence, and any untested deployment step

Dependencies & Execution Order

  • T001 can run in parallel with T002.
  • T002 blocks T004 and T007.
  • T003 blocks T004, T005, and T006.
  • T004 and T005 complete User Story 1.
  • T006 and T007 complete User Story 2; T008 verifies its operator documentation.
  • T009 and T010 require both user stories. T011 is last.

Parallel Opportunities

  • T001 and T002 affect separate files and can run in parallel.
  • After T003, the positive and negative image checks are separate commands, but they should be executed serially if Docker capacity is constrained.

Implementation Strategy

  1. Complete T001–T003 and validate the production build interface.
  2. Complete the P1 image/browser smoke test before touching deployment documentation beyond the necessary operator instructions.
  3. Complete the P2 negative build check.
  4. Rebuild on Dokploy only after both local checks pass, then record the production smoke result.