# 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.

## Revisit If

<!-- MANDATORY (added 2026-08-09, hkl). The conditions under which this decision should be
     RE-EXAMINED. An ADR records a decision made under specific forces; when those forces
     change, the ADR must not become a hurdle that outlives its own reasoning.

     Write the invalidation triggers, not a vague "review periodically":
     - Which Context force, if it disappeared or reversed, would remove the decision's basis?
     - Which constraint was a cost/capacity/tooling limit that a future change could lift?
     - What measurement or threshold would signal this is now the wrong call?
     - What was explicitly OUT of scope here, so a later reader does not over-apply the rule?

     Scope discipline matters as much as the trigger: state what this decision does NOT
     govern, so it is not cited against cases it never considered.

     Example:
       - The 100 KB proof-image cap exists because of base64-in-DB bloat (ADR-072). If proof
         images move to object storage, re-examine the cap — it is a storage artifact, not a
         product requirement.
       - This governs PUBLIC marketing media only. It does NOT govern client-confidential
         media, which stays under ADR-049 regardless.
-->

- **Revisit if:** ...
- **Does NOT govern:** ...

## 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. -->

- ...