Sonomundi: gradually building a polished product

1. Project context

Sonomundi is a Laravel/Vue monorepo designed as a long-term personal side project around events and music. I intend to take the time to finish it properly and release it gradually once it is sufficiently polished, without imposing a rushed launch schedule.

I began Studi’s Event Project Management course in July 2024. My attendance certificate records 1,000 hours; I estimate that personal work and deeper study took the actual investment beyond that figure, but I only present the certified total as verifiable. The linked public document is the curriculum in force in July 2026 and now shows an indicative 500-hour duration; my certificate remains the source for the course started in 2024.

The course did not lead to certification because I could not secure the required internship. I live in an isolated rural area where event-industry opportunities are scarce, geographically distant and often difficult to identify or access without an established local professional network. After an unsuccessful search, I chose to invest my energy in building Sonomundi rather than indefinitely waiting for an internship.

The curriculum covered strategy and feasibility, market and positioning, client needs, project design, budget and risk, KPIs, reporting, feedback, project-team creation, delegation and internal communication. Returning to training was intended to move beyond a purely technical product perspective and learn how to carry a project forward with others.

I then applied part of these concepts to Sonomundi: MVP framing, specifications and planning, risk prioritization, roles and responsibilities, readiness indicators, reporting, feedback loops and continuous improvement. This replaces neither the missing internship nor human-management experience, but it provides concrete, demonstrable practice.

Development stays outside working hours and can be paused. It is organized so it does not interfere with my full availability to an employer.

2. Problem addressed

The product core organizes event discovery and navigation between events, artists and tracks. The work also demonstrates the ability to turn a rich need into architecture, contracts, access rules and verifiable flows.

3. Main features

• Events hub and region selection.
• Opening an event, artist and then a track.
• Public, authenticated and administrative surfaces.
• API resources, jobs and OpenAPI/Scramble documentation.

4. Architecture

The core combines a Laravel/PHP API and a Vue 3/TypeScript SPA. MySQL stores primary data; Redis supports cache, queues and local coordination. Python/FastAPI services cover targeted needs. Migrations, resources, middleware, jobs, tests and API contracts document the boundaries.

As observed on July 21, 2026, the VPS runs 37 containers associated with Sonomundi. This total describes two application environments and their operations platform; it does not mean the product consists of 37 microservices or demonstrate production-scale load.

• 11 containers for the demo and 11 for pre-production: web interface, API, HTTP proxy, worker, scheduler, real-time transport, audio transcoding, MySQL, two Redis workloads and Neo4j.
• 15 shared containers: source forge and CI/CD, agent orchestration and semantic code search, observability and logs, error tracking, operations dashboards, supporting databases and access gateways.

5. Stack

• PHP 8.2, Laravel 12, Vue 3 and TypeScript.
• MySQL, Redis and Neo4j for graph/recommendation exploration.
• Python/FastAPI for targeted satellite services.
• Docker, local k3s, OpenAPI/Scramble, PHPUnit and Playwright.

6. Authentication and roles

The scope includes multi-role authentication and differentiated access for unauthenticated visitors, authenticated public users, artists, labels and administrators. Middleware and test matrices verify these boundaries.

7. Ontology and functional traceability

Sonomundi has a versioned, machine-readable ontology. It formalizes domain entities — accounts, roles, artists, labels, releases, tracks, events, venues, audio assets, content requests and proofs — together with their relations, invariants, provenance policies and visibility rules.

A functional projection connects user-visible capabilities to application surfaces, six role spaces and test evidence. The reviewed July 24, 2026 baseline inventories 511 capabilities, 113 router surfaces and 3,066 capability-role cells. Missing or contradictory evidence remains explicitly decision-needed; it is never inferred from similarity or LLM output.

The ontology acts as a knowledge and governance contract: business boundaries, permissions and coverage gaps are auditable by people and agentic tooling alike. Neo4j is a separate graph and recommendation exploration; it is not the ontology’s source of truth.

8. Data and performance

MySQL remains the main application database. Redis is used for cache, queues and local coordination. Neo4j is still experimental. No real-production latency or commercial load capacity is published because those measurements are absent from the available evidence.

9. Tests

The static inventory of gitea/main on July 16, 2026 identifies 2,189 PHPUnit tests across 401 PHP files. It describes the volume of tests present in the repository, not the result of a full run or a coverage rate.

A Playwright matrix complements this evidence with 683 validated scenarios across five access profiles. These figures document the breadth of the validation system without claiming universal coverage or production validation.

10. CI/CD

Changes are isolated through branches and worktrees, then validated with Docker, Make, targeted tests and broader checks when shared contracts are affected. The recruiter demo is pinned to a dedicated version. A separate pre-production environment is continuously improved.

11. Observability

Grafana/Loki and GlitchTip/Sentry are among the explored technical rails. Mature production observability, SLOs, incident history and real availability measurements are not demonstrated; they remain industrialization work.

12. Use of AI tools

I adapted Paperclip as the control plane for agentic delivery: specifications feed work packages assigned to specialized agents, with targeted context, bounded tasks, documentary memory, isolated branches and worktrees, Docker/CI validations and pull-request pre-review. Codex, MCP and LangChain/LangGraph complement this system for analysis, implementation, testing, documentation and audits.

The ontology and versioned contracts give agents a business vocabulary and verifiable boundaries without delegating functional truth to them. There is no auto-merge; the LLM is never the source of truth and I remain accountable for integration.

In the long term, the goal is to automate validation, PR review, documentation updates, deployments and monitoring alerts as far as practical, reducing routine maintenance and avoiding unnecessary interruptions.

13. Current limits

• Private repository and candidate-led demonstration.
• No imposed release date: quality and maintainability take priority over speed.
• Billing, wallet, settlement, monetization and real audio are separate or partial workstreams.
• Observability, backups, secrets and infrastructure need strengthening for industrialization.
• Some advanced surfaces remain frozen or incomplete.

14. Lessons learned

The main lesson is to reduce the MVP earlier and distinguish technical evidence from produced volume. Tests, contracts, module boundaries, migrations and documented decisions matter more than lines of code or commit count. AI speeds up production; it does not replace framing or responsibility.

Coordinating agents forces me to make the objective explicit, distribute responsibilities, provide the right context, control dependencies, give feedback and arbitrate results. This is not human-management experience, but it is a concrete environment for strengthening coordination practices that I want to apply as a senior contributor or lead serving a team.

15. Demo and screenshots

The recruiter flow shows the events hub, a region, an event, an artist and a track. The screenshots below complement the demo and anonymized architecture. The reader is not asked for repository access or local installation.

To access a more complete interface, create an account in the demo. Without signing in, the demo remains limited to public features.