Here is what we shipped in October 2025

feat(magnetron): enhance loading experience with document status updates

• Why: The loading experience for documents lacked user feedback on the current processing status, which could lead to confusion during longer operations. Users benefit from visibility on what the application is currently doing.

• What: Introduced detailed status messages and a visual representation of illustrations being processed. The loader now communicates different stages of document handling, including "Processing Source Files", "Processing Slides", and "Processing Illustrations".

• How:

  • A new state variable documentStatus was added to track the current processing status of the document.
  • Implemented a function getStatusMessage that returns corresponding titles and subtitles based on the document status.
  • Added a nested IllustrationGrid component that displays illustrations being processed when the status is "PROCESSING_ILLUSTRATIONS".
  • Updated the ProcessMagnetronDocumentUseCase to set different processing statuses during the execution of document processing. This includes calls to the new updateStatus method which updates the document's status in the database after certain processing stages.

This comprehensive enhancement provides an improved user experience by clearly indicating document processing stages and showcasing relevant visual elements.

refactor(tts): remove redundant logging in ChirpTTS service

• Why: The previous implementation of the ChirpTTS service included verbose logging for each response and the final result. This information was not essential for the core functionality, leading to unnecessary console noise during execution.

• What: This commit simplifies the logging within the ChirpTTS class by removing logs that output the URL, duration, and hash for each audio chunk as well as for the final result. It preserves the total duration log for the operation, providing a concise overview.

• How: Specific lines were removed from the response logging sections within the forEach and success handling statements. By doing this, we maintain a clean console output while still allowing developers to track the total duration of audio generation.

feat(audio): enhance audio loading and playback management in SceneEditor

• Why: To ensure smoother audio playback experience and better error handling when loading generated audio files in the SceneEditor component.

• What: Added logic to create a new audio element upon successfully generating audio. Included event listeners for managing the loading state, handling playback end events, and catching errors during audio loading.

• How:

  • The audio element is only instantiated if the URL of the generated audio file is available.
  • Implemented event listeners to handle the canplaythrough event for confirming audio readiness and the error event for any audio loading issues.
  • Managed playback state by pausing any currently playing audio before loading the new audio and added cleanup for when playback ends. This ensures that the UI reflects the correct state of the audio player.

feat(text-to-speech): implement text-to-speech functionality in audio editor

• Why: The goal is to enhance the audio editing capabilities within the Magnetron application by integrating a text-to-speech (TTS) feature, allowing users to generate audio from written text. This adds value by making content creation easier and more accessible.

• What:

  • Introduced a new TextToSpeechController to handle TTS requests and responses.
  • Implemented TextToSpeechUseCase to encapsulate the logic for generating audio from text using the specified voice.
  • Enhanced the BrowserApiClient with a method to interact with the TTS API.
  • Updated the SceneEditor component to trigger audio generation when audio files are unavailable or have changed.
  • Added new request and response interfaces (ITextToSpeechRequest and ITextToSpeechResponse) that define the structure for TTS operations.

• How:

  • The SceneEditor now checks if audio needs to be generated based on narration text and voice. If so, it calls the TTS API asynchronously and updates the scene's audio properties upon successful generation.
  • The implementation utilizes the Chirp3TextToSpeechUseCase for the underlying TTS logic, including error handling to ensure proper feedback to users if audio generation fails.
  • The routing infrastructure has been updated in userRouter to direct TTS requests to the new controller, encapsulating the functionality behind a clear API endpoint.

This commit significantly expands the capabilities of the audio editor, enhancing user experience in content creation within the Magnetron application.

fix(contact): change redirect method to hard refresh for LinkedIn requests

• Why: The previous implementation used router.push() for navigating to the next LinkedIn contact. This method may not trigger a full page reload, potentially leading to issues with the updated contact status not reflecting as expected.

• What: Updated the redirect logic to use window.location.href instead of router.push(). This ensures that the application performs a hard refresh when navigating to the next contact, helping to clear the previous state and load the new contact information.

• How: Replaced instances of router.push('/admin/contacts/ready/next/linkedin') with window.location.href = '/admin/contacts/ready/next/linkedin' in the specified file. This change ensures that users are redirected correctly after updating the contact status, which improves overall user experience.

