chore(adr): add initial adrs

.adr/0000-template.md

@@ -0,0 +1,17 @@
+# Title
+
+## Status
+
+What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
+
+## 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?

.adr/0001-record-architecture-decisions.md

@@ -0,0 +1,30 @@
+# Recording Architecture Decisions
+
+## Status
+
+Proposed
+
+## Context
+
+At SigNoz, architecture decisions are stored across internal communication channels, Notion, GitHub Issues, or directly
+in PR comments and code.
+
+When we need to understand the reasoning behind a large change or a specific decision in the codebase, finding it is
+difficult because we must search across many different places.
+
+## Decision
+
+Instead of storing architecture decisions outside this codebase, we will use the structure proposed
+by [ADR](https://github.com/architecture-decision-record/architecture-decision-record).
+
+This is the first decision being stored, alongside [0000-template.md](./0000-template.md) which serves as the template
+for new decisions.
+
+The current template is basic and inspired
+by [Michael Nygard's template](https://github.com/architecture-decision-record/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-michael-nygard/index.md).
+Over time, we can improve or change it to better fit our needs.
+
+## Consequences
+
+We can still store internal discussions or private matters in our internal communication channels. However, with this
+approach, we have a single place to look for decisions about the codebase.

.adr/0002-migrate-to-oxlint.md

@@ -0,0 +1,61 @@
+# Migrate from ESLint to Oxlint
+
+## Status
+
+Accepted
+
+## Context
+
+Current implementation (02/17/2025) uses ESLint v7 (latest is v10):
+
+- **Dependencies**: 12 (without eslint itself)
+- **Execution time**: 113s locally, 185s on CI
+- **Memory usage**: 3472mb
+
+Our pain with Eslint is caused by the integration of it when create a commit, causing the git commit to take multiple
+seconds instead of being instant or feel instant.
+
+### Requirements for new tooling
+
+- Fast execution (primary goal)
+- Community/plugin support
+- IDE support (Cursor/VSCode, JetBrains)
+- Fewer dependencies (install speed, reduced threat vector)
+
+### Alternatives evaluated
+
+| Feature           | ESLint | Biome | Oxlint |
+|-------------------|--------|-------|--------|
+| Lint Speed        | 195s   | 13s   | 6s     |
+| Format Speed      | 20s    | 0.5s  | 1.3s   |
+| Type-aware        | Yes    | Yes   | Yes*   |
+| Plugin Support    | Yes    | No**  | Yes    |
+| Dependencies      | 12     | 1     | 6      |
+| Replaces Prettier | No     | Yes   | Yes*** |
+
+\* Type-aware via tsgolint (uses Go-based TypeScript compiler)
+\** Biome uses GritQL for custom rules
+\*** Via oxfmt
+
+## Decision
+
+Migrate to Oxlint.
+
+References:
+- https://app.notion.com/p/signoz/Linting-Formatting-30cfcc6bcd1980a7bb47f04a41e67c21#30cfcc6bcd1980d28398c2fd8bcb53fb
+
+### Rationale
+
+1. **VoidZero ecosystem alignment**: Oxlint is part of Oxc project under VoidZero initiative (includes Vite, Vitest,
+   Rolldown). Future migration to Vite benefits from consistent tooling.
+
+2. **Performance**: Fastest option at 6s vs 195s (32x improvement). CI time: best among alternatives.
+
+3. **JS plugin support**: Custom rules possible without learning GritQL. Example: `signoz/no-zustand-getstate-in-hooks`
+   rule already implemented.
+
+## Consequences
+
+- **Development speed**: 32x faster linting (6s vs 195s)
+- **CI time**: Significant reduction in pipeline duration
+- **Memory usage**: Lower footprint than ESLint

.adr/0003-migrate-to-pnpm.md

@@ -0,0 +1,63 @@
+# Migrate from Yarn to pnpm
+
+## Status
+
+Accepted
+
+## Context
+
+Yarn install time is one of the slowest part of the CI, around 108s locally or 120s on CI. Also, we are using v1 that is
+on maintenance mode since 2020, and [will eventually reach EOL](https://github.com/yarnpkg/yarn/issues/9062).
+
+### Requirements
+
+- Faster install times
+- Better CI performance
+- Reduced attack surface for supply chain attacks
+
+## Decision
+
+We decided to migrate to pnpm mostly due to the usage of this package manager already by
+our [Component Library](https://github.com/SigNoz/components). We had good experience and the performance was great.
+
+### Performance improvements
+
+| CI Job    | Yarn   | pnpm  | Diff     |
+|-----------|--------|-------|----------|
+| tsc/js    | 2m56s  | 1m21s | -95s     |
+| test/js   | 10m30s | 8m20s | -130s    |
+| fmt/js    | 2m25s  | 33s   | -112s    |
+| lint/js   | 2m56s  | 44s   | -130s    |
+| authz     | 11m9s  | 9m24s | -105s    |
+| openapi   | 2m41s  | 1m7s  | -94s     |
+| **Total** |        |       | **-11m** |
+
+Install time: 108s → 16s (5.8x faster)
+
+### Security hardening
+
+Added `pnpm-workspace.yaml` with minimum release age:
+
+```yaml
+trustPolicy: no-downgrade
+minimumReleaseAge: 2880 # 2d
+minimumReleaseAgeStrict: true
+minimumReleaseAgeExclude:
+  - '@signozhq/*'
+blockExoticSubdeps: true
+```
+
+Prevents installing packages released less than 2 days ago — mitigates supply chain attacks where malicious code is
+pushed and quickly removed.
+
+## Consequences
+
+- Replace `yarn` commands with `pnpm` equivalents
+- `yarn add` → `pnpm add`
+- `yarn install` → `pnpm install`
+- `yarn run` → `pnpm run` (or just `pnpm <script>`)
+
+### References
+
+- PR #11158: https://github.com/SigNoz/signoz/pull/11158
+- PR #11274: https://github.com/SigNoz/signoz/pull/11274