Fleetbase

My earliest pull requests were small and infrastructural: dependency and formatting cleanup in fleetbase-js, organization lookup, a package-publishing workflow, a release, and a Node adapter fix. The next work moved through storefront-js, the Navigator mobile application, and Storefront’s application architecture.

That sequence built a map:

• SDK packages defined contracts used by products;
• applications consumed those packages on different runtimes;
• Laravel services held domain behavior and validation;
• Ember packages supplied shared components and extension points;
• release automation determined whether a fix actually reached a user.

Without that map, a local fix could be correct in one repository and incomplete in the product.

One February change is a clear example. A customizable widget-based dashboard required coordinated work in three repositories:

• ember-core added widget registration behavior;
• core-api added dashboard and widget services;
• fleetbase connected the capability to the product.

The visible feature lived in the application, but its contract and persistence belonged elsewhere. Treating it as one frontend ticket would have left the system split across incompatible assumptions.

This was the practical value of learning the repository topology: knowing which part of the change should not be implemented in the file currently open.

Another group of March pull requests moved component-context utilities into ember-core, then removed duplicate local versions from FleetOps and Pallet.

The code change was modest. The architecture decision mattered more. Shared behavior belonged in the package that owned the convention, not copied into every application that happened to need it.

The same principle appeared in SDK typing, storefront rules, model reflection, package releases, Android fixes, customer/order views, permissions, and boot-screen behavior: follow the product behavior across repositories, then make the smallest coherent change at each boundary.

In my own repository, I can merge my interpretation of the system. In external open source, the change must fit maintainers’ constraints, release direction, and review.

Forty merged pull requests show that the learning became useful to Fleetbase. The six unmerged requests are part of the record too. Contribution includes proposals that are superseded, rejected, or no longer worth the change they require.

That is a healthier feedback loop than measuring learning by the amount of code produced.