YapHub

Appearance

Weekly report ​

Student:@student.ucll.be
Study: Professional BachelorMajor: ICT
Company: YappaCity: Bilzen

Activities Week 08 (30/03/2026 - 03/04/2026) ​

Monday (Day 36) ​

Today, I received feedback on the foundation PR which Davy had started reviewing. The initial feedback noted that the PR's scope was still too large and that the MVP contained too much functionality, making it difficult to review the code within a reasonable timeframe.

Later in the day, I had a meeting with Davy and Wesley to discuss these findings and determine our next steps. We decided to simplify the initial pull requests even further by stripping the MVP down to its bare minimum: creating a list, adding knowledge items, extracting content from a URL, and generating an AI digest sent via Slack.

Once this simplified foundation is established and merged, we can progressively build upon it and introduce features as requested. Moving forward, I can use my existing MVP codebase as a reference for these new features, as the underlying architecture is already complete and thoroughly tested.

Tuesday (Day 37) ​

Today, I created three clear and concise Pull Requests that focus solely on the core Proof of Concept steps: Input, Process, and Output. To support these changes, I updated the Knowledge Hub Documentation Site with a comprehensive overview of the three PRs. This page explains the functionality and architectural impact of each step.

Step 1 — Input: Create Lists & Add Knowledge Users can organize knowledge through the Slack App Home by creating themed lists (categories) and adding knowledge items to them. This step establishes the full layered architecture, connecting the Slack UI to database persistence. It introduces the base infrastructure, including the Controller, Orchestrator, Service, and Repository layers, alongside the Mapper pattern for DTO transformations.

Step 2 — Process: URL Detection & Content Extraction When a user shares a URL in a Slack channel, the bot detects it and offers to save it via a prompt. Alternatively, a user can manually enter a URL in the AddKnowledge modal. Both actions trigger the same content extraction pipeline, which retrieves the URL's contents and appends it to any user-provided text. This step solidifies the Slack event handling pipeline and the backend content extraction process with built-in SSRF protection and HTML parsing.

Step 3 — Output: AI-Enhanced Digest & DM Delivery Users can generate an ad-hoc digest for any list. The backend queries the respective knowledge items, utilizes the Symfony AI Bundle (connecting to OpenAI) to produce concise 2–3 sentence summaries, and delivers a formatted Slack DM containing these summaries and Notion links. This step establishes the complete AI provider stack, the QueryService pattern, and the DigestOrchestrator responsible for coordinating AI generation.

After receiving approval from Wesley, I spent the rest of the day finalizing and submitting the Slack/Symfony PR's for step 1.

Wednesday (Day 38) ​

Today, I focused entirely on refining the pull requests by stripping out MVP features to strictly adhere to the Proof of Concept (POC) scope. This process ensured that the initial changes remain focused on the core requirements of Input, Process, and Output without getting bogged down by additional complexities.

Thursday (Day 39) ​

I continued refining the POC pull request, taking the opportunity to address several structural inefficiencies in the codebase. I refactored the NotionSync logic into an abstract service where specific services like NotionSync[Entity] act as concrete implementations. I also improved type safety within the concrete Data Transfer Object (DTO) builders (QueryContextDto, DomainContextDto, OperationContextDto). To do this, I added specific domain-driven methods like withNotionId(), which delegate to the underlying set() method from AbstractContextBuilder. This dramatically improves readability at the call sites, replacing generic array-like assignments with fluent, typed method calls.

Additionally, I reduced code duplication in the query and persistence layers. For example, CategoryQueryService and KnowledgeQueryService now extend a unified BaseQueryService following the QueryServiceInterface contract. Similarly, CategoryPersistenceService and KnowledgePersistenceService were refactored to use a BasePersistenceService governed by the PersistenceServiceInterface.

Friday (Day 40) ​

I finalized and pushed the pull request for Step 1 of the POC (Focusing on Knowledge and Category endpoints). To facilitate a smooth review process for Davy and Wesley, I logically split the massive ~5000 lines-of-code PR into four core, manageable commits:

  1. Base Architecture (+1567 LOC): Establishing foundations such as BaseOrchestrator, BaseQueryService, logging DTOs, MapperRegistry, base repositories, and core Symfony configurations.
  2. Notion Infrastructure (+220 LOC): Core Notion modifications including the NotionPageBuilder, NotionRepositoryManager, and the newly refactored AbstractNotionSync.
  3. Category Domain (+1051 LOC): Layered implementation of the Category domain following the strict Controller > Orchestrator > Resolution Service > Query/Persistence Service > Sync pipeline.
  4. Knowledge Domain (+1315 LOC): Same as the 3rd commit, but for the Knowledge domain.

Additionally, I took some time to configure and finalize our Husky pre-commit hooks—a piece of technology I had researched and added in previous weeks but hadn't yet documented. I integrated cs-fixer, phpstan, and prettier directly into the pre-commit workflow to enforce strict formatting and static analysis checks locally, ensuring that no violating code reaches the CI pipeline.

New skills ​

  • Refactoring towards abstract base services and unified interfaces (QueryServiceInterface, PersistenceServiceInterface).
  • Implementing fluent, type-safe builder patterns for Data Transfer Objects (DTOs).
  • Strategic commit splitting to structure large pull requests (~5000 LOC) for easier code review.
  • Configuring and integrating Husky pre-commit hooks to enforce local code quality and static analysis checks.

Useful data ​

Remarks ​

This week highlighted the importance of scoping work effectively. Transitioning from a feature-heavy MVP back to a lean, reviewable POC was challenging but necessary. Breaking down the massive PR into four logical architectural commits and improving type safety within DTO builders will vastly improve the code review experience and long-term maintainability of the codebase.