setup domains

cleanup

cleanup

cleanup

feat(magnetron): refactor scene population to separate service

• Why: The previous implementation for populating scenes from slides was tightly coupled within the MagnetronRouter component, making it difficult to maintain and test. It also resulted in code duplication and increased complexity in handling different slide types.

• What: This commit introduces a new ScenePopulationService that centralizes the logic for converting slides into scenes. The MagnetronRouter now relies on this service to handle scene population, simplifying its implementation. Additionally, the ProduceMagnetronDocumentForContactUseCase has been updated to utilize the ScenePopulationService, ensuring scenes are correctly populated when no existing scenes are present.

• How: The ScenePopulationService contains a method populateScenesFromSlides which encapsulates the logic for creating scenes based on slide types. It handles errors gracefully by returning a structured result that indicates success or failure. The MagnetronRouter has been updated to call this method and handle potential errors accordingly. This refactoring improves code readability and supports better unit testing by isolating the scene creation logic from UI components.

feat(render): enhance progress logging in video rendering service

• Why: It is important for users and developers to have clear visibility into the rendering process, especially in production environments. Improved logging will help in tracking the loading of documents and the preparation of scenes, making debugging easier.

• What: Added two new progress log entries that notify when a document is successfully loaded and when the rendering of scenes is about to commence.

• How: Implemented asynchronous logging calls within the MagnetronVideoRenderService to output messages regarding the successful loading of document scenes and the current environment state. These logs will be triggered sequentially after scenes are populated, providing relevant context to users regarding the rendering process.

feat(docker): add service to produce magnetron for contacts

• Why: To enhance the functionality of the magnetron service by enabling the production of magnetron documents specifically tailored for contacts. This addition supports future integrations and improves the data handling capabilities in the application.

• What: Introduced a new service named produce-magnetron-for-contacts in the docker-compose.yml. This service leverages the existing Dockerfile to build an environment configured for production. Additionally, a new script entry "produce-magnetron-for-contacts" was added to package.json to facilitate the execution of the relevant process.

• How: The new Docker service runs the command npm run produce-magnetron-for-contacts within a production environment, using the shared volume magnetron-data to access necessary data files. The service is set to restart unless stopped, ensuring reliability in long-running operations.

feat(contacts): improve rendering and styling in ContactsReady component

• Why: The rendering of contact data needed refinement to improve readability and ensure proper handling of complex video data structures, including checks for null values and object types.

• What:

  • Refined the error handling to ensure that any errors are captured as part of the component state.
  • Improved the display of the contacts header and the messages shown when no contacts are found.
  • Ensured that video data rendering correctly handles nested objects and checks for null values before accessing properties.
  • Added safeguards to gracefully handle potentially invalid video file references.

• How:

  • Utilized typeof checks and null checks on contact.videoData.renderedVideoFile and related fields to prevent runtime errors.
  • Split long text print statements for better readability in the UI.
  • Made minor stylistic adjustments to condense formatting for better visual appeal and consistency.
  • Updated the getServerSideProps function to include clearer console logs for debugging and validation of audio-visual components within the page data.

feat(contacts): highlight contact statuses with background colors

• Why: To improve the user experience by visually distinguishing contacts based on their status. This helps users quickly identify the current state of each contact, enhancing the overall usability of the contacts page.

• What: Added conditional background colors for contact items based on their status. Contacts with statuses indicating progression (e.g., "SELECTED_FOR_MAGNETRON_GENERATION") are highlighted in green, while those with rejection statuses (e.g., "INCORRECT_BLOG") are marked in red.

• How: Implemented logic within the .map function to assign a specific background color class to each contact based on its status. This makes use of template literals to dynamically apply the appropriate classes directly in the JSX markup. The changes enhance the visual layout without altering the underlying contact data structure.

feat(contacts): add magnetron document creation and status management

• Why: To enable management of contacts that require magnetron documents, including the creation, updating, and viewing of related contacts and their status. This is part of enhancing our system's capability to handle document generation workflows.

