# Repository Guidelines

## Project Structure & Module Organization
The SwiftUI application lives in `Cable/`, with `CableApp.swift` bootstrapping shared state and the scene hierarchy. Feature views such as `CalculatorView`, `SystemEditorView`, and `LoadEditorView` sit beside their supporting models (`CableCalculator`, `UnitSystem`, `Item`). Shared assets are stored in `Assets.xcassets`, while entitlement and configuration files remain at the top level. Unit tests reside in `CableTests/` and UI automation in `CableUITests/`; mirror new feature code with corresponding test folders.

## Build, Test, and Development Commands
Work in Xcode 15 or newer targeting the iOS 17 simulator. Use `open Cable.xcodeproj` to launch the project with the correct scheme configuration. From the command line, `xcodebuild -scheme Cable -destination 'platform=iOS Simulator,name=iPhone 15' build` performs a debug build, and `xcodebuild -scheme Cable -destination 'platform=iOS Simulator,name=iPhone 15' test` runs both unit and UI test bundles. Prefer running through Xcode when iterating on UI so previews and Instruments remain available.

## Coding Style & Naming Conventions
Follow idiomatic Swift style: four-space indentation, trailing commas for multiline collections, and 120-character soft line limits. Types use `UpperCamelCase`, methods and properties use `lowerCamelCase`, and tests follow `testScenario_expectedResult`. Keep SwiftUI view files focused on a single view struct, extracting supporting types or extensions into adjacent files when logic grows. Rely on Xcode's "Re-Indent" and "Add Missing Conformance" tools for quick formatting passes before reviews.

## Testing Guidelines
`CableTests.swift` demonstrates standard XCTest usage; add focused test cases that cover each calculator branch and unit conversion rule you touch. Place UI flows that require navigation assertions in `CableUITests/`, reusing launch helpers from `CableUITestsLaunchTests`. Run `xcodebuild ... test` (above) or the Test action in Xcode before submitting changes. Aim to keep or raise coverage for core calculation logic when introducing new units or system behaviors.

## Commit & Pull Request Guidelines
Existing history favors short, descriptive subjects (e.g., `systems first`); continue with concise, imperative summaries under 50 characters, adding optional bodies when context is needed. Group unrelated work into separate commits to keep diffs reviewable. Pull requests should link related issues, summarize functional changes, call out impacted screens, and attach simulator screenshots for major UI updates. Mention any follow-up tasks or technical debt explicitly in the PR description.