// Canonical shape of the .workflow/emails/emails.json file passed between the fetch and summarize states — required fields (sender, recipient, subject, date, body), types, and field semantics. Read this whenever you write or read emails.json so producer and consumer agree on the shape.
Reference vocabulary for designing instrumented harnesses that drive vulnerability discovery — design classes (trigger-driven vs coverage-driven), tiered scope (T1 isolated function / T2 multi-component / T3 full build), systematic input exploration, the two-coverage distinction (fuzzer-feedback vs audit), existing-fuzzer selection (libFuzzer / AFL++ / Jazzer / atheris / `go test -fuzz`), seed-corpus discipline, diagnostic checkpoints, common pitfalls, and design-document scope. Read when designing or reviewing a harness specification. Stays neutral on language and stack — pulls in the relevant surface skill (e.g. `memory-safety-c-cpp`) for bug-class taxonomy.
Reference vocabulary for interpreting vulnerability findings — detector-vs-impact distinction, severity anchoring on demonstrated evidence, the eleven-item interpretation rubric, delegation transparency, primitive-extent scaling, the disqualifier taxonomy (D-0..D-4), CVSS Achievable / Environmental framing, hedging-phrase elimination, and falsification asymmetry. Read when interpreting a finding to decide whether the demonstrated evidence supports the severity it would warrant. Surface-neutral; pulls in the relevant surface skill (e.g. `memory-safety-c-cpp`) for bug-class-specific exploitability factors.
Reference vocabulary for memory-safety vulnerabilities in native C/C++ code — bug-class taxonomy, common arithmetic patterns that lead to corruption, dispatch-family discipline, type-confusion idioms, use-after-free patterns, and exploitability factors. Read when analyzing, hypothesizing, designing harnesses for, or triaging findings against C/C++ code with sanitizer support (ASAN/UBSAN/TSAN/MSan). Not applicable to managed runtimes (JVM, .NET) or scripting languages — those have their own skills.
Markdown formatting conventions for email summary documents — heading depth, list style, line length, emoji policy, and a mandatory provenance footer. Read this when producing a markdown report that summarizes one or more email messages so the output matches the project's house style.
Reference for Gmail's search query syntax — operators like is:sent, newer_than:, from:, has:attachment, label:, and how they compose. Read this when constructing a Gmail search query string for the google_workspace.gmail_search_messages Code Mode call, especially when filtering by sent vs received, recency, sender, or labels.
Tone and length conventions for email summaries — voice, verb tense, what to include vs omit, and target sentence count. Read this when writing the prose Summary line for each email so the voice is consistent across the report.
| name | json-schema-emails |
| description | Canonical shape of the .workflow/emails/emails.json file passed between the fetch and summarize states — required fields (sender, recipient, subject, date, body), types, and field semantics. Read this whenever you write or read emails.json so producer and consumer agree on the shape. |
The fetch state writes .workflow/emails/emails.json and the summarize
state reads it. The file is a single JSON array of email objects. The
canonical JSON Schema is in the sibling file schema.json; this document
explains the fields and their semantics.
A JSON array. Each element is an email object. The array order is preservation order — the consumer renders emails in the order they appear, so the producer should write them in the order it wants them rendered (typically newest-first as returned by the API).
All fields are required and must be strings unless noted.
sender — the From address. Format Name <addr@example.com> if the
source provides a display name, else the bare address.recipient — the To addresses, comma-separated. If the source has
multiple To recipients they are joined with , (comma + space). CC
and BCC are not represented in this schema.subject — the email subject line, verbatim. Empty string is allowed
if the source has no subject; do not substitute "(no subject)".date — the date as it appears in the source headers (RFC 2822 or
whatever the API returns). Do not reformat or normalize the timezone.body — the message body as plain text. If the source is HTML, the
producer is responsible for stripping tags before writing. Newlines
are preserved; tabs are replaced with two spaces.The sibling schema.json is a draft-2020-12 JSON Schema. Tooling that
needs to validate the file structurally should load it from there; this
document is the human-readable companion.