create-warlock 4.2.5 → 4.2.7

package/templates/warlock/skills/module-boundaries/SKILL.md

@@ -0,0 +1,283 @@
+---
+name: module-boundaries
+description: 'Architecture rules for how modules under `src/app/**` relate — each module owns one domain noun (`orders`, `users`, `carts`, `payments`); standard layout per module (`controllers/`, `services/`, `models/<noun>/`, `repositories/`, `schema/`, `resources/`, `types/`, `utils/`, `events/`, `errors/`, `routes.ts`); public surface exposed through sub-folder barrels (`services/index.ts`, `utils/index.ts`, `types/index.ts`) — NEVER a module-root `index.ts` re-exporting everything; no module reaches into another module''s internal files; zero circular dependencies between modules; inter-module communication is explicit — direct service call OR `@mongez/events` bus, never shared mutable globals; cross-cutting helpers live in `src/app/shared/`. Triggers: adding a new module under `src/app/**`; importing from another module; deciding where new code belongs; circular import error; ESLint `import/no-restricted-paths` violation; user asks "can module A use module B''s internals", "how should modules talk", "where should this code live", "I''m getting a circular dependency", "what folders does a module need", "what goes in shared". Skip: intra-module file organization (load `skills/code-standards/SKILL.md` § 4); barrel mechanics within a module (load `skills/code-standards/SKILL.md` § 2.2); deploying / packaging / monorepo questions; framework primitive details — load relevant `@warlock.js/*` skill.'
+---
+
+# Module boundaries
+
+**Status:** Stable
+**Applies to:** Every module under `src/app/**` and every import that crosses between modules.
+
+A module is a unit of substitution. If two modules are tangled, you can't refactor either without touching both. These rules keep modules independent enough that any one can be rewritten, extracted, or deleted with a contained blast radius.
+
+> **Sub-agent rule:** Before adding a new module or importing across modules, read this file.
+
+---
+
+## 1. One domain noun per module
+
+### 1.1 The rule
+
+A module is named after the noun it owns: `users`, `orders`, `carts`, `payments`, `ai-models`, `chats`. Lowercase, kebab-case, plural.
+
+### 1.2 If the name needs an "and", split it
+
+`orders-and-payments/` is two modules. So is `users-and-auth/`. Each gets its own folder.
+
+### 1.3 Cross-cutting concerns live in `shared/`
+
+Auth helpers, logging adapters, enum definitions, router utilities — anything used by more than one domain module — lives in `src/app/shared/`. The existing `src/app/shared/{enums.ts, get-random-color.ts, locales.ts, router.ts, ...}` is the pattern.
+
+### 1.4 Match modules to domain boundaries
+
+If the business has an "orders team" and a "payments team", you probably have an `orders` module and a `payments` module — not one `commerce` module. Module boundaries should mirror who owns the code and who gets paged when it breaks.
+
+---
+
+## 2. Standard module layout
+
+Every module follows this folder shape. Not every folder is required — only the ones the module actually uses.
+
+```
+src/app/<module>/
+  controllers/              ← HTTP handlers (one per endpoint)
+    <verb>-<noun>.controller.ts
+  services/                 ← business logic (one per use case)
+    index.ts                ← sub-folder barrel ✅
+    <verb>-<noun>.service.ts
+  models/
+    <noun>/                 ← model folder (Cascade convention)
+      <noun>.model.ts
+      index.ts
+      migrations/
+        <timestamp>-<noun>.migration.ts
+  repositories/             ← Cascade RepositoryManager subclasses
+    <nouns>.repository.ts
+  schema/                   ← seal schemas (v.object + Infer<>), value + type per file
+    <verb>-<noun>.schema.ts
+  resources/                ← output mappers (defineResource)
+    <noun>.resource.ts
+  types/                    ← TypeScript types and enums
+    index.ts                ← sub-folder barrel ✅
+    <noun>-status.type.ts
+  utils/                    ← pure helpers used inside the module
+    index.ts                ← sub-folder barrel ✅
+    <verb>-<noun>.ts
+  events/                   ← if the module emits events
+    <noun>-<verb>.event.ts
+  errors/                   ← custom error classes
+    <noun>-not-found.error.ts
+  routes.ts                 ← the module's route registrations
+  README.md                 ← module purpose, public surface, ownership
+```
+
+### 2.1 Empty folders are fine to omit
+
+Don't create `events/` if the module emits nothing. Don't create `errors/` until you have an error to put there. The layout is a vocabulary, not a checklist.
+
+### 2.2 No module-root `index.ts`
+
+This is the one absolute rule:
+
+```
+❌ src/app/orders/index.ts                ← banned
+✅ src/app/orders/services/index.ts        ← good (sub-folder barrel)
+✅ src/app/orders/utils/index.ts           ← good
+✅ src/app/orders/types/index.ts           ← good
+```
+
+See `skills/code-standards/SKILL.md` § 2.2 for the reasoning.
+
+---
+
+## 3. Public vs private surface
+
+### 3.1 Public (importable from other modules)
+
+- `src/app/<module>/services` (the sub-folder barrel)
+- `src/app/<module>/utils` (the sub-folder barrel)
+- `src/app/<module>/types` (the sub-folder barrel)
+- `src/app/<module>/resources/<noun>.resource.ts`
+- `src/app/<module>/models/<noun>` (the model folder — for `BelongsTo("Name")` registrations and typed references)
+- `src/app/<module>/errors/<noun>-<reason>.error.ts`
+
+### 3.2 Private (not importable from other modules)
+
+- `src/app/<module>/controllers/*` — controllers serve HTTP; nobody else should call them
+- `src/app/<module>/repositories/*` — repositories are a service-internal detail; other modules go through services
+- `src/app/<module>/schema/*` — schemas belong to the endpoint that uses them
+- `src/app/<module>/routes.ts` — registers routes for the framework, nobody imports it
+
+### 3.3 Enforce with ESLint
+
+Add `eslint-plugin-import/no-restricted-paths` rules:
+
+```js
+// eslint.config.js — proposed addition
+{
+  rules: {
+    "import/no-restricted-paths": ["error", {
+      zones: [
+        { target: "src/app/*/controllers", from: "src/app/*/controllers", except: ["./"] },
+        { target: "src/app", from: "src/app/*/repositories", except: ["./*/services"] },
+        { target: "src/app", from: "src/app/*/schema", except: ["./*/controllers"] },
+      ],
+    }],
+  },
+}
+```
+
+The exact rule shape depends on the eslint config — but the principle is: cross-module imports go through services / utils / types / resources / models / errors, never through the private folders.
+
+---
+
+## 4. No reaching across module internals
+
+```typescript
+// ✅ public surface — the module's barrel
+import { listUsersService } from "app/users/services";
+
+// ✅ public — a typed type
+import { type User } from "app/users/types";
+
+// ✅ public — model class for relations
+import { User } from "app/users/models/user/user.model";
+
+// ❌ private — repository is service-internal
+import { usersRepository } from "app/users/repositories/users.repository";
+
+// ❌ private — controller is HTTP-internal
+import { listUsersController } from "app/users/controllers/list-users.controller";
+```
+
+If you find yourself needing another module's internals, the boundary is wrong. Either:
+
+- The internal API should be promoted to public (add a service that exposes it).
+- The functionality belongs in `shared/`.
+- The two modules should be merged.
+
+---
+
+## 5. Zero circular dependencies
+
+### 5.1 What a cycle looks like
+
+`app/orders` imports `app/users/services`, and `app/users` imports `app/orders/services`. Even one level deep, this is a cycle.
+
+### 5.2 Why it's banned
+
+- Runtime import-order bugs that only surface in production
+- Refactor blast radius: changing either module forces changes in both
+- Module-level reasoning breaks down — you can't think about either in isolation
+
+### 5.3 The fix
+
+Almost always: extract the shared concept into a third module.
+
+```
+❌  orders ↔ users        (cycle)
+✅  orders → users-shared  ← shared types / events
+    users  → users-shared
+```
+
+Or, if the shared concept is purely cross-cutting (not a domain), it goes to `app/shared/`.
+
+### 5.4 Detect in CI
+
+`eslint-plugin-import/no-cycle` catches cycles at lint time. Enable it.
+
+---
+
+## 6. Inter-module communication
+
+### 6.1 Direct call — when you need a result
+
+`app/orders` needs the user's name to format an order confirmation: import `getUserService` from `app/users/services`, call it, use the result.
+
+This is the default. Most inter-module communication is direct calls.
+
+### 6.2 Event bus — when you don't need a result
+
+`app/orders` finishes placing an order; `app/notifications` wants to send a confirmation email; `app/analytics` wants to log the event. None of those need to block the order-placement flow, and orders shouldn't know about either.
+
+Use `@mongez/events`:
+
+```typescript
+// ✅ orders module emits
+import { events } from "@mongez/events";
+events.trigger("order.placed", { orderId, userId });
+
+// ✅ notifications module listens
+events.subscribe("order.placed", async ({ orderId, userId }) => {
+  await sendOrderConfirmationEmail(userId, orderId);
+});
+```
+
+### 6.3 Pick rule
+
+- "I need a result" → direct service call
+- "Interested parties may want to know" → event
+- "I need both" → direct call for the result + emit event for the others
+
+### 6.4 Never shared mutable globals
+
+```typescript
+// ❌
+// app/orders/state.ts
+export let currentOrderCount = 0;
+
+// app/dashboard/services/get-stats.service.ts
+import { currentOrderCount } from "app/orders/state";
+```
+
+Top-level mutable exports across modules are the worst kind of coupling — invisible, untyped, untestable. Always go through a service or an event.
+
+---
+
+## 7. Where shared code lives
+
+| If the code is...                       | Put it in                                     |
+| --------------------------------------- | --------------------------------------------- |
+| Used by 2+ modules, stable, cross-domain | `src/app/shared/`                            |
+| Used by 2+ modules, domain-specific      | Extract a new domain module                   |
+| Used by exactly 1 module                 | Stays inside that module's `utils/`           |
+| Third-party integration glue (SDK wrappers) | `src/app/shared/` (or a dedicated module)  |
+| Build-time config                        | `src/config/` (one file per concern)          |
+
+### 7.1 Promotion to `shared/` is a deliberate choice
+
+If a util is duplicated across two modules, that's a signal — but the right answer isn't always "move to shared". Sometimes the two utils have drifted intentionally; sometimes one module is about to absorb the other. Promote only when the abstraction is genuinely stable.
+
+### 7.2 `shared/` is not a junkyard
+
+Every file in `shared/` has a clear single purpose. If `shared/utils/` grows past ~20 files, split it by concern (`shared/strings/`, `shared/dates/`, etc.) before it becomes the codebase's attic.
+
+---
+
+## 8. Adding a new module — the checklist
+
+When you create a new module:
+
+1. **Pick the noun.** Single domain concept. Lowercase, kebab-case, plural.
+2. **Create the folder.** `mkdir src/app/<noun>`.
+3. **Add `README.md`** at the module root. One paragraph: what the module owns, who owns the code, public surface.
+4. **Scaffold only what you need.** Don't pre-create `events/` and `errors/` if you won't use them today.
+5. **Add sub-folder barrels** only where you have 2+ files. A single service doesn't need a `services/index.ts` yet — but it will the moment a second service lands.
+6. **Wire `routes.ts`** for any HTTP endpoints, register events for any emitted signals.
+7. **Verify no module-root `index.ts`** was created.
+
+---
+
+## 9. Review checklist
+
+Before merging a change that adds, restructures, or imports across modules:
+
+- [ ] New module is named after a single domain noun
+- [ ] Standard folder layout from § 2 (only the folders the module needs)
+- [ ] No module-root `index.ts` created
+- [ ] Sub-folder barrels exist for `services/`, `utils/`, `types/` where applicable
+- [ ] No imports from another module's `controllers/`, `repositories/`, `schema/`
+- [ ] No circular imports between modules (ESLint `no-cycle` clean)
+- [ ] Cross-module communication uses direct service call or `@mongez/events` — never shared mutable globals
+- [ ] Shared code that's used by 2+ modules lives in `src/app/shared/`, not duplicated
+- [ ] Module has a `README.md` describing purpose, public surface, and ownership

