Projects

GentleShare: SharePoint → OpenWebUI Synchronization Platform

Development of GentleShare, an administration application designed to synchronize SharePoint content with OpenWebUI, as part of an enterprise AI assistant powered by internal documents.

Between April 23 and 28, 2026, the project evolved from an initial Laravel base to an application structured around Laravel, Filament, MySQL, Microsoft Graph, and OpenWebUI. The goal was no longer just to trigger synchronization, but to build a usable platform: folder tracking, file management, asynchronous synchronizations, processing history, visible statuses in the interface, and improved error observability.

Significant work focused on improving the reliability of long-running synchronizations. SharePoint synchronization was moved out of the traditional HTTP cycle and delegated to Laravel jobs, with persisted runs, progress tracking, and an interface capable of clearly indicating the last executed process. This evolution prepares the application for real-world volumes by avoiding issues related to web request timeouts.

On the OpenWebUI side, integration was strengthened with better handling of processing times, functional warnings, and edge cases such as files with no usable content, excluded extensions, already existing files, or zero-size SharePoint files. The application now provides clearer insight into what has been processed, ignored, or rejected, file by file.

The project was also realigned for cleaner Azure deployment: corrected GitHub Actions workflow, clarified application packaging, revised nginx/startup configuration, identified environment variables, and overhauled technical documentation. README, architecture, development, product, and roadmap files were recreated to reflect the project’s actual state.

Summary: GentleStacks now has a consistent application foundation to manage SharePoint–OpenWebUI synchronization, with a more robust architecture, better process traceability, and documentation aligned with real product usage.

Stabilizing the platform before intervention

The day focused on two sensitive production upgrades on an Azure VM: OpenWebUI and n8n. The main value did not come from running the upgrades themselves, but from revalidating the actual runtime architecture before making changes.

On the OpenWebUI side, the work started with a review of the live setup. This helped correct an initial assumption about a local database and confirm a more structured configuration based on Azure Database for PostgreSQL, with a dedicated application database and a separate vector database managed through systemd. That clarification shaped the migration path, including Python prerequisites, service execution mode, and backup preparation.

The n8n upgrade required a similar technical reset. The initial failure was not caused by n8n itself, but by an incompatibility between the target version and the Node.js runtime installed on the VM. The upgrade strategy was therefore reframed into a safer sequence: secure rollback assets first, restore a stable service state, upgrade the runtime, and only then upgrade the application.

Reliable backups and platform-level fixes

Both interventions were handled with explicit rollback in mind. For OpenWebUI, verified PostgreSQL dumps were produced for both databases. A tooling issue surfaced during that step: the PostgreSQL client available on the VM was not compatible with the Azure server version. The workaround was to install a PostgreSQL 18 client so that backups could be generated and checked with confidence before any upgrade.

For n8n, the safety perimeter covered the key operational assets: the systemd unit, override files, npm global installation state, and an archive of the application directory. That preparation made it possible to handle a partially corrupted global npm installation without rushing, including a temporary rollback to a stable version to restore service quickly, followed by a clean retry after fixing a global directory issue (ENOTEMPTY).

Controlled upgrades and operational validation

The OpenWebUI upgrade from 0.8.12 to 0.9.1 was then completed inside the production virtualenv, after resolving an initial failure caused by Python environment write permissions. After restart, checks confirmed a normal service state: application listener up, health endpoints responding, and the expected version successfully deployed.

For n8n, the chosen path led to a system runtime switch from Node 20 to Node 22, followed by the application upgrade to n8n 2.18.0. Final validation covered binary/package/service consistency as well as overall service continuity on the VM, including OpenWebUI and Caddy.

Beyond the installed versions, the day primarily strengthened the platform’s operational reliability: verified backups, recovered disk headroom, updated architecture documentation, and a clearer rollback path for future production changes.

Marketing reporting: simpler instrumentation, better fit with the existing stack

The day focused on making marketing reporting in Nova more reliable, with two concrete goals: improving visibility on notification delivery and fixing a business logic mismatch in coupon campaign analytics. A new KPI was added to the Marketing dashboard to track, day by day, the ratio between sent notifications and notifications actually received, based on records stored in individual_notifications.

The implementation choice was intentionally pragmatic: a native Nova Trend metric was used instead of building a custom frontend card. This keeps the dashboard aligned with existing project patterns, avoids unnecessary technical overhead, and removes the need for an extra JavaScript dependency for a fairly contained reporting need.

Business-level review of coupon campaign analytics

The most significant part of the work was the review of the “coupon analysis by campaign” card. The investigation showed that the existing calculation model did not match how ExpirationReminder campaigns actually work. The screen was computing figures from coupons created by the campaign, while this campaign type does not create new coupons at all; it sends reminder notifications about already existing ones. The zero values observed were therefore not just a data issue, but the result of an unsuitable business assumption in the reporting logic.

