Keep repository configuration files canonical, documented, and free of personal workspace/debug artifacts. Why: Config files determine runtime behavior and developer onboarding. Committing personal IDE or temporary debug configs pollutes the repo, causes accidental formatting/behavior differences, and hides the canonical way to run the app. Likewise, config schemas consumed by the app should be explicit and stable so tooling/parsers and CI can validate them. How to apply: - Do not commit personal workspace or IDE/debug files (e.g., .vscode/launch.json). Add them to .gitignore, or commit a vetted template (e.g., .vscode/launch.json.template) with instructions. - Example: remove .vscode/launch.json and document the standard run command: `task electron:dev`. - Provide and document one canonical method to run services in dev (tasks, npm scripts, Makefile entry). Put those instructions in CONTRIBUTING.md or README_DEV.md so everyone uses the same flow. - Make config formats explicit and machine-friendly. Add clear fields rather than relying on ad-hoc parsing, and document accepted separators/formatting. - Example (from keybindings): { "command": "app:openConnectionsView", "keys": [], "commandStr": "/mainview connections" } Document parsing rules (e.g., comma, whitespace, or '\n' accepted as separators) and enforce via a linter or schema validator in CI. - If developers need personal debugging conveniences, keep them local (ignored) or provide documented templates and scripts to reproduce behavior without committing per-user files. Enforcement suggestions: - Add lints/CI checks that validate config schemas and fail on unexpected workspace/debug files being committed. - Maintain a small set of canonical templates and clear developer docs for running and debugging the app. References: discussion indices [0, 1].