Specification, thirteen tickets, and a scaffold verified end to end

The Trascendence final project at 42 Barcelona is now underway: an AI-assisted job search platform with a professional profile, in-depth searches, listing extraction, and a recruiter module. This first entry in the project diary focuses on the foundations.

Everything stays in its own folder

The first organizational decision: each feature lives in its own folder, with its own routes, services, and templates. This prevents related pieces from becoming scattered, and adding a new feature no longer results in it ending up inside another feature’s modules. Following the same approach, I prepared the initial specification and decision map, and published thirteen tickets in GitHub Issues with their inherent dependencies. Corporate identity has also been included in the planning, although the logo and colors have yet to be decided.

The scaffold, verified against a real database

Before distributing the tickets, we needed a scaffold that would not create conflicts between agents. The key was understanding why the schema and routes come together on their own: each feature declares its tables and router in its own folder, and the server collects them at startup. Adding a feature does not require editing a central registry that everyone would have to touch. The scaffold has now been verified end to end against a real PostgreSQL database, with registration, login, and the default role working, and with the application compiled and launched from the built code.

Fighting the usage limit

I wanted to distribute the thirteen tickets among subagents in parallel, each working in its own worktree, but the model’s usage limit shut down the agents after a few minutes, leaving work unfinished. The agent also failed on its own: it changed the route contract while the agents were running. The lesson came down to two parts: when the usage limit has been exhausted, the reliable approach is to implement sequentially from the main session, without promising parallelism that the environment cannot sustain; and to establish the technical contract before distributing the work, not while it is running. Some of the work abandoned in the worktrees could be recovered manually.

Thirteen tickets closed, and the review that uncovered the gaps

Five features were implemented first, with tests and no loose ends: account access, professional profile, in-depth searches, configuration and service limits, and user and role administration. The suite totaled 49 API tests and 28 web tests. Then all thirteen tickets were completed. However, the review along two axes—standards and specification—uncovered what a self-review could not see: the application returned fabricated text instead of calling a real provider, users’ own credentials and limits did not govern usage, notifications had neither a scheduler nor email, the recruiter could not see the candidate’s profile, and several screens were not wired up.

The fixes changed the substance more than the appearance: there is now a real AI client with an OpenAI-compatible API, credential resolution happens on every request and deducts the service limit, the notification is sent via SMTP to each person’s email address with the scheduler triggering it, and the authorized recruiter can access the candidate’s profile. The suite now stands at 116 API tests and 36 web tests, and the full build compiles.

The lesson of the day

Green tests do not equal a working product. The difference between a passing suite and an application that does its job is marked by the gaps that only become visible when you ask what will happen in production.