The fix was implemented as a targeted adjustment in the related API route: filter notifications effectively sent during the selected period, extract the referenced coupon_id values, then compute business indicators on the coupons truly impacted by the campaign. The historical logic was kept unchanged for other campaign types, which limits the functional surface of the change and helps avoid regressions outside the expiration reminder scope.

End-to-end validation on real data and production hardening

The updated behavior was then checked end to end after importing the production database locally, with a specific review of the “5-day coupon expiration reminder” campaign. This validation confirmed that backend endpoints were now returning consistent, non-zero figures for sent notifications, targeted coupons, opened, expired, and used coupons, making it possible to isolate the remaining issue on the Nova display/integration side.

The last step was a production-side fix: correcting a class resolution error caused by an incorrect namespace on the new Nova metric. The Marketing dashboard now loads safely in the target environment, closing the loop between business clarification, backend correction, and more dependable marketing instrumentation.

Structuring the We miss you use case

The day was mainly focused on cleaning up how mobile notifications are managed in Nova. The goal was not to add another campaign type, but to properly frame it: a form reduced to only the fields truly useful for mobile notifications, dates hidden in the interface and secured by default in the model with a permanent range. This choice simplifies administration without leaving any gray areas about the actual behavior of the campaign.

At the same time, a business rule was added to prevent multiple campaigns from coexisting. The key point is that this control was implemented at the application validation level, rather than relying solely on the Nova interface. This ensures consistent behavior even if creation is handled through another entry point in the future.

Explicit linking of notifications to campaigns

The main decision of the day concerned the data model. Linking a notification to its campaign now relies on a real campaign_id column in individual_notifications, rather than a simple piece of information embedded in the payload. The migration was created and applied, then the link was integrated into the main generation flows.

This choice makes Eloquent relationships more reliable, simplifies Nova filtering, and enables cleaner tracking of notifications by actual campaign. It also allows a gradual move away from technical codes that were historically useful but become less robust when analysis or evolution of the system is needed.

Reporting improvements

Finally, the Nova statistics card was refined in a targeted way: fixing date filter initialization, improving usability, harmonizing labels, and adapting the backend calculation to group first by campaign_id when present, with a fallback to campaign_code for historical data. The Nova notification filter was aligned with this same logic, displaying campaign names instead of codes. Overall, this improves both business readability and tracking reliability.

Fixing breakpoints in loyalty campaign flows

The main focus of the day was to straighten several sensitive marketing and loyalty flows around campaigns and coupon issuance. Work started with a full reconstruction of the “We miss you” campaign path, from Nova to coupon generation, export, and point-of-sale usage. This review exposed a structural gap between the historical flow and the current implementation: batch generation was bypassing Eloquent events, which silently prevented the related notifications from being triggered.

The fix was applied as close as possible to the actual breakpoint, inside the generation service, by explicitly creating individual notifications for coupons produced in batch. This restores consistent behavior without disrupting the existing queueing model or the OneSignal delivery pipeline.

In the same area, a drift in couponnumber formatting was corrected: UUIDs were being generated instead of the expected business format. The service was brought back in line with the standard numbering logic, and duplicate protection was added for batch processing. A production recovery path was also prepared through a dedicated Artisan command, with date filtering and a safe dry-run mode, so already-issued invalid coupons can be corrected in a controlled way.

Making marketing notifications easier to operate

A second track focused on improving visibility of notification activity in the back office. Native Nova metrics were not well suited to the reporting need, especially with time-based filtering, so the solution was to build a dedicated custom Nova card for individual notification statistics. The interface was consolidated into a single summary table, with campaigns as rows and statuses as columns, making operational reading much clearer than a set of separate widgets. The component was packaged locally, aligned with existing dashboard conventions, and validated through front-end build integration.

Repositioning a business trigger in the signup journey

The welcome coupon trigger was also moved within the registration flow. Coupon creation no longer happens at initial signup, but only after the email address has been effectively validated, on the first successful verification. This change better aligns the business trigger with a completed user action and clarifies the distinction between coupon creation and welcome email delivery. Test coverage was updated accordingly to secure the new behavior.

In parallel, the analysis of pre-expiration reminders isolated a likely cause behind notifications still being sent while a campaign appeared inactive: campaign status is correctly checked when jobs are queued, but not revalidated at send time. The issue is now clearly framed for a later targeted fix.

Azure scheduled execution: correction and clarification

The day focused on a concrete operational reliability issue: a reminder campaign was not being triggered in production. The analysis made it possible to reconstruct the full execution chain for scheduled campaigns, validate the expected trigger times, and isolate a configuration flaw in how the Laravel scheduler was being used within Azure WebJobs.

The setup was then realigned with Azure’s execution model:

