## Summary
- fix multi-select trigger overflow in shared select bridge by making
trigger/value flex children shrink correctly
- harden grouped assignment summaries against long selected-value text
wrapping overflow
- normalize card header/body spacing and node card IP row height so card
layouts stay visually consistent across modules
## Verification
- ran `npm run build` in `vite-frontend` successfully
- checked diagnostics on changed frontend files (no diagnostics)
## Summary
- Clarify that FLVX is a deeply reworked fork rather than a light patch.
- Update the Modifications section to reflect backend rewrite and
frontend rework scope.
- Align infrastructure notes with current deployment and installer
workflow wording.
## Summary
- update root `AGENTS.md` metadata and notes to reflect `main@137c34e`
and tag `2.1.4-rc2`
- refresh `vite-frontend/AGENTS.md` to document the shadcn bridge
architecture and Tailwind v4 semantic token wiring
- add current frontend conventions/anti-patterns to prevent regressions
(raw JWT header and token import requirements)
## Summary
- add backend support to bind users to one or more user groups on
create/update
- add a new `/user/groups` API endpoint and repository methods for
user-group mapping queries/mutations
- update user modal UI to fetch/select user groups and submit `groupIds`
with user create/edit requests
## Notes
- includes minor frontend formatting changes in existing pages
(`config.tsx`, `dashboard.tsx`, `tunnel.tsx`) that were part of the
working tree
## Summary
- extract reusable frontend domain modules (hooks, api typing/error
helpers, and page helper submodules for dashboard/forward/node/tunnel)
to reduce page-level coupling
- add a local shadcn/ui foundation plus HeroUI-compatible bridge layer
and migrate app imports to the bridge, enabling full UI stack
replacement without rewriting business logic
- replace HeroUI theme/plugin dependencies with local Tailwind token
configuration, remove HeroUI packages from dependencies, and document
the end-to-end migration/refactor execution plan
## Verification
- npm run build
- npm ls @heroui/button @heroui/system @nextui-org/system --depth=0
Old schema.sql created tables with inline UNIQUE column constraints,
which PostgreSQL auto-names as <table>_<column>_key. GORM expects
uni_<table>_<column> (its NamingStrategy convention). On upgrade,
AutoMigrate issued DROP CONSTRAINT uni_... against a name that did not
exist, crashing startup with SQLSTATE 42704.
Add preparePostgresLegacySchema() that runs before autoMigrateAll and
renames all five mismatched constraints:
- vite_config_name_key -> uni_vite_config_name
- peer_share_token_key -> uni_peer_share_token
- peer_share_runtime_reservation_id_key -> uni_peer_share_runtime_reservation_id
- peer_share_runtime_resource_key_key -> uni_peer_share_runtime_resource_key
- federation_tunnel_binding_resource_key_key -> uni_federation_tunnel_binding_resource_key
The function is idempotent: it checks information_schema before each
rename so re-runs on already-migrated databases are no-ops.
Co-authored-by: Antigravity <antigravity@google.com>
Reduce repetitive raw SQL in test bodies by routing scalar and multi-column checks through shared helpers, keeping test intent clearer without changing behavior.
- Extract database layer into model and repo packages
- Split repository into focused modules (control, federation, flow, groups, mutations)
- Remove monolithic db.go and sqlite/repository.go
- Update handlers to use new repository structure
- Migrate contract tests to new patterns
- Add migration plan documentation
* feat(announcement): add database schema for SQLite and PostgreSQL
Add announcement table with id, title, content, enabled, created_at, updated_at columns to both SQLite and PostgreSQL schemas to support announcement system.
* feat(announcement): implement SQLite repository for announcement management
Add announcement CRUD operations in SQLite repository including create, read, update, delete, and list methods with proper error handling.
* feat(announcement): add HTTP handlers and auth middleware for announcement API
Implement admin-only update endpoint and public read endpoint for announcements. Add auth middleware to enforce admin-only access for update operations.
* feat(announcement): add frontend API client for announcement endpoints
Implement API client methods for fetching announcements and updating announcement settings with proper error handling.
* feat(announcement): add announcement display component to dashboard
Implement announcement display section in dashboard with real-time updates and proper styling using HeroUI components.
* feat(announcement): add announcement management UI to config page
Implement announcement settings panel with enable/disable toggle and content editor for admin users to manage announcements.
When unsharing a federation node, tunnels created via federationTunnelCreate
were not cleaned up, allowing clients to continue using them. Added
cleanupFederationTunnels() to delete these tunnels and reload the node agent.
Added dual-layer port range enforcement for federation sharing:
Server-side (Provider):
- federationRuntimeApplyRole: validate runtime.Port against share range
- validateFederationCommandPorts: hardened against malformed JSON bypass
- New helpers: validateRemoteNodePort, remoteNodePortRange
Client-side (Consumer):
- prepareTunnelCreateState: pre-check ports for remote nodes
- tunnelCreate type=1: validate targetPort for remote entry
- forwardCreate/Update/BatchChangeTunnel: port range validation
Prevents consumers from using arbitrary ports outside provider's allowed range.
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
- Fix Type 1 (port forwarding) tunnels to call applyFederationRuntime
Previously only Type 2 tunnels applied federation runtime, causing
port forwarding tunnels to not be properly configured in federation mode
- Remove incorrect UDP tunnel type override in federationTunnelCreate
UDP tunnels were being incorrectly set to Type 2, which conflicted with
the federation runtime logic that expects Type 1 for port forwarding
These fixes ensure all tunnel types are properly handled in federation mode
with correct runtime configuration applied.
The federationRuntimeCommand handler forwarded AddService/UpdateService
commands from consumers to provider nodes without validating that the
port in the service payload falls within the share's allowed port range.
This allowed consumers to use any port on shared nodes, bypassing the
provider's port_range_start/port_range_end restrictions.
Add port extraction and validation in federationRuntimeCommand for
service commands, rejecting requests with ports outside the allowed
range with a 403 error.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Run Postgres id-sequence repair on every startup migration and add contract coverage plus a GitHub Actions Postgres job to catch schema-drift regressions before release.
sagit