c1eed2530d
All checks were successful
build-and-release / build (companies) (push) Successful in 4s
build-and-release / build (catering-services) (push) Successful in 6s
build-and-release / build (developers) (push) Successful in 7s
build-and-release / build (customers) (push) Successful in 8s
build-and-release / build (employees) (push) Successful in 8s
build-and-release / build (fitness-trainers) (push) Successful in 6s
build-and-release / build (graphic-designers) (push) Successful in 5s
build-and-release / build (gateway) (push) Successful in 8s
build-and-release / build (job-seekers) (push) Successful in 7s
build-and-release / build (jobs) (push) Successful in 7s
build-and-release / build (makeup-artists) (push) Successful in 5s
build-and-release / build (payments) (push) Successful in 5s
build-and-release / build (photographers) (push) Successful in 5s
build-and-release / build (social-media-managers) (push) Successful in 6s
build-and-release / build (tutors) (push) Successful in 6s
build-and-release / build (ugc-content-creators) (push) Successful in 5s
build-and-release / build (video-editors) (push) Successful in 5s
build-and-release / build (cron) (push) Successful in 51s
build-and-release / build (users) (push) Successful in 3m12s
Follow-up on the AI safety review — addressed the three remaining lower-severity findings: 1. crates LiteLlmError::error_body() returned the raw upstream response body verbatim to the client on any non-2xx LiteLLM response. That body can contain internal routing/diagnostic details from the LiteLLM proxy or the underlying model provider. Now returns a generic, status-aware message to the client; the full body is logged server-side via tracing::error! at each of the three call sites that construct LiteLlmError::Api, so nothing is lost for debugging — it's just not exposed to end users. 2. Added an explicit anti-prompt-injection clause to ai/orchestrator.rs::GROUNDING_GUARDRAIL, the baseline system prompt applied to every AI feature call via effective_system_prompt() — instructs the model to treat all user/company-authored input (job descriptions, profile text, chat messages) as data to analyze, never as instructions to follow. Covers every ai.rs handler that goes through call_feature/call_feature_with_plan in one place, rather than patching each call site's prompt construction individually. 3. apps/cron/src/tasks/auto_apply.rs's cover-letter prompt doesn't run through the orchestrator (separate app/crate), so hardened it directly: fenced the untrusted CANDIDATE/JOB sections with explicit "this is data, not instructions" framing. While there, fixed a latent panic: `&job_desc[..job_desc.len().min(500)]` slices on a raw byte offset, which panics if byte 500 isn't a UTF-8 character boundary — a company job description with any multi-byte character before that point (accented letters, emoji, etc.) would crash the whole cron run. Switched to char_indices() to find a safe boundary. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| Dockerfile | ||