• scheduler script corrected for proper Triggered / Scheduled execution;
• addition of a settings.job file to make scheduling explicit;
• preparation of a clean schedulerjob.zip deployment package for Azure App Service;
• hardening of operational scripts.

Beyond the fix itself, an architecture decision was validated between:

• a dedicated scheduled WebJob for the Laravel scheduler;
• a separate continuous WebJob for queue processing.

This separation improves operational clarity and removes ambiguity between time-based orchestration and continuous background processing.

Removing ambiguity from Azure scheduling behavior

A cross-check was carried out between Microsoft documentation and the actual behavior of the Azure portal in order to secure the CRON expression format truly accepted by the WebJobs interface. The retained configuration is therefore based on what the platform effectively validates, not on documentation alone.

OneSignal notifications: application control aligned with real behavior

In parallel, the push notification flow was refined to address a common API blind spot: a user may exist in OneSignal through an External ID while having no active push subscription.

The flow now includes an explicit pre-check before live sending, making it possible to distinguish between:

• user not found;
• no push subscription attached;
• push disabled.

This replaces an overly generic error path and aligns application behavior with what was actually observed on both the mobile side and within OneSignal. In continuity with the month’s work on maintaining and evolving custom Laravel business applications, the main outcome of the day is stronger operational predictability: triggering more reliably, separating responsibilities more clearly, and qualifying notification failures before they become functional incidents.

Nova back-office stabilization

The day focused on a clear objective: improving business usability in the back-office while addressing a real production weakness observed on Nova. In continuity with this month’s work on the Laravel/Nova web and mobile loyalty application, the effort combined functional enhancement, incident diagnosis, and structural remediation of a sensitive architectural point.

Business-oriented filters ready for operations

On the individual notifications resource, directly usable operational filters were added:

• a status filter focused on the key execution states Sent / Failed;
• a date-range filter on Sent at, structured with separate start and end boundaries.

The implementation deliberately relied on Nova’s native date filters rather than a custom component, favoring maintainability, compatibility, and more predictable behavior in the admin interface.

Root cause diagnosis in production

The incident analysis quickly ruled out the notifications resource and isolated the actual source of the dashboard failure: an Analytics dashboard endpoint triggered with parameter 3. The blocking issue came from an unresolved global function (getZoneBillingStats) used inside a serialized closure context, with an additional attention point regarding Nova v5 filter method signatures and expected type contracts.

This made it possible to clearly define the real incident scope and avoid applying a superficial fix to the wrong component.

Structural correction instead of a workaround

The fix consisted in removing business logic from Analytics routes and moving it into a dedicated application service: ZoneBillingService. Nova routes now resolve the service explicitly through Laravel’s container, reducing dependence on route loading behavior and making execution safer in cached / serialized production contexts.

The SQL query was also strengthened through explicit column qualification to prevent ambiguity and column resolution errors.

Validation and production readiness

Modified files were syntax-checked (php -l), and the production rollout sequence was prepared explicitly: application cache clearing, route cache rebuild if enabled, then targeted retesting of the Analytics endpoint.

Beyond the day’s fix, this work extends the broader yearly trajectory of maintaining and evolving business applications with the same guiding principle: making Laravel/Nova components clearer, more robust, and safer to operate in production.

Securing the authentication flow

The day was dedicated to targeted hardening of a Laravel / Nova loyalty application, with a clear objective: block functional access until the email identity is confirmed, without degrading the continuity of the user journey.

The changes affect the user model, registration and verification controllers, as well as the protection of sensitive routes via auth + verified. This work goes beyond a simple interface tweak: it realigns the sequence registration → verification → application access by removing implicit workarounds and inconsistent redirects.

The verification view was also revised in French, integrated into the main layout, and made more explicit about available actions, notably resending the message. The verification email was also customized via a dedicated template to align both content and presentation.

Coupon notifications: clarified business logic

A second focus was to refine the logic for selecting notification templates for coupons. Coupons linked to an invoice — or belonging to the Classic / Threshold types — now explicitly switch to the NewCouponNotification campaign, while other cases can continue using the coupon’s source campaign.

This adjustment improves the readability of the business rule and reduces ambiguity in notification delivery. In parallel, first name injection was standardized to Title Case with a fallback to Client, ensuring more reliable rendering of placeholders in the actual messages sent.

Back-office control and API interoperability

On the Nova side, the notification title, content, and link fields have been made configurable for NewCouponNotification, with a reminder of available placeholders ({{prenom}}, {{nom}}, {{montant_bon}}, {{date_expiration}}). The goal is less about adding fields and more about restoring proper editorial control to the back-office over a now central scenario.

Finally, endpoints now explicitly return text/plain; charset=ISO-8859-1. This subtle but important detail ensures interoperability with consuming systems and avoids display or interpretation discrepancies on the integration side.

As part of the month’s continuity, this work extends an ongoing effort in evolutionary maintenance focused on application robustness, functional consistency, and integration quality on a custom business foundation.

