Mark/Kimi_Agent_Brother_10_Digitizing_App

Fork 0

Actors integration testing: single-compose stack on node_hub #20

New issue

Closed

opened 2026-06-26 15:22:23 +00:00 by Mark · 2 comments

Mark commented

2026-06-26 15:22:23 +00:00

Owner

Context

ThreadCraft (this repo) is the "actor" — the workspace itself drives the integration test by calling POST /v1/digitize on the easystitch-service backend and rendering the stitch results on Fabric.js. For that test to be runnable end-to-end on the tailnet, the frontend and the backend need to be deployed together somewhere reachable.

The production ("wild") topology is separated: frontend on a static-web surface, backend on its own node_hub-managed container. That is tracked in a sibling issue. This issue is for the actors-test stack only.

Goal

Bring up ThreadCraft + easystitch-service as a single deployable on nodehub.tail018ac4.ts.net such that the workspace's actor flow (upload artwork → /v1/digitize → render stitch plan → export PES) hits a real backend with no mocks.

Shape (decision required)

Two valid shapes; pick one before implementation:

(a) Single container, both processes. One node_hub app, one image. Uvicorn serves the API on :8080; a static-file handler (e.g. nginx sidecar or aiofiles-served SPA fallback) serves ThreadCraft's vite build output on the same port or a sibling port with /api → :8080 proxying.
(b) Multi-container stack, one node_hub app. node_hub app references a compose file; two containers link (frontend ↔ backend). Frontend's ALLOWED_ORIGINS configured via env to the backend's tailnet DNS.

Both shapes are acceptable. (a) is simpler and matches how Mark/easystitch-service already deploys today (single container, port 8080). (b) is closer to the wild topology and gives a cleaner integration surface. Pick one in a comment before dispatching.

Acceptance

actors up (or equivalent documented command) brings the stack to a healthy state on the tailnet, with both the workspace URL and the service URL reachable.
ThreadCraft's workspace can upload an SVG, call the backend, and render a non-empty stitch plan without mock fallbacks.
The deploy artifact (compose file or Dockerfile + manifests) lives in this repo unless it's codebase-specific to the service (in which case it goes in Mark/easystitch-service).
Healthchecks wired for both the backend (/healthz) and the frontend's index.html.
ALLOWED_ORIGINS configured so the frontend origin is permitted on the service (see related issue in easystitch-service).

Mark/Kimi_Agent_Brother_10_Digitizing_App#21 — Wild deploy: separated frontend + backend
Mark/easystitch-service#TBD — Service-level origin allowlist + CORS for actors stack
Mark/easystitch-service docs/deployment.md (Option A standalone image, port 8080) — starting point for the service container.

Out of scope

Production / wild deploy (separate issue, #21).
Defining what "actors integration testing" means (see #22 — confirms scope before this is dispatched).
Test harness beyond ThreadCraft's own actor flow.

## Context ThreadCraft (this repo) is the "actor" — the workspace itself drives the integration test by calling `POST /v1/digitize` on the easystitch-service backend and rendering the stitch results on Fabric.js. For that test to be runnable end-to-end on the tailnet, the frontend and the backend need to be deployed together somewhere reachable. The production ("wild") topology is **separated**: frontend on a static-web surface, backend on its own node_hub-managed container. That is tracked in a sibling issue. **This issue is for the actors-test stack only.** ## Goal Bring up ThreadCraft + easystitch-service as a single deployable on `nodehub.tail018ac4.ts.net` such that the workspace's actor flow (upload artwork → `/v1/digitize` → render stitch plan → export PES) hits a real backend with no mocks. ## Shape (decision required) Two valid shapes; pick one before implementation: - **(a) Single container, both processes.** One node_hub app, one image. Uvicorn serves the API on `:8080`; a static-file handler (e.g. nginx sidecar or `aiofiles`-served SPA fallback) serves ThreadCraft's `vite build` output on the same port or a sibling port with `/api` → `:8080` proxying. - **(b) Multi-container stack, one node_hub app.** node_hub app references a compose file; two containers link (frontend ↔ backend). Frontend's `ALLOWED_ORIGINS` configured via env to the backend's tailnet DNS. Both shapes are acceptable. (a) is simpler and matches how `Mark/easystitch-service` already deploys today (single container, port 8080). (b) is closer to the wild topology and gives a cleaner integration surface. Pick one in a comment before dispatching. ## Acceptance - [ ] `actors up` (or equivalent documented command) brings the stack to a healthy state on the tailnet, with both the workspace URL and the service URL reachable. - [ ] ThreadCraft's workspace can upload an SVG, call the backend, and render a non-empty stitch plan without mock fallbacks. - [ ] The deploy artifact (compose file or Dockerfile + manifests) lives in this repo unless it's codebase-specific to the service (in which case it goes in `Mark/easystitch-service`). - [ ] Healthchecks wired for both the backend (`/healthz`) and the frontend's `index.html`. - [ ] ALLOWED_ORIGINS configured so the frontend origin is permitted on the service (see related issue in easystitch-service). ## Related - Mark/Kimi_Agent_Brother_10_Digitizing_App#21 — Wild deploy: separated frontend + backend - Mark/easystitch-service#TBD — Service-level origin allowlist + CORS for actors stack - Mark/easystitch-service `docs/deployment.md` (Option A standalone image, port 8080) — starting point for the service container. ## Out of scope - Production / wild deploy (separate issue, #21). - Defining what "actors integration testing" means (see #22 — confirms scope before this is dispatched). - Test harness beyond ThreadCraft's own actor flow.

Mark referenced this issue

2026-06-26 15:22:23 +00:00

Wild deploy: separated frontend + backend on node_hub #21

Mark referenced this issue from Mark/easystitch-service

2026-06-26 15:22:23 +00:00

ALLOWED_ORIGINS: support multiple origins via env for actors stack #4

Mark added the

triage-approved

needs-decompose

labels

2026-06-26 15:22:36 +00:00

Mark commented

2026-06-26 15:22:36 +00:00

Author

Owner

Auto-triage: needs decompose

Marked triage-approved + needs-decompose. decompose-executor will pick this up and break it into implementable sub-issues.

## Auto-triage: needs decompose Marked `triage-approved` + `needs-decompose`. decompose-executor will pick this up and break it into implementable sub-issues.

Mark referenced this issue

2026-06-26 15:23:03 +00:00

Confirm: "actor" in actors integration testing = ThreadCraft workspace itself #22

Mark added the

in-progress

label

2026-06-27 06:19:39 +00:00

Mark commented

2026-06-27 06:41:48 +00:00

Author

Owner

Auto-triage: needs decompose

Marked triage-approved + needs-decompose. decompose-executor will pick this up and break it into implementable sub-issues.

## Auto-triage: needs decompose Marked `triage-approved` + `needs-decompose`. decompose-executor will pick this up and break it into implementable sub-issues.

Mark

2026-06-27 07:11:22 +00:00