ref-sp-dev-projects-architecturelisted

# Projects Architecture ## Purpose Provide portable repository and feature-structure defaults that keep codebases modular, discoverable, and resistant to accidental coupling. ## When to use this skill - Designing the folder layout for a new feature or tool. - Deciding whether code belongs in product source or in maintenance scripts. - Reviewing whether a feature has grown beyond one file or one folder. - Choosing when shared utilities are justified. - Refactoring a repository that has started to blur boundaries. ## Scope Boundaries - Use this skill for portable structure decisions such as feature boundaries, shared-utility thresholds, and product-versus-maintenance separation. - Use a repo-local conventions skill (in this repo, `ref-sp-dev-repo-conventions`) when the question is about a specific repository's exact top-level folders, `pyproject.toml`, or agent wiring. - Use `ref-sp-py-python`, `ref-sp-js-javascript`, or `ref-sp-js-typescript` when the question is about language-specific folder shapes. - Use `ref-sp-js-web-standalone-template` when the structure question is specific to a browser-only local app or mini-tool. ## Defaults - Prefer feature-first organization over type-based dumping grounds. - Keep product code under the main source tree. - Keep maintenance and repo automation separate from product features. - Keep tests near the code they explain when the project layout allows it. - Add a short `README.md` at the root of each real feature folder so the feat