Nova campaigns: practical structuring, not just UI polish

The day focused on making notification campaign setup more reliable in a Laravel / Nova loyalty application, with changes driven by real back-office usage. The interface was reworked to display business fields conditionally depending on the campaign type — welcome, expiration reminder, loyalty birthday — so that configuration stays aligned with the actual operational intent and data entry errors are reduced.

Field labels were also harmonized, and notification-related inputs were moved ahead of date fields. This improves form readability and helps prevent inconsistent setup during campaign configuration.

Notification data made manageable at campaign level

The campaigns model was extended with notification_title, notification_content, and notification_link through a migration executed and validated in the application environment. These fields are now exposed in Nova only for relevant campaign types.

This is a meaningful step: notification content is no longer handled as implicit or peripheral logic, but as governed business data attached to each campaign. It improves maintainability and prepares cleaner functional evolution of the loyalty / CRM scope, in line with the month’s broader work on custom business applications.

OneSignal rule formalization and XLProg encoding fix

A documentation-based diagnostic was carried out on OneSignal constraints and translated into concrete application rules: Laravel/Nova validation boundaries for title, content, and link, plus placeholder examples added directly in input helpers to standardize authoring.

In parallel, a character encoding issue was isolated on the XLProg API integration. The fix was implemented without breaking the existing legacy client contract: keeping the current output pattern (echo / exit), converting UTF-8 output to ISO-8859-1, and deliberately avoiding any new HTTP header that could introduce regression risks. This decision favors integration stability and fits within the broader yearly trajectory of maintaining and evolving interconnected business applications.

Diagnosis and hardening of loyalty processes

The day focused on a sensitive area of a customer loyalty application built with PHP / Laravel / Nova, with a twofold objective: identify the root cause of account-linking anomalies and secure reminder workflows tied to expiration campaigns.

Production log analysis made it possible to trace the observed anomalies back to a specific business scenario: sales recorded without an attached loyalty account, later leading to inconsistencies in account association. This was not just a basic application review; the work aimed to isolate a real production case, establish its cause with confidence, and prepare a more reliable corrective or process-level response.

In parallel, the configuration of scheduled tasks used for pre-expiration reminder campaigns was reviewed and validated. Manual trigger procedures were also introduced to support more controlled end-to-end testing, without relying solely on automated execution windows. This strengthens the ability to validate functional chains under near-real conditions.

Targeted improvements to the Nova admin interface

On the back-office side, the work also improved the operational readability of individual notifications:

• implementation of a custom filter based on campaign code, enabling direct segmentation in the administration interface;
• enhancement of the admin view with target device identification (Android / iOS).

This second enhancement was implemented by dynamically parsing OneSignal JSON payloads, extracting the relevant business information without changing the existing database schema. The trade-off is important: adding useful operational visibility while preserving the current application structure.

As part of this month’s broader work on Laravel / Nova business applications, this sequence reflects a pragmatic consolidation effort: starting from observed incidents, hardening scheduled workflows, and enriching the back-office with information that is immediately actionable for business teams.

The day focused on implementing the new loyalty birthday voucher campaign, covering the entire chain: business scoping, back-office configuration, application logic, execution automation, and local validation testing.

The business rules were consolidated to make the system usable without functional ambiguity:

• reference date based on account creation;
• 7-day catch-up window to absorb any automation incident;
• explicit handling of February 29th mapped to February 28th in non-leap years;
• eligibility limited to accounts created more than one year ago;
• anti-duplication mechanism to prevent resending an already processed voucher;

Application Integration and Automation

At the product level, a new campaign type "Loyalty Birthday Voucher" was added in the back-office with its dedicated amount and duration parameters. The automatic voucher generation logic was then connected to the existing system, reusing the "new voucher" notification flow rather than creating a parallel one.

Execution was industrialized via a dedicated Artisan command, integrated into the Laravel scheduler. Push notification management was also reinforced with three distinct operating modes: actual sending, simple OneSignal check, or complete deactivation. The cautious mode was selected by default to secure the rollout phase.

This work is part of the ongoing developments carried out this month on the loyalty application: beyond a one-off feature, it strengthens a Laravel/Nova foundation oriented toward manageable campaigns, reliable automation, and controlled operations.

Framing the new campaign type

The day focused on a structuring evolution of the loyalty application: introducing a New voucher notification campaign type designed not as a coupon creation mechanism, but as a business authorization layer for push delivery when a voucher is created. This decision moved the feature away from a historically ad hoc welcome-specific handling toward a more generic model aligned with the actual coupon lifecycle.

Centralized triggering and deduplication

Notification triggering was moved to the right place in the technical flow, directly into the coupon creation lifecycle through a model hook. The goal was to eliminate scattered calls across generation flows, a common source of omissions and inconsistent behavior. At the same time, technical identifiers were aligned through consistent campaign_code and event_key usage, and expiration reminder deduplication was revised to rely only on the voucher identifier. This improves trigger readability, functional reliability, and delivery predictability.

