[P0] Define public catalog boundary for garage-store build-time fetches #1

New issue

Closed

opened 2026-07-16 22:44:31 +00:00 by yuris · 0 comments

yuris commented

2026-07-16 22:44:31 +00:00

Owner

Decision

The separate static garage-store site will fetch public catalog data from the Garage application during its build. It will generate static pages from that response. It will not access PostgreSQL directly and will not rely on a repository export/synchronization command.

This issue

Document and approve the cross-repository boundary before implementation:

Garage owns inventory and public catalog source data.
garage-store owns static rendering and SEO pages.
Garage exposes only a dedicated read-only public catalog endpoint.
Vercel build-time configuration supplies the endpoint base URL; no database credentials are sent to Vercel.
A failed fetch must fail the build rather than silently publish empty or stale catalog pages, unless a deliberate fallback policy is separately approved.
Runtime availability is not required for the first release; the storefront asks customers to confirm stock through WhatsApp.

Acceptance criteria

Boundary, ownership, build flow, and failure behavior are documented in the Garage and store repositories.
The public response schema has an explicit allowlist and version.
The endpoint has no access to authenticated dashboard data beyond the selected public records.
Issue #2 owns the data fields/publish workflow.
Issue #3 owns the endpoint implementation and contract tests.

This supersedes the previous wording about a sanitized export command.

PRD: https://git.nokopia.com/yuris/garage/src/branch/main/docs/store-prd.md

## Decision The separate static `garage-store` site will fetch public catalog data from the Garage application during its build. It will generate static pages from that response. It will not access PostgreSQL directly and will not rely on a repository export/synchronization command. ## This issue Document and approve the cross-repository boundary before implementation: - Garage owns inventory and public catalog source data. - `garage-store` owns static rendering and SEO pages. - Garage exposes only a dedicated read-only public catalog endpoint. - Vercel build-time configuration supplies the endpoint base URL; no database credentials are sent to Vercel. - A failed fetch must fail the build rather than silently publish empty or stale catalog pages, unless a deliberate fallback policy is separately approved. - Runtime availability is not required for the first release; the storefront asks customers to confirm stock through WhatsApp. ## Acceptance criteria - Boundary, ownership, build flow, and failure behavior are documented in the Garage and store repositories. - The public response schema has an explicit allowlist and version. - The endpoint has no access to authenticated dashboard data beyond the selected public records. - Issue #2 owns the data fields/publish workflow. - Issue #3 owns the endpoint implementation and contract tests. This supersedes the previous wording about a sanitized export command. PRD: https://git.nokopia.com/yuris/garage/src/branch/main/docs/store-prd.md

yuris changed title from ~~[P0] Define sanitized catalog export for garage-store~~ to [P0] Define public catalog boundary for garage-store build-time fetches

2026-07-16 22:53:39 +00:00

yuris closed this issue

2026-07-17 08:57:00 +00:00

yuris referenced this issue from a commit

2026-07-17 19:31:24 +00:00

chore: connect storefront scaffold (#1)

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

yuris/garage#1

No description provided.

Rows
Columns