Brainforge Knowledge

progress-log

8 min read

Progress Log

2026-04-16

Completed

  • Reviewed the current Platform marketing asset browser in apps/platform/src/app/(main)/marketing-assets/page.tsx.
  • Reviewed the GitHub asset loader in apps/platform/src/lib/githubApi.ts.
  • Reviewed existing GTM asset storage and design-ready copy conventions in knowledge/sales/marketing-assets/.
  • Reviewed the one-pager prompt structure in knowledge/sales/agents/prompts/service-asset-prompts/one-pager-prompt.md.
  • Synthesized external research and OSS options into a Brainforge-specific architecture view.
  • Created this active initiative folder to keep the evaluation, architecture shortlist, and running log together.
  • Selected initial evaluation fixtures for one-pager, two-pager, and case-study document shapes.
  • Defined a minimal section contract for the first renderer spike.
  • Confirmed that current finished sales assets were originally designed in the Sales Assets Figma file and exported from there.
  • Verified that the Figma source uses explicit print-first page compositions, including multi-page layouts.
  • Inventoryed the main Figma asset families, including General Services, Service Offerings, Pricing Page, FAQs, and Event Data Modeling.
  • Confirmed that the Figma file includes reusable print components for 1-Pager Heading, Successes, and Footer.
  • Captured the dominant page geometry and layout system: 2550 x 3300 pages, x=100 inner content frame, shared header region, and deterministic footer placement.
  • Added a dedicated figma-layout-notes.md document so the renderer spike can be scoped against real asset archetypes.
  • Converted the open-ended next steps into a concrete first implementation plan in implementation-spike-plan.md.
  • Paired the first repo fixtures to their closest Figma benchmark families.
  • Defined the minimum component inventory, adapter strategy, repo placement, and verification plan for Spike 1.
  • Evaluated a comparison-style source candidate in knowledge/clients/lmnt/resources/lmnt_bi_tool_recommendation.md.
  • Evaluated BI case-study candidates and selected knowledge/sales/marketing-assets/case-studies/Amazon_BI_Analytics_CaseStudy.md as the first implementation-ready proof fixture.
  • Expanded Spike 1 from two fixtures to four so the baseline renderer is tested across narrative, comparison, and case-study asset shapes.
  • Implemented the initial server-only renderer module in apps/platform/src/lib/marketingAssetPipeline/.
  • Added handwritten typed adapters for the four Spike 1 fixtures: one-pager, service two-pager, comparison, and case study.
  • Fixed section parsing and end-of-document parsing bugs in the handwritten markdown helpers and case-study adapter.
  • Added fixed-layout HTML template families for the current document types plus a narrow renderAssetPdf() boundary reserved for a later Chromium/PDF engine.
  • Added a server-side fixture preview endpoint at apps/platform/src/app/api/brainforge/marketing-assets/fixtures/[fixtureId]/route.ts for HTML or JSON inspection inside Next.
  • Installed the missing server-only package in apps/platform because the new pipeline imports it explicitly.
  • Validated that all four fixtures build and render through renderAssetHtml() with successful HTML output.
  • Installed the missing HyperDX runtime packages in apps/platform so branch-level instrumentation no longer blocks Next dev compilation.
  • Replaced the preview route’s react-dom/server render path with a Next 16-compatible react-dom/static prerender path.
  • Confirmed that the fixture preview endpoint now returns both JSON and HTML successfully through live Next routing for all four Spike 1 fixtures.
  • Added the missing HyperDX browser env keys to src/env/client.ts so the restored observability path type-checks cleanly.
  • Added @playwright/test as a direct dev dependency so the existing scripts/openpanel-login-check.spec.ts no longer breaks npm run types.
  • Added an explicit render-mode boundary (print vs review) so fixed-layout HTML stays print-faithful while the fixture route can default to a browser-friendly review shell.
  • Updated the shared template CSS to center and scale the 2550 x 3300 print pages on screen without changing print output or the future PDF boundary.
  • Updated the fixture preview route to default HTML requests to mode=review, expose an explicit mode=print override, and include both review and print preview URLs in JSON metadata.
  • Re-validated the render-mode plumbing with npm run types plus live fixture metadata requests for all four Spike 1 fixtures.
  • Tightened the shared template review pass by removing the last stale blue accent values and increasing the screen-only review zoom so fixture pages are easier to inspect without affecting print output.
  • Captured a refreshed review screenshot for insuranceWorkflowAutomationOnePager in apps/platform/tmp/marketing-asset-review/insuranceWorkflowAutomationOnePager-review-current.png.
  • Implemented the first Chromium-backed renderAssetPdf() path behind the existing renderer boundary using Playwright in apps/platform/src/lib/marketingAssetPipeline/render/renderAssetPdf.ts.
  • Updated the fixture preview route so ?format=pdf returns inline PDF output from the server-side renderer.
  • Fixed PDF pagination by scaling the 2550 x 3300 print canvas down to letter-sized CSS pixels during the PDF pass and locking each asset page to a fixed-height print shell.
  • Validated PDF output for all four Spike 1 fixtures and confirmed the page counts now match the typed document models: one-pager (1), two-pager (2), comparison (1), and case study (2).
  • Added a dedicated internal review route at apps/platform/src/app/(main)/marketing-assets/review/page.tsx that lets the team switch fixtures, inspect typed document metadata, open HTML/PDF artifacts directly, and compare review vs print mode side by side.
  • Validated the new review route live in Next for at least the one-pager and two-pager fixtures, including fixture switching and embedded preview loads.
  • Added a lightweight Fixture Review entry point from the existing /marketing-assets header so the internal review surface is discoverable without knowing the route.
  • Added Figma benchmark mapping, per-fixture review checklists, and page-target notes directly into the internal review route so design review can happen against the intended print archetypes instead of raw artifact links alone.
  • Added a display-safe cleanup pass in the handwritten markdown helpers so review/print artifacts stop leaking markdown emphasis, editorial instructions, and placeholder-only lines from the source fixtures.
  • Removed the last hardcoded placeholder values still rendered by the insurance two-pager and workflow one-pager adapters, then re-validated the review HTML to confirm the visible leak strings were gone.
  • Reworked the insurance service two-pager page 2 template from a generic two-column card dump into explicit layout slots: full-width capabilities, a deliberate audience/proof middle row, and a full-width CTA band above the footer.
  • Added page-level footer reservation and a slimmer service-page-2 header treatment in the shared print CSS so contact/footer ownership stays explicit instead of competing with body content.
  • Re-validated the live review page DOM after the layout pass to confirm the new page 2 section spans and footer spacing were actually being applied by the rendered HTML.
  • Tightened the insurance service two-pager page 1 composition by suppressing empty Trusted by sections and replacing the equal-width grid with explicit KPI/process ownership: metrics span four columns and process spans eight.
  • Re-validated the live review artifact after the page 1 refinement and confirmed the empty Trusted by card no longer renders while the KPI/process blocks now occupy the intended widths.
  • Fixed the marketing asset frontmatter array regex so typed adapters can parse YAML list fields reliably instead of silently returning empty arrays.
  • Added deploy-safe bundled fixture loading for the renderer: synced the four Spike 1 markdown sources into apps/platform/content/marketing-assets, added a dedicated sync script, and wired the Platform build/dev steps to ship that content in standalone output.
  • Corrected extractBoldSubsections() so subsection bodies keep newline and markdown marker structure needed by downstream bullet and numbered-step parsers.
  • Tightened the insurance workflow one-pager adapter to consume only each section’s Copy subsection so visual-direction notes stop leaking into publishable body content.
  • Re-ran targeted validation for the current PR fix pass: eslint on touched renderer files, npm run types, and direct adapter smoke tests over the four bundled Spike 1 fixtures.

