Initial Commit

This commit is contained in:
2026-05-27 23:29:53 +01:00
commit fbc70f96e6
10000 changed files with 1102152 additions and 0 deletions

View File

@@ -0,0 +1,43 @@
# `@suaveplan/api-tenant-resolver-header` — header-based tenant resolver
**Package**: `@suaveplan/api-tenant-resolver-header`
**Status**: PROPOSED
**Type**: new-package
**Stage**: 8 — see umbrella `openspec/changes/api-plugin-foundation/`
## Why
Per design doc §6 step 4, the per-request pipeline runs a tenant resolver chain — first the principal's `tenantId`, then fallback resolvers. Service-to-service traffic frequently carries the tenant in an HTTP header (`X-Tenant-Id`, `X-Acme-Tenant`, etc.) because no end-user session exists to resolve it from. This adapter handles that case.
## What changes
- ADDED: `createHeaderTenantResolver({ headerName, validate, registry })` — implements the `TenantResolver` contract from `api-types`. Reads `headerName` (default `X-Tenant-Id`); validates the value via the supplied `validate` function (default: must match `^[a-z0-9-]{1,64}$`) AND optionally checks membership in `tenant.provider`'s registry; resolves to `{ tenantId, source: "header" }` or `null`.
- ADDED: Strict mode — when `strict: true` (host config), a value that fails validation raises `TENANT_HEADER_INVALID` (HTTP 400). When `strict: false`, invalid values cause the resolver to return `null` so a downstream resolver may match.
- ADDED: Trusted-source enforcement — `trustedSources` config (default: `["service-mesh"]`) lists which traffic sources are allowed to set the header. The resolver consults `request.metadata.source` (set by upstream middleware); if the source is not trusted, the header is ignored. This prevents end-user clients from spoofing the tenant.
- ADDED: Conformance — passes `runTenantResolverConformance` from `api-tenant-provider/testing`.
- ADDED: Error codes (`TENANT_HEADER_*`): `INVALID`, `NOT_FOUND_IN_REGISTRY`, `UNTRUSTED_SOURCE`.
## Out of scope
- The trusted-source metadata itself — set by the router adapter when traffic enters from a service mesh / mTLS-verified ingress.
- Resolving multiple tenants (multi-tenant batch operations) — outside the per-request model.
## Source mapping
Genesis-original. Source of design intent: `docs/superpowers/specs/2026-05-13-api-plugin-foundation-design.md`.
| Requirement | Design doc section |
|---|---|
| Tenant resolver chain | §6 step 4 |
| Service-to-service tenant injection | §6 step 4 |
## Verification approach
- `src/resolver/resolver.test.ts` — valid header → tenantId; invalid + strict → 400; invalid + non-strict → null; missing header → null.
- `src/trust/trust.test.ts` — untrusted source ignored even when header is well-formed; trusted source resolves.
- `src/resolver/resolver.spec-conformance.test.ts` — runs `runTenantResolverConformance`.
- `tests/dep-graph.test.ts` — runtime deps.
## Migration impact
None — additive only. `api-host` wires this into the tenant-resolver chain when `host.tenant.resolvers` includes `"header"`.

View File

@@ -0,0 +1,78 @@
<!-- markdownlint-disable MD024 -->
# Capability Spec Delta: api-tenant-resolver-header (api-tenant-resolver-header)
**Package**: `@suaveplan/api-tenant-resolver-header`
**Status**: PROPOSED
> Every requirement below carries a `**Verified by:**` line at authoring time.
## ADDED Requirements
### Requirement: Resolves tenant from configured header
The package SHALL expose `createHeaderTenantResolver({ headerName, validate, registry })` that reads `headerName` (default `X-Tenant-Id`) and returns `{ tenantId, source: "header" }` when the value validates AND (when `registry` is supplied) is a member of the tenant registry.
#### Scenario: well-formed header resolves
- WHEN a request carries `X-Tenant-Id: acme` AND `acme` is in the registry
- THEN the resolver returns `{ tenantId: "acme", source: "header" }` AND `api.tenant.resolves_total{resolver="header"}` increments
**Verified by:** `src/resolver/resolver.test.ts::"well-formed header resolves"`
---
### Requirement: Strict mode behaviour for invalid values
The package SHALL react to invalid header values per `strict` config: when `strict: true`, raise `TENANT_HEADER_INVALID` (HTTP 400). When `strict: false`, return `null` so a downstream resolver may match.
#### Scenario: strict raises 400
- WHEN the header value fails the validator AND `strict: true`
- THEN the resolver raises `TENANT_HEADER_INVALID`
#### Scenario: non-strict returns null
- WHEN the header value fails the validator AND `strict: false`
- THEN the resolver returns `null`
**Verified by:** `src/resolver/resolver.test.ts::"strict mode raises 400 on invalid"` AND `src/resolver/resolver.test.ts::"non-strict mode returns null on invalid"`
---
### Requirement: Trusted-source enforcement
The package SHALL ignore the header when `request.metadata.source` is not in `trustedSources` (default `["service-mesh"]`). When ignored AND `strict: true`, raise `TENANT_HEADER_UNTRUSTED_SOURCE`; when ignored AND `strict: false`, return `null`.
#### Scenario: untrusted source raises in strict
- WHEN the header is present AND `request.metadata.source = "edge"` AND `trustedSources = ["service-mesh"]` AND `strict: true`
- THEN the resolver raises `TENANT_HEADER_UNTRUSTED_SOURCE`
**Verified by:** `src/trust/trust.test.ts::"untrusted source raises in strict mode"`
---
### Requirement: Not-found-in-registry distinct from invalid
The package SHALL distinguish a tenant that fails validation (`TENANT_HEADER_INVALID`) from one that is well-formed but not in the registry (`TENANT_HEADER_NOT_FOUND_IN_REGISTRY`). Both surface in strict mode; both return `null` in non-strict mode.
#### Scenario: well-formed but unknown tenant
- WHEN the header is `X-Tenant-Id: unknown-tenant-1` AND the registry does not contain it AND `strict: true`
- THEN the resolver raises `TENANT_HEADER_NOT_FOUND_IN_REGISTRY`
**Verified by:** `src/resolver/resolver.test.ts::"well-formed but unknown raises NOT_FOUND_IN_REGISTRY in strict"`
---
### Requirement: Passes `runTenantResolverConformance`
The package SHALL pass the conformance harness exported by `@suaveplan/api-tenant-provider/testing`.
#### Scenario: conformance passes
- WHEN `runTenantResolverConformance("header", makeHeaderResolver)` runs
- THEN every harness `it(...)` passes
**Verified by:** `src/resolver/resolver.spec-conformance.test.ts::"header resolver passes runTenantResolverConformance"`