package/templates/warlock/skills/observability-and-resilience/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: observability-and-resilience
+description: 'How this project stays debuggable in production and survives flaky dependencies — `log.<level>(module, action, message, context)` from `@warlock.js/logger` with `X-Request-Id` propagation (already shipped via core middleware), structured metrics naming `<area>.<noun>.<unit>`, health endpoints (`/health/live` for liveness vs `/health/ready` for readiness), timeouts on every external call (`@warlock.js/http` `timeout` per Http instance / per request), retries with exponential backoff for idempotent ops only (never auto-retry POST without an idempotency key), idempotency keys for side effects (payments, emails, webhook deliveries), circuit breakers for flaky deps, graceful shutdown via `log.configure({ autoFlushOn: ["SIGINT", "SIGTERM", "beforeExit"] })`, N+1 detection, streaming for large payloads. Triggers: making an HTTP / AI / queue / DB call; adding a timeout or retry; designing an idempotency key for a side effect; instrumenting metrics; adding a health check; tracing a request across services; user asks "timeout", "retry policy", "idempotency", "request id", "tracing", "graceful shutdown", "health check", "circuit breaker", "N+1 query", "caching strategy", "metrics naming"; touching `@warlock.js/http` / `@warlock.js/scheduler` / `@warlock.js/ai` call sites. Skip: log call signature (load `skills/code-standards/SKILL.md` § 8); secrets in logs (load `skills/security-baseline/SKILL.md` § 8); pure-function refactors with no external I/O; cache driver setup (load `@warlock.js/cache` skills); HTTP client config in depth (load `@warlock.js/http` skills).'
+---
+
+# Observability & resilience
+
+**Status:** Stable
+**Applies to:** Every external call, every long-running operation, every production process.
+
+Without observability you debug by guessing. Without resilience one slow dependency takes the whole service down. These rules cost a few extra lines per call site and save days of incident response.
+
+> **Sub-agent rule:** Before making any external call or designing a long-running operation, read this file.
+
+---
+
+## 1. Request ID propagation
+
+### 1.1 One ID per request
+
+The framework's `@warlock.js/core` HTTP middleware already attaches an `X-Request-Id` header — honoured if the client sent one, generated if not. The same id is echoed back in the response and available to every log call within the request's lifetime.
+
+### 1.2 Include it in every log line
+
+Inside a request, pass the request id as part of the log context:
+
+```typescript
+// ✅
+log.info("orders", "order-placed", "Order created", {
+  orderId,
+  userId,
+  requestId: request.id,
+});
+```
+
+Without it, debugging a production incident is archaeology — you can't correlate the upstream log line with the downstream failure.
+
+### 1.3 Propagate downstream
+
+When this service calls another service or a third-party API, forward the request id as `X-Request-Id` on the outgoing call. The full trace is what makes distributed debugging possible.
+
+---
+
+## 2. Timeouts
+
+**Every external call has an explicit timeout.** No exceptions.
+
+### 2.1 HTTP — `@warlock.js/http`
+
+Set a default at the `Http` instance level; override per request when the endpoint legitimately needs more.
+
+```typescript
+// ✅ instance-level default
+const stripeClient = new Http({
+  baseURL: "https://api.stripe.com",
+  timeout: 10_000,  // 10s — enough for most calls, short enough to fail fast
+});
+
+// ✅ per-request override for a known-slow call
+await stripeClient.post("/v1/payouts/preview", body, { timeout: 30_000 });
+```
+
+### 2.2 AI calls
+
+AI calls run longer than typical HTTP. Use the per-provider defaults from `@warlock.js/ai` adapters and override per call when streaming a known-large completion. Never leave AI calls without a timeout — a hung model = a wedged worker.
+
+### 2.3 Database queries
+
+Driver-level timeout (set in `config/database.ts`) + per-statement timeout for known-expensive queries. A 30-second query lock kills concurrency under load.
+
+### 2.4 Queue ops
+
+Set the visibility timeout to match the expected processing time of the message — long enough that the handler finishes, short enough that a crashed worker doesn't park the message for hours.
+
+### 2.5 Why this matters
+
+A dependency that hangs without timing out is worse than a dependency that errors. Errors are visible; hangs eat workers silently until the pool is empty and the service stops responding.
+
+---
+
+## 3. Retries
+
+### 3.1 Retry only idempotent ops
+
+- **Safe to retry**: `GET`, `PUT`, `DELETE`, reads, lookups, queries
+- **Never auto-retry**: `POST` without an idempotency key, queue ops without dedup, payment charges
+
+A naive retry on a failed payment charge double-charges the customer. Don't.
+
+### 3.2 Exponential backoff with jitter
+
+A retry storm against a recovering service brings it down again. Backoff with jitter spreads the load:
+
+```
+attempt 1 → fail
+wait 100ms ± 50ms
+attempt 2 → fail
+wait 250ms ± 100ms
+attempt 3 → fail
+wait 600ms ± 200ms
+```
+
+### 3.3 Bounded
+
+Max retries: small (3–5). Past that, surface the failure to the caller and let them decide. Infinite-retry-with-backoff is just a slower hang.
+
+### 3.4 Retry budget
+
+When a dependency is clearly down (sustained failure rate > 50% over 30s), stop retrying entirely and fast-fail. See § 5 circuit breakers.
+
+---
+
+## 4. Idempotency keys
+
+### 4.1 What needs one
+
+Any operation whose accidental retry would cause real-world harm:
+
+- Payment charges, refunds, payouts
+- Outbound emails, SMS, push notifications
+- Webhook deliveries
+- Third-party POSTs that mutate state
+
+### 4.2 Key generation
+
+- **Server-internal calls**: generate the key at the call site (UUID / nanoid), store it.
+- **Client-originated mutations** (e.g. "place order" from a mobile app): the client generates the key and sends it as a header (`Idempotency-Key`); the server stores `key → result`.
+
+### 4.3 Storage
+
+Persist `key → result` with a TTL longer than your retry window (24h is typical). On retry with the same key, return the stored result without re-executing.
+
+### 4.4 Pattern
+
+```typescript
+// ✅
+export async function chargePaymentService(input, idempotencyKey) {
+  const cached = await idempotencyRepository.find({ key: idempotencyKey });
+  if (cached) {
+    return cached.result;
+  }
+
+  const result = await stripeClient.post("/v1/charges", input);
+  await idempotencyRepository.create({ key: idempotencyKey, result, expiresAt: in24h });
+
+  return result;
+}
+```
+
+---
+
+## 5. Circuit breakers
+
+### 5.1 When to add one
+
+For any dependency that's flaky enough that retries alone aren't enough — typically third-party APIs, edge services, anything outside your operational control.
+
+### 5.2 States
+
+- **Closed** — normal operation, calls pass through.
+- **Open** — failure rate exceeded threshold; calls fail fast without hitting the dependency.
+- **Half-open** — after a cooldown, allow a few calls through to probe recovery.
+
+### 5.3 Fallback behaviour
+
+When the breaker is open, the call site needs a plan:
+
+- Return a cached value (if the data is cacheable)
+- Queue for later (if the operation can wait)
+- Fail-fast to the user (if neither — at least the user knows immediately)
+
+Never silently swallow.
+
+---
+
+## 6. Health checks
+
+### 6.1 Two endpoints, two semantics
+
+- **`/health/live`** — liveness. Is the process alive? Almost always returns 200; the only way it returns non-200 is if it's about to crash anyway. Used by the orchestrator to decide whether to kill and restart.
+- **`/health/ready`** — readiness. Can the process serve traffic? Checks DB connectivity, queue connectivity, warm-up completion. Used by the load balancer to decide whether to route traffic.
+
+### 6.2 Don't conflate them
+
+Returning 503 from `/health/live` because the DB is down causes the orchestrator to restart the process — which doesn't fix a DB problem and adds restart-loop chaos to an outage. Use `/health/ready` for "I can't serve right now" so the LB drains traffic without the orchestrator interfering.
+
+### 6.3 No internal details leaked
+
+Health endpoints return a status code, not internal version info, env names, dependency hostnames, or stack traces. Those are information leaks under a different name.
+
+---
+
+## 7. Metrics
+
+### 7.1 Three primitive types
+
+- **Counter** — things that happened, monotonically increasing (`orders.placed.total`, `auth.login.failed.total`)
+- **Gauge** — current value (`queue.depth`, `connections.active`, `cache.size_bytes`)
+- **Histogram** — distribution (`http.request.duration_ms`, `ai.completion.tokens`)
+
+### 7.2 Naming — `<area>.<noun>.<unit>`
+
+Match the log `module` / `action` convention. The metric `orders.placed.total` corresponds to the log call `log.success("orders", "order-placed", ...)`. Symmetry across observability surfaces makes incidents debuggable.
+
+### 7.3 Cardinality discipline
+
+**Never** include high-cardinality values as labels: user-id, request-id, order-id, email. Each unique value creates a new metric series; a million users = a million series = your monitoring backend's invoice goes vertical.
+
+Use logs for high-cardinality data, metrics for aggregates.
+
+### 7.4 What to instrument
+
+Start with the four golden signals:
+
+- **Latency** — `http.request.duration_ms` histogram, by route
+- **Traffic** — `http.requests.total` counter, by route + status
+- **Errors** — `http.requests.errors.total` counter, by route + error class
+- **Saturation** — queue depth, connection pool usage, memory
+
+Add business metrics on top (`orders.placed.total`, `revenue.cents.total` — taking care with cardinality).
+
+---
+
+## 8. Graceful shutdown
+
+### 8.1 The sequence
+
+SIGTERM (or SIGINT) →
+
+1. Stop accepting new requests / new queue messages (close the listeners).
+2. Finish in-flight work with a hard timeout (30s typical).
+3. Flush logs.
+4. Close DB / external connections cleanly.
+5. Exit 0.
+
+### 8.2 Logger flush
+
+`@warlock.js/logger` covers step 3 when you configure it correctly:
+
+```typescript
+// ✅ config/log.ts (or equivalent boot file)
+log.configure({
+  channels: [/* ... */],
+  autoFlushOn: ["SIGINT", "SIGTERM", "beforeExit"],
+});
+```
+
+Without `autoFlushOn`, buffered log entries are lost on shutdown — exactly when you most want them.
+
+### 8.3 The hard timeout matters
+
+If in-flight work doesn't finish in 30s, kill it anyway. The alternative is hanging forever waiting for one stuck request, which makes deploys / restarts unreliable.
+
+---
+
+## 9. Performance defaults
+
+These belong here because performance failures present as resilience failures — a slow query starves the pool, a missing index turns a 10ms call into a 5-second call, an unbounded list returns 50k rows and OOMs the response serializer.
+
+### 9.1 N+1 queries are bugs, not warnings
+
+A list endpoint that fires one query per item is a bug. Either eager-load relations (Cascade's `.with("relation")`) or batch-fetch the related ids in a single query and join in-process.
+
+A code review that lets an N+1 through is doing its job poorly. Add it to the review checklist (already in `skills/api-design/SKILL.md`).
+
+### 9.2 Pagination always
+
+See `skills/api-design/SKILL.md` § 3. No unbounded list ever, even if today's dataset is 12 rows.
+
+### 9.3 Stream large payloads
+
+For responses > 1MB or uploads > 1MB, stream end-to-end. Never buffer a 50MB file into memory to send it.
+
+### 9.4 Cache invalidation strategy
+
+Pick one and stick to it per surface:
+
+- **TTL** — simplest; tolerable staleness for a fixed window. Good for read-mostly catalog data.
+- **Write-through** — invalidate on the corresponding write. Good for user-owned data where staleness is visible.
+- **Event-driven** — invalidate on a published event. Good across multiple services.
+
+`repository.listCached(...)` exists for hot read paths — use it where the dataset changes rarely. Invalidate on the corresponding write through the repository's hooks.
+
+### 9.5 No sync I/O on the request path
+
+`readFileSync`, `execSync`, sync DB drivers — all banned in handler code. They block the event loop and crater throughput under load.
+
+---
+
+## 10. Review checklist
+
+Before merging a change that touches an external call, long-running op, or production wiring:
+
+- [ ] Request id propagated in every log line within the request lifecycle
+- [ ] External call has an explicit timeout (HTTP, AI, queue, DB)
+- [ ] Retries only on idempotent ops; non-idempotent ops have an idempotency key
+- [ ] Idempotency keys persisted with a TTL longer than the retry window
+- [ ] Circuit breaker considered for any flaky third-party dependency
+- [ ] Health endpoints split — `/health/live` separate from `/health/ready`
+- [ ] No high-cardinality values (user-id, request-id) as metric labels
+- [ ] Metric names follow `<area>.<noun>.<unit>`, mirror log `module.action`
+- [ ] `log.configure({ autoFlushOn: ["SIGINT", "SIGTERM", "beforeExit"] })` set
+- [ ] No N+1 introduced — relations eager-loaded or batched
+- [ ] No unbounded list endpoint
+- [ ] No sync I/O on the request path
+- [ ] Cache invalidation strategy declared for any new cache surface