# SPEC — F-001 Scaffold modular monolith skeleton

## Problem
No codebase exists. MercadoDeVida vNext needs a boring, typed, modular home before any business feature.

## Goal
TypeScript modular monolith skeleton with strict module boundaries and a green toolchain.

## Non-goals
- No business logic
- No database access
- No frontend

## User story
As a developer (human or AI), I can run install/build/lint/typecheck/test from `project/` and get a running HTTP app with a health endpoint, so every later feature starts from a known green base.

## Functional requirements
1. `project/` contains a Node + TypeScript app with Fastify.
2. Layout: `src/modules/`, `src/shared/`, `src/infrastructure/`, `src/app/`.
3. Every module folder exposes its public API through `index.ts`.
4. A boundary checker fails when a module imports another module's internal files.
5. `GET /health` returns 200 `{"status":"ok"}`.

## Business rules
- Modules communicate only through public interfaces (`index.ts`).
- Composition happens only in `src/app` (composition root).

## Inputs
- `GET /health`: none.

## Outputs
- `GET /health`: `200 application/json {"status":"ok"}`.

## Edge cases
- Invalid route → 404 JSON envelope.
- Server start failure (port busy) → non-zero exit with clear error.

## Acceptance criteria
1. `npm install`, `npm run build`, `npm run lint`, `npm run typecheck`, `npm test` all green in `project/`.
2. `GET /health` returns HTTP 200 with `{"status":"ok"}`.
3. `src/modules`, `src/shared`, `src/infrastructure`, `src/app` exist.
4. A module importing another module's internal file fails the boundary check (demonstrated by test).
5. `./scripts/verify.sh` green at repo root.

## Dependencies
- None (first ticket).

## Security implications
- No secrets, no auth surface. Error responses must not leak stack traces.

## SEO implications
- None.

## Performance implications
- None measurable yet; baseline latency observable via test only.