• What:

  • Added new pages for displaying contacts with magnetron documents and those with blog recommendations.
  • Updated the Contact model to include magnetronDocumentEid and magnetronDocumentVersionEid fields in the database schema.
  • Introduced new use cases for producing magnetron documents for contacts, including request and response interfaces.
  • Modified existing APIs and repositories to accommodate the new document management features.
  • Implemented UI links for easy navigation to new contact statuses and actions based on the document's state.

• How:

  • New components for the frontend allow admin users to view contacts with magnetron documents and those with blog recommendations.
  • Backend logic leverages new use cases, like ProduceMagnetronDocumentForContactUseCase, to manage document creation and processing.
  • Updates to the ContactRepo for saving and retrieving contacts with their latest document status.
  • Adjusted existing methods in the UpdateContactStatusUseCase to handle new statuses related to magnetron document processing.

This commit significantly enhances the functionality surrounding document generation, making it easier for users to process and keep track of their contacts and associated documents.

feat(blog): add service for selecting contacts for blog recommendations

• Why: To enhance the functionality of the Magnetron application by enabling the selection of contacts specifically for blog recommendations. This feature aims to improve user engagement and content personalization.

• What:

  • Created a new service in docker-compose.yml named select-contact-for-blog-recommendation.
  • It includes a build context pointing to the current directory and specifies a command to run the newly added npm script.
  • Added a corresponding npm script to package.json for performing the contact selection task.

• How:

  • The new service in docker-compose.yml is set to use the production environment. It shares a volume with the existing services to ensure data persistence.
  • The npm command for the service invokes the SelectContactForBlogRecommendationUseCase, which is implemented in the application to handle the selection logic efficiently.

feat(api): clean up imports in BrowserApiClient and update dependencies

• Why: The BrowserApiClient.ts file had unnecessary imports which cluttered the code and made maintenance harder. Additionally, dependency versions in package.json were updated to lock their versions for consistency across different environments.

• What:

  • Removed duplicate and unused import statements in BrowserApiClient.ts.
  • Added necessary import statements for IImportApolloCSVRequest, IImportApolloCSVResponse, and ISaveMagnetronDocumentResponse that were missing.
  • Updated the versioning of posthog-js and posthog-node in package.json to specific versions to prevent unintended upgrades.

• How: The cleaning of imports involved manually reviewing the import statements and ensuring only the required ones remained. The package.json changes were made to provide more predictable behavior in builds by specifying exact versions of critically relied-on packages.

trigger build

refactor(importApolloCSV): replace ErrorCodes enum with string literals

• Why: The previous implementation relied on an ErrorCodes enum which made the code dependent on an external structure, complicating error handling and making it less straightforward to identify errors in the application logic.

• What: This commit replaces the ErrorCodes enum with direct string literals for error codes throughout the ImportApolloCSVUseCase. This change simplifies error handling and enhances readability by removing the indirection provided by the enum.

• How: Each instance where an error code was being generated (e.g., ErrorCodes.VALIDATION_ERROR, ErrorCodes.API_ERROR, etc.) has been updated to use the corresponding string literal (e.g., "VALIDATION_ERROR"). This simplifies the process of defining and identifying errors and ensures that error message management remains fluid without requiring additional dependencies.

feat(admin): add CSV import functionality for contacts management

• Why: The need to streamline the process of importing contacts from Apollo.io into our system has been identified. This feature allows users to upload CSV files containing contact data, improving efficiency and data management.

• What:

  • Introduced a new API endpoint for importing CSV files (/contacts/import-csv).
  • Implemented a front-end component for file upload, including validation for CSV file type and user feedback on upload status.
  • Created a controller (ImportApolloCSVController) to handle requests, which utilizes a use case (ImportApolloCSVUseCase) for processing the uploaded CSV files.
  • Implemented logic to either process files from a local path or download files from a remote URL.

• How:

  • The BrowserApiClient was modified to include the importApolloCSV method for handling import requests.
  • The ImportApolloCSVUseCase includes logic for validating input, downloading remote CSV files if necessary, processing the data, and handling errors during the import process.
  • The responsive UI is designed to give real-time feedback on the upload and processing status, ensuring users can easily monitor progress and resolve errors directly.

