GET /api/admin/verifications returned a bare JSON array, but every
consumer (Verification Management, Approval Management, and the e2e
test's own mock) expects {items: [...]}. Array.isArray(payload?.items)
was always false against a bare array, so both admin screens have been
showing "No verification requests found" regardless of what's actually
in the queue.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The prior push (crates/cache change) rebuilt all 20 workspace services
concurrently, and the employees job's build/push landed a digest that
doesn't exist in the registry (kubectl confirmed ImagePullBackOff with
"not found" resolving that exact sha256). This commit only touches
apps/employees/ so the CI path-filter rebuilds just that one service in
isolation, without the same concurrent-build congestion.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Employees (internal admin/staff) had no self-service password reset —
only /login, /logout, /session existed. Adds /api/admin/auth/forgot-password
and /api/admin/auth/reset-password, mirroring the existing users-table flow
but against EmployeeRepository and a distinct Redis key namespace
(reset:employee:*) so a code for one identity store can never be consumed
against the other.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
extract_documents() recognized a stale set of document keys that no longer
matched what the frontend actually uploads (portfolio_ownership_proof,
professional_certifications, qualification_proof, tax_document), so every
non-COMPANY role's verification case was created with an empty documents
array. Also extracts role_key_to_display/role_to_table into a shared
role_meta module — verifications.rs and approvals.rs were each missing
UGC_CONTENT_CREATOR from their inline copies, so that role's rejections
and final approvals were silently no-ops.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The admin/employee login handler had no brute-force protection, unlike
the regular user login path. Given these accounts hold internal/
super-admin privileges, add a tighter limit (5 attempts/15min vs 10
for regular users) using the existing sliding-window Redis limiter.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Roles assigned at registration are immediately active for login + session.
Document/profile approval (handled separately by user_role_profiles in
onboarding/verifications) is the correct gate for review workflows —
do not gate raw role assignment on that flow.
Previously defaulted to PENDING for non-demo accounts, which get filtered
out by get_user_role_keys (WHERE status = 'APPROVED') and produced JWTs
with empty roles, causing the 'role is not assigned' UX bug after login.
capacity=3/node (9 total) oversubscribed the 8 physical cores per
node - individual builds slowed roughly 3x under contention (observed
directly: builds that took ~2m37s standalone were still running after
8+ minutes), for no clear net throughput win since this workload is
CPU-bound. Also found and fixed the actual reason capacity wasn't
taking effect at all initially: the runner daemon command never
passed --config, so it was silently running on default settings
regardless of config.yaml. Settled on 2/node (6 total, matching
docker-ready runner-2/3/4 - the control-plane node nxtgauge-1 is
deliberately excluded from the runner DaemonSet and should stay that
way, not used for build load).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bumped runner.capacity from 1 to 3 on all 3 runner pods (9 total
concurrent slots - nodes were sitting at 7-11% CPU during builds, so
plenty of headroom), matched here with max-parallel: 9.
Also fixed a real bug: the gitops-push retry loop had no check after
exhausting all attempts, so a job whose every push attempt failed
would still exit 0 and report "success" - which is exactly what
happened on the previous run (verified: all 20 services built and
pushed their images correctly, but the actual GITOPS_PAT secret was
invalid/expired, and the retry loop silently swallowed the resulting
failure across all 20 jobs). Fixed the secret itself (confirmed the
existing admin-scoped Forgejo token has valid push access to
ashwin/nxtgauge-gitops and rotated GITOPS_PAT to it), and added an
explicit exit 1 if the retry loop exhausts without a successful push.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Confirmed via the matrix run: every service's actual docker build and
push succeeded, but the GitOps-update step failed on all of them with
"GITOPS_PUSH_TOKEN is empty". Checked the repo's configured secrets -
GITOPS_PUSH_USERNAME/GITOPS_PUSH_TOKEN were never set; only a leftover
GITOPS_GITHUB_USERNAME/GITOPS_GITHUB_TOKEN pair (from before the
gitops repo moved to Forgejo) and GITOPS_PAT exist. Confirmed
ashwin/nxtgauge-gitops lives on ci.nxtgauge.com matching this
workflow's defaults, so GITOPS_PAT is the one meant for this.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The build was structured as a single job looping through all ~20
services sequentially, so only 1 of the 3 deployed runner pods (one
per worker node) was ever used - the other 2 sat idle for the entire
build. Switched to a static per-service matrix (max-parallel: 3,
matching the 3 runners at capacity 1 each) so independent services
build concurrently. Each matrix job does its own quick "does this
service need building" check up front (same change-detection logic,
now per-job) rather than relying on a shared job output, to avoid
needing cross-job artifact/output passing.
GitOps updates also move into each matrix job (previously a single
step at the end) since there's no longer one job aggregating all
results - added a fetch/reset/retry loop since multiple jobs can now
push to the same gitops branch concurrently.
Tried adding cargo registry/target cache mounts to Dockerfile.simple
for a bigger per-build win too, but measured it directly (local A/B:
cold build 2m37s vs a second, supposedly-cached build 7m18s) and it
made things slower here, likely cargo's own cache-verification pass
outweighing the benefit for this dependency set - reverted that part,
Dockerfile.simple is unchanged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docker buildx --metadata-file writes pretty-printed JSON (space after
the colon: "containerimage.digest": "sha256:..."), but the digest
grep required compact JSON with no space, so it always matched
nothing. That produced an empty $digest, which the script correctly
treated as fatal and exited on - right after the first service
(gateway) had already built and pushed successfully, silently
aborting the rest of the service loop. Verified the fix against a
real locally-generated metadata file from the same buildx command.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The official rust:alpine base (unlike whatever image the old defunct
registry.nxtgauge.com mirror actually held) already ships a full
rustup-installed toolchain, so the extra `curl rustup.rs | sh` step
now fails with "cannot install while Rust is installed". Drop it and
the /root/.cargo/bin PATH override (the base image already sets PATH
to its own /usr/local/cargo/bin) - just add the musl target, which the
existing rustup binary can do directly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
registry.nxtgauge.com was set up back in April for the old Woodpecker
CI (commit 09df032) as a manual one-time mirror of rust:alpine to
dodge Docker Hub rate limits. It never had a real ingress route wired
up on the current cluster (confirmed: no Ingress/IngressRoute matches
that host anywhere), so every build has been failing at the base-image
pull. ci.nxtgauge.com is the registry actually in active use since the
Forgejo migration, and the build job already authenticates against it
for pushing service images, so no new credentials are needed. Manually
mirrored rust:alpine there as a one-time step.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
--add-host=host.docker.internal:host-gateway is not being honored by
this act_runner setup (tried via the runner's global container.options
and a per-job container: block; neither worked, confirmed by two
separate failed runs with identical DNS-lookup errors). Read the
container's real default-route gateway from /proc/net/route instead
(portable, no iproute2 dependency) and export it as DOCKER_HOST via
GITHUB_ENV. This is the actual IP of the dind engine that spawned the
job container, regardless of hostname-aliasing support.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Forgejo's docs note --add-host via the runner's global
container.options config is not reliably honored for jobs using pure
label-based runs-on mapping. Setting the same image + options
explicitly per-job via jobs.build.container is the more directly
supported path for per-job container customization.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
127.0.0.1:2375 only worked from the runner container's own network
namespace (sibling to the dind sidecar in the same pod). The actual
job container that runs each step is spawned *by* that dind engine,
one level deeper, so its own loopback doesn't reach the sidecar.
host.docker.internal (mapped to the job container's real gateway via
--add-host=host.docker.internal:host-gateway in the runner's
container.options) reaches back to the dind engine that created it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The unindented heredoc terminator (<<EOF2 ... EOF2 flush-left) broke the
YAML block-scalar indentation contract for the `run: |` step, causing
Forgejo to log "ignore invalid workflow build.yaml: yaml: line 75:
could not find expected ':'" and silently skip the workflow entirely
on every push since this line was introduced. No builds have run on
main or high-performance since 2026-07-05 as a result. Replaced the
multi-line heredoc with a single-line bash here-string, which needs
no extra indentation and keeps the shell logic identical.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The gateway forwards /api/jobs unmodified to the jobs service, but the
service registered its routes at bare /jobs with no prefix — every
other service (companies, users) nests under /api/<service> to match.
This made the public job listing endpoint unreachable (404) through
the gateway on test111.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Remove build-and-deploy-forgejo.yml from GitHub Actions
- Forgejo CI at ci.nxtgauge.com now handles all builds and deployments
- All images pushed to Forgejo registry (ci.nxtgauge.com/ashwin/*)
- GitOps updates handled by Forgejo workflows
- Update workflow to push to ci.nxtgauge.com/ashwin/*
- Use FORGEJO_USERNAME and FORGEJO_TOKEN secrets
- Fix gitops repo cloning to use x-access-token
- Add ai-assistant to deployment scripts
- Add #![allow(dead_code)] pragma to all main.rs files
- Remove unused imports from users handlers (ai_cache, AiCreditPackageRepository, AiCreditTransactionRepository)
- Make LiteLLMChatMessage and LiteLLMChoice public with public fields
- Fix remaining unused variables with cargo fix
- Add missing pub visibility modifiers to litellm structs
All packages now compile with ZERO warnings and errors!
- Remove duplicate 'name' field from PricingPackageRow struct
- Add tracecoins_credited variable from package.tracecoins_amount
- Change rust_decimal to use i32 instead of Decimal for SQL compatibility
- Simplify discount calculation to work with paise (integer) values
- Fix payu config field names (merchant_key, merchant_salt)
payments package now compiles successfully.
- Fix match arm type errors in ai.rs: wrap bare String returns in (String, bool)
tuples to match expected return type (response_text, _ollama_used)
- Add Deserialize trait to LiteLLMChatMessage for deserialization
- Add missing fields to GenerateFieldResponse constructors
- Remove body.user_id reference from form extraction (field doesn't exist)
- Add get_llm_base_url() and get_llm_model() helper functions
users package now compiles successfully (only warnings remain).
- Restore deleted module declarations (tutor, ugc_content_creator, user,
user_role_profile, verification, video_editor) in db/models/mod.rs
- Add mod ai; to users/src/main.rs (fixes crate::ai import)
- Add pub mod ai_auto; to handlers/mod.rs
- Add rust_decimal dependency to payments/Cargo.toml
- Fix missing PgPool import in payments/src/ai_credits.rs
- Make LiteLLMUsage fields public in users/src/litellm.rs
- Add get_llm_base_url() and get_llm_model() helper functions
- Remove leading underscore from variables that are used
Partial fix for high-performance branch build issues.
Delete legacy code that used old company_ai_usage/job_seeker_ai_usage tables:
- Remove has_active_ai_pack() - old AI_PACK pricing package check
- Remove check_and_increment_usage() - legacy daily quota tracking
- Remove BASE_AI_LIMIT, get_ai_limit_for_package constants/functions
- Remove legacy queries from ai_auto_apply() and ai_usage_status()
- Update auto_apply.rs to use user_ai_subscriptions.daily_actions_used
instead of job_seeker_ai_usage table
- Inline apply_scheduled_downgrades() and expire_trials() in cron tasks
to remove dependency on users crate internal modules
The new system uses user_ai_subscriptions with:
- daily_actions_used / daily_credits_used counters
- monthly_credits_total / monthly_credits_used
- purchased_credits_total / purchased_credits_used
All AI billing now flows through the wallet/ledger system with
LiteLLM integration (Tasks 1-10).
- Delete apps/companies/src/handlers/ai.rs (broken placeholder code)
- Remove ai module export from handlers/mod.rs
- Remove /api/companies/ai route from main.rs
The broken stub had:
- Uuid::parse_str("placeholder") that always errored
- Uuid::new_v4() generating random IDs instead of using auth
- Queries to non-existent company_ai_credits/ai_usage_log tables
AI credits are now properly handled by the users service with
the new ai_credits module (wallet, ledger, LiteLLM integration).
Critical: ai_access_middleware was wired via from_fn_with_state((), ...)
- passing the unit type as state - and pulled AppState from request
extensions, which nothing ever populated. Every request through
/api/ai/* and /api/ai/auto/* returned 500 INCOMPLETE_CONTEXT. Fixed by
extracting State<AppState> properly and passing the real state at both
call sites; removed the redundant, identically-broken inner middleware
layer inside ai_router().
Security: ai_addon_purchase (/api/ai/addons/purchase, /api/ai/credits/buy)
and ai_plan_upgrade (/api/ai/plans/upgrade) granted AI credits / plan
upgrades (including enterprise) with zero payment verification - any
authenticated user could mint unlimited free credits, and the frontend
already called this directly. Disabled both until wired to a real
payment flow.
Quality: added a grounding/anti-hallucination system prompt applied to
every AI feature call (orchestrator::call_feature /
call_feature_with_plan, plus the handful of call sites that bypass the
orchestrator). Verified against the live model that it reduces but does
not eliminate fabrication on harder reasoning tasks - even the larger
model invents facts not present in the input on some prompts. This is a
real limitation of the two locally-hosted models, not something a
system prompt alone fully solves; flagged for follow-up (e.g. a
verification pass or deterministic checks for high-stakes decisions
like auto-apply).
Also fixed Persona/Pillar keyword detection using naive substring
matching (e.g. "team" matching inside "esteemed", "lead" matching
inside "leadership") - added a word-boundary-aware contains_word()
helper and applied it to all keyword classifiers in this file.
The frontend (lib/payu.ts, payu-return.tsx) and admin config UI had
already switched to PayU, but the payments service was still calling
Razorpay's order API and verifying Razorpay HMAC signatures -
payments were broken end to end. Rewrites apps/payments to PayU's
hash-based hosted-checkout flow (SHA-512 request/response hash,
key+salt from admin config or PAYU_MERCHANT_KEY/PAYU_SALT), for both
the tracecoin wallet purchase flow and the AI credits flow. The AI
credits frontend checkout was also fabricating a fake payment_id and
signature client-side instead of ever opening a real PayU checkout -
fixed to use the same real flow as tracecoin purchases.
Also fixes the ai_create_ticket endpoint on the users service, which
never validated the X-AI-Service-Key header despite the client
sending one - anyone could create tickets under an arbitrary user_id.
