Rebuild the generated certificate to match the client's templates
Elazar supplied the four real .pptx templates on 2026-10-08 (one per tier). Stored in pm/client-provided/certificate-templates/ (git-ignored) with the original Drive zip; findings committed in pm/reference/certificate-template-findings.md (bd8928b). The generated PDF shipped in WEBCERTI-16 does not match them. Differences read out of the OOXML, not guessed: the client deck is SQUARE, 10287000x10287000 EMU = 11.25in (810x810pt), while the app renders A4 landscape per Elazar s instruction. Headline is "Career Webinars Engagement Certificate", not "Career Workshops"/"Certificate of Achievement". Body is "Has attended N [new] Career Webinars and has reached the <Tier> Level." followed by "The following webinars were attended:" and exactly three "<title> by <speaker>" lines. Signatory is Mirta Aguirre, Head of Coaching and Employability, with a signature PNG. No date of issue appears anywhere. Artwork is four PNGs in the slide master: background blobs, VI logo, tier-badge strip with the earned tier highlighted, signature. Fonts in the deck are Poppins/Roboto/Exo/Tahoma; the app embeds Lato. THREE BLOCKERS, all need Elazar, none guessable: 1. Square (client) vs A4 landscape (his instruction) - which format ships. 2. Champion reads "3 NEW Career Webinars" while Champion needs >=12 total, and there are exactly three webinar slots. That reads as "webinars since the previous tier certificate", which the app can compute from certificates.sent_on, but it is not proven and nothing in domain-knowledge-from-spreadsheet-rebuild.md covers it. Printing the wrong count puts a false statement on a participant-facing document. 3. Whether the app may embed the VI logo, the tier badges and Mirta Aguirre s signature image in an automatically generated certificate. Not blocked by the above: the copy strings and the layout are a single constant (COPY) plus the draw calls in src/lib/certificate/pdf.ts, and the four PNGs can be lifted from any of the decks at ppt/media/.
Activity
-
Shipped in 45ad9ad (v0.3.0). Elazar answered the three blockers 2026-10-08: (1) square, (2) yes to logo/badges/signature, (3) derive the count from the data. Count rule DERIVED, not guessed - evidence in pm/reference/certificate-template-findings.md: Explorer sample robert4asiedu@gmail.com has exactly 3 attendances, listed verbatim in the deck, wording '3 Career Webinars' with no prior send; Champion sample emkay618@gmail.com says '3 new' and lists what he attended after his SuperStar send of 2025-08-13 (the third listed title, 2025-10-22, is the webinar migration/README.md records as 10-of-15 rows lost to #REF!, and our copy holds 5 attendees vs 58-59 either side). Rule: a tier names the qualifying webinars attended after the newest lower tier's send date, all of them when none was sent; printed N is that list's length; 'new' appears exactly when a lower tier has gone out. Window also closes at this tier's sent_on so a reprint reproduces what was sent. Built: 810x810pt page, master coordinates for the logo/background/tier badge strip/signature/rule, Poppins Regular+Bold from Google Fonts OFL (Lato dropped), variable-length webinar list that shrinks to fit, singular/plural, no date of issue. Verified in production: 200, %PDF-, 219761 bytes. Open, for the client not the code: (a) 18 of 382 migrated sends are one short of their threshold and one (nushjaleel@gmail.com superstar) has sent_on 2015-08-13, a typo for 2025 - those certificates will print a count one lower than she typed; (b) nobody has two pending tiers today, so 'Explorer and Star both pending' is a choice (anchor on newest SENT lower tier), not a derivation.
-
completed
-
Correction: the sent_on-window rule I closed this with was NOT derived - both models fit the two samples, and the client's answer picked the block model. Her workbook proves it directly: Certificates_Summary groups Webinar 1-12 under EXPLORER/STAR/SUPERSTAR/CHAMPION headers, 3 columns each. Reimplemented as a fixed block of the qualifying sequence, positions (previous threshold + 1)..(this threshold), read from certificate_tiers - no send-date dependency, so reprints are stable and the double-pending question is moot. Shipped ab45e90 v0.3.1. The Explorer threshold conflict this exposed is WEBCERTI-19.