Phase F (curl /api/v1/health) only proved the backend is reachable, so
a frontend bundle that crashes Chromium on load passed CI green every
single time. We just shipped exactly that : a Rollup `vendor-state`
chunk with a circular import → "Cannot access 'wt' before initialization"
TDZ ReferenceError at page load, invisible to curl.
Phase G runs Playwright headless Chromium against the deployed public
URL after Phase F succeeds. It :
- Listens for `pageerror` and console.error during navigation, fails
the run on TDZ-style messages (ReferenceError, "before
initialization", dynamic-import failures, …). This is the test
that catches the current production bug — verified locally against
https://staging.veza.fr : both / and /login fail with the exact
`'wt' before initialization` line.
- Asserts every <script src> on the homepage returns 200, so a
mismatched index.html ↔ assets/ tarball fails fast.
- Asserts /api/v1/health is reachable from the SAME origin as the
SPA, catching SNI/host-routing breaks.
Strict mode for staging : on smoke failure the workflow re-runs the
veza_haproxy_switch role with the prior color (read from
/var/lib/veza/active-color-<env>.history line 2) and exits non-zero.
That preserves the invariant "users always see a working app" even
when the build is structurally green.
Tags @smoke-remote isolate these tests from the local-backend suite ;
playwright.smoke-remote.config.ts has no webServer block and refuses to
start without PLAYWRIGHT_BASE_URL so a misconfigured CI step can't
silently fall back to localhost.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two regressions, one introduced by the previous Phase E fix and one
that was always there but invisible :
1. The include_vars of haproxy/defaults/main.yml in veza_haproxy_switch
sat at very high precedence in Ansible's variable order — well above
group_vars/all — so it silently overrode haproxy_letsencrypt:true
with the role-default haproxy_letsencrypt:false. Each switch
re-rendered haproxy.cfg without the `bind *:443 ssl crt …` directive,
leaving HAProxy listening on :80 only. Existing certs in
/usr/local/etc/tls/haproxy/ were never loaded.
Fix : mirror the missing haproxy_* vars into this role's own defaults
(lowest precedence) so group_vars/<env> still win. Drop the
include_vars task.
2. Phase F's internal fallback always used HTTP, regardless of whether
the public URL was HTTPS. So a broken 443 bind passed the deploy as
long as :80 still answered with the right Host header. The fallback
now uses the same scheme as veza_public_url, and the failure message
points at the likely cause when both probes fail under HTTPS.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase F (commit 89cc698b run) succeeded through E but the public
health probe got 503 from haproxy: every backend server in
staging_backend_api was DOWN. Phase D's curl from the haproxy
container to green:8080 had returned 200 just before, so the
container itself is reachable — the failure is purely DNS.
Root cause: the rendered haproxy.cfg uses .lxd FQDNs with
`init-addr last,libc,none resolvers veza_dns` and a `nameserver
incus_gw 10.0.20.1:53` block. HAProxy chroots into /var/lib/haproxy
at startup, after which libc can no longer read /etc/hosts (where
Phase D pinned the IPs) — so all runtime re-resolution falls back
to the configured nameserver. That nameserver does not reliably
answer for *.lxd inside the chroot, the `hold valid 10s` timeout
fires, and every server is marked DOWN within seconds of HUP.
Fix: stop relying on runtime DNS entirely. veza_haproxy_switch
now `incus list`s every blue/green app container (staging + prod
× backend/stream/web) on the incus host, builds an IP map, and
the haproxy.cfg.j2 template substitutes the IP literal directly
into each `server` line. Containers that don't exist yield empty
stdout — those entries fall back to the FQDN form, which fails
libc lookup at HUP and the server stays DOWN cleanly.
Also drop `resolvers veza_dns` from default-server in the
blue-green block (no longer needed) and switch
`init-addr last,libc,none` → `init-addr libc,none` so a stale
"last" IP from a destroyed-and-recreated container is never
preferred over the freshly-rendered literal.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase E rendered roles/haproxy/templates/haproxy.cfg.j2 without
loading roles/haproxy/defaults/main.yml — the template references
haproxy_listen_stats / haproxy_health_check_* / haproxy_sticky_cookie_name
etc., none of which were in scope. Result: 'haproxy_listen_stats is
undefined' on every deploy run, rescue rolled back to prior cfg.
Pull the defaults in via include_vars at the start of the role so the
template resolves cleanly without forcing a meta dependency that
would re-run haproxy provisioning tasks.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bumps VERSION to 1.0.10 and rolls a CHANGELOG entry covering the 12
items shipped over the last cluster session :
- Légal 1-4 : cookie banner + age gate + CGU/CGV/mentions versionnées
+ royalty splits multi-créateurs.
- Sécu 5-7 : API keys (audité), JWT JTI revocation ledger, SSRF /
open-redirect on Stripe Connect + KYC.
- Ops 8-12 : MinIO cross-region replication, RUM Web Vitals, business
KPIs alerting, DB pool monitoring + N+1 detection, WCAG 2.1 AA
axe-core CI.
Refreshes :
- CHANGELOG.md — full v1.0.10 entry with sub-sections per cluster.
- docs/PROJECT_STATE.md — version table now reflects 2026-05-05 +
next-version line points at v2.0.0-rc1.
- docs/FEATURE_STATUS.md — header date + last-update note.
- CLAUDE.md — Historique entry for v1.0.10 + last-updated header.
Pre-flight : `go build ./...` clean ; targeted package tests
(handlers / database / middleware / monitoring / metrics /
core/marketplace / core/auth) all pass with VEZA_SKIP_INTEGRATION=1.
The pre-requirements blocking v2.0.0-public are now closed. Next
step is the v2.0.0-rc1 → v2.0.0-public transition (already
sequenced in the W6 GO/NO-GO checklist from v1.0.9 Day 26).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase D failed on the previous run because the haproxy container
runs systemd-resolved (Debian 13 default) and cannot resolve
`.lxd` hostnames out of the box — same isolation we already work
around inside app containers via blockinfile in /etc/hosts.
Discover backend/stream/web bridge IPs for both colors via
`incus list` on the Incus host (delegate_to + run_once), drop
them as a managed block in haproxy:/etc/hosts, then probe.
The same pin keeps Phase E healthy: haproxy.cfg references
`{{ host }}-{blue,green}.lxd` in its `server` directives, so
reloading without /etc/hosts entries would resolve to nothing
and mark every backend DOWN. Pinning before the curl ensures both
the probe and the subsequent config reload see consistent IPs.
Containers that don't exist yet (first deploy: only one color
will have been launched) are filtered out so blockinfile only
emits live entries — assert verifies the *inactive* color
(the one we're switching to) has all 3 components resolved.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
vite.config.ts uses build.outDir='dist_verification', not the default
'dist'. The build-web step copied apps/web/dist/* — empty — so the
tarball shipped only VERSION. nginx then 403'd on `/` because
try_files fell through to a non-existent /index.html. Fix the copy
path, and harden the path against future drift:
- workflow: copy from dist_verification, assert index.html present
in the staged dir before tar, fail loudly if vite output dir
changes again.
- veza_app/vars/web.yml: own the install tree as www-data:www-data
so nginx reads files without depending on the "other" bit.
- veza_app/tasks/artifact.yml: skip the user-create task for
static (www-data is owned by the nginx package); add a
post-extract assert that index.html exists; chmod -R u=rwX,go=rX
so any tarball-shipped 0640 still becomes nginx-readable.
- veza_app/tasks/probe.yml: rescue path now dumps nginx error.log,
access.log, docroot listing, nginx -T, and a curl -v of the
health URL when the failing component is kind=static — turns
any future opaque "non-200" into an actionable diagnostic.
SKIP_TESTS=1 is the documented bypass (.husky/pre-commit + CLAUDE.md);
none of the files in this commit touch frontend test surfaces, the
failing tests are pre-existing on unrelated design-system token
changes living on the working tree.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the "single-region MinIO" gap. The 4-node EC:2 cluster
tolerates 2 simultaneous drive losses but a regional outage
(network partition, DC fire, operator error wiping the cluster)
remains a single point of data loss.
New Ansible role minio_replication :
- Wrapper script veza-minio-replicate.sh runs `mc mirror --preserve`
from the local cluster to a remote S3-compatible target every 6h
(configurable via OnCalendar).
- Writes textfile-collector metrics on each run :
veza_minio_replication_last_run_timestamp_seconds
veza_minio_replication_last_success_timestamp_seconds
veza_minio_replication_last_duration_seconds
veza_minio_replication_last_status (1/0)
veza_minio_replication_target_bytes
- systemd timer with Persistent=true catches up missed runs after
reboot (this is the disaster-recovery surface, can't afford to
silently skip ticks).
- Idempotent : `mc alias set` re-applies cleanly, `mc mb
--ignore-existing` for the target bucket.
- Refuses to run with vault placeholders to avoid accidental
prod application against bogus credentials.
Why mc mirror, not MinIO native bucket replication : works against
any S3-compatible target (Wasabi, Backblaze B2, AWS S3) with just
an access key, where MinIO BR/SR requires the target to be
MinIO-managed and bidirectionally reachable. mc is the lowest-
common-denominator that lets us decouple from the choice of
target operator.
Alerts in alert_rules.yml veza_minio_backup group :
- MinioReplicationLastFailed (warning, single failed run)
- MinioReplicationStale (CRITICAL, no success in 12h — past RPO)
- MinioReplicationNeverSucceeded (warning, fresh deploy stuck)
- MinioReplicationTargetShrunk (CRITICAL, > 20% drop in 1h —
operator-error guard rail)
Runbook docs/runbooks/minio-replication.md covers triage by alert,
common ops tasks (manual sync, pause, credential rotation), and
the manual restore procedure for DR.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds tests/e2e/24-axe-wcag.spec.ts — a Playwright spec running
@axe-core/playwright (already in deps) against home, login, register,
dashboard, discover, and search. The test fails on any "serious" or
"critical" axe violation at WCAG 2.1 AA conformance level ; "moderate"
and "minor" violations are logged for backlog visibility but don't
gate the build.
What this catches that 11-accessibility-ethics.spec.ts (heuristic
checks) misses :
- Color-contrast violations across the entire DOM
- ARIA role / state mismatches
- Form fields without programmatic labels
- Focus-trap errors in modals
- Heading-order regressions
Wiring :
- New @a11y test tag + npm script "e2e:a11y"
- .github/workflows/e2e.yml runs e2e:a11y after e2e:critical on
every PR + push (~30s overhead).
- Toast portals excluded ([data-sonner-toaster], .toast-container)
to avoid false positives on transient color-contrast.
- Failure prints rule ids + impact + node count so the cause is
visible in the CI log without artifact retrieval.
Lighthouse/LHCI was previously removed (security audit A06) —
axe-core is the modern recommended replacement and is what the
WCAG 2.1 AA conformance ask actually needs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two complementary signals : pool-side (do we have enough connections
for the load?) and per-request side (does any single handler quietly
run hundreds of queries?). Both feed Prometheus + Grafana + alert
rules.
Pool stats exporter (internal/database/pool_stats_exporter.go) :
- Background goroutine ticks every 15s and feeds the existing
veza_db_connections{state} gauges. Before this, the gauges only
refreshed when /health/deep was hit, so PoolExhaustionImminent
evaluated against stale data.
- Wired into cmd/api/main.go alongside the ledger sampler with a
shutdown hook for clean cancellation.
N+1 detector (internal/database/n1_detector.go +
internal/middleware/n1_query_counter.go) :
- Per-request *int64 counter attached to ctx by the gin
middleware ; GORM after-callback (Query/Create/Update/Delete/
Row/Raw) atomic-adds.
- Cost : one pointer load + one atomic add per query.
- Cardinality bounded by c.FullPath() (templated route, not URL).
- Threshold default 50, override via VEZA_N1_THRESHOLD.
- Histogram veza_db_request_query_count + counter
veza_db_n1_suspicions_total.
Alerts in alert_rules.yml veza_db_pool_n1 group :
- PoolExhaustionImminent (in_use ≥ 90% for 5m)
- PoolStatsExporterStuck (gauges frozen for 10m despite traffic)
- N1QuerySpike (> 3% of requests over threshold for 15m)
- SlowQuerySustained (slow query rate > 2/min for 15m on same op+table)
Tests : 8 detector tests + 4 middleware tests, all pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Real User Monitoring closes the gap between synthetic probes (which
already cover server-side latency) and what users actually see in
their browsers. Slow CDN edges, third-party scripts, mobile-CPU
regressions, and bundle bloat all surface here but stay invisible
to backend-side dashboards.
Frontend (apps/web) :
- web-vitals@^4.2.4 dep
- src/observability/webVitals.ts collects LCP / CLS / INP / FID /
TTFB via the npm web-vitals package and POSTs to the backend
using sendBeacon (with fetch keepalive fallback)
- Pageload-level sampling decision (flip a coin once, contribute
all metrics or none) avoids per-metric histogram bias
- Sample rate via VITE_RUM_SAMPLE_RATE (default 1.0 dev / 0.25 prod)
- main.tsx wires initWebVitals() right after initSentry()
- Route slug derived client-side (strips uuid-ish + numeric ids
to keep cardinality low)
Backend :
- internal/handlers/web_vitals_handler.go : POST
/api/v1/observability/web-vitals — anonymous, IP rate-limited
(reuses FrontendLogRateLimit), validates value ranges, normalizes
route + device labels for cardinality
- internal/monitoring/web_vitals.go : Prometheus histograms with
buckets aligned to Google's good/needs-improvement/poor
thresholds, plus beacons-received / beacons-rejected counters
- Tests : 6 handler tests + 3 helper-function tests + 10 frontend
vitest tests (all pass)
Alerts in alert_rules.yml veza_rum group :
- WebVitalsLCPP75Poor (p75 LCP > 4s on a route+device for 30m)
- WebVitalsCLSP75Poor (p75 CLS > 0.25 for 30m)
- WebVitalsINPP75Poor (p75 INP > 500ms for 30m)
- WebVitalsBeaconsStopped (zero beacons for 30m vs yesterday)
Cardinality discipline : labels are bounded to {route, device}
where route is alnum/dash, ≤32 chars, and device is one of
mobile/desktop/tablet/unknown. No per-user labels.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
\`template: validate:\` requires a %s placeholder for the staged
tempfile path; the previous \`nginx -t -c /etc/nginx/nginx.conf -q\`
expression has none, so Ansible refused the task with
"validate must contain %s".
Restructured to:
1. Stat existing site (for rollback).
2. Backup it as .bak if it exists.
3. Render the template (no validate).
4. Run \`nginx -t -c /etc/nginx/nginx.conf -q\` as a follow-up task
— this catches BOTH syntax errors in our site AND interactions
with the rest of the included config.
5. On rc != 0: copy .bak back over the site, then fail with
stderr in the message.
Backend + stream + migrations are all green this run; web was the
last component blocked. Rest of the playbook (Phase D cross-probes,
Phase E HAProxy switch, Phase F external verify) doesn't share this
\`validate:\` pattern, so this should unblock the full deploy.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
stream_server's config/mod.rs:369 calls require_env(\"DATABASE_URL\")
which panics with the FATAL line we saw on the failed run:
thread 'main' panicked at src/utils/env.rs:30:9:
FATAL: Required environment variable DATABASE_URL is not set.
Same postgres + veza role + veza database the backend uses. Stream
reads it for analytics-side queries (sqlx pool).
Backend was green in the same run (12-retry probe finally hit 200),
so the only remaining blocker on the stream container was this var.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Backend's actual error from the rescue dump:
FATAL: config.NewConfig: dial tcp: lookup veza-staging-redis.lxd
on 127.0.0.53:53: no such host
Incus DNS (.lxd suffix) doesn't reach the app container's systemd-
resolved by default — the migrate tool worked earlier only because
Phase A was already passing the IP directly via veza_postgres_host.
Phase A's incus_hosts play now discovers IPs for postgres, redis,
rabbitmq AND minio in one shell-loop and exposes them as facts on
the runner host. The veza_app role then writes a /etc/hosts block
at the top of container.yml mapping each {{prefix}}<svc>.lxd hostname
to its bridge IP, plus a short alias. Backend / stream containers
connect via the env file's existing hostnames; resolution short-
circuits to the static entry without ever touching DNS.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
main.go's config-load failure path silently os.Exit(1)s, which means
lumberjack's file-rotation buffer never flushes before exit and the
journal only sees \"started → exited 1\" with zero diagnostic. Last
deploy run's app log had only the \"Logger initialized\" line; the
actual NewConfig error never made it to disk because os.Exit doesn't
run defers.
A plain fmt.Fprintf to stderr → goes to systemd journal synchronously
→ the next probe rescue dump will show what's actually failing.
The original \"don't write to stderr to avoid broken pipe with
journald\" comment cited a concern that doesn't apply at this point in
startup: there's no parent to break the pipe to, and journald accepts
arbitrary bytes on stderr. Keep the os.Exit but print first.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Go backend uses lumberjack file rotation for its zap output —
config.go:602 calls NewLoggerWithFileRotation pointing at
/var/log/veza/backend-api*.log. systemd journal therefore shows only
the bare "exit-code 1" lines, not the actual error.
Probe rescue block now also tails:
/var/log/veza/backend-api-error.log
/var/log/veza/backend-api.log
/var/log/veza/stream*.log
…and prints a redacted dump of the rendered /etc/veza/<component>.env
so any "X is required but unset" failure surfaces immediately, with
the env values that were actually rendered (first 8 chars only —
secrets stay protected).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.0.10 sécu item 7. The SSRF audit flagged callbacks on Hyperswitch +
distribution submissions ; investigating those revealed a different
risk class on the user-supplied return_url fields :
* sell_handler.ConnectOnboard accepts return_url + refresh_url and
forwards them to Stripe Connect.
* kyc_handler.StartVerification accepts return_url and forwards it
to Stripe Identity.
Stripe doesn't fetch these URLs server-side (so SSRF is not the
risk), but it redirects the user's browser there after the flow
completes. Without an allow-list, an attacker can craft an onboarding
or verification link with `return_url=https://attacker.com/phishing`
and a victim who clicks the resulting Stripe URL lands on the
attacker's page after Stripe finishes — open-redirect attack
disguised as a legitimate Stripe flow.
Hyperswitch + distribution were already protected :
* Webhook URLs go through validators.ValidateWebhookURL
(services/webhook_service.go:54) which blocks private IPs +
requires HTTPS — pre-existing SSRF guard from SEC-07.
* Hyperswitch's own callback URL is configured server-side, not
user-supplied (cf. hyperswitch/client.go) — no SSRF surface.
* Distribution submissions don't carry user-supplied callbacks —
the destination platforms are hard-coded.
What's added :
validators/url_validator.go
* ValidateRedirectURL(rawURL, allowedHosts) — accepts http or
https (since Stripe-redirect targets may be local dev hosts),
requires hostname to match one of allowedHosts exactly OR be
a subdomain of one. Empty allowedHosts ⇒ permissive (used in
dev / unconfigured envs ; only checks for non-internal IPs).
* Reuses the existing IsInternalOrPrivateURL guard so SSRF
protection still applies for the permissive branch.
handlers/sell_handler.go + handlers/kyc_handler.go
* Both handlers now take an allowedRedirectHosts []string param
at construction. Validation runs after the URL defaults are
applied so the caller's submitted URL is checked, not the
backend-derived fallback.
* Validation failure → 400 with a clear message ("invalid
return_url: <reason>") so the SPA can render the right error.
api/routes_marketplace.go
* Both handlers receive the existing
cfg.OAuthAllowedRedirectDomains list at construction. Same
list as the OAuth callback validation, same operator config,
single source of truth.
Tests pass : go test ./internal/{handlers,validators} -short.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Generic packages in Forgejo's package registry are immutable — a
re-upload of an already-existing <name>/<version>/<file> path returns
HTTP 409. With \`curl -f\` that surfaces as exit-code 22 and kills the
build, even though the artifact is in fact present and ready for the
deploy step to consume.
All three push steps (backend / stream / web) now capture the HTTP
code and treat 409 as success. Any other non-2xx still fails the
step. Re-runs of the same SHA — common when iterating on the deploy
playbook itself — no longer require purging the registry first.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The platform already had two revocation surfaces : Redis-backed
TokenBlacklist (token-hash keyed, T0174) and TokenVersion bump on the
user row (revokes ALL of a user's tokens). Both work but leave gaps :
* Redis restart wipes the blacklist — a token revoked seconds before
a Redis crash becomes valid again until natural expiry.
* No way to revoke "session #3 of user X" from an admin UI : the
blacklist is keyed by token hash, the admin doesn't have it.
This commit adds a durable, jti-keyed revocation ledger that closes
both gaps. The jti claim is already emitted on every access + refresh
token (services/jwt_service.go:155, RegisteredClaims.ID = uuid).
Schema (migrations/993_jwt_revocations.sql)
* jwt_revocations(jti PK, user_id, expires_at, revoked_at, reason,
revoked_by). PRIMARY KEY on jti = idempotent re-revoke. Indexes
on user_id (admin "list my revocations") and expires_at (cleanup
cron).
Service (internal/services/jwt_revocation_service.go)
* NewJWTRevocationService(db, redisClient, logger) — Redis is
optional cache.
* Revoke(ctx, jti, userID, expiresAt, reason, revokedBy)
- Redis SET (best-effort cache, TTL = remaining lifetime)
- DB INSERT (durable record, idempotent via PK)
* IsRevoked(ctx, jti)
- Redis GET fast path
- DB fallback on cache miss / Redis blip (fail-open : DB error
is logged + treated as not-revoked, because the existing
token-hash blacklist still protects).
- Backfills Redis on DB hit so the next request hits cache.
* ListByUser(ctx, userID, limit) — for the admin/user "active
sessions" UI.
* PurgeExpired(ctx, safetyMargin) — daily cron handle.
Middleware (internal/middleware/auth.go)
* JTIRevocationChecker interface + SetJTIRevocationChecker setter.
* After ValidateToken, in addition to the token-hash blacklist
check, IsRevoked(claims.ID) is called. Either match = reject.
* Nil-safe via reflect.ValueOf.IsNil() pattern matching the
existing tokenBlacklist nil guard.
Wiring
* config/services_init.go : always instantiate the service (DB
required, Redis passed as nil if unavailable).
* config/middlewares_init.go : SetJTIRevocationChecker on the auth
middleware after construction.
* config/config.go : new Config.JWTRevocationService field.
Logout flow (handlers/auth.go)
* In addition to TokenBlacklist.Add(token, ttl), now calls
JWTRevocationService.Revoke(jti, ...). Best-effort : the blacklist
already protects the immediate-rejection path ; this just adds
durability + a stable handle for admin tools.
Tests pass : go test ./internal/{handlers,services,middleware,core/auth}
-short -count=1.
What v1.0.10 leaves to v2.1
* /api/v1/auth/sessions/revoke/:jti — admin-targeted endpoint.
Service is ready ; the admin UI to drive it follows.
* Daily PurgeExpired cron — call from a Forgejo workflow once
per day with safetyMargin = 1h to keep table size bounded.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Found the silent killer: cmd/api/main.go calls config.NewConfig() and
exits(1) without writing to stderr if it returns an error (line 80).
Three env vars in our template did not match what the code requires,
so config init failed during \`getEnvRequired\` and the systemd unit
"started" but the process died immediately with no journalctl output.
Code expectations vs prior template:
* getEnvRequired("DB_PASSWORD") — template had only DB_PASS, code's
required key got nothing → exit(1).
* getEnvRequired("JWT_SECRET") — template had no JWT_SECRET at all
(only RS256 paths). Code requires SOME value here even though the
active algorithm is RS256.
* services_init.go ClamAVRequired defaults true — and our staging
cluster has no ClamAV. NewUploadValidator returned an error, which
also bubbles into NewConfig and silent-exits.
Fixes:
* DB_PASSWORD added (DB_PASS kept for back-compat).
* JWT_SECRET = vault_chat_jwt_secret (32+ char, distinct from the
RS256 keys; satisfies the required check).
* JWT_ISSUER + JWT_AUDIENCE set explicitly.
* ENABLE_CLAMAV=false + CLAMAV_REQUIRED=false (no ClamAV deployed in
v1.0 staging — re-enable in prod once the daemon ships).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two changes to reduce time-to-diagnostic when the backend fails to bind
its port (the current symptom):
1. Probe retries: 30×2s (60s) → 12×3s (36s). Long enough for a Go
service to open DB/redis/rabbitmq, short enough that the rescue
block's journalctl dump appears in workflow output instead of the
deploy job timing out at 30 min mark.
2. config_binary.yml now stats every .pem secret right after install
and fails loudly if any is missing or <100 bytes. Empty
vault_jwt_signing_key_b64 / vault_jwt_public_key_b64 (the most
likely cause of the silent-crash) would now produce a clear error
pointing at the missing vault var, instead of a 30×retry probe
timeout followed by an obscure Go parse error in journalctl.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.0.10 légal item 4. Marketplace products can now have a per-recipient
payout structure ; each purchase fans out the net (post-platform-fee)
amount across the recipients per their basis_points share. Audit ledger
captures every change for legal-evidence purposes.
Without this, a co-produced track gets paid to the registered seller
only and the contributors must chase reimbursement off-platform =
contentieux risk. F250 in the ORIGIN spec called this out as a v2.0.0
blocker ; this commit closes the gap.
Schema (migrations/992_royalty_splits.sql)
* royalty_splits : (product_id, recipient_user_id, basis_points, role_label).
UNIQUE on (product_id, recipient_user_id).
CHECK : basis_points in (0, 10000]. Sum-to-10000
invariant lives in the service layer (cross-row).
* royalty_splits_audit : append-only history. action ∈ {set, replace,
remove}. previous_splits + new_splits as
JSONB snapshots. Never deleted.
ON DELETE :
products → CASCADE (a deleted product takes its splits with it)
users → RESTRICT (a recipient must be removed from splits before
their account can be deleted ; preserves payment
history coherence)
Service (internal/core/marketplace/royalty_splits.go)
* GetRoyaltySplits(productID) — public read.
* SetRoyaltySplits(actor, productID, inputs, reason)
Validations : seller-owned, sum == 10000 bps, no duplicate
recipients, all recipients exist, each bp in (0, 10000].
Single transaction : delete old rows + bulk insert new + audit
entry. action='set' on first write, 'replace' afterwards.
* RemoveRoyaltySplits(actor, productID, reason)
Idempotent. action='remove'. Reverts the product to single-seller
payout on the next purchase.
* distributePerProductSplits(productID) → recipient → bps map. Used
by processSellerTransfers ; nil result triggers the legacy path.
Sentinel errors :
ErrSplitsForbidden / ErrSplitsSumInvalid / ErrSplitsRecipientDup /
ErrSplitsRecipientNF / ErrSplitsBPRange.
Hook (service.go::processSellerTransfers)
Per-item resolution : if the product has splits, fan the net out
across recipients (rounding remainder absorbed by the dominant
recipient so the total stays exact) ; otherwise the legacy
single-seller path runs. SellerTransfer rows still get one per
recipient, with the originating seller's commission rate carried
through for audit. Mixed orders (some products with splits, some
without) are handled correctly.
Handler (internal/handlers/royalty_splits_handler.go)
* GET /api/v1/marketplace/products/:id/royalty-splits public
* PUT /api/v1/marketplace/products/:id/royalty-splits seller-only
* DELETE /api/v1/marketplace/products/:id/royalty-splits seller-only
Error mapping : sentinel → AppError code so the SPA can render the
right toast without parsing messages. Both PUT and DELETE go through
the existing RequireOwnershipOrAdmin middleware (defense in depth ;
service layer also checks).
What v1.0.10 leaves to v2.1
* UI for managing splits (product editor) — backend-complete here ;
UI follows. Operators can already configure splits via the API.
* Dispute workflow (third-party arbitration when a recipient
contests their share). For v2.0.0 the legal coverage is "splits
are visible publicly, audit log is append-only, contentieux goes
through legal channels with the audit log as evidence."
* Tax allocation (each recipient may be in a different tax
jurisdiction). Splits today distribute the gross-minus-fee evenly
by share ; per-jurisdiction tax math comes later.
Tests pass : go test ./internal/core/marketplace ./internal/handlers
-short → ok.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.0.10 légal item 3. RGPD requires explicit re-acceptance of any
terms-of-service-class document on material change. Adds a per-user,
per-document, per-version ledger so disputes can be answered with
evidence (timestamp + originating IP + user-agent).
Backend
* migrations/991_terms_acceptance.sql — table terms_acceptances with
UNIQUE (user_id, terms_type, version) so re-accepts are idempotent.
inet column for IP, varchar(512) for UA, both nullable for the
internal seed paths.
* internal/services/terms_service.go — TermsService :
- CurrentTerms map (ISO date version per class) is the single
source of truth ; bump on text edit.
- CurrentVersions(userID) returns versions + the user's
unaccepted set ; userID==Nil ⇒ versions only (anonymous OK).
- Accept(userID, []AcceptInput) : validates each (type, version)
against CurrentTerms (ErrTermsVersionMismatch on stale POST),
writes one row per accept in a single transaction, idempotent
via FirstOrCreate against the unique index.
* internal/handlers/terms_handler.go — REST surface :
- GET /api/v1/legal/terms/current (public, OptionalAuth)
- POST /api/v1/legal/terms/accept (RequireAuth)
- Captures IP via gin's ClientIP() (X-Forwarded-For-aware) and
UA from the request, truncates UA to fit the column.
* routes_legal.go — wires the two endpoints. `current` falls back
to no-middleware when AuthMiddleware is nil so test rigs work.
Frontend
* features/legal/pages/{CGUPage,CGVPage,MentionsPage}.tsx — initial
drafts with version constants matching the backend's CurrentTerms.
Counsel review required before v2.0.0 (text is honest baseline,
not finalised legal copy).
* services/api/legalTerms.ts — fetchCurrentTerms() / acceptTerms() ;
hand-written to keep the consent-modal wiring readable.
* components/TermsAcceptanceModal.tsx — non-dismissable modal that
opens on every authenticated session when the unaccepted set is
non-empty. Per-document checkboxes + single submit ; refusal keeps
the modal open (no decline-and-continue path because the legal
contract requires acceptance to use the platform).
* Mounted in App.tsx alongside CookieBanner ; both must overlay
every screen.
* Lazy-component registry + routes for /legal/{cgu,cgv,mentions}.
Operator workflow when text changes :
1. Edit the text in the relevant page component. Bump the
`*_VERSION` const in that file.
2. Bump CurrentTerms[*] in services/terms_service.go to the same
value.
3. Deploy. Every existing user gets force-prompted on their next
session ; new users prompted at registration.
baseline checks : tsc 0 errors, eslint 754, go build clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
veza-backend started but didn't bind 8080, so the probe spent 30
retries on connection-refused with no visible cause. Wrapped the
probe in block/rescue: on failure, dump systemctl status + last 200
journal lines + listening sockets, then fail explicitly with a
pointer at the diagnostic output.
Next run will show the actual reason the backend crashed at startup
(env var, JWT key, OTEL endpoint, etc.) instead of opaque retries.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
container.yml's "Record the SHA + color" task copies into
{{ veza_state_root }} (/var/lib/veza), but the dir is only created
later in os_deps.yml. Phase A through migrations + Phase B + Phase C
container-launch all pass; the role then dies on the first write to
/var/lib/veza on a freshly-launched container.
Pre-create the dir at the top of container.yml. os_deps.yml will run
the same file task again later (idempotent — already exists).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The migrate_tool actually completed successfully on the previous run —
all 130+ migrations ran, "Migrations completed successfully", rc=0,
DB connection cleanly closed. But Ansible reported FAILED because of
a Jinja2 syntax error in the changed_when expression
(\`'\"msg\":\"migration appliquée\"' in (migrate_result.stdout | default('') | lower)\`)
— the embedded escaped JSON quotes choked the Jinja parser.
Replaced with a simple, syntax-safe predicate:
changed_when: migrate_result.rc == 0
migrate_tool is idempotent (every migration logged as "déjà appliquée"
on re-runs), so reporting "changed" whenever the binary returns 0 is
correct enough for deploy summary purposes — and the predicate can't
break.
Also kept the postgres cross-bridge verification play that was added
in the same edit cycle (deploy_data.yml) so any future TCP/firewall
issue surfaces with diagnostics in deploy_data, not opaque retries
in deploy_app.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- backend.env.j2: postgres direct (no pgbouncer), redis/minio hostnames,
sslmode/disable to match unmanaged TLS in data tier
- stream.env.j2: minio hostname aligns with deploy_data containers
- deploy_app.yml: postgres IP discovery fails loud on empty stdout;
Phase F tries public URL then HAProxy bridge IP + Host header
- vault.yml.example: pre-deploy checklist for required vault_* keys
v1.0.10 légal item 2. The signup endpoint /api/v1/auth/register and
its frontend form now require a date of birth and refuse registrations
where the registrant would be < 16 years old at registration time.
Threshold rationale :
COPPA (US, < 13 forbidden) + RGPD strict (< 16 needs parental
consent in every EU member state at the highest interpretation).
16 is the conservative single cutoff that satisfies both regimes
without per-jurisdiction branching. If a future market needs a
different threshold, change MinRegistrationAgeYears in
internal/core/auth/service.go ; the frontend reads the same
constant so they stay aligned.
Backend changes
* dto.RegisterRequest gets a `Birthdate string` field, validated
`required,datetime=2006-01-02` so swaggo / orval emit the right
OpenAPI schema and the validator catches malformed values
before the handler even runs.
* AuthService.Register signature is now
(ctx, email, username, password, birthdate *time.Time). The
pointer lets internal seed paths / tests pass nil while the
public handler always supplies a parsed value.
* Age check uses a yearsBetween helper that handles the "anniversary
hasn't passed yet this year" case correctly (someone born
2008-05-01 is 16 on 2008+16-05-01, not on 2008+16-01-01).
* New sentinel auth.ErrUnderage ; handler maps it to 400 with a
friendly message ("You must be at least 16 years old to register")
so the SPA can render the right copy without parsing the message.
* 11 test call sites updated : test-only paths pass nil ; the
public-handler test (TestRegister_Success) and the in-package
handler test pass a fixture Birthdate "2000-01-15".
Frontend changes
* RegisterFormData type + zod schema in RegisterForm.tsx + initial
form state get a `birthdate` field.
* RegisterPageForm.tsx renders an `<AuthInput type="date">` with a
`max=` attr 16 years ago today (UX guard ; legal floor stays in
the API).
* useRegisterPage's validate() computes age client-side with the
same algorithm as backend ; emits localised errors
`birthdateRequired` / `birthdateInvalid` / `birthdateUnderage`
so the user gets immediate feedback.
* services/api/auth.ts RegisterRequest interface + register()
body include the new field.
Tests : `go test ./internal/core/auth ./internal/handlers -short`
passes ; `tsc --noEmit` clean ; `eslint src` 754 (baseline unchanged).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
pg_isready kept getting "no response" even after the previous fix
because the handler-based restart was racing with `Ensure enabled +
started` — postgres got started for the first time AFTER the conf
edits, so the change was on disk but the handler's `state: restarted`
was a no-op (already current state).
Refactor to be explicit about ordering:
* Discover the actual postgresql.conf path via `find` instead of
hardcoding /etc/postgresql/16/main, in case PGDG laid it out
differently
* Use blockinfile with a marker for listen_addresses (idempotent
without depending on the default file's exact comment format)
* Apply pg_hba.conf bridge-subnet allow next to it
* Drop the handler — replace with an unconditional Restart task
AFTER the enabled-only systemd task, so the restart always runs
regardless of whether ansible thinks the file was changed
* Add a diagnostic step that dumps `ss -tlnp | grep 5432` so any
future "still not listening" failure shows the actual socket state
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
v1.0.10 légal item 1. The privacy policy at /legal/privacy now exists
and the SPA shows a non-modal banner asking for consent before any
optional cookie is set. Conformité ePrivacy + CNIL guidance.
Banner (apps/web/src/components/CookieBanner.tsx) :
* Bottom strip, NOT a modal — public pages remain browsable while
the user is undecided. Only optional-cookie-using surfaces gate
on consent.
* Two equal-weight buttons : "Refuser le non-essentiel" and "Tout
accepter". No dark patterns / nudging — both actions are full
size, both have visible borders.
* Choice persisted in localStorage as
`{ choice: 'all'|'essential', timestamp: ISO8601 }`.
* Auto-expires after 13 months (CNIL guidance) — the next visit
after expiry re-shows the banner.
* Custom event `veza:cookie-consent-changed` fires on decision so
analytics wiring can react without polling.
* Three exported helpers : readCookieConsent (sync) / useCookieConsent
(React hook) / resetCookieConsent (revoke from settings page).
Co-located with the banner because they're contextually inseparable
— splitting would obscure the contract.
Privacy page (apps/web/src/features/legal/pages/PrivacyPage.tsx) :
* Public minimalist privacy notice — what data, why, how long, who
we share with, RGPD rights.
* Hosts the cookie controls : shows current choice + "modifier"
button that calls resetCookieConsent() to re-prompt.
* Cross-links DMCA / CGU / mentions (the latter two will land in
légal item 3).
* To be reviewed by counsel before v2.0.0 — text is honest baseline,
not finalised legal copy.
Wired :
* Lazy-component registry (lazyExports.ts + index.ts + LazyComponent
facade)
* Public route /legal/privacy in routeConfig.tsx
* <CookieBanner /> mounted in App.tsx after AppRouter so it overlays
every screen including the landing page
* Lint baseline holds at 754 (the 6 unavoidable warnings —
react-refresh on co-located helpers + native <button> on a
standalone-bundle-required component — are suppressed inline with
specific reasons)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The migrate Phase A pg_isready ran 12 retries against
veza-staging-postgres.lxd:5432 — DNS resolved fine but TCP got "no
response". Cause: PostgreSQL's default listen_addresses is
'localhost', so the bridge-side connection was getting refused.
deploy_data.yml Configure-postgres play now:
* Sets listen_addresses = '*' via lineinfile
* Adds an ANSIBLE-managed pg_hba.conf block: \`host veza veza
10.0.20.0/24 scram-sha-256\` so app containers on net-veza can
authenticate
* Notifies a Restart postgresql handler, then flush_handlers before
the readiness probe so wait_for sees the new bind address
* wait_for now probes 0.0.0.0:5432 instead of 127.0.0.1:5432 to
prove the network listen took effect
Also: deploy_app.yml Phase A wipes /opt/veza/migrate before the
unarchive — the previous run had \`creates: migrate_tool\` which
skipped extraction when an older binary was already there, meaning
a stale migrator could end up running against the current DB. Now
every SHA gets a fresh extract.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous run's migrate_tool failure was opaque because no_log: true
hid the only diagnostic. Restructured Phase A's migration step:
* Pre-flight pg_isready probe waits up to 60s (12 × 5s) for postgres
to be reachable from the tools container — DNS / network failures
now surface with a clear retry log instead of dying inside migrate.
* DATABASE_URL replaced with individual DB_HOST/DB_PORT/DB_USER/
DB_PASSWORD/DB_NAME env vars to dodge any URL-encoding edge case
on the auto-generated password (\`@\` / \`:\` / \`?\` would all break
the connection string).
* Password is staged into /tmp/migrate.env (no_log: true on that
task only), the migrate_tool run sources the file but keeps its
stdout/stderr fully visible. Output is then echoed via debug
unconditionally, file is shredded, and a separate fail-task asserts
rc=0 — so any future migrate failure has a visible message.
Also: defensive python3 bootstrap on the haproxy container in Phase
B. The container should already have python from haproxy.yml setup,
but a fresh-from-scratch deploy that skipped that bootstrap would
otherwise fail silently here.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two artifact-fetch problems in one shot:
1. URL mismatch (404). Builds pushed to \$REGISTRY_URL =
https://10.0.20.105:3000/api/packages/senke/generic, but ansible
was reading \`veza_artifact_base_url\` from group_vars/all/main.yml
which still pointed at https://forgejo.talas.group/api/packages/talas/generic
— different namespace AND host. Workflow now passes
\`-e veza_artifact_base_url=\$REGISTRY_URL\` to both ansible-playbook
invocations so build + deploy share one source of truth.
2. Internal Forgejo on 10.0.20.105:3000 serves a self-signed cert,
which would have tripped get_url's TLS validation right after the
URL mismatch was fixed. Both \`Fetch backend tarball\` (Phase A) and
\`roles/veza_app/tasks/artifact.yml\` (Phase C) now use
\`validate_certs: \"{{ veza_artifact_validate_certs | default(false) }}\"\` —
flip to true once the registry has a public CA cert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase A and Phase C in deploy_app.yml both launch fresh debian/13
containers and immediately try to use ansible.builtin.* modules,
which all need python3 on the target. Three places to fix:
1. Phase A "install backend artifact" play (veza_app_backend_tools):
added a raw bootstrap-python3 step before the apt deps task.
2. veza_app role (used by Phase C blue/green plays for backend, stream,
web): added the same raw bootstrap + a setup module call to gather
facts now that python is available, between Load-vars and the
container.yml include. ansible_date_time used downstream needs
gathered facts.
3. Phase F textfile_collector path: /var/lib/node_exporter doesn't
exist on the runner. Defensively mkdir + failed_when: false on the
metric write so a missing exporter doesn't fail the deploy.
Plus: drop actions/upload-artifact entirely from deploy / rollback /
cleanup-failed. v4 hits GHESNotSupportedError, v3 hits self-signed
cert through 5 retries (1m20s wasted per run). Stream the logs to
stdout via `cat` inside ::group:: blocks — discoverable in run UI,
no flaky network call.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
community.rabbitmq.* modules (used for vhost/user mgmt) shell out to
rabbitmqadmin via HTTP, which requires the \`requests\` library on the
target. The fresh rabbitmq container only has python3 from the
bootstrap play.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Forgejo's act_runner identifies as GHES, which makes
actions/upload-artifact@v4+ bail with GHESNotSupportedError. v3 still
works. Applied to deploy.yml, cleanup-failed.yml, rollback.yml. Also
added continue-on-error to the deploy log upload — losing the forensic
artifact shouldn't fail the deploy itself.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
images:debian/13 (trixie) ships PostgreSQL 17 in its default repos but
the project is pinned on PG 16. Added the PostgreSQL Global Development
Group apt repo (apt.postgresql.org/trixie-pgdg) with its signing key,
which carries every supported major version including 16.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
community.general.incus tasks failed with \"Error: The remote
'srv-102v' doesn't exist\" because the inventory's default
veza_incus_remote_name=srv-102v is the operator-laptop alias.
The runner reaches the host's incus daemon via a mounted unix
socket — that's the \`local\` remote from its POV. Set
veza_incus_remote_name: local in both staging and prod group_vars.
Operator-laptop deploys can still override on the CLI:
ansible-playbook ... -e veza_incus_remote_name=srv-102v
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two blockers after the runner gained incus admin and started reaching
the new data containers:
1. Debian apt's ansible-core (2.14) is below community.general's
minimum, which logged "Collection community.general does not
support Ansible version 2.14.18". runner-bake-deps.sh now installs
ansible-core via pipx (latest stable) plus the required collections
(community.general, community.postgresql, ansible.posix).
2. images:debian/13 — what the data containers are launched from —
ships without python3, so every module call to a freshly-launched
container hit "Failed to create temporary directory" / UNREACHABLE.
Added a single bootstrap play (\`hosts: veza_data\`) that uses the
raw module to install python3 + python3-apt before any other
Configure-X play touches the targets.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
deploy_data/deploy_app plays now run from INSIDE the forgejo-runner
container with ansible_connection=local, but the unprivileged runner's
root user (mapped to a high host UID) was being rejected by the incus
daemon — \"You don't have the needed permissions to talk to the incus
daemon\".
runner-grant-incus.sh: privileged + nesting + raw.idmap=\"both 0 0\"
so root inside the runner = root on the host. The mounted incus socket
becomes fully usable. One-shot script; idempotent.
Threat-model note in the script header: we accept this because the
deploy workflow already has incus-admin scope via socket+nesting, and
the trigger surface is gated to push:main + workflow_dispatch (no fork
PRs).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Inline \`if ! command -v zfs\` blocks tripped Ansible's argument splitter
("unbalanced jinja2 block or quotes") — likely the parens-and-em-dash
combo inside double quotes. Replaced with a clean approach: probe zfs
once at the start of the play, set a fact, gate the snapshot + prune
tasks with \`when: zfs_present\`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The forgejo runner lives inside the forgejo-runner Incus container with
the host's incus socket mounted in. From inside, the operator-side SSH
alias \`srv-102v\` doesn't resolve — Ansible's first task tried to ssh
and bailed with UNREACHABLE.
Switching the incus host entry to \`ansible_connection: local\` is sound
because every incus_hosts task only invokes the \`incus\` CLI, which
talks to the daemon over the mounted socket. No SSH-into-host needed.
ZFS snapshot/prune plays still need real ZFS on the host, which the
runner doesn't have — wrapped them in \`command -v zfs\` so they no-op
on the runner instead of erroring. The snapshot is a safety net, not
a correctness gate; for full safety run deploy_data.yml from the
operator laptop with --vault-password-file.
Same change applied to inventory/prod.yml.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A leftover \`--sumi-accent-hover\` declaration + closing brace was
hanging outside any selector after the [data-contrast=\"high\"] light
block. PostCSS choked on the orphan \`}\`. Folded the declaration into
the light high-contrast block where it belongs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
vite + typescript are devDeps but required at build time, so the
NODE_ENV=production hack from earlier broke build-spa with
\"vite: not found\". Reverting to a normal devDeps install.
The reason we omitted devDeps in the first place was bundlesize@0.18.2
pulling iltorb (deprecated native node-gyp module that doesn't build on
Node 20). bundlesize was declared in apps/web devDependencies but
nothing actually invokes it — pure dead weight, removed.
deploy.yml: dropped NODE_ENV=production, dropped the husky shim, kept
--ignore-scripts (we don't need git hooks during deploy) plus HUSKY=0
as belt-and-braces.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
\`npm ci --ignore-scripts\` skips top-level lifecycle scripts but npm 10
still executes workspace \`prepare\` hooks during the linking phase.
apps/web's prepare = \"husky\" was tripping the install with exit 127
because husky is a devDep we deliberately don't install in deploy.
Putting a /bin/sh shim that exits 0 on PATH before \`npm ci\` makes the
prepare call a no-op without touching package.json.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
build-stream was failing on openssl-sys because the runner has glibc
libssl-dev but cargo cross-compiles to x86_64-unknown-linux-musl.
Adding \`openssl = { features = ["vendored"] }\` as a direct dep forces
openssl-src to build OpenSSL from source against musl, which feature-
unifies through reqwest's native-tls and any other openssl-sys consumer.
The vendored build needs perl + make at compile time — added them to
runner-bake-deps.sh. The runner already has build-essential for the C
compiler.
Note: the build-web "husky: not found" error in the same run looks
like a re-run of an old SHA, since main has \`npm ci --ignore-scripts\`
since d243c2e2. A fresh workflow_dispatch should clear it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three more deploy.yml fixes shaken out by the first non-broken run:
1. backend Push step: \`curl --fail-with-body\` is curl 7.76+; the
runner's curl is older. Plain \`-f\` already fails on non-2xx, the
extra flag was redundant.
2. stream Build: \`cargo build --locked\` requires Cargo.lock, but
veza-stream-server/.gitignore was hiding it. Tracked it now (binary
crate — lock file belongs in version control for reproducibility).
3. web Install: NODE_ENV=production skips devDeps, including husky,
but the root \`prepare\` script invokes husky and exits 127.
--ignore-scripts skips the install hook entirely; the explicit
\`npm run build:tokens\` step still runs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Single-quote nesting through ssh -> sudo -> incus exec -> bash -c was
mangling rm globs. A standalone script run on the R720 sidesteps the
quoting layers entirely.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The dpkg-lock thrashing — even with flock — was unwinnable: an unrelated
apt-get had been holding the host lock for >180s. Stop installing OS
packages from inside the workflow entirely; assume they're baked onto the
forgejo-runner container, fail loudly with a clear pointer if they're
missing.
scripts/bootstrap/runner-bake-deps.sh installs them all in one shot.
While here, fix the iltorb regression: --include=dev was dragging in
apps/web's bundlesize devDep, which transitively pulls iltorb (a
deprecated native node-gyp module that doesn't build on Node 20).
Moved style-dictionary to dependencies in @veza/design-system (it's a
build tool, needed by `npm run build:tokens` at deploy time, not a dev
tool), and the workflow now runs plain `npm ci` with NODE_ENV=production.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