Current decision

  • Treat this as an active evaluation, not a loose research note.
  • Keep the work anchored to Brainforge’s existing markdown-first content flow and GitHub-backed distribution model.
  • Recommend that Spike 1 live inside apps/platform as a server-only rendering module rather than starting with a separate rendering service.

Current recommendation

  • Start with componentized HTML-template rendering and server-side PDF export.
  • Keep review and approval inside Platform first, with a later Cursor skill acting as a thin invocation layer over the renderer.
  • Only add print-specialized tooling if the baseline cannot meet multi-page quality needs.
  • Judge the spike against current Figma layouts, not only against markdown structure.
  • Treat the first templates as fixed-layout asset families, not one generic flowing print stylesheet.
  • Use handwritten adapters for the first fixtures instead of inventing a general markdown parser too early.
  • Keep comparison tables and case-study metadata explicitly typed during Spike 1 rather than broadening the parser boundary.

Open questions

  • Keep Spike 1 inside apps/platform; revisit service extraction only after implementation feedback.
  • Should output publishing target brainforge-files directly from the renderer, or go through a review step first?
  • Should Brainforge define a stricter section schema before implementing templates?
  • Full apps/platform typecheck is currently blocked by an unrelated import mismatch in scripts/test-github-app-auth.ts, not by the marketing asset pipeline work.

Next steps

  1. Re-run targeted validation on the updated insurance service two-pager, including the current PDF artifact, and decide whether the combined page-1/page-2 composition now clears the first design-review bar.
  2. Run one more print-fidelity pass only if the refreshed artifact still shows weak hierarchy, awkward footer balance, or page density issues.
  3. Keep new fixture support typed and asset-family-specific until the first four shapes have passed design review.
  4. Prepare the renderer work for a scoped PR once the current layout pass is judged good enough to ship as the Spike 1 baseline.

Last updated: 2026-04-16

Graph View

Backlinks