fix: route email trigger path through standard info channel

[hugocasa]

Summary

Two related fixes for email triggers — the wire-format change is in the EE companion (windmill-labs/windmill-ee-private#553); this PR contains the skill/docs side and the EE ref bump.

What changed in this PR

• triggers skill now documents email triggers (was missing entirely). New section in system_prompts/base/triggers.md covers:
  • local_part / workspaced_local_part config and the localpart+key=value@… URL-extras convention
  • the parsed_email / raw_email / email_extra_args payload shape
  • where trigger_path lives after the EE fix (only with a preprocessor, at event.trigger_path)
  • attachments are S3 objects — parsed_email.attachments[i].body is { s3: "windmill_emails/<job_id>/attachments/<filename>" }, must be read via wmill.loadS3File / wmill.load_s3_file
  • same fallback for oversize raw_email bodies, and the parquet server feature requirement
• EmailTrigger is now in SCHEMA_MAPPINGS, so the generated triggers/SKILL.md includes the email-trigger YAML schema next to the others (one combined skill — there is not one skill per trigger type).
• "Email" added to the trigger-kinds line in cli/src/guidance/core.ts.
• Regenerated system_prompts/auto-generated/ (skill + new email_trigger.schema.yaml) and cli/src/guidance/skills.gen.ts.

What changed in the EE companion

windmill-labs/windmill-ee-private#553 — stops conflating trigger_path with user-supplied URL extras. Before, both were stuffed into the same map and bundled under email_extra_args via a bespoke build_job_args_v2 override. After, URL extras go through the payload, trigger_path rides the standard info channel, and the default TriggerJobArgs impl puts it at event.trigger_path — same as every other trigger.

Breaking change

Scripts that read email_extra_args.trigger_path (with or without preprocessor) need to switch to event.trigger_path and add a preprocessor. Add a clear note in the next release.

Test plan

• Run `python system_prompts/generate.py` — output matches what's checked in.
• Run `wmill init` against a fresh dir, confirm the generated `triggers/SKILL.md` has the email section + email schema appended.
• Send an email to a custom email trigger with +foo=bar extras; confirm the job receives email_extra_args = {foo: "bar"} (no trigger_path mixed in).
• Same trigger with a preprocessor: confirm event.trigger_path, event.kind === "email", event.email_extra_args = {foo: "bar"}, event.parsed_email, event.raw_email.
• Send an email with a binary attachment to a workspace with S3 configured; confirm the script can wmill.loadS3File(parsed_email.attachments[0].body).
• Capture flow still records samples for both custom email triggers and default email runnables.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying windmill with    Cloudflare Pages

Latest commit:	9f5c0ee
Status:	✅  Deploy successful!
Preview URL:	https://0ae147c7.windmill.pages.dev
Branch Preview URL:	https://email-trigger-path-attachmen.windmill.pages.dev

View logs

[windmill-internal-app]

🤖 Updated ee-repo-ref.txt to 26184ab7a4aadfc529dcedf038aa08d36c7ad381 after windmill-ee-private PR #553 was merged.

[cubic-dev-ai]

No issues found across 8 files

[hugocasa]

/ai-fast review this PR

[claude]

Claude finished @hugocasa's task in 1m 37s —— View job

---

Review

• Read changed files
• Analyze docs/skill content for accuracy
• Verify auto-generated files match base inputs
• Post review

Verdict: LGTM. Docs are accurate, regenerated artifacts match the base inputs (triggers.md + generate.py + utils.py), and the schema slot for EmailTrigger is wired through both system_prompts/generate.py and cli/src/guidance/skills.gen.ts consistently. The .sqlx cache rename matches the corrected predicate (NOT (workspace_id = $3 AND path = $2)) so old-cached prepared statements won't drift after the EE merge.

A few minor observations — none blocking:

1. Code-fenced JSON example uses non-JSON placeholder

system_prompts/base/triggers.md:32:

{ "s3": "windmill_emails/<job_id>/attachments/<filename>" }

The fence is json but <job_id> / <filename> aren't valid JSON tokens. Readers parse the intent fine, but if this ever gets fed through a strict JSON-aware tool it will fail. Either drop to a text fence or leave as-is — matches the convention already used elsewhere in the file. Non-blocking.

2. "URL-style extras" wording

system_prompts/base/triggers.md:18:

Senders may append URL-style extras to the local-part with +: mytrigger+foo=bar+baz=qux@….

URL extras are usually ?k=v&k=v. Here they're +k=v+k=v, which is RFC 5233 sub-addressing repurposed. Could trip a reader. Consider plus-addressing extras or subaddress extras. Non-blocking.

3. RFC reference

system_prompts/base/triggers.md:24 — "the raw RFC 822 message". RFC 822 was obsoleted by 2822 and then 5322. Most people still say "RFC 822" colloquially, so this is fine; flagging only in case you want to be precise.

4. Fallback string is verbatim

system_prompts/base/triggers.md:46 quotes the literal fallback "configure s3 in the workspace settings to handle attachments". Worth pinning in EE so the docs don't drift if that string is ever re-worded — but that's an EE-side concern, not this PR.

5. Schema completeness

system_prompts/auto-generated/schemas/email_trigger.schema.yaml:

• Missing description: on most top-level fields (local_part, workspaced_local_part, labels, error_handler_path). The other trigger schemas in this repo also have sparse descriptions, so this is consistent — but the user-facing skill would benefit from descriptions on local_part and workspaced_local_part in particular since those are the email-specific knobs. The fix is upstream in the OpenAPI annotations, not in this PR.

6. cli/src/guidance/core.ts:40

The trigger-kinds list now reads "HTTP routes, WebSocket, Kafka, NATS, SQS, MQTT, GCP, Azure, Email, or Postgres CDC triggers." Order is fine, just noting that Postgres CDC is the only kind that follows a different naming convention (no plain "Postgres") — keeping it last preserves readability. No change needed.

---

Nothing in here would block the merge. The auto-generated files mirror the base sources exactly (verified by inspecting both diffs — same body, just template-literal-escaped in the .gen.ts copy), and the schema is wired in both SKILL_DEFINITIONS and the schema_names list in generate.py so future regens stay in sync.
• Branch: email-trigger-path-attachments