Nova upgrade and reduced maintenance risk

The Nova back office was updated accordingly:

• full integration of the new type into the campaign administration form;
• dedicated explanatory content;
• aligned input and display rules;
• corrected dynamic hiding of irrelevant fields for Welcome, Expiration reminder, and New voucher notification campaign types.

Beyond the visible UI fix, the key point was the refactoring of visibility and validation logic. Repeated type lists and duplicated rules across hide, dependsOn, showOnCreating, and showOnUpdating were removed in favor of centralized constants and helpers. The result is a clearer back office, less brittle maintenance, and a safer foundation for future campaign types.

In continuity with this month’s Laravel / Nova custom application evolution work, this intervention strengthens both business execution quality and long-term application maintainability.

Controlled production-grade scheduling

Significant work was completed on automating loyalty coupon expiration reminders, with an architectural choice deliberately aligned with the application’s standard operating model: centralized execution through the Laravel scheduler, configurable timing, and targeting of coupons expiring within a date range consistent with each campaign’s lead time. The goal was not just to run reminders, but to make the trigger mechanism readable, maintainable, and fully aligned with day-to-day application operations.

Hardening the notification pipeline

The main contribution of the day was the end-to-end reliability of the notification lifecycle:

• systematic recording of processing dates, including failed sends;
• addition of a scheduled date at creation time to improve operational traceability;
• duplicate prevention through a dedicated event key;
• validation of behavior when the process is re-run.

This consolidation strengthens the overall robustness of the feature within a broader stream of continuous application evolution on a Laravel / Nova stack connected to third-party systems.

Non-destructive validation in development

A sensitive point was addressed around validating push notifications without sending real pushes. A technical verification mode was introduced in development environments to check the presence of the external_id and the status of OneSignal subscriptions, with explicit distinction between three cases: missing identifier, no push subscription, and push disabled.

This made it possible to perform end-to-end validation on real notification datasets while avoiding uncontrolled or intrusive delivery. It is a concrete improvement in both test safety and operational control.

Stronger business safeguards and admin UX

Additional corrections helped stabilize the administration layer:

• cleanup of date rendering in Nova to remove irrelevant timezone information;
• removal of a duplicated column;
• addition of a blocking validation rule preventing overlap between campaigns of the same type over the same period;
• correction of the technical method signature behind that validation to preserve compatibility with the admin framework.

Beyond a one-off fix, the day contributes to a broader pattern of disciplined application maintenance: industrializing without adding unnecessary complexity, increasing reliability without diverging from framework standards, and reinforcing controls where they have direct business impact.

Controlled functional extension

Targeted evolution of the loyalty application to introduce a new Welcome campaign type, with its dedicated parameters and associated migration. The work was not limited to the data model: the Nova administration was reworked to make this new case truly usable in production, with clearer field ordering, conditional displays by type, and contextual help aligned with business usage. Validation included checking migration states and ensuring no regression on the modified Nova resources.

Automation separate from the existing flow

An architectural decision was made to handle the welcome voucher with a dedicated logic, rather than overloading the existing flow. This separation keeps behavior more readable and controllable in a business application already integrated with its ecosystem. Concretely:

• detection of an active Welcome campaign;
• automatic coupon creation when a loyalty account is opened;
• population of business parameters from the current campaign;
• anti-duplication safeguard to prevent multiple issuances.

This choice aligns with the functional evolutions carried out this month on Laravel / Nova applications: favoring clean, testable, and maintainable extensions over an accumulation of special cases in existing pipelines.

Securing the notification pipeline

The day also closed the loop on the mobile side with the addition of an individual OneSignal notification triggered after voucher creation, scheduled with a deep link to the customer's vouchers area. Beyond the integration, the key point was diagnosing the execution chain: validating the scheduler, identifying the queue driver actually in use (database), then launching a worker to clear and process pending jobs.

To secure functional testing, a temporary routing of the Welcome notification to a fixed OneSignal External ID was put in place. This approach made it possible to test the full chain deterministically, from the business event to mobile delivery. Overall, this represents a concrete evolution of the application: more than a new campaign, a welcome mechanism that is now coherent, manageable, and verified end-to-end.

Structuring a push flow separate from legacy

As a continuation of the developments carried out this month on the web and mobile customer loyalty application, the day focused on setting up an individual notifications foundation separated from the existing global system. The main decision was to preserve the legacy system while opening a new, more finely controlled relational flow.

• creation of a dedicated individual_notifications table
• definition of the associated model with sending statuses, provider traceability, scheduling, and queue support
• schema validation and local execution of the migration
• structuring to handle JSON data and business timestamps

Operational back-office control

