The big change today was rethinking the core model. What I used to call a “project” is now a “client”, and each client can contain its own projects: array. The motivation was real-world structure: I work with a client who has several distinct apps, and I wanted to switch into “client X / web” or “client X / api” and get the right command set for each, without duplicating all the shared client-level links.

That meant a precedence chain for commands: project > client > global. When a project is active its commands win, falling back to the client’s, then to global. The same layering applies to the browser choice, so a command can override the project, which overrides the client, which overrides the global default. I reworked resolve_current to return the client and the optional nested project together, and threaded that through list, current, and switch. switch now presents clients first; if the chosen client has nested projects, a second prompt lets me pick the client itself (shown as <name> (client)) or one of its projects. current and the launcher header both display the active selection as client / project.

To avoid breaking every existing config, old files using projects: / currentProject: are migrated in place to clients: / currentClient: on first load, and included configs get the same treatment. The merge rules for shared configs were extended to cover nested projects (matched by name, and a project can’t itself nest further). I also dropped the add command entirely — it never kept pace with the config schema, and editing ~/.project-switch.yml directly is simpler and more honest about what’s going on. The README and example configs were rewritten throughout to reflect the new vocabulary.