Overall, this commit enhances the admin interface for contact management, making it more user-friendly and efficient for users engaging with the contact data.

devops

feat(ui): enhance login page with new design and user prompts

• Why: The previous login page lacked visual appeal and effective calls to action, which could lead to a suboptimal user experience. A refreshed design aims to engage users better and encourage account creation for new visitors.

• What: Redesigned the login page to include a welcoming header, a streamlined login form, and additional features displayed to attract user interest. Added a clear call to action for users who do not have an account.

• How:

  • Introduced a flex container for centering the content with a max width and padding for better responsiveness.
  • Added a header section with a welcoming message and some motivational text.
  • Included a bottom section with links to sign up and reminders of key features of the service, enhancing the tendency for new user sign-ups.
  • Utilized Tailwind CSS for styling elements to ensure consistency and responsiveness across devices.

trigger build

feat(runner): remove TestWebCrawlMagnetron runner functionality

• Why: The TestWebCrawlMagnetron runner was deemed unnecessary for the current functionality of the application. Removing it simplifies the code base and reduces potential points of failure.

• What: This commit removes the TestWebCrawlMagnetron runner. The corresponding import statement is deleted from run.ts, and the entire functionality of this runner has been removed, including the related logic for document creation via web crawling.

• How: The implementation details included the removal of imports and definitions that were specific to TestWebCrawlMagnetron. The runner's logic, including web URL handling, user retrieval, and document creation processes, has been deleted to streamline the application and prevent unused code from affecting future maintenance.

feat(magnetron): add web URL input for document creation

• Why: Users need the ability to provide a web URL as a content source when creating magnetron documents. This enhances the flexibility and utility of the document creation feature, allowing users to summarize and create presentations based on web content.

• What:

  • Introduced a new input field for web URLs in the CreateMagnetron component.
  • Updated the logic in the document creation use case to validate and handle the provided web URL alongside existing prompt and file inputs.
  • Implemented fetching and processing of web content when a URL is provided to enhance the document's prompt.
  • Added a new runner, TestWebCrawlMagnetron, to facilitate testing of the web crawling functionality.

• How:

  • Modified the CreateMagnetron component to maintain webUrl and showUrlInput states, and included UI elements to input and manage URL data.
  • Enhanced the CreateMagnetronDocumentUseCase to check if at least one content source (prompt, files, or web URL) is provided. If a URL is submitted, it retrieves web page content and augments the document creation prompt accordingly.
  • Utilized the GetWebPageUseCase to fetch and parse web content, ensuring any fetched text is manageable within token limits. Error handling was added to maintain functionality even if fetching fails.

feat(video-generation): implement Sora2 video generation use case

• Why: To support video generation using the Sora 2 model from OpenAI, we need a new use case that handles the creation and retrieval of video jobs based on user-defined prompts and images.

• What: Introduced the Sora2VideoGenerationUseCase, which defines two interfaces (ISora2VideoGenerationRequest and ISora2VideoGenerationResponse) for input and output. Implemented logic for image downloading, video generation, and uploading to Google Cloud Storage. Added Sora2VideoGeneration and RetrieveSoraVideo runners to facilitate user interaction and job status checking.

• How: The use case leverages axios for API communication and fs/promises for file handling, utilizing FormData for multipart uploads. The video generation process includes downloading the input images, making an API call to OpenAI's Sora 2 endpoint, and handling the job status through polling. Runners have been provided to orchestrate the video generation and retrieval process, offering clear console outputs and error handling.

devops management

cleanup

feat(update): rename instances of HelloSketch to Magnetron

• Why: The project name has been updated from HelloSketch to Magnetron, necessitating changes in various components to maintain consistency across the codebase.

• What:

  • Updated the welcome message in the CreateMagnetron component to reflect the new project name.
  • Adjusted the font weight in the IntroSlideSceneProvider service to improve visual consistency, changing it from 700 to 400.
  • Modified the test text in the ChirpTTS service to incorporate the new project name.

• How:

  • The header in the CreateMagnetron component was amended to replace "HelloSketch" with "Magnetron".
  • Font properties within the IntroSlideSceneProvider were updated to reduce the weight, ensuring text appears appropriately styled.
  • The runTest method in the ChirpTTS class was updated to reflect the new branding in the test output string.