The work was not limited to the technical model: it also focused on enabling operational use within the Laravel Nova back office.

• creation of a Nova resource dedicated to individual notifications
• integration of sending history within the user profile
• targeted exposure of operational fields, with a clear separation between business input and read-only technical data
• clarification of navigation to clearly distinguish between global notifications and individual notifications

Securing the OneSignal sending lifecycle

A significant part of the day addressed the actual reliability of the sending protocol. The service was extended to target a user via their loyalty identifier and to manage the full lifecycle (pending, queued, sent, failed, skipped).

The diagnosis of a false positive send — a OneSignal response without a usable identifier but incorrectly interpreted as a success — led to correcting the marking logic to prevent any erroneous sent status. Final validation confirmed a successful send with a usable provider response.

Transition to asynchronous processing and duplicate-free rescheduling

The pipeline was then strengthened by moving to controlled asynchronous processing: dedicated job, Nova action for queueing, command to enqueue scheduled notifications, and execution via a Laravel worker. A fix was applied to ensure the scheduled date is respected, preventing unintended immediate dispatches.

Finally, a clean rescheduling mechanism was implemented: when the send date changes, the pending job is deleted and recreated, securing the flow against accumulation and duplicates. This type of decision fits into an annual dynamic of maintaining and evolving business applications with increasing requirements for execution robustness.

Application stabilization and flow diagnostics

The day focused on bringing a Laravel-based customer satisfaction survey application back under control, with a dual objective: better understand unexpected behaviors in the response journey and secure the delivery pipeline that supports operations.

On the application side, the work involved diagnosing points where the questionnaire response flow could diverge from expected behavior. This review went beyond functional observation: it helped identify sensitive areas in the web/backend flow in order to prepare safer fixes within a Laravel architecture combining web rendering, API, and Nova administration.

Regaining control of the GitHub Actions / Azure pipeline

The main focus of the day, however, was the reliability of build and deployment:

• review of the GitHub/Azure pipeline to eliminate several concrete causes of instability;
• correction of the main workflow to use up-to-date actions and a PHP version compatible with the project;
• addition of Nova credentials handling in CI to prevent failures when retrieving private dependencies;
• explicit locking of Laravel Nova to the target version, with validation of the local state to ensure alignment between development and automation;
• strengthening of Azure deployment against 409 publishing conflicts, through additional safeguards on the Kudu lock and concurrent execution;
• cleanup of the .gitignore strategy to better manage local Nova components;
• verification of composer.lock, confirming that it must remain versioned in this context to preserve reproducibility.

Scope of the work

Beyond targeted fixes, this intervention is part of a broader continuity of maintenance and evolution of business applications: realigning the delivery foundation with the project's actual dependencies, reducing sources of drift between local, CI, and production environments, and restoring a sufficient level of predictability to resume functional fixes on a clean basis.

The result of the day is modest but structuring: a more robust pipeline, better-controlled versioning, secured Nova dependencies, and the main build/deploy blockers addressed.

Targeted upgrade of a production business application

Consolidation work on a Laravel / Nova application already in production, in continuity with the work carried out this year on more robust, governable, and sustainable technical foundations. The goal was not to “update for the sake of updating,” but to restore an acceptable level of confidence on a genuinely exposed scope: security, runtime stability, and system maintainability.

Practical security and debt reduction

The work focused on upgrading the technical stack, reviewing dependencies, and cleaning up the frontend build chain to eliminate the most critical weaknesses.

• validation of a production state with no detected vulnerabilities on runtime dependencies;
• isolation of residual alerts on development tooling, with no direct exposure in production;
• modernization of the frontend stack toward a more sustainable and readable setup;
• reduction of accumulated technical debt around scripts, tools, and peripheral components.

Fixing regressions and improving business reliability

The upgrade also required addressing post-upgrade regressions, with a focus on sensitive processes, particularly document generation. The intervention aimed to restore reliable behavior in the most critical business functions, rather than stacking ad hoc fixes.

At the same time, the Nova administration interface was streamlined to regain operational consistency:

• clearer navigation;
• interface better aligned with actual usage;
• improved localization quality and overall readability.

Maintenance handled as a consolidation effort

This workday extends the yearly thread of maintenance, support, and evolution of client business applications, with the same approach applied to more structural projects: start from reality, diagnose breaking points, decide what needs modernization, then stabilize the existing system without overpromising.

The result is a cleaner, more reliable application, better prepared for future evolution, with a technical foundation that is once again fit for use under good conditions.

Focus of the day

The day was dedicated to defining a practical strategy for summarizing very long texts and conversations in a way that can be used inside an enterprise AI and document-assistance stack. The work went beyond model comparison: it focused on shaping a realistic, cost-aware approach compatible with durable memory management.

Model selection by role

A first round of decisions clarified which models fit which purpose:

