Lucas Manuel Rodriguez
9032883b47
Resolves #44970 (1/2). --- - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * `fleetctl get fleets` / `get teams` now display software and setup experience from authoritative software endpoints. * Preserve literal setup_experience fields (avoid erroneous macos_setup renames) when applying and when transmitting JSON for software entries. * **Tests** * Added regression tests and test helpers to ensure software/setup_experience are sourced correctly and to prevent nil panics in related tests. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Platform packages
This directory contains infrastructure and cross-cutting technical concerns that are independent of Fleet's business domain. These packages provide foundational capabilities used across the codebase.
Platform vs domain
Following separation of concerns, we distinguish:
- Platform (infrastructure): Technical concerns like database connectivity, HTTP utilities, middleware, and transport-level error handling. These packages have no knowledge of Fleet's business domain.
- Domain (business logic): Feature-specific code organized into bounded contexts. Domain packages depend on platform packages, not the reverse.
Guidelines
- Platform packages must not import domain packages
- Platform packages should be general-purpose and reusable
- Architectural boundaries are enforced by
arch_test.go