fix(generateChangeLog): update branch reference to main for commits

• Why: The previous branch reference was set to "hellosketch," which may have been outdated or incorrect. This could lead to fetching the wrong set of commits when generating the changelog.

• What: Updated the branch reference from "hellosketch" to "main" in the GenerateChangeLogUseCase.ts file. This change ensures that the application fetches commits from the currently active main branch.

• How: The modification was made in the section of code responsible for defining GitHub repository details. By changing the string value assigned to the branch variable, the code now correctly points to the main branch for fetching commit data.

feat(editor): add drag-and-drop functionality for scene reordering

• Why: Enhancing user experience by allowing users to reorder scenes via drag-and-drop increases the flexibility of the editor. Previously, users could not change the order of scenes intuitively, which could hinder workflow efficiency.

• What: Integrated the react-beautiful-dnd library to implement drag-and-drop functionality in the EditorShell component. Users can now reorder scenes directly within the table of contents, which automatically updates the state and saves changes without manual intervention.

• How:

  • Wrapped the scenes listing in a DragDropContext and utilized Droppable and Draggable components to manage drag-and-drop operations.
  • Implemented a handleDragEnd function to handle the reordering logic, updating the magnetron document's scenes array and saving the updated document automatically after a drag operation.
  • Stylized the draggable components to provide visual feedback during dragging, enhancing usability through visual cues.

This change significantly improves the interactivity of the editor and provides a more dynamic way for users to manage their scenes.

fix(changelog): correct spelling in publish-changelog script

• Why: The existing script name for generating the changelog contained a typo, which could lead to confusion and potential errors when attempting to execute the command.

• What: Updated the key command in the package.json from GenerateChangeLog to GenerateChangelog for consistency.

• How: This change only modified the string in the publish-changelog script section, ensuring that it correctly references the intended function as it is defined in the codebase.

feat(changelog): enhance changelog management and UI updates

• Why: To improve the functionality of the changelog generation process and enhance the user experience by providing a clearer distinction for current and past months in the UI.

• What:

  • Added a new script publish-changelog to automate changelog generation in the build process.
  • Enhanced the changelog page UI to indicate when the displayed entries correspond to the current month.
  • Updated the date range for changelog generation to default to the last 2 days instead of the previous 30 days to give a more relevant and timely view of changes.

• How:

  • Modified the Dockerfile to include the new publish-changelog script execution during the build process.
  • Introduced a helper function isCurrentMonth in [month-year].tsx that checks if the changelog displayed is for the current month, modifying the heading accordingly to improve user clarity.
  • Adjusted the GenerateChangelog.ts script to set the default date range for changelog generation, dynamically calculated to focus on recent changes rather than a broader historical range.

chore(docker): remove unnecessary network configurations from services

• Why: The previous configuration included a dedicated network for the services which was unnecessary as the default bridge network suffices for container communication. This simplification helps streamline the Docker setup.

• What:

  • Removed the networks section for each service in the docker-compose.yml file.
  • Deleted the magnetron-network definition from the networks section since it was no longer being used.

• How: Adjusted the docker-compose.yml file by deleting the relevant lines related to the custom network, ensuring that the services continue to operate under the default Docker networking settings. This change reduces complexity and improves maintainability of the Docker configuration.

feat(sitemap): streamline sitemap generation with changelog integration

• Why: The previous implementation generated a sitemap based on questions and markdown services, which limited the site's visibility for static pages and changelog entries. We needed to enhance the sitemap by including relevant URLs for improved SEO and user accessibility.

• What: This update refactors the GenerateSitemapUseCase to focus on generating a sitemap that includes static pages and changelog URLs. The QuestionRepo and MarkdownService dependencies were removed in favor of the ChangeLogRepo, simplifying the use case's responsibility.

• How:

  • The sitemap generation now starts by adding predefined static URLs.
  • A query to the ChangeLogRepo retrieves unique changelog months, allowing the addition of URLs for both the main changelog page and individual month pages.
  • Error handling was improved to ensure robust execution and logging in case of unexpected issues. The response structure remains intact, returning the generated XML as before.