• For high-quality synthesis on very large inputs:
  • Gemini 2.5 Pro for its large context window
  • GPT-5.2 Thinking / GPT-5.4 for faithful, well-structured synthesis
  • Claude Opus 4.6 for readability and nuance
• For low-cost extraction workflows:
  • Gemini 2.5 Flash-Lite as the leanest option
  • Gemini 2.5 Flash as a cost/performance compromise
  • DeepSeek V3.x and Qwen 2.5 72B as credible alternatives for structured chunk-based extraction

Architectural decision

The key decision of the day was to avoid a single monolithic summary pass and instead adopt a staged pipeline:

1. chunking,
2. structured extraction per chunk,
3. merge and deduplication,
4. final consolidation.

Prompting was reframed accordingly: ask the model for key-idea extraction rather than narrative summarization. The target output includes categories such as main ideas, decisions, constraints, key facts, action items, and open questions, using strict JSON output.

Cost control and useful memory

A second major track focused on limiting the cost of continuous memory extraction:

• do not summarize every exchange by default;
• filter messages first and retain only durable information;
• prioritize user messages over every assistant response;
• trigger memory extraction only on significant events;
• separate raw recent context, compact durable memory, and full archives accessible through RAG.

The target pipeline therefore becomes: local rules → candidate fragments → deduplication → minimal LLM call → atomic storage.

Broader continuity

This work directly extends the monthly effort around OpenWebUI and the sovereign document stack: the goal is no longer only to have an interface or a RAG layer, but to make the extraction, capitalization, and reuse of useful conversational knowledge reliable. At the yearly scale, it strengthens the build-out of a sovereign enterprise AI foundation able to turn raw exchanges into reusable knowledge without uncontrolled cost growth or loss of architectural control.

Making OpenWebUI data operational

Today’s work focused on bringing OpenWebUI’s internal data under control to better operate a self-hosted document AI stack. A first stream of work clarified the JSON structure stored in chat and produced SQL queries that are actually usable to:

• extract messages from chat->'messages'
• rebuild question/answer pairs
• generate full conversation transcripts
• add transcript length, byte size, and last-24h filtering

Several technical details were also hardened: using json_array_elements(...) because the column is json rather than jsonb, converting Unix timestamps with to_timestamp(...) for chat_message.updated_at, and rendering JSON content cleanly with content #>> '{}'.

Consistency checks across files, chunks, and knowledge

A second major topic was the detection of inconsistencies across document_chunk, file, and knowledge. The analysis made it possible to clearly separate:

• files attached to a knowledge base through meta.data.knowledge_id
• technical standalone collections named file-<uuid>
• potentially orphaned or incomplete records

In a multi-database setup, the practical decision was to compare datasets in n8n instead of forcing local SQL joins. The resulting checks strongly suggest there are no orphans for the specific criterion document_chunk.vmetadata->>'file_id' vs file.id, shifting the investigation toward other causes such as incomplete metadata, chunks without file_id, or broader application-level inconsistencies.

n8n orchestration and OpenWebUI memory hardening

The orchestration layer was also improved through n8n: SQL-side aggregation before comparison, consolidation of rows into a single JSON payload, generation of a clean results_text field for prompts, parsing LLM JSON outputs, and branch synchronization with Merge in Combine mode.

At the same time, OpenWebUI memory behavior was clarified, especially the distinction between Memory, Notes, and Knowledge. Reviewing the Auto Memory function exposed several structural issues, leading to a clear conclusion: the concept is relevant, but the code as reviewed is not reliable enough for production without fixes and proper log-based instrumentation.

As part of the monthly effort to optimize OpenWebUI and consolidate a sovereign enterprise document AI stack, today’s work strengthens the annual trajectory: turning OpenWebUI into a controlled front-end backed by verifiable data, traceable workflows, and a governable document architecture.

Design and structuring of a publication platform dedicated to a multilingual technical timeline, with a data model able to support dated cards, editorial content, and bilingual categorization. Today's work focused on the architecture of daily, monthly, and yearly levels of reading, in order to achieve a coherent rendering both in detail and summary. Implementation was based on an Azure PostgreSQL database structured to clearly separate content, temporal groupings, and the tag repository. The schema included consistency checks on dates, identifiers suited for editorial use, and automatic timestamp management to ensure reliable updates. A French / English tag repository was also standardized to harmonize content qualification and prepare for clean use on the interface side. This work fits into the month’s dynamic to turn technical achievements into publishable content, and continues the annual trajectory of structuring a controlled, sustainable, and valuable stack as part of a professional product approach.

Work continued on SharePoint document retrieval, with a more user-oriented approach. The focus was no longer just on synchronization, but also on simplifying access to content and enabling its use in workflows. Research on packages, connectors, and recovery strategies built upon the previously laid foundations. The subject remains central for feeding an exploitable knowledge base. This continuity confirms the strategic importance of Microsoft 365 in the architecture.

