# ADR-NNN Short Imperative Title

## Status

Proposed, YYYY-MM-DD.

<!-- When accepted or superseded: update this line and append the same transition below in Status History.
     Do not edit earlier history entries or other sections of an Accepted/Deprecated ADR;
     write a new superseding ADR instead. -->

## Status History

```yaml
status_history:
  - date: YYYY-MM-DD
    status: Proposed
    changed_by: hkl
    reason: Initial proposal
    changed_via: adr-kit (360lm)
```

## Context

<!-- The problem this ADR resolves and the constraints driving the decision.
     Cite evidence: incidents, prior ADRs, code paths, PWAs affected.
     Avoid hand-waving ("scalability", "best practice"); state the actual force. -->

## Decision

<!-- The chosen approach, in imperative voice. One paragraph or short bulleted list.
     Single concrete decision, no hedging language, traceable identifiers (file paths,
     function names, config keys) where applicable. -->

**Decision Maker:** hkl

## Implementation Notes

<!-- HOW the decision is applied in practice. Fill in what a future developer needs
     to not re-derive from scratch:
     - Exact file paths + line numbers where the pattern is implemented
     - Key function / RPC / table names
     - Config keys, env vars, or constants to change
     - Copy-paste snippet or grep command to find all call sites
     - Any "gotcha" that would only be discovered by running it

     Example:
       File: hub/index.html:616 — CFG.apiHeaders object
       Add both Accept-Profile and Content-Profile headers for RPC calls.
       Grep: grep -r "Accept-Profile" /var/www/360lm --include="*.html"
-->

- **Files:** ...
- **Key identifiers:** ...
- **Find all sites:** `grep -r "" /var/www/360lm --include="*.html" | head -20`

## Alternatives Considered

<!-- At least two alternatives, each with a one-line rejection reason.
     "Do nothing" counts if it was actually weighed. -->

- **Alternative A.** Rejection reason.
- **Alternative B.** Rejection reason.

## Consequences

<!-- Both directions required. -->

**Positive:**
- ...

**Negative / Trade-offs:**
- ...

**Risks and mitigations:**
- ...

## Related Decisions

<!-- Other ADRs this one depends on, supersedes, is superseded by, or relates to.
     Use ADR-NNN identifiers. -->

- None.

## References

<!-- Links to incidents, code paths, prior PRs, memory files, or external docs
     that support the decision. At least one concrete reference required. -->

- ...