stroblmeandClaude Opus 5 518231aa39
Docs / docs (push) Successful in 22s
Playwright Tests / test-playwright (1, 2) (push) Failing after 1m9s
Playwright Tests / test-playwright (2, 2) (push) Failing after 11s
pre-commit / pre-commit (push) Failing after 1m59s
Test Backend / test-backend (push) Failing after 2m28s
Compose Smoke Test / test-compose (push) Failing after 11s
Playwright Tests / merge-reports (push) Failing after 2m19s
Touch is a panel setting, and the rail grows with it
It described the wrong object. A dashboard is a document that may hang on a
hallway tablet and in a desk browser at the same time, and only one of those
has fingers on it — so the flag moves off `DashboardDef.settings` and onto
`PanelDef` as a plain bool, ticked in the Panels dialog. `useCanvasRoot` takes
it as an argument rather than reading the document, and `/panel/{id}` is the
only surface with a panel to ask.

Dropping the message binding with it is deliberate: nothing drove it, and a
flow deciding whether a screen has fingers on it was never the point. A stored
`settings.touch` is inert rather than migrated, which `_check_settings`
skipping unknown names already guaranteed.

The rail was the other half. It had no touch behaviour at all and its 40px
buttons met neither branch of the 44/32 rule. `[data-touch] .dui-rail{-item}`
in `ui/core/core.css` spends the padding and the gap on the buttons instead,
so they reach the 44px target and the rail comes out taller at exactly the
same width — `RAIL_INSET` never moves, and the arrangement under it does not
either.

Also closes the panels-dialog icon gap: `DashboardSummary` carries the `icon`
now, so the dialog draws each assigned dashboard's rail glyph beside its
checkbox. `initials()` went from three identical copies in the looks to one in
`Dashboard/icons.ts`, so the dialog and the rail fall back the same way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Va7ExQDtuwKN7kNpHhWWNQ
2026-08-31 19:04:20 +02:00
2026-08-31 10:12:01 +02:00
2026-08-31 10:12:01 +02:00
2026-02-03 21:43:09 +01:00
2026-08-31 10:12:01 +02:00
2026-08-31 10:12:01 +02:00

Fluksio App

Fluksio is a node-based automation software that brings trust and reliability to your flow. It just works and looks good.

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)

Layout

backend/        FastAPI + SQLModel + Alembic + SQLite
  fluksio/flow/ the flow engine (nodes, pipeline, state backends, controller)
  fluksio/cli.py  `fluksio serve` / `enroll` / `worker`
worker/         the `fluksio-worker` distribution: the agent and the node runner
frontend/       React 19 + TanStack Router + Tailwind 4 + shadcn/ui
docs/           the public documentation site (zensical), served on docs.${DOMAIN}
docker/         compose.yml → compose.dev.yml → compose.local.yml (+ compose.traefik.yml)
scripts/        generate-client.sh, test.sh

Install without Docker

Get started quickly by running

pip install fluksio
fluksio serve

Then, head over to fluksio.com, sign up and add a new instance. Using the code provided, run

fluksio enroll <code>

and you're ready to rock.

Fluksio is distributed at it's heart. A machine that should only run nodes for an engine elsewhere installs less:

pip install fluksio-worker
fluksio-worker --url wss://api.fluksio.com/api/v1/workers/attach --token "$TOKEN" --labels gpu

Getting started

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

make install       # uv sync + bun install
make dev-utils     # proxy and mailcatcher 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

The public site lives in docs/ and is built with zensical:

make docs-serve   # live preview on :8000
make docs         # static build into ./site

It is served at docs.${DOMAIN} by the docs service in docker/compose.yml, and .gitea/workflows/docs.yml builds it with --strict on every push.

License

Copyright (C) 2026 Melvin Strobl - GNU Affero General Public License v3.0 or later. See LICENSE.

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%