Chris Farhood
24033ca977
Remove all references to the incorrect `config.watchPlugins: false` requirement that was believed necessary for Headlamp v0.39.0+. Investigation revealed that plugins work correctly with the default `watchPlugins: true` setting. The earlier documentation was based on a misunderstanding of the plugin loading mechanism. Changes: - Remove watchPlugins: false from all YAML configuration examples - Remove warning sections about watchPlugins requirement - Update troubleshooting guides to focus on actual issues - Simplify installation instructions by removing unnecessary config Files updated: - README.md (main installation docs and troubleshooting table) - docs/DEPLOYMENT.md - docs/TROUBLESHOOTING.md - docs/getting-started/* (quick-start, installation, prerequisites) - docs/deployment/* (helm, production) - docs/troubleshooting/* (common-issues, README) - Multiple other doc files formatted by prettier This cleanup ensures ArtifactHub and GitHub documentation show correct, simplified installation instructions. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering>
Architecture Decision Records
This directory contains Architecture Decision Records (ADRs) for significant architectural choices made in the Headlamp Polaris Plugin.
What is an ADR?
An Architecture Decision Record (ADR) captures an important architectural decision made along with its context and consequences. AD Rs provide historical context for future developers and serve as documentation for why certain approaches were chosen.
When to Create an ADR
Create an ADR when:
- Making a significant architectural choice (e.g., state management approach)
- Selecting between multiple technology options (e.g., React Context vs. Redux)
- Establishing a pattern that impacts multiple components
- Making a trade-off decision with non-trivial consequences
- Introducing a new dependency or external integration
- Defining security or performance constraints
ADR Format
Each ADR follows this template (based on Michael Nygard's format):
# ADR-NNN: Title
**Status**: [Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
**Date**: YYYY-MM-DD
**Deciders**: [List key decision makers]
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?
### Positive
- ...
### Negative
- ...
### Neutral
- ...
## Alternatives Considered
### Option 1: Name
**Pros**: ...
**Cons**: ...
**Decision**: Not chosen because...
## References
- [Link to related issues, docs, discussions]
ADR Index
| ADR | Title | Status | Date |
|---|---|---|---|
| 001 | Use React Context for State Management | Accepted | 2026-02-12 |
Note: Additional ADRs documenting other significant decisions (service proxy approach, drawer navigation, MUI import restrictions) can be created following the template above.
Creating a New ADR
- Determine the next ADR number (e.g., if last ADR is 004, new ADR is 005)
- Create a new file:
NNN-short-title.md(e.g.,005-exemption-management.md) - Use the template above and fill in all sections
- Add entry to this README in the ADR Index table
- Submit for review via pull request
ADR Lifecycle
- Proposed: ADR is drafted and under discussion
- Accepted: Decision has been made and is currently in effect
- Deprecated: Decision is no longer recommended but not yet superseded
- Superseded by ADR-XXX: Decision has been replaced by a newer ADR