feat(changelog): improve commits handling and safety checks

• Why: Previously, the code did not robustly handle cases where the commits array might not exist or be of an unexpected type, potentially leading to errors when rendering the changelog.

• What: Introduced a helper function getCommitsArray to ensure safe access to the commits array. This function returns an empty array if the provided commits is not an array, thus preventing runtime errors during display.

• How: The function is used throughout the ChangelogMonth component to safeguard against undefined or non-array commits when calculating lengths and mapping through commits. Additionally, the changes in GetChangelogsByMonthUseCase ensure that the commits are always an array, improving reliability in how changelogs are processed and displayed.

feat(changelog): enhance commit display with improved styling and structure

• Why: To improve the user experience when viewing the changelog by providing better visual separation and clarity for each commit entry.

• What: This update includes adjustments to the spacing between commit entries, the addition of commit index labels, and a visual separator for better organization. The changes make the commit list more readable and visually appealing.

• How:

  • Increased the spacing between the commit entries from space-y-4 to space-y-6 for greater separation.
  • Added a label to each commit entry indicating the index of the commit (e.g., "Commit 1 of X") to help users track their position in the commit list.
  • Implemented a conditional visual separator (a horizontal border) between commits to distinguish them clearly, only shown if the commit is not the last in the list.

feat(changelog): implement automated changelog generation, storage, and display functionality with monthly overview and commit details.

feat(changelog): add automated changelog generation and storage

• Why: To enhance our project’s documentation and tracking of changes, we needed a systematic way to generate changelogs. Manual updates were prone to errors and missed details, so an automated solution is essential for accuracy and efficiency.

• What: Implemented a comprehensive changelog feature that captures commits within a specified date range. This includes:

  • New schema changes to support committing logs in the database.
  • Creation of various service classes and mappers to handle changelog data.
  • Automated creation of JSON files per day with commit details gathered from the GitHub API.

• How: Developed a new GenerateChangeLogUseCase class that:

  • Validates date ranges and fetches commit data from the GitHub repository.
  • Groups commits by date and generates individual files containing the changelog entries.
  • Introduced a new ChangeLog aggregate root and associated mapper and repo for handling database interactions.
  • Ensured that the application flow can easily trigger changelog generation through the GenerateChangelog runner class.

feat(admin): implement FlyWheels management page and database changes

• Why: To provide a user interface for managing Fly Wheels and their configurations, including the ability to view and edit Fly Wheel properties. This change addresses the need for a frontend component to handle Fly Wheel records effectively.

• What:

  • Introduced a new page (pages/admin/fly-wheels.tsx) for displaying Fly Wheels, handling loading states, and displaying error messages.
  • Added two migrations:
    • One to add a slug column to the FlyWheel table.
    • Another to create a ChangeLog table for tracking changes.
  • Modified the FlyWheel model in schema.prisma to include the new slug field.
  • Updated the FlyWheelRepo to replace the findByAdminOrCreate method with findBySlugOrCreate to align with the new data structure.
  • Implemented GetAllFlyWheelsUseCase to retrieve all Fly Wheel records and format them for the frontend.

• How:

  • The Fly Wheels component uses React and Next.js, leveraging server-side rendering to fetch data on page load.
  • The new use case interacts with Prisma to retrieve Fly Wheel data, with error handling to manage possible issues during database queries.
  • Updated the database schema and repository methods to accommodate changes in data structure.

• Risks/Trade-offs:

  • The addition of the slug field may require existing Fly Wheel records to be updated to avoid null constraint violations. Migration scripts were carefully crafted to ensure table integrity.
  • The introduction of the ChangeLog table adds complexity but supports future auditing needs.

• Testing:

  • Verified that the Fly Wheels page loads correctly and displays data as expected.
  • Tested the migration to ensure that the new column was added successfully and did not disrupt existing records.
  • Ensured that the new use case retrieves and formats data correctly, including handling errors and edge cases.

Add FlyWheel aggregate, mapper, and repository implementation.

Add FlyWheel model and corresponding migration SQL script to the Prisma schema.