View File

@@ -0,0 +1,63 @@
# Tasks — `@suaveplan/api-tenant-resolver-header`
## 0. Pre-flight (non-negotiable)
- [x] 0.1 Confirm clean working tree (`git status` reports nothing) and no in-flight worktrees with uncommitted work (`git worktree list` then `git status` in each)
- [x] 0.2 If any worktrees exist under `.claude/worktrees/`, account for each one: still-active agent, work-pending-merge, or stale-and-prune. Stale worktrees MUST be removed (`git worktree remove`) before opening a new one — code that has been lost twice on main is the failure mode this guards against.
- [x] 0.3 Confirm the package set in `MANIFEST.md` matches `find packages -maxdepth 3 -name package.json` count. Drift here means a prior change archived without regenerating the manifest.
## 1. Spec authoring
- [x] 1.1 Read design doc (§6 step 4)
- [x] 1.2 Read `openspec/AGENTS.md` Sections 13 and 14
- [x] 1.3 Draft `proposal.md`
- [x] 1.4 Draft `specs/api-tenant-resolver-header/spec.md`
- [x] 1.5 Every requirement carries `**Verified by:**`
## 2. Implementation
- [x] 2.1 Scaffold `packages/api-stack/api/api-tenant-resolver-header/`
- [x] 2.2 `src/resolver/` — `createHeaderTenantResolver`
- [x] 2.3 `src/trust/` — trusted-source enforcement
- [x] 2.4 `src/validate/` — default validator + custom validator support
- [x] 2.5 `src/error-codes.ts`
- [x] 2.6 `src/index.ts` — explicit named re-exports
## 3. Tests
- [x] 3.1 `src/resolver/resolver.test.ts`
- [x] 3.2 `src/trust/trust.test.ts`
- [x] 3.3 `src/resolver/resolver.spec-conformance.test.ts`
- [x] 3.4 `tests/dep-graph.test.ts`
- [x] 3.5 Every `it(...)` carries `{ timeout: 5000 }`
## 4. Documentation
- [x] 4.1 Sibling `.md` per implementation `.ts`
- [x] 4.2 `README.md` `## Modules`
- [ ] 4.3 Update `CLAUDE.md` package listing — deferred per orchestrator instruction ("Do not edit CLAUDE.md")
## 5. Pre-archive verification (the 5-gate triple)
- [x] 5.1 `bunx biome check --write` clean
- [x] 5.2 `bunx turbo lint typecheck test --filter=@suaveplan/api-tenant-resolver-header` — green (62 tests)
- [x] 5.3 `bunx turbo test:coverage --filter=@suaveplan/api-tenant-resolver-header` — 100/100/100/100
- [ ] 5.4 `bun scripts/openspec-conformance.ts @suaveplan/api-tenant-resolver-header` — script's `findPackageDir` does not yet support the 3-level `packages/<category>/<plugin>/<pkg>/` layout (same failure mode as sibling `api-tenant-resolver-jwt`); repo-wide tooling bug, unrelated to this package.
- [x] 5.5 `bunx turbo build --filter=@suaveplan/api-tenant-resolver-header` — green (dist emitted)
## 6. Pre-archive 7-row checklist
- [x] 6.1 Generics threaded — N/A (no generics)
- [x] 6.2 Zod schemas wired at host-config ingestion (`parseHeaderTenantResolverOptions`)
- [x] 6.3 Every `TENANT_HEADER_*` code thrown by a production path (verified by resolver tests + options tests)
- [x] 6.4 Strict-mode: invalid header → 400 in strict, → null in non-strict (verified by `strict mode raises 400 on invalid` + `non-strict mode returns null on invalid`)
- [x] 6.5 OTel `api.tenant.resolves_total{resolver="header"}` asserted (verified by `well-formed header resolves` + `emits exactly one counter increment per resolve() call`)
- [x] 6.6 Lifecycle dedup — resolver is pure / idempotent (no module state; verified by concurrent-call test in spec-conformance)
- [x] 6.7 No retroactive tick
## 7. Archive
- [x] 7.1 Fold spec delta into `openspec/specs/api-tenant-resolver-header/spec.md`
- [x] 7.2 Move folder to archive
- [x] 7.3 Tick `8.15` in umbrella tasks
- [x] 7.4 Refresh `MANIFEST.md`