feat: Oracle Canvas Component Schema and Qwen 3.6 integration (#31)

Co-authored-by: Sagnik <sagnik7896@gmail.com>
Reviewed-on: #31
This commit was merged in pull request #31.
This commit is contained in:
2026-04-20 01:43:39 +05:30
parent 57144e1bd3
commit e519339cc9
129 changed files with 625213 additions and 262 deletions

View File

@@ -26,6 +26,10 @@ Key files:
- `desineuron-ingress-home-ip-sync.service`: systemd oneshot service for the IP sync
- `desineuron-ingress-home-ip-sync.timer`: persistent timer that reruns the sync every 5 minutes and on boot
- `install_linux_ingress_ip_sync.sh`: Linux-side installer for the IP sync service
- `deploy_velocity_site.sh`: canonical manual, timer, and webhook deploy entrypoint on the Linux origin
- `gitea_velocity_webhook_receiver.py`: authenticated Gitea push-hook receiver on Linux origin
- `desineuron-velocity-gitea-webhook.service`: systemd service for the webhook receiver
- `install_linux_velocity_webhook.sh`: targeted installer for the webhook receiver
Manual Cloudflare work still required unless API credentials are provided:
- set the six hostnames to DNS-only
@@ -36,3 +40,20 @@ Dynamic home IP handling:
- `rathole` control port `2333/tcp` is intentionally open on the ingress so public services do not break when the ISP IP changes
- SSH fallback on the ingress remains restricted to the current home public IP on `22/tcp`
- the Linux-side IP sync service keeps that SSH fallback rule current after ISP churn or reboot
Project Velocity deploy triggers:
- Manual:
- `sudo systemctl start desineuron-velocity-site-update.service`
- or `sudo /usr/local/bin/deploy_velocity_site.sh`
- Timer:
- `desineuron-velocity-site-update.timer`
- Webhook:
- `https://velocity.desineuron.in/hooks/gitea/project-velocity`
- secret is stored in `/etc/desineuron-velocity-webhook.env`
- only `push` events for `refs/heads/main` on `sagnik/Project_Velocity` trigger deploy
Webhook design:
- receiver binds `127.0.0.1:8788` only
- nginx proxies the public HTTPS hook path to the local receiver
- signature is verified with `X-Gitea-Signature`
- deploy execution is serialized with `flock` so overlapping pushes cannot race each other