In March, efforts shifted towards stabilizing and coherently assembling the components already explored. The focus was on the practical use of OpenWebUI, PostgreSQL, embeddings, and document processing. The objective was no longer just to compare, but to ensure that everything fits together within a reliable framework. This includes the performance, functional coherence, and limitations of the chosen components. The month was dedicated to an active consolidation phase.

March also shows a stronger willingness to transform completed work into publishable content. The reflection on a timeline, a technical portfolio, and the storytelling of achievements becomes more visible. The goal is to present topics in the form of accomplishments, decisions, tests, and concrete integrations. The technical aspects here begin to be reworked as assets for professional communication.

This month saw the emergence of several practical topics around OpenWebUI: response quality, system prompt, analytics, branding, and integration. Efforts focused on improving the tool’s actual behavior in professional production settings. This points to a gradual shift toward issues of user experience, management, and perceived value. The tool is no longer viewed solely as a technical component, but also as a product usable in a professional enterprise context.

Strengthening the link between architectural choices and a clear, business-oriented offer. The focus covers controlled hosting, confidentiality, document-based AI, and the business value of the assistants developed. Technical elements are gradually tied to a clearer service proposition. This is no longer just technical experimentation, but the transformation into a credible, professional business offering. This gives the month of March a more product-oriented and strategic dimension.

The month was also marked by more technical operational topics related to Azure, PostgreSQL, and the deployment environment. Efforts focused on the database, extensions, migrations, reverse proxy, and relevant managed services. Cost, simplicity, and robustness trade-offs were central concerns. The objective was to make the ecosystem more stable and more consistent with the intended uses. This consolidation supported professional AI and documentary experiments.

The experiments encountered very concrete constraints related to CPU, memory, and processing time. The work consisted in testing what could actually run on the Windows Server 2025 VM in terms of embeddings, local models, and overall load. Options that were too heavy were reconsidered in light of observed performance. Self-hosted viability became as important a criterion as theoretical quality. This led to more realistic and usable choices, notably migrating to a Linux Ubuntu VM hosted on Azure, which manages resources (CPU, RAM, and disks) more efficiently.

Instead of evaluating OpenWebUI in the abstract, the work focused on its real-world behaviors in a professional production context. Topics addressed include collection management, file addition, use of external parsers, and integration with RAG services. Functional limitations were more clearly identified. This made it possible to distinguish what should remain inside the tool and what should be moved outside. The role of OpenWebUI was refined as an interface layer rather than a complete solution.

The month marked a transition between the target architecture and concrete implementation. The work focused on how to connect an external retrieval, manage the index, and ensure the actual reliability of the system's behavior. Issues around deletion, updating, index reconstruction, and result consistency became more prominent. The challenge was to move beyond a simple prototype towards a usable workflow. This phase reinforced the operational dimension of the company's document management project.

Exploration of an architecture where indexing and retrieval are managed outside the chat interface. The work focused on the benefits of finer control over documents, vectors, and content lifecycle. This paved the way for advanced features such as reranking or hybrid search logics. The approach also allowed for a clearer separation of responsibilities between the interface, search engine, and ingestion pipeline. This orientation clarified the overall structure of the enterprise AI system.

Assessment of trade-offs between indexing quality, CPU cost, vector size, and feasibility on virtual machines. Several approaches were compared for document extraction and embeddings, with particular attention to stability. The topic was not only theoretical: it was necessary to identify what could actually be supported in the environment. This phase allowed us to rule out some overly resource-intensive options. It also prepared the ground for more pragmatic decisions in upcoming developments.

The work included synchronization logic, change tracking, and the preparation of a continuous feed for the document engine. Delta queries and library management were at the core of the considerations. The aim was to build a robust flow between Microsoft 365 and the knowledge base. This project is part of a professional, industrialized approach to document orchestration.

Consolidation of n8n as an automation layer to manage document flows and service calls. The work focused on structuring sub-workflows, managing configuration flows, and composing technical JSON objects. The approach aimed to make processes reusable and readable. This made it possible to prepare for the progressive industrialization of pipelines. n8n has begun to play a central role in assembling the building blocks.

Definition of a documentary foundation capable of ingesting, indexing, and delivering company content in an actionable way. The work covered the complete pipeline: extraction, splitting, embeddings, vector indexing, and retrieval. Several options were compared to maintain strong technical control without complicating operations. The objective was to establish a clear, modular, and sustainable architecture. This phase served as a basis for the decisions made in the following weeks.

Exploration of the exact role of OpenWebUI within a broader document architecture. The topic is not only the interface, but also the boundary between what should remain native and what should be externalized. The analysis focused on collections, embeddings, parsers, and the overall behavior of the system. The challenge is to avoid being limited by the tool in more ambitious use cases. This work has prepared a more decoupled approach between UI, indexing, and search.