# flowcanwas

**Repository Path**: bmcbdt/flowcanwas

## Basic Information

- **Project Name**: flowcanwas
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-09-03
- **Last Updated**: 2026-09-04

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# FlowCanvas

FlowCanvas is organized according to `doc/aigc-canvas-architecture.md`: Vue/Vite is the only frontend entry, `api-server` is the only public HTTP service, `workflow-worker` executes asynchronous workflows, `model-dispatcher` calls upstream model providers, and `billing-server` owns model reservation and settlement. Shared GORM Models and Repositories live under `backend/internal/model` and `backend/internal/repository`.

## Local start

1. Start MySQL and Redis with `docker compose up -d`.
2. Apply every file in `backend/migrations/` to the empty `flowcanvas` database in filename order. The baseline creates the schema and the later migration removes the legacy canvas identity constraints. The PowerShell helper `backend/scripts/migrate.ps1` applies all SQL schema migrations automatically.
3. To create or synchronize the schema from the GORM structs, run `go run ./cmd/migrate` in `backend`. Then run `go run ./cmd/seed` to idempotently write the built-in canvas node definitions and the Tencent COS debug node. Seed data is implemented as Go code under `backend/cmd/seed`; it is not stored in SQL migration files. The root `start-dev.cmd` runs both commands automatically. For local startup automation, set `$env:AUTO_MIGRATE="true"` before starting the internal services.
4. In `backend`, run `go mod tidy` once, then start the services in separate terminals:

```powershell
$env:MYSQL_DSN="flowcanvas:flowcanvas@tcp(127.0.0.1:3306)/flowcanvas?charset=utf8mb4&parseTime=true&loc=UTC"
go run ./cmd/workflow-worker
go run ./cmd/model-dispatcher
go run ./cmd/billing-server
go run ./cmd/api-server
```

5. In `frontend`, run `npm install` and `npm run dev`, then open `http://localhost:5173`.

The legacy interactive reference remains in `前端原型/`; the new Vite app is the implementation entry point and uses the documented API envelope. The public task API is `POST /api/v1/tasks` and `GET /api/v1/tasks/:job_code`. The task contract uses the existing `jobs` table from `sql/test.sql`; no project or billing account table is invented outside that schema.

## Tencent COS direct upload

The API server provides `POST /api/v1/storage/uploads`, `POST /api/v1/storage/uploads/:upload_id/complete`, `GET /api/v1/storage/uploads/:upload_id`, and `GET /api/v1/storage/assets/:asset_ref/access-url`. For uploaded assets, `asset_ref` is the returned `upload_id` (the `upload_asset.unique_id`). The browser uploads directly to COS with the short-lived STS credentials returned by the initialization endpoint. The COS event adapter calls `POST /api/v1/storage/callbacks/tencent-cos`; configure `STORAGE_CALLBACK_TOKEN` on both the event adapter and API server. A callback or fallback `HEAD Object` check is required before `upload_asset` is created. Access URLs are signed on demand and are never stored in MySQL.

Required environment variables for a Tencent node include `TENCENT_COS_APP_ID` and `STORAGE_CALLBACK_TOKEN`. The selected active default `oss_node` supplies the bucket, region, endpoint and server-side credentials. Optional values are `STORAGE_UPLOAD_TTL_SECONDS` (default 1800), `STORAGE_ACCESS_TTL_SECONDS` (default 600), `STORAGE_CALLBACK_WAIT_SECONDS` (default 8), and `REDIS_DB` (default 0).