stroblmeandClaude Opus 5 fe7a98f292
Playwright Tests / test-playwright (1, 2) (push) Canceled after 0s
Playwright Tests / test-playwright (2, 2) (push) Canceled after 0s
pre-commit / pre-commit (push) Canceled after 0s
Compose Smoke Test / test-compose (push) Canceled after 0s
Playwright Tests / merge-reports (push) Canceled after 0s
Bound a panel credential where the route check cannot reach
Three things the security pass on the portal pairing turned up. The first two
were already true of a screen on the local network; what changed is that a
panel credential is now presentable from the internet, which is what makes
them worth closing rather than recording.

The artifact endpoint authenticates for itself, because a worker's credential
has to open it and that token is no use anywhere else. It resolved the caller
without handing over the request, so the one credential that is scoped by
route was judged by no route at all — a panel could read and write the store
as whoever approved it. It passes the request it already holds now.

The websocket has no route to judge either, and there the bound has to be on
what is sent: a panel is given the values its own dashboards draw and nothing
else — no node status, no logs, no shape of the graph. The keys stay in the
message, emptied, because a screen on a wall runs the bundle it was paired
with. `messages_for` reads that set off the published dashboards, and is the
walk the `/messages/` allowlist has wanted for a while.

And locality is no longer a header anyone can type. The marker the connector
stamps is a value minted per process, so reaching this API directly cannot buy
a device the credential meant for one that cannot reach it at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017F9RnYCJgASuBTcAjxmnsp
2026-08-21 00:09:18 +02:00
2026-08-20 22:43:03 +02:00
up
2026-08-20 10:30:12 +02:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-08-20 22:43:03 +02:00
2026-02-03 21:43:09 +01:00
2026-08-16 00:22:41 +02:00

Fluksio App

Fluksio has the goal to build a revolutionary system to tackle any sort of automation challenge.

The core of Fluksio: a node-based, test-driven automation software built to scale. This repo holds the FastAPI backend, the flow engine, and the dashboard SPA. It is served on app.${DOMAIN} (SPA) and api.${DOMAIN} (API); the marketing site lives in the sibling index repo.

Layout

backend/        FastAPI + SQLModel + Alembic + Postgres
  app/flow/     the flow engine (nodes, pipeline, state backends, controller)
frontend/       React 19 + TanStack Router + Tailwind 4 + shadcn/ui
docker/         compose.yml → compose.dev.yml → compose.local.yml (+ compose.traefik.yml)
scripts/        generate-client.sh, test.sh

Getting started

Normally driven from the workspace root (make init once, then make dev). Standalone:

make install       # uv sync + bun install
make dev-utils     # db, adminer, proxy, mailcatcher, prestart only
make dev-backend   # FastAPI on :8000, hot reload
make dev-frontend  # Vite on :5173
make test           # pytest + Playwright (the e2e half needs the stack up)
make lint           # ruff + mypy + biome
make generate-client  # regenerate the frontend SDK from the OpenAPI schema

make help lists every target.

Documentation

  • ROADMAP.md — strategy and feature record
  • NOTEPAD.md — deferred work and findings
  • DESIGN.md — points at the workspace root's DESIGN-GUIDELINES.md
  • docs/architecture/ in the sibling docs repo — the requirement sources
S
Description
No description provided
Readme AGPL-3.0
7.1 MiB
Languages
Python 54%
TypeScript 42.6%
CSS 1.9%
HTML 0.5%
JavaScript 0.5%
Other 0.3%