Add comprehensive Core-Monitor wiki

docs/wiki/App-Startup-And-Lifecycle.md

@@ -0,0 +1,9 @@
+# App Startup And Lifecycle
+
+Startup is controlled by `Core_MonitorApp.swift`, `WelcomeGuideProgress.swift`, `StartupManager.swift`, `DashboardShortcutManager.swift`, and `AppCoordinator.swift`.
+
+The app must satisfy two conflicting goals: behave like a quiet menu bar utility for returning users, and show a visible dashboard/onboarding surface for first launch or explicit dashboard requests. The current delegate disables automatic termination, handles duplicate launches, purges deprecated defaults, determines welcome-guide presentation, installs global shortcuts/observers, creates menu bar items, and opens the dashboard if needed.
+
+Activation policy matters. The app can be accessory-style for menu bar operation, but it must temporarily promote visibility when the dashboard is shown so the window does not vanish behind other apps or launch invisibly.
+
+Shutdown is also functional: fan modes that Core-Monitor owns should be returned to system automatic best-effort before process exit. That cleanup is part of the trust model.

docs/wiki/Assets-And-Media.md

@@ -0,0 +1,7 @@
+# Assets And Media
+
+Assets include app icons, accent colors, Pock weather/status icons, website screenshots, Gatekeeper walkthrough images, videos, and Kernel Panic audio.
+
+Several media files were replaced or removed across history, including old walkthrough videos, screenshots, MP3 soundtrack files replaced by M4A assets, and stale UI images.
+
+Keep source-control size in mind. App bundles, DerivedData, module caches, and generated build products have been removed before and should stay out of normal commits.

docs/wiki/Battery-Power-And-Thermals.md

@@ -0,0 +1,7 @@
+# Battery Power And Thermals
+
+Battery data is modeled in `BatteryInfo` and formatted through `BatteryDetailFormatter`. Data includes charge, source, status, cycle count, health, voltage, amperage, power watts, temperature, capacities, and time remaining where macOS provides it.
+
+Power data is used both for user-facing visibility and fan-control heuristics. Smart and custom fan modes can treat high watt draw as an effective temperature boost, which lets Core-Monitor respond to sustained load before raw temperature alone catches up.
+
+Thermal readings come from SMC keys and ProcessInfo thermal state. The app must be honest about missing sensors: unsupported keys should show unavailable/fallback messaging rather than pretending exact measurements exist.

docs/wiki/CPU-GPU-Memory-Disk-Network.md

@@ -0,0 +1,9 @@
+# CPU GPU Memory Disk Network
+
+CPU load comes from host CPU counters and per-processor load info. Apple Silicon performance and efficiency core utilization uses logical-core grouping from sysctl when available.
+
+GPU temperature is SMC-backed and depends on chip-specific keys. The app probes several known keys and falls back when a sensor is unavailable. GPU utilization is not the same as GPU temperature and should not be implied unless a real utilization source exists.
+
+Memory stats come from VM statistics: used, wired, compressed, free, page-ins, page-outs, swap, and derived pressure. UI should explain pressure and swap in user terms, not only percentages.
+
+Disk stats are gated because filesystem capacity and process-level disk activity do not need the same cadence as CPU load. Network throughput uses byte deltas over time, not a raw absolute counter.

docs/wiki/Custom-Fan-Curves.md

@@ -0,0 +1,7 @@
+# Custom Fan Curves
+
+Custom presets are modeled by `CustomFanPreset` and edited through `FanCurveEditorView.swift`. A preset includes a sensor source, curve points, optional update interval, smoothing step, RPM bounds, per-fan offsets, and optional power boost.
+
+The editor constrains point movement, temperature range, speed range, nearest-handle selection, template application, and validation. Tests under `CustomFanPresetTests` and related curve editor geometry coverage protect these rules.
+
+Custom curves are high-risk because they turn user configuration into hardware behavior. Validate bad JSON, invalid curve order, impossible RPM ranges, and fallback defaults defensively.

docs/wiki/Dashboard-Architecture.md

@@ -0,0 +1,9 @@
+# Dashboard Architecture
+
+The dashboard is mainly in `ContentView.swift`, `MonitoringDashboardViews.swift`, `FanCurveEditorView.swift`, `FanModeGuidanceCard.swift`, `MenuBarConfigurationSection.swift`, `LaunchAtLoginSection.swift`, `PrivacyControlsSection.swift`, `WeatherLocationAccessSection.swift`, `HelpView.swift`, and support cards such as helper diagnostics.
+
+`ContentView.swift` remains oversized and mixes shell, sidebar, overview cards, system pages, fan controls, Touch Bar customization, helper support, and about surfaces. The architecture docs already call it a pressure point. New UI work should prefer extracting small dedicated views rather than growing it.
+
+Dashboard data should come from `SystemMonitorSnapshot`, `FanController`, `SMCHelperManager`, and settings objects. Avoid ad hoc timers or local telemetry state in SwiftUI views. Detailed process panels should request detailed sampling while visible and release that reason when hidden.
+
+`DashboardWindowLayout.swift` owns safe window sizing and frame reset rules; use it instead of hardcoding dashboard geometry.

docs/wiki/Developer-Workflow.md

@@ -0,0 +1,7 @@
+# Developer Workflow
+
+Before editing, read `docs/ARCHITECTURE.md`, relevant feature files, and nearby tests. Prefer the smallest owner of behavior, add focused tests, build, run relevant tests, and inspect user-visible UI directly.
+
+Do not hide broad refactors inside high-risk files. If a change crosses monitoring, helper, fan control, and UI boundaries, document the reason in the commit message and worklog.
+
+Standard test command: `xcodebuild -project Core-Monitor.xcodeproj -scheme Core-Monitor -destination 'platform=macOS' CODE_SIGNING_ALLOWED=NO test`.

docs/wiki/Fan-Control.md

@@ -0,0 +1,9 @@
+# Fan Control
+
+`FanController.swift` owns fan modes: Smart, System/Silent, Balanced, Performance, Max, Manual, Custom, and Automatic/System restoration.
+
+Managed modes require the helper because they write fan targets. Monitoring itself does not. Smart mode blends the hottest CPU/GPU reading with system power draw. Balanced and Performance pin fans near fixed percentages of maximum. Manual writes a fixed RPM. Custom follows a persisted curve.
+
+The UI should always explain who owns the fan curve: macOS firmware or Core-Monitor. If Core-Monitor owns it, quitting or switching to automatic should hand control back to the system best-effort.
+
+Fan behavior can lag visibly on Apple Silicon. The guide copy intentionally warns users that a write can succeed before RPM changes are immediately obvious.