Define production foundation and project boundaries

docs/README.md

@@ -29,6 +29,9 @@ Use these when setting up or operating the project.
 
 Use these to understand system boundaries.
 
+- [Production Foundation And Project Boundary Design](superpowers/specs/2026-07-11-production-foundation-design.md):
+  production boundaries, reliability requirements, engineering standards, and
+  phased branch delivery plan.
 - [Model Integration Framework](model-integration-framework.md): Java-to-Python
   model-service contract, model runtime configuration, and weight handling.
 - [Async Detection Jobs](async-detection-jobs.md): Redis-backed asynchronous
@@ -42,14 +45,17 @@ These documents are useful for understanding how the project evolved.
 - [Frontend API Integration Plan](superpowers/plans/2026-07-07-frontend-api-integration.md)
 - [Real Nonescape Runtime Plan](superpowers/plans/2026-07-08-real-nonescape-runtime.md)
 - [Platform Design Spec](superpowers/specs/2026-07-07-image-authenticity-platform-design.md)
+- [Production Foundation Design](superpowers/specs/2026-07-11-production-foundation-design.md)
 
 ## Reading Order For Interview Review
 
 1. Read the [Project README](../README.md).
 2. Read the [Project Worklog](project-worklog.md).
-3. Read the [Improvement Roadmap](project-improvement-roadmap.md).
-4. If discussing architecture, read
+3. Read the [Production Foundation Design](superpowers/specs/2026-07-11-production-foundation-design.md).
+4. Read the [Improvement Roadmap](project-improvement-roadmap.md) for earlier
+   gap analysis and completed phases.
+5. If discussing architecture, read
    [Model Integration Framework](model-integration-framework.md) and
    [Async Detection Jobs](async-detection-jobs.md).
-5. If demonstrating the project, run through
+6. If demonstrating the project, run through
    [Full-Stack Evaluation Demo](fullstack-evaluation-demo.md).

docs/project-improvement-roadmap.md

@@ -609,3 +609,15 @@ Nonescape Mini 权重更轻，适合 3090、本地 CPU fallback 和 Docker 演
   server model integration branch.
 - Next frontend branch: `feature/evaluation-frontend`, focused on listing
   evaluation runs, showing metrics, and inspecting wrong samples.
+
+2026-07-11 production-foundation update:
+
+- Evaluation backend and frontend slices are now present, but evaluation
+  execution still uses deterministic scoring rather than the model service.
+- The delivery order from this older roadmap is superseded by
+  [Production Foundation And Project Boundary Design](superpowers/specs/2026-07-11-production-foundation-design.md).
+- The next code branch is `feature/reliable-job-dispatch`, followed by
+  short-lived execution transactions, secure ingestion, real-infrastructure
+  tests, and observability.
+- Model weights and GPU verification remain assigned to
+  `feature/server-model-weight-integration`.

docs/project-worklog.md

@@ -521,25 +521,79 @@ Deferred:
 - Local headless screenshot verification was attempted with a mocked API, but
   the temporary Vite process exited before Chrome could capture the page.
 
+### 2026-07-11: Production Foundation And Project Boundary Design
+
+Branch:
+
+```text
+feature/production-foundation-spec
+```
+
+What changed:
+
+- Audited the current frontend, Java backend, PostgreSQL, Redis, storage,
+  model-service, evaluation, testing, CI, and repository-governance boundaries.
+- Compared the design with Spring Modulith, Debezium outbox guidance, Redis
+  Streams, Testcontainers, OpenTelemetry, Resilience4j, OWASP upload guidance,
+  and maintained AI-image detection benchmarks.
+- Defined measurable reliability, security, observability, reproducibility,
+  testing, API, data-governance, and repository standards.
+- Split future work into focused branches from reliable dispatch through GPU
+  server integration.
+
+Why:
+
+- The project needs interview-visible engineering depth that solves real
+  failure modes instead of adding unrelated pages or infrastructure names.
+- Database-to-Redis consistency, long-running database transactions, upload
+  trust, and fake evaluation execution are concrete current risks.
+- Model weights remain deferred, so the local stage must make the surrounding
+  system reliable and verifiable first.
+
+Verification baseline:
+
+- `npm run test`: 8 passed.
+- `npm run lint`: passed.
+- `npm run build`: passed.
+- `mvn -B test`: 47 passed.
+- Python model-service tests: 6 passed.
+
+Recorded risk:
+
+- `npm audit` reported one high and one low vulnerability. The Vite finding is
+  isolated to the next `fix/frontend-dependency-security` branch.
+
+Next branch:
+
+```text
+feature/reliable-job-dispatch
+```
+
+The branch will implement a PostgreSQL transactional outbox and idempotent
+Redis publication before evaluation is connected to real inference.
+
+---
+
 ## Next Recommended Work
 
-Continue Phase B from `docs/project-improvement-roadmap.md` with a backend
-observability branch:
+Start Stage 1 from the production foundation design with a reliable dispatch
+branch:
 
 ```text
-feature/evaluation-observability
+feature/reliable-job-dispatch
 ```
 
 Scope:
 
-- Add structured logs around evaluation execution start, retry, completion, and
-  failure.
-- Add lightweight timing fields or counters that make run latency explainable.
-- Document how to inspect evaluation execution behavior locally and in CI.
-- Keep the deterministic model boundary until GPU weights are available.
+- Persist task dispatch requests in PostgreSQL in the same transaction as the
+  business command.
+- Publish pending outbox records to Redis with a versioned event envelope.
+- Add idempotent publication, bounded retry, stale-claim recovery, inspection,
+  and explicit replay behavior.
+- Document queue failure and recovery operations.
 
 Reason:
 
-The project now has evaluation execution and frontend result explainability. The
-next interview-visible step is to show production-minded observability without
-expanding scope into training, video detection, or heavy model operations.
+The current database-to-Redis call is a dual write. Reliable dispatch provides
+a reusable foundation for detection and evaluation, demonstrates a real
+production consistency problem, and can be implemented without model weights.